Construire sa propre suite collaborative avec Claude : architecture, souveraineté et fin du vendor lock-in

Format : Blog technique | Thèmes : Souveraineté numérique, architecture logicielle, critique du SaaS, retour d'expérience Niveau : Ingénieur, DSI, décideur technique

Introduction : ce que nous appelons modernité n'en est pas

Pendant des décennies, le progrès numérique des organisations a été mesuré à l'aune d'un seul indicateur : le nombre de services cloud adoptés. Migrer vers Microsoft 365, déployer Google Workspace, centraliser sa collaboration sur Slack, son stockage sur SharePoint, sa signature sur DocuSign... chaque abonnement souscrit était présenté comme une étape vers la transformation digitale.

Ce récit mérite d'être interrogé frontalement.

Ce que beaucoup d'organisations ont accompli au cours de ces quinze dernières années ressemble, à distance, moins à une transformation qu'à un transfert de dépendance. Elles ont remplacé des infrastructures internes qu'elles maîtrisaient imparfaitement par des plateformes externes dont les conditions de contrôle sont différentes, pas nécessairement meilleures. Elles ont gagné en confort d'usage immédiat, mais les marges de manœuvre sur les données, les formats et les tarifs se sont, dans bien des cas, réduites.

Ce texte documente une expérience différente : la reconstruction, depuis zéro, d'une suite collaborative complète, accessible depuis n'importe quel navigateur, sur n'importe quel système d'exploitation, sans dépendre d'aucun éditeur propriétaire. Un projet rendu possible à une échelle individuelle grâce à Claude, et qui démontre que l'alternative n'est pas seulement théorique.

L'objectif n'est pas de proposer une solution universelle ni de prétendre que chaque organisation devrait reproduire exactement cette démarche. L'objectif est de montrer ce que cette démarche révèle sur l'état réel du marché SaaS, sur le coût réel du vendor lock-in, et sur ce que l'IA rend désormais possible pour des équipes techniques réduites qui souhaitent reprendre le contrôle.

I. Anatomie du vendor lock-in : ce que les contrats ne disent pas

1.1 Le coût visible : les licences

La critique la plus immédiate du SaaS porte sur son coût direct. Elle est légitime mais souvent mal formulée. Le problème n'est pas que les licences soient chères en valeur absolue. Une licence Microsoft 365 Business Standard à 12,50 euros par utilisateur et par mois peut sembler raisonnable pour une organisation de dix personnes. Elle le devient nettement moins à trois cents utilisateurs, quand s'y ajoutent les modules complémentaires (Defender, Purview, Copilot), les licences premium pour les cas d'usage avancés, et les coûts d'intégration avec les outils tiers qui, eux, ne sont pas inclus.

Mais le coût visible n'est que la partie émergée. Ce qui rend le vendor lock-in structurellement difficile à briser, c'est l'accumulation de coûts invisibles que les contrats ne mentionnent jamais.

1.2 Le coût invisible : l'enfermement progressif

L'enfermement ne survient pas par surprise. Il se construit graduellement, par accumulation de petites décisions qui semblent toutes raisonnables au moment où elles sont prises.

La dépendance aux formats propriétaires. SharePoint développe ses propres structures de métadonnées. Teams construit son graphe social dans l'écosystème Microsoft. Power Automate crée des workflows qui ne fonctionnent que dans cet environnement. Chaque brique ajoute une couche d'intégration spécifique qui rend la migration un peu plus coûteuse.

La perte de compétences internes. À mesure que les équipes s'habituent à des interfaces propriétaires, elles perdent la familiarité avec les standards ouverts. Les DSI qui ont externalisé leur messagerie vers Exchange Online depuis dix ans ont souvent perdu la capacité interne d'administrer un serveur mail. Ce savoir-faire ne se reconstruit pas en quelques semaines.

L'effet d'inertie documentaire. Des années de production documentaire dans des formats propriétaires créent une masse de données dont la migration est techniquement réalisable mais organisationnellement très coûteuse. Pas tant pour des raisons techniques que pour des raisons humaines : qui va relire, revalider, réorganiser dix ans de fichiers ?

