Souveraineté logicielle : garder les données, les clés et le choix
La souveraineté ne signifie pas tout héberger seul. Elle signifie conserver la capacité réelle d’expliquer, d’exporter, de remplacer et d’opérer les composants critiques du produit sans demander la permission à un fournisseur.
Définir ce qui ne doit pas devenir captif
Commencez par l’inventaire des actifs critiques : données utilisateur, historique de décisions, règles métier, identités, clés, prompts, évaluations et formats d’export. Tous ne demandent pas le même niveau de contrôle.
Pour chacun, posez une question simple : si ce fournisseur disparaît ou change ses conditions demain, pouvons-nous continuer à servir l’utilisateur ? La réponse détermine où investir dans la portabilité, le local-first ou l’auto-hébergement.
Traiter les données au plus près du besoin
Le local-first est utile quand la latence, la confidentialité, le travail hors ligne ou la propriété des données sont déterminants. Il ne supprime pas le cloud ; il évite d’en faire le seul endroit où le produit et les données peuvent exister.
La minimisation reste le premier levier. Ne pas collecter une donnée réduit davantage le risque que de multiplier les couches de protection autour d’une collecte inutile. Documentez la finalité, la durée de conservation et le chemin d’effacement avant l’intégration d’un modèle.
Créer une frontière autour des fournisseurs
Les appels de modèles, de stockage ou d’envoi doivent passer par des contrats internes stables. Conservez les formats métier dans votre système et traduisez-les à la frontière du fournisseur. Cela évite que son schéma devienne votre architecture.
La portabilité ne demande pas de maintenir cinq fournisseurs en parallèle. Elle demande un scénario de sortie testé : export complet, remplacement d’une clé, migration d’un petit échantillon et estimation des fonctions qui seraient perdues.
Garder les moyens d’opérer et de revenir en arrière
Les secrets doivent rester séparés du code, avec des droits minimaux et une rotation possible. Les actions critiques ont besoin d’un journal, d’un responsable et, si possible, d’une compensation ou d’un retour arrière.
Enfin, gardez un mode dégradé utile. Quand un modèle distant est indisponible, le produit peut parfois revenir à une recherche, une règle, un traitement local ou une file d’attente. La souveraineté se mesure aussi le jour où une dépendance tombe.
Le test de souveraineté
- 01
Les données critiques sont exportables dans un format documenté
- 02
Les règles métier ne vivent pas uniquement dans un fournisseur
- 03
Les secrets sont séparés, limités et rotatifs
- 04
Un changement de modèle ne réécrit pas tout le produit
- 05
La suppression et la rétention sont opérables
- 06
Un scénario de sortie fournisseur a été testé
- 07
Un mode dégradé conserve une utilité réelle