Souveraineté

Pouvez-vous le modifier lorsque vous en avez besoin ?

De nombreuses organisations avec lesquelles nous parlons ont fait ce que le débat sur la souveraineté leur demandait. Elles ont déplacé des services vers des fournisseurs européens, choisi des centres de données dans l’Union et ajouté les bonnes clauses à leurs contrats. Puis, lorsqu’elles ont dû modifier quelque chose de critique, elles ont découvert qu’elles ne le pouvaient pas. Le service d’identité dépendait encore d’un plan de contrôle externe. Le support passait par une autre juridiction. Les seules personnes capables de reconfigurer le système travaillaient pour le fournisseur.

C’est généralement là que commence la véritable question de souveraineté.

Nous utilisons souveraineté comme un mot d’ingénierie, pas comme une étiquette. La question n’est pas de savoir si un service porte un drapeau européen. Elle est de savoir si une institution peut voir les dépendances sous une fonction essentielle, comprendre qui les contrôle et continuer à agir lorsqu’il faut en modifier une.

Un système peut être hébergé en Europe tout en restant dépendant de décisions prises ailleurs. Un composant peut venir de l’extérieur de l’Europe et pourtant se trouver dans une architecture dont l’accès, les clés, l’exploitation et la voie de remplacement sont fermement sous contrôle institutionnel. La géographie est un élément de preuve. Ce n’est pas la réponse.

Notre position est plus étroite et, selon nous, plus utile. La souveraineté est une propriété opérationnelle d’un système, pas un attribut d’un fournisseur. Elle existe lorsque la dépendance est assez visible pour être gouvernée, assez circonscrite pour être modifiée et assez comprise pour que l’institution puisse juger les affirmations qui la concernent.

L’objet de la souveraineté est la dépendance

Lorsque la souveraineté est discutée comme une propriété des fournisseurs, la conversation se transforme en listes : fournisseurs approuvés, juridictions préférées, clouds certifiés. Les listes sont utiles pour les achats. Elles disent rarement à une institution si elle peut agir.

Nous partons d’ailleurs : de la fonction essentielle et des dépendances qui la soutiennent. L’unité que nous examinons est la relation entre une fonction et ce dont elle dépend.

Les questions pratiques sont simples à poser et souvent difficiles à résoudre :

• De quoi cette fonction dépend-elle réellement ?
• Qui peut modifier, suspendre ou contraindre cette dépendance ?
• Sous quelle juridiction et dans quelles conditions contractuelles fonctionne-t-elle ?
• Quelle partie l’institution contrôle-t-elle, techniquement et physiquement ?
• Qu’advient-il de la fonction si le fournisseur, la route ou la situation juridique change ?
• La dépendance pourrait-elle être isolée, remplacée ou placée sous un autre modèle d’exploitation ?

Une affirmation de souveraineté ne devient utile que lorsque les réponses peuvent modifier une décision. Sinon, l’affirmation est décorative.

Nous sommes à l’aise avec une réponse que beaucoup d’évaluations évitent : inconnu. Lorsqu’une dépendance ne peut pas être étayée, nous la laissons non résolue et nous le disons. « Inconnu » est une réponse acceptable. Une maîtrise supposée ne l’est pas.

Le contrôle a plusieurs couches

Il n’existe pas une seule couche de souveraineté. Une fonction numérique repose sur plusieurs systèmes qui peuvent avoir des propriétaires, des juridictions et des modes de défaillance différents. Nous trouvons utile de distinguer cinq formes de contrôle, car les institutions en sécurisent souvent une tout en en perdant une autre.

Physique. Les systèmes numériques reposent sur des routes de fibre, de l’électricité, des bâtiments et des nœuds de routage. Une application bien gouvernée sur un substrat que l’institution ne peut ni voir ni influencer reste exposée à des décisions prises ailleurs. L’accès juridique à une infrastructure et l’accès opérationnel effectif ne sont pas la même chose : un droit de demander l’accès peut encore dépendre de procédures contrôlées par quelqu’un d’autre.

Opérationnel. Qui peut réellement exploiter le système ? Qui peut déployer, révoquer un accès, détenir les clés, rétablir le service et modifier le routage ? Un service peut être hébergé au bon endroit et dépendre malgré tout d’un administrateur externe, d’un fournisseur d’identité ou d’une plateforme gérée pour toute action significative.

Juridictionnel. Le lieu apporte un élément de preuve mais ne règle pas la juridiction. L’exposition juridique dépend de l’opérateur, du propriétaire, de la société mère, de la partie contractante et du droit applicable à chaque relation. Un suffixe de domaine ou une adresse de bureau est un signal, pas une conclusion.

Chaîne d’approvisionnement. Le matériel, les micrologiciels, les mises à jour logicielles, les registres de paquets et la maintenance spécialisée sont tous des points de contrôle. En juillet 2024, une mise à jour défectueuse d’un seul fournisseur de sécurité a perturbé des systèmes dans des compagnies aériennes, des hôpitaux et des services publics partout dans le monde, quel que soit leur lieu d’hébergement. Déplacer une couche tout en laissant dessous un point de contrôle non examiné ne crée pas de souveraineté.

