Migration, réversibilité : est-il possible de quitter LaSuite ?

Voici un nouveau format. Sans prétention particulière sur son utilité future ni sur sa régularité, l’idée est simplement de partager davantage certaines notes prises au fil de cette aventure autour de la souveraineté numérique. Beaucoup de choses sont testées, documentées, comparées ou simplement notées pour garder une trace. Lorsque ces notes peuvent être utiles à d’autres, autant les rendre publiques. Elles ne seront donc pas forcément construites comme les articles habituellement publiés ici : parfois plus directes, plus techniques, plus proches d’un carnet de bord que d’un article classique.

Une première note de ce type avait d’ailleurs été publiée sur les réseaux sociaux autour de l’installation d’une instance AT Protocol, le protocole utilisé notamment par Bluesky.
Avec le recul, elle semble avoir trouvé son public et répondre à un véritable intérêt. Elle sera donc probablement publiée ici également.

Pour cette première, le sujet était presque évident. Il est assumé ici comme ailleurs sur les réseaux sociaux : LaSuite fait aujourd’hui partie des solutions que je teste le plus dans ce parcours autour de la souveraineté numérique. Elle est installée, maintenue, utilisée au quotidien, documentée et régulièrement mise en avant. Il est donc assez naturel d’en parler dès qu’une occasion se présente.

Évidemment, assumer aussi clairement ce choix attire aussi les critiques. Dans les conférences et salons comme sur les réseaux sociaux, certaines remarques viennent de concurrents, d’éditeurs ou simplement de personnes qui craignent que cette initiative portée par l’État ne parasite les investissements des acteurs privés français, voire ne favorise indirectement les grandes solutions américaines. Bref, on connaît la chanson. Ce n’est pas le sujet ici et l’objectif n’est pas d’ouvrir une nouvelle polémique.

En revanche, parmi toutes les remarques reçues, une question revenait régulièrement et méritait d’être prise au sérieux : la souveraineté numérique, c’est bien la liberté de choisir ?

Sur ce point, ma position est sans ambiguïté : oui.

Mais une seconde question venait immédiatement derrière : si cette souveraineté repose réellement sur la liberté de choisir, est-il possible demain de quitter LaSuite sans difficulté et sans y perdre des plumes ?

Et là, il fallait reconnaître une chose : je n’avais pas la réponse.

Il aurait été facile de chercher quelques arguments permettant de défendre une solution appréciée, de sélectionner les éléments les plus favorables et de conclure que tout allait pour le mieux dans le meilleur des mondes possibles. Mais cela aurait complètement raté l’objectif. Une démarche de souveraineté numérique suppose aussi d’accepter de remettre ses propres choix en question. Sinon, il ne s’agit plus vraiment de souveraineté, mais simplement d’une nouvelle guerre de chapelles.

La question devenait donc beaucoup plus concrète : si demain une organisation ou un utilisateur souhaite partir, peut-il récupérer ses documents, ses fichiers, ses données et son travail dans de bonnes conditions ? Et surtout, peut-il réellement repartir ailleurs ?

C’est ce que cette note cherche à examiner.

C’est aussi là que Genma, suivi depuis de nombreuses années et véritable source d’inspiration sur ces sujets, est entré dans l’histoire. Lui aussi a posé cette question. La réponse était simple : nous ne la connaissions pas encore, mais il était possible d’essayer de la trouver à deux.
De là est née une proposition qui me paraissait évidente : pousser l’exercice jusqu’au bout et écrire cette note à quatre mains.

Il a répondu : Chiche

Il n’en fallait pas davantage.

Et travailler cette question avec lui avait justement un intérêt majeur : ne pas rester dans une logique de validation. Son rôle a été au contraire de challenger la démarche, de poser les questions qui fâchent, de pointer les angles morts et d’obliger à aller plus loin. Le but de l’exercice n’était donc absolument pas de faire les louanges de LaSuite, mais de vérifier si cette solution correspond réellement aux principes défendus autour de la souveraineté numérique.

N’étant ni technicien, ni développeur, ni ingénieur, ni issu du sérail, il semblait également indispensable que le regard d’un vrai expert puisse venir compléter cette réflexion. Genma a donc apporté cette dimension : aider à poser les bonnes questions, confronter les intuitions à la réalité technique, et surtout valider, nuancer ou corriger les conclusions lorsque cela était nécessaire.

