De mon utilisation de CozyCloud

Contexte

J’amasse des données depuis 1996. Ce n’est pas que je n’avais de données avant mais plutôt que le système que j’utilisais  est devenu inutilisable et que les sauvegardes l’étaient aussi. Je ne dirai pas que je suis devenu un obsédé de la sauvegarde. J’ai un NAS à la maison pour les sauvegardes et des serveurs dédiés que je transforme en VPS. Avoir des doublons ne m’inquiète pas. En revanche, amasser c’est bien mais il faut pouvoir retrouver ce que l’on recherche.

J’ai une approche tout est document : une conversation par messagerie est autant un document que les vieux documents PDF ou LaTeX qui trainent. Pour les documents web j’ai utilisé Annotea un certain temps mais le projet a perdu d’intérêt avec son absence d’implémentation suivie. Pour les vidéos j’utilisais du smil. Pour les livres et les recettes je me suis tourné vers des français (TEA, Open Food System – plus d’actualité depuis juin 2015) qui avaient promis des formats dédiés au stockage et au partage. Les promesses n’ont pas été tenues.

Bref, c’est faisable pour un poste fixe mais pénible à configurer et à maintenir. Le partage se fait avec des moyens classiques comme Seafile mais rien d’intégré. La récolte des documents est manuelle. C’est aussi compliqué à consulter à distance. Ce n’est pas l’outil que l’on peut installer en douce à la fin d’une install party pour booster l’acceptation de Linux avec des fonctionnalités cools.

La recherche

J’ai une forte habitude des systèmes de gestion de contenu et des grands frères pour entreprises. J’aurai pu monter mon propre outil mais je cherchais une approche plus novatrice. J’ai testé des outils comme Marmotta qui sont axé sur l’enrichissement mais peu pratique pour la navigation et le partage ou Seafile trop axé sur le partage et pas sur l’enrichissement.

Je me suis tourné vers les boîtes à outils du cloud avec 0wncloud et quelques autres. Le LAMP à plutôt tendance à me faire fuir : ce que l’on gagne en légèreté sur le serveur se paie lourd en nécessité de réinventer sans cesse la roue ou de gérer des dépendances de 5 lignes (cela vaut aussi pour l’écosystème Node.js).

Puis une startup a proposé de tenir un stand et une conférence sur l’outil qu’elle développait aux JDLL 2012. J’ai rencontré les développeurs et le concept m’a séduit. Tout le contenu des applications est stocké dans une base orientée document qui est synchronisable facilement. Pour commencer, j’ai testé dans une virtualbox pour évaluer l’installation et les besoins du serveur. Je ne le recommande pas : ce n’est pas utilisable en production et les limites que j’ai rencontré étaient celle de ma VM.

Installation et import des données.

J’ai choisi le mode facile avec un VPS et une image préinstallée. Quelques clics et ça démarre avec l’offre la plus basse (2Go RAM et 10Go SSD). Il a ensuite fallu que je fasse les mise-à-jour système et serveur car l’image n’était pas de première jeunesse. Un petit tour sur IRC a suffit pour mes quelques interrogations. Tout fonctionnait.

Le premier import proposé est celui- des données Google. En dehors des contacts et d’un agenda je n’y stocke rien. Ce fut un peu lent mais sans problème. En revanche, un compte IMAP me servant d’archive a mis en évidence plusieurs points gênant pour le grand public :

• L’import est lent. Vraiment. Et il n’y a pas de jauge permettant d’estimer l’avancement du processus.
• 2Go de RAM ce n’était pas assez. En fait si, mais c’est la consommation moyenne de mon instance sans compter le système. Donc ça swap (cf point précédent).
• C’est de l’IMAP, l’import a repris à chaque redémarrage en tâche de fond (cf points précédents)

Au bout de deux jours j’ai regardé les logs système avec un développeur pour convenir que mon instance VPS était trop juste (j’utilisais le swap et je remplissais 95M de l’espace disque). Il m’a fallu attendre la fin de l’import de ce compte pour faire un nettoyage de la base (je suis redescendu à 80% d’occupation disque) et un passage à l’option supérieure du VPS. Pour le coût, je suis vraiment au large maintenant pour le prix d’un petit serveur dédié.

J’ai ensuite configuré 2 Rapsberry Pi pour avoir des instances secondaires locales en cas de besoin et l’application fonctionne bien pour android 7.0 depuis sa version 2.2. Les versions précédentes fonctionnaient bien avec android 6. La version desktop semble fonctionner.

J’ai encore eu quelques soucis sans doute liés à l’image VPS d’origine qui sont rentrées dans l’ordre avec l’aide des développeurs.

Les avantages et inconvénients de CozyCloud

En dehors de l’aspect synchronisation fort sympathique, Cozy Cloud c’est surtout un environnement de développement d’applications. Le but de ces application n’est pas la manipulation des données mais le stockage et, bientôt, l’enrichissement.

Je n’ai plus besoin d’aller télécharger mes factures chez mes fournisseurs, une application s’en charge. Les données de mon smartphones sont sauvegardées. Pour ma veille journalière je peut conserver un lien ou l’article complet. Une petite appli IRC (il manque du XMPP ;). Pour les mises-à-jour je reçoit les notifications via l’application android puis il suffit d’un clic. Petite ombre : pour importer mes flux OPML de Newsblur vers ZeroFeeds il m’a fallu rajouter l’extension ‘.opml’ au fichier. En revanche, pour mes projets collaboratifs j’utilise Taiga et Kallithea. Ce sont des données hors de la sphère personnelle.

À ce stade c’est l’outil idéal qui fait ce dont on a besoin et dont on oublie la complexité. Mais… non, en fait on oublie pas la complexité. Une application demande une installation manuelle dans le système (l’image VPS mal installée) et lorsqu’une erreur survient c’est vraiment galère de trouver les logs et de comprendre le problème. Grâce à npm, les applications s’installent et se mettent à jour.  Ou pas. C’est un problème général avec cet outil et pas un problème de CozyCloud. Nous sommes du coup assez loin d’un outil à mettre entre les mains d’un individu lambda.

Le dernier inconvénient : point de partage ou d’outil connectable. Un plugin Seafile ou XMPP me conviendrait. Lorsque j’ai des données à partager je les sélectionne et je mets à disposition sur un dépôt séparé. Lorsque j’ai fini je détruit le dépôt. Ce n’est pas un outil de travail en groupe mais bien un partage de données personnelles.

Enfin, à la fois un avantage et un inconvénient : chaque instance est personnelle et il n’est pas possible actuellement d’installer deux instances dans le même système. J’hésite à passer à une installation en docker (engine+compose+swarm) pour le VPS en gardant un rapsberry pi par personne physique. C’est plus la fonction de partage qui manque à mon goût qu’un système de mutualisation des instances.

Ce que j’aimerai maintenant c’est un  ou plusieurs systèmes d’indexation (Qwant ?) et d’amélioration (Marmotta ?). Je suis conscient que les fonctionnalités vont varier selon la puissance de l’hébergement. S’il y a déjà des tags dans un article que je marque ou que je sauvegarde j’aimerai pouvoir les avoirs automatiquement et aussi pouvoir rajouter les miens. Chaque application peut implémenter cela de son côté; si c’est un fonction du framework cela deviendra le standard. Avec la conteneurisation, cela peut être un ou plusieurs conteneurs en boîte noire disposant juste d’une API de requêtage.