La dépendance réglementaire. Certaines organisations ont construit leurs politiques de conformité autour des certifications d'un éditeur spécifique (ISO 27001 portée par Microsoft, certifications HDS via Azure...). Changer d'éditeur implique souvent de requalifier l'ensemble du dispositif de conformité.

1.3 Le coût stratégique : la perte d'agentivité

Le plus grave n'est pas économique. C'est l'effet sur la capacité à décider.

Une organisation profondément dépendante d'un éditeur perd progressivement sa capacité à négocier. Elle ne peut pas menacer crédiblement de partir, parce que partir coûterait trop cher. Elle subit donc les augmentations tarifaires et les modifications de conditions d'utilisation. Les questions sur l'utilisation des données clients, les droits d'accès des équipes de l'éditeur, ou les conditions exactes de portabilité ont des réponses qui varient significativement selon les contrats et les versions. Ce flou a un coût pour l'organisation qui ne contrôle pas son environnement.

II. Critique économique du SaaS : ce que le marché rationalise mal

2.1 Le SaaS a résolu de vrais problèmes

Le SaaS a résolu des problèmes réels. Avant l'essor du cloud : mises à jour complexes, gestion des licences par poste, coûts d'infrastructure disproportionnés pour les petites structures, difficulté à collaborer à distance. Ces gains sont indéniables.

La question n'est donc pas "SaaS ou pas SaaS". Elle est : à quel moment le modèle se retourne contre celui qui en dépend ?

2.2 Le modèle SaaS optimise pour le fournisseur, pas pour le client

Le modèle économique du SaaS est fondé sur la récurrence. Un éditeur SaaS rentable est un éditeur dont les clients restent. Les mécanismes d'incitation sont donc orientés vers la rétention : intégrations profondes, écosystème propriétaire cohérent, migration coûteuse. Ce n'est pas une critique morale, c'est la logique d'un abonnement.

La conséquence pour le client est structurelle : plus l'intégration est profonde, plus le coût de sortie est élevé. Ces deux logiques coexistent confortablement pendant des années, puis entrent en friction lors d'une augmentation tarifaire, d'un changement de conditions contractuelles ou d'une acquisition par un tiers.

2.3 L'illusion de la mutualisation des coûts d'infrastructure

L'argument le plus fréquent en faveur du SaaS est la mutualisation : pourquoi investir dans une infrastructure que je pourrais partager avec des milliers d'autres clients, amortissant ainsi les coûts de sécurité, de maintenance, de redondance ?

Cet argument est valide dans un nombre limité de cas. Il l'est beaucoup moins quand :

2.4 Ce que le marché n'intègre pas dans ses analyses de coût total

Les analyses TCO (Total Cost of Ownership) standard comparant SaaS et on-premise tendent à sous-représenter certains postes. Le rapport Gartner "True Cost of SaaS" (2022) relevait déjà que les organisations surestiment en moyenne de 20 à 30 % les économies réalisées par rapport à une infrastructure propre, une fois les coûts d'intégration, de personnalisation et de sortie comptabilisés. Le coût du risque de dépendance reste pour l'essentiel non chiffré. La valeur des compétences internes progressivement perdues n'apparaît dans aucune ligne budgétaire standard. Ce n'est pas une critique de la méthode TCO en tant que telle, mais un rappel que les périmètres de comparaison sont rarement identiques entre les deux colonnes du tableau.

III. Souveraineté numérique : de l'abstraction à la pratique

3.1 Ce que la souveraineté numérique signifie concrètement

La souveraineté numérique est souvent invoquée dans des discours institutionnels comme une valeur abstraite. Elle mérite d'être traduite en termes opérationnels précis.

Une organisation dispose d'une souveraineté numérique réelle lorsqu'elle satisfait simultanément à cinq critères :

