Souveraineté numérique : ce que cela veut vraiment dire

Ce qu’est la souveraineté, et ce qu’elle n’est pas

La souveraineté, au fond, signifie la maîtrise : le droit et la capacité de décider de ce qui se passe, sans qu’un autre en décide par-dessus votre tête. En théorie de l’État, cela concerne un pays. La souveraineté numérique applique la même idée à votre système d’information.

Pour une organisation, elle se décompose en trois questions, et il vaut mieux les poser séparément :

• Qui peut accéder à vos données ? Non seulement qui en a le droit, mais qui le peut techniquement et juridiquement, y compris sans que vous le remarquiez.
• Qui décide si votre technique continue de fonctionner ? Une licence non renouvelée, un service arrêté, un prix qui double : ce sont autant de décisions d’un autre qui atterrissent sur votre exploitation.
• Pouvez-vous partir ? Et pas en théorie. Pouvez-vous le démontrer, dans un délai auquel vous survivez ?

Ce qu’elle n’est pas : l’autarcie. Tout construire et tout gérer soi-même n’est un choix raisonnable pour presque aucune organisation, et cela ne produit pas non plus de souveraineté : cela déplace seulement la dépendance vers les deux personnes qui comprennent le système. La souveraineté ne consiste pas à externaliser moins, mais à externaliser en gardant la sortie en vue.

Pourquoi un centre de données européen ne suffit pas

C’est là que la plupart des discussions s’enlisent, et c’est le point qui compte.

Le CLOUD Act américain de 2018 établit que les autorités des États-Unis peuvent contraindre un fournisseur relevant de leur juridiction à remettre des données qu’il détient ou contrôle, quel que soit le pays où ces données se trouvent physiquement. La loi s’attache à la maîtrise des données, non à leur emplacement. Un centre de données européen appartenant à une maison mère américaine n’y change rien en soi.

Par-dessus se pose le versant européen. La Cour de justice a invalidé le Privacy Shield dans l’arrêt Schrems II en 2020 ; depuis 2023, une nouvelle décision d’adéquation encadre les transferts vers les États-Unis. Cette décision rend les transferts praticables, mais elle ne répond pas à la question de juridiction : elle règle les conditions dans lesquelles les données peuvent franchir la frontière, pas qui peut les revendiquer de l’autre côté.

Les grands fournisseurs y répondent désormais par des variantes dotées d’une entité juridique européenne, d’un personnel européen et d’une exploitation qui ne quitte pas le continent. Elles ne sont pas creuses — elles déplacent réellement la maîtrise — mais elles ne sont ni gratuites ni disponibles partout, et les conditions exactes diffèrent selon le fournisseur et le service. Lisez-les, et faites-les examiner par un juriste avant de bâtir dessus. Nous sommes une entreprise informatique et non un cabinet d’avocats : nous pouvons vous montrer où se trouve la technique et ce qui est déplaçable, pas ce qu’un juge en dira.

Les trois couches où loge la dépendance

En pratique, il est utile de regarder la souveraineté couche par couche, car le coût et les possibilités y varient énormément.

• Les données. Où elles se trouvent, qui détient les clés qui les chiffrent, et où sont les sauvegardes. C’est la couche la moins chère à traiter et le plus souvent la plus importante.
• La technique. Votre application tourne-t-elle sur quelque chose qui tourne aussi ailleurs, ou sur un service qui n’existe qu’à un seul endroit ? Une base de données dans un conteneur déménage. Un service qui n’existe que chez un fournisseur ne déménage pas : il se reconstruit.
• L’exploitation. Qui se connecte pour administrer, depuis quel pays, et de quel droit relève la partie qui le fait. C’est la couche la plus souvent oubliée et la première à compter lors d’un incident.