C’est dans cet esprit que cette note est proposée. Pas comme une vérité définitive, ni comme une démonstration destinée à défendre LaSuite à tout prix, mais comme le résultat d’une recherche menée avec une question simple en tête : peut-on réellement parler de souveraineté si l’on n’est pas libre de partir ?

Et comme toujours dans ce type de démarche, toute correction, remarque, objection ou question supplémentaire est la bienvenue.

Objet de la note

Cette note vise à évaluer dans quelle mesure LaSuite, portée par la DINUM, peut être quittée facilement par une organisation qui souhaiterait migrer vers une autre solution.

L’enjeu est simple : une suite numérique souveraine ne doit pas seulement proposer une alternative à Microsoft 365 ou Google Workspace. Elle doit aussi permettre à ses utilisateurs de garder la maîtrise de leurs données, de leurs fichiers et de leurs usages. Autrement dit, elle ne doit pas recréer une nouvelle forme de dépendance technique.

Dans ce cadre, la question étudiée est la suivante : un utilisateur ou une organisation peut-il récupérer ses données et changer d’outil dans de bonnes conditions ?

Périmètre du test

L’analyse générale porte sur trois briques logicielles de LaSuite : Grist, Fichiers et Docs.
Le test pratique, mené sur une instance auto-hébergée sous YunoHost, porte, lui, uniquement sur Docs, car Fichiers n’est pas disponible dans cette installation et Grist n’y a pas été installé.

Pour rappel, les rôles de ces différentes briques sont les suivants :

  • Grist : application pour des tableaux structurés et des bases de données légères ;
  • Fichiers : le stockage et le partage des documents
  • Docs : pour la rédaction collaborative de documents avec possibilité d’export des contenus.

Ces trois briques ont été retenues car elles concentrent à elles-seules les usages les plus sensibles en matière de réversibilité. Ce sont en effet les espaces où les utilisateurs produisent, stockent, organisent et partagent leurs données de travail.

En cas de migration, ce sont donc les premiers éléments réinstallés pour lesquels on doit pouvoir récupérer proprement les données.

Méthode retenue

L’analyse repose sur quatre démarches complémentaires.

  • D’abord, une première question a été posée sur le canal Matrix de la communauté DINUM. L’objectif était d’observer la qualité de l’aide disponible, la réactivité de la communauté et la capacité du canal à orienter un utilisateur vers des réponses concrètes.
  • Ensuite, un contact a été pris avec LaSuite.coop, une SCOP qui utilise LaSuite comme base technique et la met à disposition de ses propres clients. Cette démarche permettait d’obtenir un retour plus opérationnel, plus proche des usages réels d’une structure qui accompagne des organisations.
  • Une recherche a également été menée dans la documentation officielle de LaSuite, notamment à partir de son dépôt GitHub. Cette étape visait à vérifier si les possibilités d’export, de migration ou de récupération des données sont documentées de manière claire et accessible.
  • Enfin, un test pratique a été mené depuis une instance auto-hébergée sur YunoHost. L’objectif est de confronter les éléments théoriques recueillis aux conditions réelles d’usage : installation, récupération des données, possibilités d’export et capacité à repartir vers une autre solution sans rencontrer de blocage majeur.

Cette méthode permet donc de croiser quatre niveaux d’information : l’aide communautaire, le retour d’un acteur professionnel utilisant la solution, la documentation officielle disponible et un test concret en environnement auto-hébergé.

Premiers retours obtenus

1. Retour du canal Matrix de la communauté DINUM

Le premier retour obtenu sur le canal Matrix confirme que la question de la réversibilité est bien identifiée comme un sujet important. Plusieurs réponses ont reconnu que la possibilité de quitter une suite numérique sans perdre ses données, son organisation de fichiers ou ses usages devait être prise au sérieux.

En revanche, les échanges n’ont pas permis d’obtenir une réponse immédiatement complète et opérationnelle. La principale piste évoquée concerne le projet OpenBuro, mentionné par Riël Notermans, de mosa.cloud.

OpenBuro ne se présente pas comme une nouvelle suite bureautique complète, mais plutôt comme un standard commun destiné à faire mieux communiquer entre elles différentes briques libres ou open source : documents, fichiers, messagerie, agenda, outils collaboratifs, etc. L’objectif est de dépasser le simple assemblage d’applications séparées pour construire une expérience plus cohérente, comparable à ce que proposent Microsoft 365 ou Google Workspace, mais sans dépendance à un seul éditeur.