Information. Les institutions dépendent aussi de la manière dont leurs informations sont publiées et interprétées. Si des informations publiques ne peuvent être comprises qu’au travers d’une plateforme propriétaire ou des conjectures d’un fournisseur de modèle, une partie de la frontière de publication de l’institution s’est déplacée hors d’elle. C’est ici que la souveraineté rejoint notre travail sur la préparation à l’IA.

La réglementation européenne reflète de plus en plus cette vision en couches. NIS2 impose aux entités essentielles et importantes de traiter la sécurité de leurs chaînes d’approvisionnement, pas seulement celle de leurs propres systèmes. La logique est la même : le contrôle n’est jamais plus fort que la couche la moins examinée sous la fonction.

La propriété et le contrôle sont différents

Il est naturel d’associer souveraineté et propriété. Si nous le possédons, nous le contrôlons. En pratique, les deux se séparent constamment.

Une organisation peut posséder son infrastructure tout en dépendant d’un fournisseur pour l’administration, d’une plateforme propriétaire pour la configuration, d’une équipe externe pour la reprise ou d’une route amont pour la connectivité. La propriété confère un titre. Elle ne confère pas la capacité d’agir.

L’inverse est également vrai. Utiliser une infrastructure appartenant à quelqu’un d’autre ne supprime pas automatiquement le contrôle. Une relation gouvernée peut donner un contrôle réel si l’accès, l’autorité, la juridiction, la sécurité, la continuité et la sortie sont explicites et applicables.

Cela compte parce que cela ouvre une voie plus réaliste. Aucune institution ne peut posséder chaque câble, serveur et composant dont elle dépend. Elle peut toutefois définir les conditions dans lesquelles une dépendance est acceptable et s’assurer que ces conditions peuvent être vérifiées.

La question n’est pas « qui possède tout ? ». Elle est : quels droits et quelles capacités rendent le contrôle réel pour la fonction que nous devons protéger ?

Une liste d’alternatives n’est pas une sortie

Une assurance fréquente dans les discussions sur la souveraineté est que des alternatives existent. Il y a d’autres clouds, d’autres fournisseurs, d’autres produits. La dépendance ne serait donc pas un problème.

Une alternative disponible sur le marché n’est pas une sortie. Une dépendance n’est substituable que lorsque l’institution peut décrire comment la fonction essentielle passerait à une autre condition d’exploitation sans perdre de capacité, de données, d’identité, de sécurité ni la possibilité de se rétablir. Cela signifie généralement comprendre :

• comment les données quittent et rejoignent le système, et sous quelle forme ;
• comment l’identité et l’accès changent ;
• de quels protocoles et interfaces la fonction dépend ;
• comment les clés et certificats se déplacent ;
• quelles procédures et compétences doivent changer ;
• quelles contraintes contractuelles ou juridiques s’appliquent ;
• combien de temps l’ancien et le nouveau système doivent fonctionner en parallèle, et comment revenir en arrière.

Le Data Act a commencé à traiter une partie de cette question pour les services cloud en établissant des obligations qui facilitent le changement de fournisseur. C’est une étape significative. Elle ne rend pas, à elle seule, une institution particulière capable de changer. La substituabilité n’est pas une propriété du marché. C’est une propriété du système déployé.

Notre test de souveraineté le plus fort en découle : l’architecture peut-elle être modifiée délibérément sans perdre la fonction qu’elle existe pour protéger ?

La souveraineté exige la capacité de juger

Toute évaluation de souveraineté finit par reposer sur des affirmations. Un fournisseur déclare où les données sont traitées. Un contrat précise qui a accès. Un certificat atteste une norme. Un plan de migration promet que le changement est possible.

Certaines de ces affirmations sont bien fondées, d’autres non. La différence n’est visible que pour quelqu’un capable de les juger.

C’est pourquoi nous traitons le jugement comme une condition de la souveraineté, et non comme un supplément facultatif. Une institution qui ne peut pas évaluer ce que ses fournisseurs lui disent au sujet du contrôle n’est pas en contrôle. Elle fait confiance. Cette confiance peut être justifiée, mais c’est autre chose.

Le jugement, ici, n’est ni un document ni une checklist. C’est un état que l’institution doit atteindre et maintenir : des personnes qui comprennent assez bien les dépendances pour poser les bonnes questions, reconnaître une réponse évasive et savoir quelle preuve trancherait la question. Cela s’applique aussi aux systèmes qu’utilise l’institution. Un système de suivi ou d’achat qui ne peut pas distinguer une déclaration d’un fait vérifié transmettra cette confusion à tous ceux qui s’y fient.

C’est ici que la souveraineté rejoint notre travail sur le transfert de capacité. Une propriété formelle sans la capacité de juger et de modifier un système est une forme faible de contrôle. Toute décision importante continue de passer par la compréhension de quelqu’un d’autre.

