La souveraineté numérique commence par des choix d'architecture

On aborde souvent la souveraineté numérique comme une question de fournisseur : quel hébergeur, dans quel pays, avec quel contrat. Ces questions comptent, mais elles arrivent tard. Les décisions qui déterminent réellement l'autonomie d'une organisation sont prises bien plus tôt, au moment où l'on conçoit l'architecture de ses systèmes.

Un système peut être hébergé au bon endroit et rester pourtant impossible à comprendre, à déplacer ou à faire évoluer sans son intégrateur d'origine. À l'inverse, une architecture bien pensée laisse à l'organisation de vrais choix, y compris celui de changer d'hébergeur le jour où ses besoins ou le contexte réglementaire évoluent.

Ce que recouvre vraiment la souveraineté

Être souverain sur un système numérique, c'est pouvoir en garder la maîtrise dans la durée. Cette maîtrise repose sur trois dimensions complémentaires, et une faiblesse sur l'une suffit à compromettre les deux autres.

• Les données : savoir où elles sont, qui y accède, sous quelle juridiction, et pouvoir les récupérer intégralement.
• La technologie : pouvoir remplacer un composant, un logiciel ou un fournisseur sans devoir tout reconstruire.
• Les compétences : disposer, en interne ou chez des partenaires choisis, des personnes capables d'opérer et de faire évoluer le système.

Cartographier les données avant de choisir un hébergement

Aucune politique de résidence des données ne peut être appliquée sans un inventaire préalable. La première étape consiste donc à décrire les données que le système traite, leur niveau de sensibilité et leurs déplacements. C'est souvent à ce moment que l'on découvre des flux oubliés : une sauvegarde répliquée à l'étranger, un outil d'analyse qui reçoit des journaux complets, un service tiers qui stocke des pièces jointes.

Cette cartographie n'est pas un exercice ponctuel. Elle doit être tenue à jour à chaque nouvelle intégration, car c'est précisément par l'ajout progressif de services que la maîtrise se perd.

• Classifier les données selon leur sensibilité et les obligations qui s'y appliquent.
• Identifier chaque lieu de stockage, y compris les sauvegardes, les journaux et les environnements de test.
• Tracer les flux entre systèmes et vers les fournisseurs externes.
• Documenter la juridiction applicable à chaque lieu de traitement et à chaque sous-traitant.

Concevoir pour pouvoir partir

La réversibilité est le test le plus concret de la souveraineté. Si changer d'hébergeur ou de progiciel impose de réécrire l'application, l'organisation n'a pas de véritable choix : elle a une dépendance. La réversibilité ne se négocie pas en fin de contrat ; elle se construit dans l'architecture.

Une clause contractuelle de réversibilité n'a de valeur que si elle est techniquement réalisable. Le meilleur moyen de le vérifier reste de la tester : exporter réellement les données, les recharger dans un autre environnement et mesurer l'effort nécessaire.

• Formats de données ouverts, documentés et exploitables sans le logiciel d'origine.
• Interfaces standardisées et versionnées entre les composants.
• Infrastructure décrite en code, donc reproductible ailleurs.
• Exports complets testés régulièrement, pas seulement prévus au contrat.

Repérer les dépendances invisibles

Les dépendances les plus coûteuses sont rarement les plus visibles. Elles se logent dans des services gérés propriétaires adoptés pour leur commodité, dans la gestion des identités, dans les outils de supervision ou dans des fonctionnalités spécifiques à une plateforme utilisées sans y prêter attention.

Il ne s'agit pas de refuser ces services : ils apportent souvent une vraie valeur. Il s'agit de les choisir en connaissance de cause, en sachant ce qu'il faudrait faire pour s'en passer. Quelques questions simples, posées à chaque décision d'architecture, suffisent à rendre ces dépendances explicites.

• Ce composant a-t-il un équivalent ouvert ou disponible chez d'autres fournisseurs ?
• Nos données y sont-elles stockées dans un format que nous pouvons relire ailleurs ?
• Combien de temps et d'effort faudrait-il pour le remplacer ?
• Qui, dans l'organisation, comprend son fonctionnement ?

Les compétences, dernier maillon de l'autonomie

Un système parfaitement documenté reste fragile si personne dans l'organisation n'est capable de l'opérer. L'autonomie repose en dernier ressort sur des personnes. Impliquer les équipes internes dès la conception, documenter les choix d'architecture et prévoir un transfert de compétences structuré sont ce qui permet à un système de survivre au départ de son intégrateur.

C'est aussi un choix économique : une organisation qui comprend ses systèmes négocie mieux, arbitre plus vite et dépend moins de prestations d'urgence.

Par où commencer

La souveraineté numérique ne se décrète pas en une fois. Elle progresse par des décisions cohérentes, prises projet après projet. Pour un système existant comme pour un nouveau projet, une démarche en cinq étapes permet de passer des principes à la pratique.

• Établir la cartographie des données et de leurs flux.
• Identifier les composants les plus difficiles à remplacer.
• Tester un export complet et un rechargement dans un autre environnement.
• Inscrire la réversibilité et la documentation dans les critères d'architecture.
• Planifier le transfert de compétences vers les équipes qui opéreront le système.

Le choix d'un hébergeur ou d'un fournisseur reste important. Mais il devient beaucoup plus simple, et beaucoup moins engageant, lorsque l'architecture a été conçue pour que ce choix puisse être revu.