Cette piste est intéressante pour la réversibilité, car elle va dans le sens d’une meilleure interopérabilité entre les outils. À terme, un tel standard pourrait faciliter le passage d’une solution à une autre, en conservant mieux les fichiers, les liens entre services, les droits d’accès, les espaces de travail et l’arborescence documentaire.

Cependant, à ce stade, OpenBuro reste encore un projet en construction. Les éléments disponibles permettent de comprendre l’ambition et la direction prise, mais ne suffisent pas encore à démontrer qu’une migration complète, simple et transparente est déjà possible en conditions réelles. Il s’agit donc d’une piste prometteuse, mais pas encore d’une garantie pratique immédiate pour l’utilisateur final.

Le retour du canal Matrix est donc contrasté : la communauté semble consciente du sujet et capable d’orienter vers des initiatives pertinentes, mais la réponse apportée reste encore prospective.

2. Retour de LaSuite.coop

Le retour de LaSuite.coop apporte des éléments plus concrets, car il vient d’un acteur qui utilise LaSuite comme base technique et la propose à des clients.

Sur les formats de fichiers, plusieurs garanties importantes ressortent.

Pour Docs, l’outil permet l’import de fichiers au format .docx et .md, ainsi que l’export vers .docx, .odt et .pdf. Le format .odt est particulièrement important, car il constitue un format ouvert de référence dans le monde bureautique, notamment avec LibreOffice. Cela va dans le bon sens pour éviter l’enfermement dans un format propriétaire unique.

Pour Fichiers, le point le plus rassurant est que les documents sont conservés à l’identique. Autrement dit, les fichiers déposés dans l’espace de stockage ne sont pas transformés ou enfermés dans un format propre à la plateforme. Ce que l’utilisateur dépose est ce qu’il peut récupérer. C’est un élément important pour la réversibilité, car cela réduit fortement le risque de perte ou de dégradation lors d’un départ vers une autre solution.

Pour Grist, l’import et l’export sont possibles en CSV et en Excel. Son format natif repose sur SQLite, ce qui constitue également un point positif, car SQLite est une technologie ouverte, connue et largement documentée. En revanche, une limite actuelle doit être signalée : l’import au format .ods, utilisé notamment par LibreOffice Calc, n’est pas encore disponible. Cela constitue une faiblesse pour les organisations qui veulent privilégier complètement les formats ouverts dans leurs usages bureautiques.

LaSuite.coop indique également qu’un export complet des données peut être fourni lorsqu’une organisation souhaite mettre fin à son abonnement ou migrer vers un autre prestataire. Ce point est important, car il montre que la réversibilité n’est pas seulement abordée sous l’angle technique, mais aussi sous l’angle de l’accompagnement client.

Toutefois, une limite importante est reconnue : la conversion de formats vers d’autres systèmes n’est pas encore disponible. Elle figure dans la feuille de route, mais ne peut pas encore être considérée comme une fonctionnalité pleinement opérationnelle.

Enfin, LaSuite.coop insiste sur le fait que les outils sont auto-hébergeables et que leur code source est disponible. Cela renforce l’idée qu’une organisation peut, en théorie, reprendre la main sur son hébergement ou confier la gestion à un autre prestataire. Cette possibilité est un élément central de souveraineté : la capacité de partir ne dépend pas seulement d’un bouton d’export, mais aussi de la possibilité de continuer à utiliser ou à déployer les outils ailleurs.

À ce stade, le retour de LaSuite.coop est donc plutôt positif. Il montre que LaSuite repose sur des formats ouverts, des outils auto-hébergeables et une logique d’export des données. Mais il confirme aussi que certaines fonctions de réversibilité avancée, notamment la conversion complète vers d’autres environnements, restent encore à consolider.

3. Lecture de la documentation officielle de LaSuite

La troisième démarche a consisté à lire la documentation publique disponible autour de LaSuite, notamment les pages officielles, les FAQ, les dépôts GitHub de Docs et Fichiers, ainsi que la documentation officielle de Grist vers laquelle LaSuite renvoie.

L’objectif était de vérifier si la réversibilité est seulement un principe affiché, ou si elle repose sur des éléments concrets : formats d’export, import de fichiers, API, possibilité d’auto-hébergement et récupération des données.

La lecture de la documentation montre que les trois briques étudiées disposent bien de portes de sortie techniques.