Contrôle des données. Elle sait où ses données sont stockées, qui y a accès, sous quelle juridiction elles tombent, et peut les récupérer intégralement à tout moment dans un format ouvert et documenté.

Contrôle du code. Elle comprend, peut auditer, modifier et faire évoluer les outils qu'elle utilise. Elle n'est pas tributaire de la roadmap d'un éditeur pour des fonctionnalités critiques.

Contrôle de l'infrastructure. Elle peut choisir où ses services s'exécutent (cloud souverain, on-premise, hybride) et peut les déplacer sans dépendance à une plateforme spécifique.

Contrôle des compétences. Elle dispose en interne (ou dans un réseau de prestataires maîtrisé) du savoir-faire nécessaire pour maintenir, faire évoluer et, si nécessaire, remplacer ses outils.

Contrôle de la trajectoire. Elle peut décider de changer d'outil, d'architecture ou de fournisseur sans que ce changement soit rendu prohibitivement coûteux par des dépendances accumulées.

La plupart des organisations qui se réclament de la souveraineté numérique ne satisfont, en pratique, qu'à un ou deux de ces critères.

3.2 Le navigateur comme vecteur d'indépendance

Un choix architectural qui paraît anodin concentre en réalité une logique de souveraineté forte : rendre tout accessible via un navigateur standard.

Ce choix a des implications profondes. Il signifie que l'OS du poste de travail devient libre. Un collaborateur sur Linux, macOS ou Windows accède exactement au même outil, avec les mêmes fonctionnalités. Il n'y a plus de client propriétaire à installer, plus de dépendance à une version spécifique d'un système d'exploitation, plus d'incompatibilité entre plateformes.

C'est une forme d'universalité technique qui rompt un premier niveau de dépendance : la dépendance au poste de travail standardisé. Elle permet d'utiliser n'importe quel matériel, d'accéder depuis n'importe quel réseau sécurisé, de ne pas imposer de contraintes OS à ses collaborateurs.

C'est précisément ce choix qui a structuré l'architecture de la suite que je décris ici.

IV. Ce que j'ai construit : retour d'expérience

4.1 Point de départ et contraintes

Le projet est parti d'un constat simple : l'essentiel de ce qu'une suite collaborative doit faire peut être reconstruit avec des technologies web standard, des bibliothèques open source matures, et un investissement en temps que l'IA permet désormais de réduire considérablement.

Les contraintes que je me suis fixées :

Ces contraintes excluaient d'emblée des solutions hybrides du type "Nextcloud avec connecteurs Microsoft" ou "déploiement on-premise de suites commerciales". L'objectif était une reconstruction depuis les fondations, pas un réhabillage d'une dépendance existante.

4.2 Périmètre fonctionnel couvert

La suite couvre les cas d'usage collaboratifs essentiels, organisés en modules indépendants mais intégrés :

Module documents. Éditeur de texte riche (format ouvert, export PDF/DOCX), gestion de versions, commentaires collaboratifs, contrôle des accès par document.

Module communication. Messagerie interne persistante avec canaux thématiques, notifications, recherche full-text dans l'historique.

Module gestion de projet. Vues Kanban et liste, assignation de tâches, suivi de statut, liens entre tâches et documents.

Module tableur. Feuilles de calcul collaboratives dans le navigateur, avec formules, mise en forme conditionnelle, import/export XLSX natif, et édition simultanée multi-utilisateurs. L'équivalent fonctionnel d'Excel Online, hébergé sur infrastructure propre.

Module base de données structurée. Vues configurables sur des collections MongoDB : grille, galerie, kanban, formulaire, calendrier. Chaque vue est une projection différente du même jeu de données. Le modèle est celui d'Airtable : champs typés, filtres persistants, permissions par vue, sans dépendance commerciale.

Module stockage. Gestionnaire de fichiers avec prévisualisation, partage par lien, versioning, organisation par espace de travail.

Module agenda. Calendrier partagé, gestion des disponibilités, intégration avec les tâches.

Module administration. Gestion des utilisateurs, rôles, journaux d'audit, configuration des politiques d'accès.

