Le principe
Le local-first couvre tout ce qui constitue la mémoire du cabinet : DCE, mémoires techniques, grilles de prix, fiches projet, retours clients, actes notariés. Ces matériaux sont stockés sur vos machines — un serveur de bureau correctement dimensionné suffit dans la plupart des cas. Par défaut, le système qui les exploite tourne là où elles sont stockées.
La distinction est fine mais décisive. Local-first ne signifie pas jamais le cloud ; il signifie jamais le cloud sans raison nommée. Quand le cloud est convoqué, c’est explicite, tracé, et toujours sur une donnée triée.
Pourquoi
Trois raisons, dans l’ordre d’importance.
La première est juridique. Selon le métier, les données traitées sont couvertes par une obligation de confidentialité (cabinets juridiques, comptables), une obligation contractuelle (clauses de confidentialité avec les maîtres d’ouvrage en BTP), ou par le RGPD, qui s’applique dès qu’un dossier contient une donnée personnelle — ce qui est presque toujours le cas. Confier ces données par défaut à un fournisseur tiers, hors UE, soumis à des juridictions étrangères, expose le cabinet à un risque qu’aucune signature ne couvre.
La deuxième est stratégique. Les données du cabinet sont un actif. La mémoire des références, des prix, des chantiers gagnés et perdus, des relations clients — c’est ce qui distingue votre cabinet d’un cabinet débutant. Confier cet actif à un fournisseur tiers, c’est accepter qu’il l’utilise pour entraîner ses modèles ou l’agréger à des bases de référence. C’est aussi accepter qu’il disparaisse, en emportant l’actif, lors d’une fermeture de service.
La troisième est économique. Les coûts d’un système hébergé chez le fournisseur croissent avec l’usage et avec les changements de tarification du fournisseur. Les coûts d’un système local sont prévisibles après installation — un serveur de bureau, une fois acheté, ne facture pas chaque requête. Il consomme de l’électricité, demande une maintenance, sera renouvelé tous les cinq ans ; ces coûts sont connus à l’avance et n’évoluent pas selon la décision d’un tiers.
Quand le cloud, alors ?
Quand le cloud apporte une capacité que le local ne peut pas reproduire. Trois cas typiques :
- Modèles propriétaires de pointe — ceux dont la frontière de capacité ne peut pas tourner sur du matériel raisonnable, et qui apportent un saut qualitatif net sur certaines tâches.
- Archivage de longue durée de très gros volumes documentaires que le cabinet n’a pas vocation à héberger (archives anciennes, sauvegardes versionnées, historique distant).
- Collaboration multi-sites où plusieurs implantations du cabinet travaillent sur un même corpus partagé.
Dans ces trois cas, le cloud est utilisé comme une complémentarité, pas comme un défaut. Et les données qui y transitent sont triées : ce qui peut sortir, ce qui ne peut pas.
Conséquence pratique
Le système installé chez vous comprend systématiquement :
- Un stockage local des dossiers et de la mémoire collective : Wiki métier, bibliothèque de mémoires techniques, bibliothèque interrogeable en langage naturel.
- Un ou plusieurs modèles ouverts en local (Gemma, Llama, Mistral) pour les tâches qui ne nécessitent pas un modèle propriétaire de pointe.
- Un sélecteur de modèles qui décide, par tâche, lequel mobiliser — local par défaut, cloud propriétaire si la tâche le justifie.
Le manuel d’installation documente ces choix, dossier par dossier, et permet à votre équipe de modifier la sélection si vos contraintes évoluent.