Ce mot est à la mode aujourd'hui, et c'est plutôt “in” d'avoir son petit lot de données dans le Cloud ( prononcer “Klaoud” ). Le cloud représente cet espace virtuel qu'est l'internet applicatif. Il contient donc des applications web, mais également les données privées des utilisateurs. Le terme ( nuage en français ) fait allusion à la nature polymorphe, en constante évolution, et excentrée qu'est censée avoir le réseau.

Dans la réalité, du fait d'un monopole de certaines firmes, le cloud comporte quand même bien des centres stratégiques, qui sont autant de points de faiblesse quant à la neutralité du réseau. D'une part parce que ces firmes qui disent offrir un service “gratuit” troquent souvent vos données “anonymisées”/libertés contre des revenus, et que leurs conditions d'utilisation n'offrent aucune garantie quant au caractère privé de vos données. Certes, la plupart de celles-ci offrent l'assurance que vos données ne feront l'objet d'aucun…etc. Seulement dans la plupart des cas, si vous vous amusez à lire les conditions d'accès à un service, la dernière close stipule que toutes ces conditions peuvent être modifiées, toute garantie peut être annulé, du jour au lendemain et sans engager la responsabilité du service. Bon. Si Google décide de facturer demain l'utilisation de Gmail, vous serez près à payer pour récupérer vos mails en otage ?

C'est extrême et peu probable comme exemple, mais ça permet de réaliser les enjeux et l'intérêt de mettre en place ses propres services et d'avoir son propre serveur. Vous créez votre morceau de nuage, et vous contribuez en même temps à décentraliser/neutraliser le réseau. Aujourd'hui avoir l'équivalent de picassa, gmail, deezer, etc sur votre propre serveur est on ne peut plus aisé. Et vous restez maître à la fois de vos données et de l'accès à celles-ci.

Aujourd'hui, la plupart des applications web s'installent assez simplement grâce à une interface web. En général donc, on dépose les fichiers de l'applications sur son ftp, on change les permissions sur le dossier pour pouvoir l'exécuter et puis on se rend sur la page d'installation avec un navigateur web. De là, il faut dans la plupart des cas fournir un nom d'utilisateur et un mot de passe mysql pour que l'application ait accès à la base de données, et d'autres informations en fonction de l'application.

Il existe deux moyens de rapatrier les fichiers sur notre serveur :

• Avec la ligne de commande : on télécharge le fichier dans un dossier sur le serveur et on le décompresse.
• Par ftp : on passe alors par une machine tiers sur laquelle on procède au téléchargement et à la décompression, puis on envoie les fichiers sur le serveur via un client ftp. Cette méthode est plus fastidieuse et demande au moins deux fois plus de bande passante, mais si on a pas d'accès SSH ou Webmin, c'est celle qu'il faudra utiliser.

Je ne décrirais que la première, puisque la deuxième est assez simple pour tenir en quatre lignes.

Accédez à la ligne de commande sur votre serveur, en vous connectant par SSH ou via l'interface de Webmin ( “Autres”

>"Commandes Shell" ) :

• Récupérer l'archive de l'application : <code bash> wget -P /chemin/du/dossier/ http://urldufichier/archive.tar.gz </code>