Pour Docs, les éléments sont plutôt rassurants. L’outil permet l’import de documents en .docx et en Markdown, selon le dépôt GitHub du projet. Il permet aussi l’export vers des formats courants comme Word, PDF et ODT, d’après la page officielle de Docs. Le format .odt est important car il s’agit d’un format ouvert, utilisé notamment par LibreOffice. Docs peut aussi être auto-hébergé, et la documentation mentionne une API permettant de récupérer, lister, déplacer ou restaurer des documents. Cela montre que la sortie ne se limite pas forcément à un export manuel fichier par fichier.

Pour Fichiers, le principe est encore plus simple : la documentation indique que l’outil permet de stocker et télécharger des fichiers de tout type. Cela suggère que les fichiers peuvent être récupérés dans leur format d’origine, sans dépendre d’un format documentaire propre à la plateforme. C’est un point important, car la meilleure garantie de réversibilité, pour un espace de stockage, est de pouvoir récupérer ses fichiers tels qu’ils ont été déposés. La documentation technique montre aussi que Fichiers repose sur un stockage compatible S3 et sur une API permettant de manipuler les éléments, les dossiers et certains paramètres.

En revanche, je n’ai pas trouvé de procédure détaillée, pensée pour un utilisateur non technique, permettant d’exporter simplement tout un espace complet avec son arborescence. Pour une petite structure, la récupération manuelle peut suffire ; pour une organisation avec beaucoup de données, une migration sérieuse demandera probablement un accompagnement technique.

Pour Grist, la documentation est la plus complète sur le sujet de la réversibilité. Grist permet d’exporter une table en CSV ou XLSX. Il permet aussi d’exporter toutes les tables d’un document au format Excel, ou de télécharger un document complet au format .grist, qui repose sur SQLite. Ce point est important, car SQLite est une technologie ouverte, connue et lisible par de nombreux outils. Le fichier .grist permet donc de conserver une copie plus complète du document, et pas seulement une sortie simplifiée en tableur. La documentation indique également que Grist peut être auto-hébergé, ce qui permet de changer d’hébergeur tout en continuant à utiliser le même outil.

Le bilan de cette lecture est donc plutôt positif : LaSuite ne repose pas uniquement sur un discours de souveraineté. Pour les trois briques étudiées, il existe des éléments techniques concrets qui permettent de récupérer ses données, de les exporter ou de réhéberger les outils.

Il faut cependant distinguer deux niveaux.

D’un côté, la réversibilité technique est réelle : formats ouverts ou standards, exports, API, code source ouvert et possibilité d’auto-hébergement.

De l’autre, la réversibilité contractuelle est moins détaillée dans la documentation publique consultée. La DINUM indique bien qu’un service sorti de bêta doit permettre un export des données dans un format ouvert en cas de fermeture du service. Mais je n’ai pas trouvé, pour chaque brique, une présentation très précise des délais de restitution, des formats exacts livrés lors d’un départ, de l’assistance fournie, du coût éventuel d’une migration ou de la récupération complète des droits d’accès et métadonnées.

En résumé, la documentation officielle confirme que l’on peut quitter LaSuite dans de meilleures conditions que des plateformes fermées. Mais elle gagnerait à rendre plus visibles, pour les organisations non techniques, les procédures concrètes de sortie : que récupère-t-on exactement, sous quel format, en combien de temps, avec quel accompagnement et avec quelles limites.

4. Test pratique depuis une instance auto-hébergée sur YunoHost

Un test pratique a été mené depuis une instance auto-hébergée sur YunoHost. Il ne porte que sur Docs, car Fichiers n’est pas disponible dans cette installation YunoHost et Grist n’a pas été installé sur cette instance.

L’application testée est La Suite – Docs, en version 4.8.6~ynh2, installée à l’adresse ecrire.mondomaine.ovh. L’environnement repose également sur Dex, utilisé pour l’authentification, et MinIO, utilisé pour le stockage objet.

Depuis l’interface utilisateur de Docs, un document de test a été créé puis exporté dans les formats proposés par l’application : PDF, DOCX, ODT et HTML sous forme d’archive ZIP. Ces exports permettent bien de récupérer le contenu du document : titre, paragraphes, liste, tableau, lien et structure générale. Ils constituent donc une solution simple pour repartir avec le contenu vers une autre suite bureautique ou un autre outil de traitement de texte.

En revanche, le test montre que ces exports ne conservent pas les éléments collaboratifs. Après partage du document avec une autre adresse, l’export HTML a été refait : il ne contient ni l’adresse invitée, ni le rôle attribué, ni les informations de partage. Le même constat vaut pour les exports bureautiques classiques : ils récupèrent le document, mais pas l’environnement de collaboration qui l’entoure.