Toutes les preuves ne disent pas la même chose

Juger une affirmation de souveraineté commence par savoir ce que chaque type de preuve peut établir, et ce qu’il ne peut pas établir.

Une requête observée dans un navigateur peut montrer qu’une page contacte un tiers. Elle ne peut pas montrer où fonctionne le backend. Un enregistrement DNS peut montrer qu’un fournisseur est autorisé à envoyer du courrier au nom d’une organisation. Il ne peut pas montrer que ce même fournisseur héberge ses applications. La déclaration d’un fournisseur montre ce qu’il déclare. Elle ne montre pas de quoi dépend une charge de travail donnée à un moment donné. Un registre de propriété établit un titre juridique. Il n’établit pas l’indépendance opérationnelle.

Ce ne sont pas des faiblesses de la preuve. Ce sont ses limites. L’erreur consiste à combiner des signaux de nature différente dans un seul score de souveraineté qui masque ce que chacun prouve réellement.

Nous les gardons séparés. Un signal reste un signal. Des signaux indépendants qui concordent renforcent une constatation. Une conclusion devrait indiquer le type de preuve qui la soutient et les inconnues qui subsistent dessous.

La souveraineté n’est pas l’autarcie

La souveraineté est parfois entendue comme un appel à tout construire en interne ou à exclure toute dépendance étrangère. Ce n’est pas notre lecture, et nous ne pensons pas que cela fonctionnerait.

Les infrastructures complexes se construisent par l’interdépendance. Le travail consiste à savoir quelles dépendances sont acceptables, lesquelles sont stratégiques, lesquelles exigent des preuves plus fortes, lesquelles ont besoin d’une voie de sortie et lesquelles concentrent le contrôle d’une manière que l’institution ne devrait pas accepter.

Une bonne architecture de souveraineté peut inclure des fournisseurs externes, y compris non européens. Ce qu’elle ne peut pas inclure, ce sont des dépendances critiques que personne n’a cartographiées, que personne ne peut gouverner et que personne ne sait remplacer.

C’est la différence entre interdépendance et dépendance sans contrôle.

Comment nous travaillons ensemble

Notre approche de la souveraineté suit la même séquence que le reste de notre travail.

Cartographier la dépendance. Avant de proposer des alternatives, identifier ce dont la fonction dépend dans les couches physique, opérationnelle, juridictionnelle, de chaîne d’approvisionnement et d’information, et où le contrôle est concentré.

Définir la frontière de contrôle. Décider, avec l’institution, quelles dépendances sont acceptables, lesquelles nécessitent des conditions et lesquelles ne sont pas acceptables pour cette fonction. Exprimer ces conditions en termes vérifiables.

Construire l’alternative lorsque la frontière n’est pas acceptable. Pas tout à la fois. Les fonctions stratégiques d’abord, avec une voie de migration réellement travaillée plutôt que supposée.

Laisser derrière nous les preuves et le jugement. L’institution devrait terminer avec un dossier qu’elle peut maintenir et des personnes capables de juger seules la prochaine affirmation.

Nous appliquons la même discipline à nous-mêmes. L’infrastructure que nous exploitons et les formats ouverts que nous publions font partie de la manière dont nous testons si cette façon de travailler tient en pratique. Nous ne pouvons pas demander de façon crédible aux autres de rendre leurs dépendances visibles tout en traitant notre propre stack opérationnel comme une boîte noire.

Lorsque nous examinons une dépendance avec un partenaire, voici les questions que nous consignons généralement :

Là où nous sommes prudents

Nous nous imposons quelques engagements quant à ce que nous affirmons.

Nous ne qualifions une dépendance de contrôlée que dans la mesure où les preuves soutiennent le contrôle sur la fonction concernée.

Nous ne déduisons pas une juridiction d’un nom de domaine ou d’une adresse d’hébergement, et nous ne traitons pas la déclaration d’un fournisseur comme une preuve de la manière dont un système fonctionne.

Nous ne décrivons pas une dépendance comme remplaçable parce qu’une alternative existe sur le marché. Seule une voie de migration réellement travaillée mérite ce terme.

Nous ne cachons pas des dépendances non résolues derrière un score unique. Lorsque quelque chose est inconnu, nous le disons.

Et nous ne présentons pas la souveraineté comme de l’isolement. Notre objectif est plus étroit : la capacité pratique de savoir où se situe la dépendance, de décider quelle dépendance est acceptable et d’agir lorsqu’elle ne l’est pas.

Lectures complémentaires

• Directive (UE) 2022/2555 (NIS2), relative à des mesures destinées à assurer un niveau élevé commun de cybersécurité dans l’Union.
• Règlement (UE) 2023/2854 (Data Act), notamment les dispositions relatives au changement entre services de traitement de données.

Thèmes associés : Transfert de capacité · Résilience · Préparation à l’IA

Évolution de cette position

• 24 septembre 2026 — Première publication.

Les modifications substantielles sont indiquées ici avec leur date. Les corrections de formulation ou de liens ne le sont pas.