Les trois ne voyagent pas ensemble. Vos données peuvent être en Europe pendant que l’administration se fait depuis un autre continent, et vous pouvez avoir un fournisseur entièrement européen qui utilise un logiciel dont vous ne vous déferez jamais. Traiter la souveraineté comme une case unique revient à cocher la couche qui était la plus facile à régler.

Ce que disent réellement les règles

On cite beaucoup de textes pour justifier des exigences de souveraineté. Voici ce qu’ils disent, et où ils s’arrêtent.

Le RGPD pose des conditions aux transferts hors de l’Espace économique européen et à ce que vous convenez avec les sous-traitants. Il n’exige pas un fournisseur européen ; il exige que vous puissiez expliquer où vont les données et sur quelle base.

NIS2, déclinée aux Pays-Bas sous le nom de Cyberbeveiligingswet, demande une gestion du risque dans la chaîne d’approvisionnement et place la responsabilité expressément au niveau de la direction. Ce n’est pas non plus une exigence de souveraineté, mais cela oblige à écrire quel fournisseur apporte quel risque — et c’est exactement l’inventaire par lequel ce sujet commence.

DORA s’applique aux entités financières depuis janvier 2025 et va le plus loin : elles doivent disposer d’une stratégie de sortie pour les prestataires informatiques critiques et peser explicitement le risque de concentration. C’est aujourd’hui l’équivalent légal le plus proche de ce dont traite cet article.

Le règlement européen sur les données s’applique depuis septembre 2025 et oblige les fournisseurs à rendre le changement possible plutôt qu’à le compliquer par contrat ; les frais qu’ils peuvent facturer pour cela doivent disparaître progressivement. Pour ce sujet, c’est l’évolution la plus utile de ces dernières années.

Un schéma européen de certification pour le cloud est en chantier depuis des années, et le niveau auquel des exigences de souveraineté s’appliqueraient est précisément la partie sur laquelle il bute. Ne comptez pas dessus au moment où vous devrez choisir.

Ce que l’on fait concrètement

Voici une échelle, du bon marché au coûteux. La plupart des organisations ne dépassent pas les trois premiers barreaux, et c’est généralement bien suffisant.

• Écrivez où se trouve chaque chose. Quel service, quel fournisseur, quel pays, sous quel droit, et ce qui s’arrête s’il disparaît. Cela coûte un après-midi et c’est la seule étape dont vous aurez besoin de toute façon : pour NIS2, pour votre assureur et pour vous-même.
• Placez vos sauvegardes ailleurs. Chez un autre fournisseur, dans une autre juridiction, écrites de façon immuable. C’est le barreau au meilleur rendement par euro : il protège contre un fournisseur qui disparaît, contre les rançongiciels et contre une facture impayée. Comment nous l’organisons figure sous sauvegarde et continuité.
• Gardez vos propres clés quand c’est possible. Un chiffrement avec des clés que vous conservez limite ce qu’un fournisseur peut produire quand on le lui demande. Sachez toutefois ce que vous achetez : dans beaucoup de services, la clé doit passer par la mémoire du fournisseur pour être utilisable, et la protection devient alors procédurale et non mathématique.
• Testez la sortie. Un plan de sortie jamais exécuté est un document, pas un plan. Une fois par an, restaurez un environnement chez un autre acteur et mesurez le temps que cela a pris. Presque personne ne le fait, et presque tous ceux qui le font tombent sur quelque chose.
• Déplacez ce qui est déplaçable. Ce n’est qu’ici qu’apparaissent les variantes souveraines, les fournisseurs européens ou le matériel en propre — une fois les quatre premiers barreaux en place et si l’arbitrage penche toujours de ce côté.

La question inverse en fait partie aussi : quand cela ne s’impose pas. Si vous ne traitez pas de catégories particulières de données personnelles, que vous ne relevez ni de NIS2 ni de DORA et qu’aucun client ne l’exige, le premier barreau suffit et les quatre autres sont de l’argent qui rapporte davantage ailleurs. Nous le disons aussi quand cela nous coûte le travail.