La vérification côté serveur donne un résultat différent. La base PostgreSQL de Docs contient bien les informations de partage. Le document de test apparaît dans la table des documents, avec son titre, son identifiant, son niveau d’arborescence et ses paramètres de lien. L’invitation créée pendant le test est également enregistrée dans la base, avec l’adresse invitée, le rôle editor, le document concerné et l’utilisateur à l’origine de l’invitation.

YunoHost permet aussi de créer une sauvegarde technique de l’environnement. Le test a montré qu’une sauvegarde cohérente doit inclure trois briques : lasuite-docs, minio et dex. La sauvegarde de lasuite-docs contient notamment un dump PostgreSQL, tandis que la sauvegarde de minio contient le bucket lasuite-docs, où se trouvent les objets techniques liés aux documents. Un dump direct PostgreSQL et une archive séparée du bucket MinIO ont également été réalisés avec succès.

Ce test confirme donc une distinction importante. Docs permet de récupérer facilement le contenu d’un document dans des formats standards. C’est un point favorable pour la réversibilité. En revanche, les droits, les invitations, les rôles et les informations de partage ne sont pas embarqués dans les exports utilisateur. Ils existent bien dans la sauvegarde technique de l’instance, mais sous une forme applicative, utile pour restaurer Docs, pas pour migrer simplement vers une autre solution.

La réversibilité est donc bonne pour les contenus, mais plus limitée pour l’environnement collaboratif complet. Pour conserver les droits et les partages lors d’une migration vers une autre solution, une opération technique spécifique serait nécessaire : extraction de la base, correspondance des utilisateurs, puis recréation des droits dans l’outil cible.

Conclusion : une sortie possible, mais pas encore une réversibilité complète

À ce stade, le constat est plutôt positif, mais il doit être nuancé. Les trois briques étudiées permettent bien de récupérer les contenus produits dans LaSuite.

Dans Grist, les données peuvent être exportées en formats standards, notamment en CSV ou XLSX. Il est aussi possible d’exporter l’ensemble des tables d’un document au format Excel, ou de télécharger le document complet au format .grist. Ce dernier format est plus riche, puisqu’il repose sur une base SQLite et contient les données, les fichiers joints, les pages, les vues et une partie de l’historique récent. En revanche, la documentation précise que ce fichier ne contient pas les informations sur les personnes avec qui le document est partagé.

Pour Fichiers, la logique semble également favorable à la récupération des contenus. Le code de l’application prévoit un export récursif d’un dossier sous forme d’archive ZIP, avec un service dédié qui reconstruit les chemins relatifs des fichiers et dossiers dans l’archive (service d’export ZIP). Cela signifie que l’arborescence peut être conservée lors de l’export. En revanche, les droits d’accès et les partages sont gérés séparément dans l’application, via un modèle d’accès propre aux fichiers et dossiers (ItemAccess). Rien n’indique que ces droits soient intégrés dans l’archive ZIP exportée.

Pour Docs, la situation est comparable. Le dépôt officiel indique que les documents peuvent être exportés dans plusieurs formats courants, notamment ODT, DOCX et PDF. Ces formats permettent de récupérer le contenu et de le réutiliser dans d’autres outils. En revanche, les droits et les partages sont eux aussi gérés dans un modèle séparé (DocumentAccess). Là encore, rien ne permet d’affirmer qu’un export bureautique conserve automatiquement les personnes autorisées, les rôles ou les invitations associées au document.

La conclusion est donc la suivante : LaSuite ne semble pas enfermer l’utilisateur dans ses formats. Les contenus peuvent être récupérés dans des formats standards ou exploitables. C’est un point important, car il distingue cette approche d’une dépendance fermée où les données resteraient prisonnières de la plateforme.

En revanche, la réversibilité n’est pas encore totale au sens strict. Quitter LaSuite en récupérant les fichiers, les documents et les tableaux paraît possible. Mais quitter LaSuite en conservant automatiquement toute l’organisation de travail : arborescence, droits, partages, personnes autorisées, rôles et invitations, semble nécessiter une opération plus technique, probablement fondée sur des scripts, des API ou une migration accompagnée.

Autrement dit, LaSuite paraît offrir une bonne réversibilité des contenus. Elle ne garantit pas encore, du moins dans les éléments documentés consultés, une réversibilité complète de l’environnement collaboratif.

Publié le

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *