Le sovereign cloud, c’est un tri du portefeuille, pas un changement de fournisseur

L’erreur la plus bruyante que je vois dans les discussions sur le « sovereign cloud », c’est de le traiter comme un sujet d’achats : remplacer AWS par un fournisseur européen, mettre à jour le slide deck, et proclamer la victoire.

Les opérateurs savent que ça ne tient pas. La souveraineté réelle est une propriété d’exploitation. Elle se joue dans la manière dont l’identité est gouvernée, l’endroit où les clés sont détenues, la façon dont les logs sont conservés, la circulation des données, et votre capacité à sortir sous contrainte. Si ces mécanismes sont fragiles, changer de logo de fournisseur ne change rien. Vous payez juste une migration, et vous ajoutez un nouveau mode de défaillance.

C’est pour cela que l’actualité où un grand constructeur aéronautique européen prévoit de migrer 70 systèmes critiques d’AWS vers le fournisseur cloud français Scaleway compte. Pas parce que « l’Europe, c’est bien, les États-Unis, c’est mal ». Parce que cela impose la seule question qui vaille : qu’est-ce qui met, précisément, ces 70 systèmes « sous contrôle européen », et comment cela sera-t-il audité dans deux ans, quand tout le monde sera épuisé par le programme ?

Quand je dirigeais une business unit internationale dans le smart-building et les contrôles connectés, puis lorsque j’ai piloté des opérations couvrant l’ingénierie, la production et le service dans l’électrification et le stockage d’énergie, j’ai appris une règle simple : si un contrôle ne se teste pas, il ne résiste pas au réel. La souveraineté cloud suit la même logique.

La seule définition utile : la souveraineté, c’est un contrôle auditable

Peu importe comment votre fournisseur se présente. Ce qui compte, c’est votre capacité à prouver, à la demande, qui accède à quoi, qui peut déchiffrer quoi, quelles données ont franchi la frontière, et à quelle vitesse vous pouvez déplacer un workload ailleurs.

Cette preuve vient d’un control plane. Pas « une plateforme », pas « une landing zone », pas des « best practices ». Un ensemble concret de mécanismes qui contraignent les comportements, au quotidien.

Si vous cherchez une image, prenez-la dans l’industrie. Une usine n’est pas « sûre » parce que ses machines sont européennes. Elle l’est parce que le lockout-tagout, le change control, les carnets de maintenance et les exercices de sécurité existent — et s’imposent. Votre posture de sovereign cloud exige la même discipline.

Étape 1 : trier — classer le portefeuille avant de toucher à quoi que ce soit

Les changements de fournisseur échouent parce que les équipes partent du plan de migration, pas de la vérité des workloads. Commencez par classer le portefeuille en quatre catégories. Puis ne migrez que ce que cette classification impose.

1. Workloads d’ancrage (à migrer impérativement). Ce sont des systèmes où l’exposition juridique, les contrôles export ou les contrats clients posent des contraintes non négociables. Souvent : annuaires d’identité, gestion des clés, télémétrie sécurité et une partie des plateformes data. Les déplacer coûte cher, mais les laisser en place réduit la souveraineté à un récit.
2. Workloads couplés (à migrer plus tard, après découplage). Ils sont « critiques » surtout à cause des intégrations : services adjacents à l’ERP, middleware d’intégration, bases partagées, message brokers. En lift-and-shift, vous importez de la fragilité dans le nouvel environnement.
3. Workloads commodités (à laisser, mais à encadrer). Outils collaboratifs, outillage développeur, analytics génériques. Ici, la souveraineté se gagne par la politique et la minimisation des données, pas par la relocalisation. Vérifiez que vous ne stockez pas des données régulées là où elles n’ont pas leur place, puis arrêtez-vous là.
4. Candidats à l’arrêt (à ne pas migrer). Le gain le plus rapide en souveraineté, c’est de retirer des systèmes que vous auriez dû tuer il y a trois ans. La migration est une excellente occasion de supprimer.

Ce tri n’est pas un workshop technique. C’est une décision de leadership. Il force des arbitrages : coût, risque de delivery, et ce que « critique » veut réellement dire.

Les patterns de control plane qui rendent la souveraineté concrète

Une fois le tri fait, il faut des patterns qui produisent des preuves. Ce sont ceux que j’exigerais, que je sois à la tête d’une activité à forte empreinte industrielle ou que je construise une plateforme SaaS comme IBHQ.

1) L’identité est la racine du contrôle

La souveraineté s’effondre si votre plan d’identité est, de fait, piloté ailleurs. Le pattern est simple :

• Une identité de référence pour les identités humaines et machines. Pas de cas particuliers par cloud.
• Les accès privilégiés sont isolés : identités admin séparées, élévation courte, et circuits d’approbation explicites.
• Des comptes break-glass existent et sont testés, pas seulement documentés.

Si vous ne pouvez pas répondre à : « qui peut prendre un rôle admin dans l’environnement souverain, et quelle dépendance externe accorde ce droit ? », vous n’avez pas de souveraineté. Vous faites de l’hébergement.

2) Les clés ne sont pas une fonctionnalité, c’est une question de garde