4.3 Les décisions techniques structurantes

Tableur collaboratif : Luckysheet + HyperFormula. Luckysheet est un moteur de feuilles de calcul open source qui s'intègre dans une application React et couvre les cas d'usage courants d'Excel : formules, mise en forme conditionnelle, fusion de cellules, graphiques. HyperFormula gère le moteur de calcul des formules avec une compatibilité étendue avec la syntaxe Excel. L'ensemble est connecté à Yjs pour la collaboration temps réel, sur le même modèle que l'éditeur de documents.

Base de données structurée : moteur de vues sur MongoDB. Le module Airtable n'est pas construit sur une bibliothèque clé en main mais sur une couche applicative maison, posée sur MongoDB. Chaque "table" est une collection MongoDB dont le schéma est défini dynamiquement (les champs, leurs types, leurs contraintes sont stockés dans un document de configuration). Les vues (grille, kanban, galerie, formulaire) sont des composants React qui interrogent la même collection avec des projections et des tris différents. Ce choix architectural a un avantage décisif : il s'appuie sur la flexibilité de schéma de MongoDB plutôt que de combattre un modèle relationnel figé pour représenter des structures de données métier évolutives.

Frontend : React avec rendu côté serveur. Le choix de React n'est pas idéologique. C'est le framework qui dispose de l'écosystème de bibliothèques le plus mature pour les composants éditoriaux et collaboratifs (éditeurs de texte riche, gestion de fichiers, calendriers, tableaux). Le SSR (Server-Side Rendering) assure des performances acceptables sur connexions lentes.

Backend : Node.js avec API REST + WebSockets. Node.js pour la cohérence du langage entre frontend et backend. WebSockets pour les fonctionnalités temps réel (présence des collaborateurs, mises à jour de documents, notifications). Une API REST versionnée pour toutes les opérations CRUD.

Base de données : MongoDB. Le modèle documentaire de MongoDB correspond naturellement à la structure des données d'une suite collaborative : un document est un objet JSON avec des métadonnées variables, des versions imbriquées, des commentaires associés. Le schéma flexible évite les migrations de table coûteuses à chaque évolution du modèle de données, et les agrégations natives permettent des requêtes analytiques (historique, statistiques d'usage) sans couche intermédiaire.

Sur le plan de la scalabilité, MongoDB est conçu pour des architectures distribuées : replica sets pour la haute disponibilité, sharding horizontal sans modification du code applicatif, et compatibilité native avec Kubernetes via son opérateur officiel. Point important dans ce contexte : ce choix n'implique pas de recourir à MongoDB Atlas. L'opérateur communautaire couvre les cas d'usage de cette suite en restant entièrement sur infrastructure propre.

Stockage fichiers : Ceph. Ceph est une solution de stockage distribué open source qui couvre simultanément le stockage objet (compatible S3), le stockage bloc et le stockage fichier. Ce qui le distingue de solutions plus légères comme MinIO, c'est sa capacité à s'adapter à des volumes massifs tout en garantissant une redondance native via sa réplication distribuée. Pour une infrastructure qui doit tenir dans la durée, Ceph offre une garantie de disponibilité et de durabilité des données sans dépendance à un service cloud tiers. La compatibilité S3 préserve en outre les options futures : si l'organisation migre un périmètre vers un cloud compatible, le code d'accès au stockage ne change pas.

Authentification : Keycloak. Solution open source de gestion des identités et des accès, compatible OIDC/OAuth2, avec support du SSO, de la 2FA, et de la fédération d'identité avec des annuaires LDAP ou Active Directory existants.

Infrastructure : conteneurisation Docker, orchestration Kubernetes (optionnel). Docker pour l'isolation des composants et la reproductibilité des environnements. Kubernetes pour les déploiements qui nécessitent une haute disponibilité, mais la suite fonctionne aussi sur un simple Docker Compose pour les petites structures.

4.4 Ce qui m'a demandé le plus de temps

