Hello Framapadist (et bienvenue par ici).
Un peu d'histoire, tout d'abord.
<ma vie>A la base, j'avais créé les WebApps pour une copine (Cécile, si tu lis un jour ce message... c'est que vraiment t'es perdu sur le web) qui voulait "essayer SPIP", qui avait téléchargé le .zip et dézippé sur son XP, et qui pestait que ça ne fonctionnait pas lorsqu'elle cliquait sur "index.php". (ben oui, forcément, ça ouvrait le notepad).
Je me suis dit que je pouvait coller un serveur web + php/mysql + une appli web dans un même dossier, et y ajouter une petite interface pour lancer le tout dans le bon ordre.
Quelques heures de développement avec les pieds plus tard (je suis économiste à la base, moi, pas développeur), les WebApps étaient nées.</ma vie>
Ce qu'il faut tirer de cette histoire ?
1. les webapps ont été conçues dans le but de tester les applications web, plus que pour l'auto-hébergement
2. quand je développe un truc, mieux vaut m'en empêcher, parce que suivant la bonne vieille
loi de Pareto, je fais sans probleme les 80% du taf, mais je laisse à d'autres le soin de gérer les 20% restants (fainéantise et procrastination inside).
Donc, revenons à ta question sur l'auto-hebergement.
* Est-ce possible ? Oui.
* Est-ce souhaitable ? Pas forcément.
Je ne suis pas expert en réseau (je vous ai déjà dit que j'avais une formation d'économiste ? Suivez, un peu
), mais dans 95% des cas, les gens vont lancer leur webApp sur un réseau local, chez eux ou dans leur petite entreprise.
Or, l'accès à internet dans ces cas là se fait souvent derriere une "box" (freebox, neufbox, machinbox, onsantapbox).
Et ces boxes permettent à l'ordinateur hébergeant la webapp d'aller chercher des infos sur le web et de les ramener (ex: Firefox demande
http://www.framasoft.net, ça sort par la box, transite par les DNS de mon FAI, arrive sur le serveur qui héberge Framasoft.net, dont le Apache fournit le code HTML et renvoi le tout via http à l'ordinateur qui en a fait la demande).
Par contre, sauf configuration spéciale, ces boxes
interdisent à une machine externe de passer à travers elles pour aller demander une info qui n'a pas été spécifiquement demandée.
Autrement dit, tu peux imaginer ça comme un immeuble dont les locataires peuvent sortir aller se chercher à bouffer, mais où aucun étranger ne peut rentrer (de là à dire que les boxes sont racistes...
)
Or le principe d'une webApp, c'est d'avoir un serveur web qui attend qu'on le contacte pour servir des pages web. En clair, un immeuble ouvert à tous.
Cela n'est pas recommandé pour le grand public. Imaginons qu'une faille (dans la webApp dotclear) permette à un utilisateur mal-intentionné de lire/ecrire des fichiers sur la machine hébergeant dotclear, ça signifierait qu'un "étranger" pourrait lire/écrire des infos sur une machine perso. Pas bon.
Donc, quand tu lance une webapp, celle-ci est accessible avec l'adresse 127.0.0.1 (qui est l'adresse réservée à la machine "localhost", on pourrait dire "l'appartement"), mais aussi par son adresse IP de ta machine attribuée par la box. Le plus souvent une adresse en 192.x.x.x qui correspond au réseau local (en gros "l'intérieur de l'immeuble"). Mais ton adresse publique, celle de l'immeuble lui même, il y a un bon gros videur à la porte (ta box), et il ne laissera personne visiter les appartements sans autorisation.
Par contre, dans un petit réseau (domestique ou entreprise), il est possible que ta webApp soit accessible directement aux autres locataires de l'immeuble (= l'ordi du salon peut accéder à la webapp lancée sur l'ordi de la chambre).
Tu peux, dans ta confirguration de ta box, autoriser les connexions depuis l'exterieur (il faut modifier les parametres "routeur" de cette derniere, le plus souvent), mais ce n'est à mon avis pas souhaitable pour deux raisons :
1. les possibilités de hacking dont je parlais plus haut
2. les webapps sont conçues pour fonctionner sur Windows, justement sans rajouter de couches de sécurité (= ton serveur web tourne avec les droits du l'utilisateur en cours), ce qui n'est pas un moyen stable et sûr de faire tourner une application web.
De plus, une personne sachant faire ces modifs devrait être suffisamment compétent pour installer sa webapp sur un serveur distant.
Alors que faire ?
Au départ, à la conception des WebApps, j'avais pensé à un systeme (pas si délirant que ça) qui permettrait, d'un simple clic, de mettre en ligne le contenu de la webapp sur un serveur distant.
En clair, tu aurais eu une option "Mettre en ligne et synchroniser" dans le menu WebApp, ça aurait ouvert une fenêtre où on t'aurait demandé "Paramètres FTP et MySQL" d'un hebergeur distant, et on aurait poussé le tout en ligne.
Cet hébergeur distant aurait aussi bien pu être un espace toto.free.fr, une machine chez OVH, ou (c'etait mon objectif) une machine gérée par Framasoft.
Techniquement, ce n'est pas tres compliqué, mais ça réclamait de le faire bien proprement, sinon les données auraient pu se perdre facilement (= utilisateurs pas contents), et je n'ai jamais trouvé le temps.
Par ailleurs, Framasoft s'est lancé dans différents projets, notamment "Framacloud/Framatools" qui vise justement à promouvoir l'autohebergement. Pour l'instant, il y a
http://framadate.org et
http://framapad.org, qui sont des "clones" de Doodle et d'Etherpad, mais d'autres devraient suivre sous peu (framatube, framatalk, framadocs, etc).
Ces services dont mis gratuitement à la disposition du public par Framasoft, d'abord pour sortir d'un "cloud privé" où vos données person sont exploitées, mais à moyen terme (fin d'année), on essaiera de rendre ça bien plus cohérent en proposant une page vantant les mérites de la décentralisation et de l'auto-hebergement. En clair, il sera possible d'utiliser l'appli mise en place par Frama*, mais il sera clairement indiqué comment mettre en place cette même application pour son usage perso. Soit sur sa machine perso, soit chez un hebergeur de votre choix.
Là encore, ça réclame du temps (les journées ne faisant que 24H), mais ça progresse...
Voilà, désolé pour ce long message, mais j'espère que les contraintes (et les objectifs) te paraitront plus clairs...