Tous les fournisseurs parlent chiffrement. La question d’opérateur, c’est la garde : qui peut contraindre l’accès, et où les clés sont-elles réellement contrôlées ?

• Centralisez la gestion des clés avec une ownership claire. Ne laissez pas chaque équipe produit inventer sa propre histoire crypto.
• Séparez les domaines de clés selon la classe de données. Les jeux de données régulés ne doivent pas partager le même blast radius que le reste.
• Faites de la rotation et de la révocation un exercice. Si vous ne savez pas tourner des clés sans interruption, votre posture est fragile.

C’est ici que la « souveraineté numérique » cesse d’être politique et devient opérationnelle.

3) Le logging est la piste d’audit, pas un sujet secondaire

En qualité industrielle, si un événement n’est pas logué, il n’a pas eu lieu. Dans le cloud, si un accès n’est pas logué, vous ne pouvez pas le gouverner.

• Centralisez les logs sur l’ensemble des clouds et on-prem, y compris les événements d’identité, les actions admin et les accès aux données.
• Rendez les logs infalsifiables : stockage write-once ou contrôles équivalents, avec une rétention alignée sur vos obligations.
• Définissez un « audit query pack » : quelques requêtes que vous exécutez en minutes pour répondre aux régulateurs, aux clients et aux équipes incident response.

Cela rejoint directement ma manière de voir l’IA (intelligence artificielle) appliquée. L’IA peut aider à résumer et à trier, mais la couche de vérité reste la trace d’événements. Pour un angle complémentaire, mon article AI leadership is workflow leadership s’applique ici : la souveraineté aussi est une chaîne de handoffs, pas un choix technologique.

4) La gravité des données décide de ce qui peut bouger

La plupart des programmes de souveraineté échouent sur la gravité des données, pas sur le compute. Les données tirent avec elles les applications, les intégrations et les workflows.

• Classez les données par exigences de résidence et sensibilité, puis cartographiez où elles vivent réellement aujourd’hui.
• Concevez des « data egress choke points ». Pas pour bloquer le business, mais pour rendre les mouvements explicites et mesurables.
• Faites porter la souveraineté par le data product. Une plateforme data souveraine, avec des frontières d’accès strictes, peut servir de nombreuses applications sans tout migrer.

Dans les technologies industrielles, nous avons appris que des capteurs connectés n’achètent pas la disponibilité. La discipline d’exploitation, si. Même logique ici. Si vos data contracts sont approximatifs, aucun choix de cloud ne vous sauvera. C’est pour cela que je reviens souvent à l’idée que l’échec commence souvent par le data contract.

5) Les tests de sortie sont le seul KPI crédible de souveraineté

Chaque fournisseur promet la portabilité. À vous de transformer cette promesse en routine.

• Définissez des objectifs de sortie par classe de workloads : RTO, RPO, et modes dégradés acceptables.
• Automatisez les exports des données, configurations et définitions d’infrastructure. Si c’est manuel, cela ne tiendra pas sous stress.
• Exécutez des tests de sortie comme des exercices incendie : trimestriels pour les ancrages, semestriels pour les workloads couplés, et au moins une fois pour le reste.

C’est la partie que beaucoup de dirigeants évitent parce qu’elle ressemble à du « travail perdu ». Ce n’est pas perdu. C’est une assurance — et c’est aussi un levier dans chaque négociation fournisseur.

Une leçon vécue : les migrations sanctionnent l’ambiguïté, pas la complexité

Quand j’ai reconstruit et fait passer à l’échelle une organisation R&D couvrant l’embarqué, le cloud, l’électronique, la mécanique et la QA, j’ai constaté que les programmes multi-domaines cassent quand les responsabilités sont floues. Les équipes font ce qu’elles peuvent mesurer, et ignorent ce qu’elles ne peuvent pas.

Les programmes de sovereign cloud sont, par nature, multi-domaines : la sécurité veut des contrôles, le juridique veut une position défendable, l’ingénierie veut de la disponibilité, la finance veut de la prévisibilité. Si vous ne traduisez pas la « souveraineté » en control plane mesurable, chaque fonction en donnera sa propre interprétation — et l’exécution se transforme en débat.

Dans mes propres ventures, notamment lors de la construction d’IBHQ et de Shopeno, je m’appuie sur des règles simples d’opérateur : standardiser l’identité, centraliser le logging, garder les clés sous une garde clairement attribuée, limiter la dispersion des données régulées, et tester les sorties. Ces règles réduisent le risque de dépendance sans ralentir le travail produit.

Mon point de vue : le sovereign cloud se mérite par la discipline d’exploitation

La souveraineté, ce n’est pas le fournisseur. C’est la preuve.

Si vous voulez que cela fonctionne ce trimestre, faites trois choses. D’abord, triez le portefeuille : migrer, encadrer, découpler, arrêter. Ensuite, mettez en place le minimum du control plane : identité, clés, logs, frontières de données, tests de sortie. Enfin, exigez des preuves. Si un contrôle ne se teste pas, il n’existe pas.

C’est comme cela que vous évitez le théâtre, et que « sous contrôle européen » veut encore dire quelque chose quand la prochaine crise arrivera.