Deux domaines ont concentré la majorité de l'effort technique.

L'éditeur de texte collaboratif en temps réel. La collaboration simultanée sur un document (à la manière de Google Docs) est techniquement l'un des problèmes les plus difficiles dans le développement web. La synchronisation d'état entre plusieurs curseurs, la résolution de conflits d'édition simultanée, la persistance cohérente : tout cela repose sur des algorithmes (OT, CRDT) qui sont à la fois bien documentés dans la littérature et difficiles à implémenter correctement en production.

La solution retenue s'appuie sur Yjs (bibliothèque CRDT open source) associée à Hocuspocus (serveur de synchronisation), avec une intégration dans l'éditeur TipTap. Cette combinaison est robuste, bien maintenue, et compatible avec un hébergement entièrement maîtrisé.

La gestion fine des permissions. Un système de collaboration implique une gestion des droits qui doit être à la fois flexible (pouvoir donner des accès différenciés par document, par espace, par rôle) et cohérente (les règles s'appliquent uniformément, sans failles de sécurité par incohérence entre couches). Implémenter un système RBAC (Role-Based Access Control) solide sans réinventer la roue a nécessité un travail d'architecture soigneux.

V. Le rôle de Claude dans ce projet

5.1 Ce que l'IA a changé dans le rapport à la complexité

Ce projet n'aurait pas été réalisable à la même échelle, dans le même délai, par un développeur seul sans assistance IA. Ce n'est pas une hyperbole. C'est un constat précis sur la nature de ce que l'IA a apporté.

L'IA n'a pas remplacé la conception. Chaque décision architecturale, chaque compromis technique, chaque choix de bibliothèque a été le résultat d'un raisonnement humain. Mais l'IA a radicalement réduit le coût de l'exploration.

Avant, explorer une nouvelle technologie signifiait : lire la documentation, trouver des exemples, comprendre les patterns idiomatiques, écrire du code d'exploration, déboguer les erreurs liées à la prise en main. Ce cycle pouvait prendre plusieurs jours pour une technologie non familière.

Avec Claude, ce cycle se réduit à quelques heures. Non pas parce que Claude produit du code parfait du premier coup, mais parce qu'il permet de se confronter beaucoup plus vite aux vraies questions. Il produit une base fonctionnelle sur laquelle le travail critique peut commencer immédiatement, sans être ralenti par les frictions de prise en main.

5.2 Les tâches où Claude a été le plus efficace

Architecture et conception. Discuter des compromis entre approches, modéliser des structures de données, anticiper les problèmes d'échelle. Claude fonctionne comme un interlocuteur technique qui a une connaissance large des patterns existants et peut rapidement confronter une approche à ses angles morts.

Génération de code boilerplate. La partie la plus fastidieuse du développement d'une application n'est pas conceptuellement difficile, mais elle est chronophage. Générer les modèles de données, les endpoints CRUD, les composants de formulaire, les configurations Docker : Claude produit ces éléments rapidement et de manière cohérente.

Débogage et lecture d'erreurs. Coller un stack trace ou un comportement inattendu, obtenir une hypothèse de cause et une piste de correction : ce cycle de débogage assisté par IA est probablement le gain de productivité le plus immédiat et le plus mesurable.

Refactoring et revue de code. "Quel est le problème avec ce code ?" ou "Comment rendre ceci plus maintenable ?" sont des questions auxquelles Claude répond avec une précision utile, en identifiant des patterns anti-production que l'auteur du code ne voit plus après plusieurs heures d'immersion.

Documentation. Générer des README, des commentaires de code, des spécifications d'API à partir d'une implémentation existante. Tâche souvent négligée faute de temps, que Claude rend beaucoup moins coûteuse.

5.3 Les limites réelles

La relation productive avec un outil comme Claude repose sur une compréhension précise de ses limites.

Claude ne remplace pas le jugement architectural. Pour des décisions ayant des implications profondes sur la maintenabilité, la sécurité ou la scalabilité, la validation humaine est non négociable. Claude propose, explique, argumente. Mais il ne connaît pas le contexte spécifique de l'organisation, ses contraintes opérationnelles, ses capacités internes.

Claude n'est pas infaillible sur les détails de version. Les bibliothèques évoluent vite. Claude peut proposer du code qui utilisait une API valide dans une version antérieure d'une bibliothèque mais plus dans la version actuelle. La vérification systématique contre la documentation officielle reste indispensable.

Claude ne remplace pas les tests. Un code qui compile et semble logique n'est pas nécessairement correct. Les tests d'intégration, les tests de sécurité, les tests de charge : ces validations restent entièrement à la charge de l'équipe technique.

5.4 Claude comme levier d'émancipation, pas comme automatisation

Il y a une distinction conceptuelle importante à faire entre deux usages de l'IA dans le développement.

Le premier usage est l'automatisation : confier à l'IA des tâches répétitives pour gagner du temps sans construire de compétence. C'est utile à court terme, mais il ne construit rien.

Le second usage est le levier d'émancipation : utiliser l'IA pour accéder à des domaines techniques que l'on n'aurait pas eu le temps d'explorer seul, pour comprendre des patterns que l'on n'aurait pas eu le temps de maîtriser, pour aller plus loin dans la complexité qu'on ne l'aurait pu avec les mêmes ressources humaines. C'est ce second usage qui a structuré ce projet.

Ce qui change fondamentalement avec un outil comme Claude, ce n'est pas la productivité sur des tâches connues. C'est la capacité à aborder des domaines de complexité qui étaient auparavant hors de portée pour une équipe de taille réduite. Ce qui était réservé aux grandes équipes d'ingénierie redevient accessible à des structures agiles qui savent utiliser l'IA comme amplificateur de compétence.

VI. Ce que ce projet révèle sur l'état du marché

6.1 La barrière technique au changement est en train de baisser

La principale raison pour laquelle les organisations ne construisent pas leurs propres outils n'a jamais été le manque de volonté. C'était le coût et la complexité. Construire une suite collaborative depuis zéro demandait une équipe importante, des délais longs, un investissement en maintenance qui se prolongeait indéfiniment.

L'IA change cette équation. Pas de manière révolutionnaire du jour au lendemain, mais de manière observable sur ce projet. Une application collaborative complète peut être conçue et développée par une équipe très réduite dans des délais sensiblement inférieurs à ce qui était réaliste il y a cinq ans.

Ce déplacement du seuil de faisabilité a des implications pour les éditeurs SaaS : la complexité technique n'est plus aussi efficacement dissuasive qu'elle l'était. Elle a aussi des implications pour les organisations qui hésitaient à s'engager dans cette direction faute de ressources suffisantes.

6.2 L'open source comme socle, pas comme idéologie

Ce projet ne plaide pas pour l'open source comme valeur en soi. Il constate que les bibliothèques open source disponibles aujourd'hui pour construire des applications web collaboratives ont atteint un niveau de maturité qui change l'équation du "construire vs acheter".

Yjs, TipTap, Luckysheet, HyperFormula, Ceph, Keycloak, Meilisearch, MongoDB : aucune de ces briques n'est un projet expérimental. Yjs est utilisé en production par Netlify, Cargo et des dizaines d'éditeurs de SaaS collaboratifs. Keycloak est déployé par des administrations publiques européennes et des institutions financières. Ceph est la fondation de stockage d'OVHcloud et de nombreux clouds souverains européens. Ces références ne prouvent pas que l'open source est toujours supérieur, mais elles réfutent l'argument selon lequel il s'agirait d'une option de second rang réservée à des environnements peu exigeants.

La sélection de bibliothèques open source pour ce type de projet obéit à des critères précis : activité de la communauté de mainteneurs, existence d'un modèle de gouvernance stable (fondation, soutien institutionnel), historique de gestion des CVE, et disponibilité d'une documentation de qualité production. Des bibliothèques qui ne satisfont pas à ces critères sont écartées, indépendamment de leur licence.

6.3 La souveraineté n'est pas une posture, c'est une architecture

La souveraineté numérique ne se décrète pas dans une politique ou un discours institutionnel. Elle se construit dans des choix techniques précis, dont les effets s'accumulent dans le temps.

Quelques exemples concrets : choisir d'exporter les documents en DOCX et en Markdown plutôt que dans un format propriétaire non documenté, c'est préserver la portabilité à dix ans. Choisir Ceph avec son interface S3 standardisée plutôt qu'un stockage objet cloud dont l'API est propriétaire, c'est garder la capacité de changer d'hébergeur sans réécriture. Choisir Keycloak avec OIDC/OAuth2 plutôt qu'un système d'authentification maison ou un fournisseur SaaS d'identité, c'est rester compatible avec n'importe quel annuaire ou fournisseur d'identité futur. Documenter les schémas de données dans un dépôt versionné, c'est s'assurer que la connaissance reste dans l'organisation et pas uniquement dans la mémoire de l'équipe qui a construit le système.

Chacun de ces choix a un coût marginal au moment où il est fait. L'effet de leur accumulation sur la trajectoire de l'organisation se mesure à l'horizon de plusieurs années, notamment au moment des crises : changement de fournisseur forcé, augmentation tarifaire brutale, incident de sécurité sur une plateforme mutualisée.

VII. Pour qui cette approche est-elle pertinente ?

7.1 Les cas d'usage où construire est clairement préférable

Les organisations à exigences réglementaires fortes. Secteur public, santé, défense, infrastructure critique : les exigences de localisation des données, de contrôle des accès et d'auditabilité sont souvent incompatibles avec les conditions réelles (pas seulement les conditions contractuelles) des grands SaaS. Construire ou déployer des solutions on-premise n'est pas un luxe dans ces contextes, c'est parfois une obligation.

Les organisations dont le numérique est un avantage concurrentiel. Si les outils numériques sont au coeur de la différenciation, les confier à des éditeurs tiers qui peuvent les copier, les orienter différemment ou en couper l'accès est un risque stratégique majeur.

Les organisations avec des compétences techniques internes. Si l'organisation dispose déjà d'ingénieurs capables de maintenir des applications web, le surcoût de maintenance d'une suite interne est marginal. Le bénéfice en termes de contrôle et d'adaptation est substantiel.

Les structures qui cherchent à construire un patrimoine numérique transmissible. Une organisation qui veut que son savoir-faire numérique reste dans ses mains, indépendamment des décisions de ses prestataires externes, a intérêt à construire.

7.2 Les cas où le SaaS reste pertinent

Il serait contre-productif de nier les cas d'usage où le SaaS reste le bon choix.

Les très petites structures sans ressource technique interne. Pour une organisation de cinq personnes sans développeur, maintenir une infrastructure souveraine n'est pas réaliste. Le SaaS standard reste souvent la solution la moins coûteuse au total.

Les fonctions périphériques non critiques. Il n'est pas nécessaire de reconstruire soi-même un outil de visioconférence ou un système de signature électronique si ces usages ne touchent pas à des données sensibles. La logique du "construire seulement ce qui est stratégique" est saine.

Les déploiements qui nécessitent une disponibilité mondiale immédiate. Un SaaS comme Zoom ou Slack peut être utilisé depuis n'importe quel pays avec des latences acceptables grâce à une infrastructure de CDN mondiale. Reproduire cela en interne a un coût que peu d'organisations peuvent assumer.

L'honnêteté intellectuelle exige de reconnaître ces limites. Ce projet ne propose pas un dogme anti-SaaS. Il propose une réhabilitation de la logique de construction là où elle est stratégiquement justifiée.

VIII. Ce à quoi ressemble la prochaine étape

8.1 La roadmap technique en cours

Ce projet est un point de départ, pas un produit fini. Les prochaines étapes sur la roadmap technique incluent :

Chiffrement de bout en bout pour les documents sensibles. La suite héberge les données sur infrastructure propre, mais les données ne sont pas chiffrées de manière à ce que même l'administrateur de l'infrastructure ne puisse y accéder. Pour les cas d'usage les plus sensibles, un chiffrement côté client avec gestion des clés par l'utilisateur est nécessaire.

Intégration d'un modèle de langage local. L'étape suivante est d'intégrer un LLM auto-hébergé (Ollama + modèle open source) pour des fonctionnalités d'assistance à la rédaction, de résumé et de recherche sémantique, sans que les contenus ne quittent l'infrastructure.

API publique versionnée. Pour permettre l'intégration avec d'autres outils internes ou des automatisations personnalisées, sans passer par des connecteurs propriétaires.

Module de publication web. La production documentaire débouche souvent sur une publication. Intégrer un système de publication léger (statique ou headless CMS) est logiquement la prochaine brique.

8.2 La question de la maintenance sur le long terme

La critique la plus sérieuse de l'approche "construire soi-même" porte sur la maintenance. Un logiciel qu'on a construit, on doit le maintenir. Les dépendances évoluent, les failles de sécurité apparaissent, les navigateurs changent leurs comportements.

C'est une réalité. Elle n'invalide pas l'approche, mais elle en définit les conditions de viabilité.

Premièrement, une architecture modulaire réduit la surface de maintenance. Si chaque composant est indépendant, une mise à jour affecte ce composant sans déstabiliser l'ensemble.

Deuxièmement, les bibliothèques choisies sont sélectionnées en partie sur la base de leur activité de maintenance communautaire. Yjs, TipTap, Keycloak, MongoDB, Ceph, Luckysheet : chacune de ces briques a une communauté active et un historique de maintenance documenté. Ceph en particulier bénéficie d'un soutien institutionnel fort (Red Hat, CERN, OVHcloud) qui réduit le risque d'abandon.

Troisièmement, et c'est peut-être le point le plus important pour la suite de ce document : l'IA change profondément le coût de la maintenance. Analyser un changelog, identifier les breaking changes, mettre à jour le code affecté, auditer les nouvelles dépendances : toutes ces tâches de maintenance routinière sont significativement accélérées par l'IA.

Conclusion : bâtir plutôt que louer, comprendre plutôt que consommer

Le point central de ce projet n'est pas technique. Il est organisationnel.

Pendant des années, le choix entre construire et acheter a été orienté vers l'achat par des facteurs réels : complexité de développement élevée, coûts d'infrastructure, difficulté à maintenir des compétences internes. Ces facteurs n'ont pas disparu, mais ils ont changé de proportion. Les coûts des licences SaaS augmentent. La complexité de sortie s'accroît à mesure que les intégrations s'accumulent. Et la barrière à la construction d'alternatives sérieuses s'est abaissée, grâce à l'IA et à la maturité de l'écosystème open source.

Ce n'est pas un appel à reconstruire tout depuis zéro, ni une critique de principe du cloud. C'est une invitation à réexaminer les choix de dépendance faits par défaut, à identifier les briques pour lesquelles construire est désormais faisable, et à recommencer à investir dans un patrimoine numérique que l'organisation possède réellement.

Ce projet le documente avec ses contraintes, ses choix et ses limites. Il ne prétend pas être une recette universelle. Il montre que pour des équipes techniques motivées et dotées des bons outils, l'alternative n'est plus théorique.

Une organisation qui ne construit pas son patrimoine numérique construit surtout sa dépendance.

La vraie question n'est plus "peut-on construire ?". Elle est "a-t-on décidé de le faire ?"

Le code source des composants principaux (architecture Docker, configuration Keycloak, schémas de base de données) est disponible dans le dépôt public associé à cet article.

Les données chiffrées sur les coûts SaaS présentées dans cet article sont des estimations construites à partir de grilles tarifaires publiques (Microsoft, Google, Atlassian, 2024) et d'études de marché publiées (Gartner, Forrester). Elles ne constituent pas des données auditées.