Souveraineté numérique : votre infrastructure cloud est-elle votre plus grande faille juridique ?

L’autonomie est plus que stratégique !
En 2026, dans un contexte géopolitique de tensions croissantes, confier son système d'information à des acteurs extra-européens peut présenter des risques. La géopatriation, à savoir le fait de rapatrier ses données et sa gouvernance en Europe devient la nouvelle norme pour les entreprises qui souhaitent garder le contrôle.

Avez-vous vraiment besoin d'un hyperscaler (AWS, Azure, Google Cloud Platform…) ? Découvrez les avantages du sur-mesure souverain.

AU SOMMAIRE DE CET ARTICLE :

1. L'illusion du datacenter local : Pourquoi la géographie ne vous protège plus.
   1. Le Cloud Act : pourquoi votre SLA ne vaut rien face au droit américain
   2. NIS 2 : L’obligation légale de contrôle
2. Stratégie cloud, l'hyperscaler n'est PAS forcément le meilleur choix
   1. L'expertise humaine VS le catalogue de services infinis
   2. Attention au risque de dépendance
   3. Replacer le besoin au centre de l’architecture
3. Migrer vers du souverain la méthode Codéin
   1. Les architectures "Standards" : La migration par translation
   2. Les architectures "Cloud Native" : Le défi du Vendor Lock-in
   3. L'humain au cœur du système
4. Finops : Passez de la facture aléatoire au budget maîtrisé
5. Tableau comparatif hyperscaler vs cloud souverain européen 

Conclusion : Quel choix pour votre infrastructure ? 

L'illusion du datacenter local : Pourquoi la géographie ne vous protège plus.

Certains pensent, à tort, que le fait d'héberger leurs données dans un datacenter situé en France suffit à les protéger, or la souveraineté est une question de juridiction. (La juridiction signifie le pouvoir d’un état et de ses tribunaux d’appliquer ses propres lois.)

Le Cloud Act : pourquoi votre SLA ne vaut rien face au droit américain

L’extra-territorialité du droit américain peut donc à tout moment devenir un risque de rupture d'activité immédiate.

Scénario possible : Imaginez une ETI française, leader dans l'énergie. Ses données R&D sont sur un cloud US. Suite à des tensions diplomatiques, Washington émet un gag order (ordonnance de non publication) L'hébergeur suspend les accès. L'usine s'arrête, le site est HS, et le support technique ne peut rien vous dire. Votre SLA s'efface devant la loi américaine. Confier ses données à un acteur soumis au Cloud Act, c’est accepter que votre "bouton on/off" puisse être activé depuis Washington.

Côté Européen et Français, la loi NIS 2 enfonce le clou.

NIS 2 : L’obligation légale de contrôle

Qu’est-ce que NIS 2 ? 

NIS 2est une directive européenne qui succède à NIS 1. Son but est d'harmoniser et d'élever le niveau de cybersécurité au sein de l'Union Européenne face à l'augmentation des cyberattaques. Elle a été transposée dans le droit français pour entrer en application pleine en 2025-2026.
Contrairement au RGPD qui protège les données personnelles, NIS 2 protège les réseaux et les Systèmes d'Information indispensables au fonctionnement de l'économie et de la société.

NIS 2 : 5 mesures de gestion des cyber-risques

1. La responsabilité des dirigeants : ils doivent valider les mesures prises et peuvent être formés et sanctionnés personnellement.
2. La sécurité de la chaîne d'approvisionnement : l'entreprise doit garantir la sécurité des produits et services de ses fournisseurs (donc de ses hébergeurs et agences web).
3. La gestion des incidents : obligation de notifier l'ANSSI en cas d'incident significatif (alerte sous 24h, rapport détaillé sous 72h).
4. La continuité d'activité : mise en place de plans de secours (PRA/PCA) et de gestion de crise.
5. lA cybersécurité de base : chiffrement, contrôle des accès…

NIS 2 : objectifs et sanctions

• Éviter qu'une cyberattaque sur un sous-traitant ne fasse tomber tout un secteur industriel.
• Faire en sorte que toutes les entreprises européennes d'un même secteur aient le même niveau de protection.
• Sanctionner avec des amendes pouvant aller jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires mondial.
   

Des milliers d’entreprises concernées par la Directive NIS 2

C'est le grand changement par rapport à NIS 1. On passe de quelques centaines d'opérateurs à des milliers d'entreprises en France.

• Les entités essentielles : les secteurs très critiques (énergie, transport, santé, administration publique, banques).
• Les entités importantes : des secteurs clés mais moins critiques (gestion des déchets, postes, agroalimentaire, fabrication industrielle dont l'aéronautique et l'automobile).
• En général, toute entreprise de plus de 50 salariés ou réalisant plus de 10 millions d'euros de chiffre d'affaires dans ces secteurs est concernée.

Tableau récapitulatif de la Directive NIS 2

Dans le cadre de NIS 2, une entreprise est désormais responsable des failles de ses sous-traitants. Si vous utilisez un hyperscaler soumis au Cloud Act, vous introduisez une "faille juridique" dans votre conformité. En cas de gel de vos services par une autorité étrangère, vous ne seriez plus en mesure de justifier la maîtrise de votre continuité d'activité auprès de l'ANSSI.

Conclusion : Vous ne pouvez pas garantir la sécurité de votre chaîne d'approvisionnement exigée par NIS 2 si votre infrastructure dépend d'un acteur soumis à des lois extra-territoriales.

Mais, au-delà des aspects légaux, le choix d’un hyperscaler n’est peut être pas adapté aux besoins de votre organisation.

Stratégie cloud, l'hyperscaler n'est PAS forcément le meilleur choix

Pourquoi choisit-on AWS ou Azure ? Sélectionner un leader mondial c’est rassurant, on fait le choix de la tranquillité. Mais est-ce vraiment la meilleure option ?

L'expertise humaine VS le catalogue de services infinis

La robustesse d'un système ne dépend pas d’un catalogue de services infini (la plupart inutiles pour vous) mais de la manière dont l'architecture est conçue. Les hyperscalers poussent leurs services génériques automatisés. L'ingénierie système c’est l’inverse, c’est proposer une infrastructure adaptée.

Choisir le cloud souverain avec Codéin, c’est bénéficier d'une équipe d'experts systèmes capables de concevoir, de sécuriser et de monitorer une infrastructure sur-mesure. C’est la garantie d’avoir une architecture conçue pour votre métier, pour vos pics de charge, votre code, vos enjeux…

Au-delà de la technique, c'est une relation de proximité gage de réactivité : chez Codéin, vous disposez d'un interlocuteur privilégié joignable directement sur sa ligne téléphonique, sans aucune barrière filtrante. Vous ne parlez plus à un système de tickets anonyme, mais à un expert qui connaît votre plateforme.

Attention au risque de dépendance

Les services managés sont des technologies créées par AWS qui n'existent nulle part ailleurs. Si vous les utilisez, certaines parties de votre code est lié à l'hébergeur.

• Exemples : DynamoDB (base de données NoSQL), Lambda (serverless), SQS (file d'attente), Kinesis (streaming de données).
• Le risque : Pour quitter AWS, vous pourriez avoir à réécrire les parties relatives à l'utilisation de ces services. C'est le niveau de risque le plus élevé pour la souveraineté.
   

Il existe des services managés basés sur des technologies Open Source qui sont intégrés dans l’interface AWS et qui utilisent ses propres outils de configuration.

• Exemples : RDS (qui peut faire tourner du PostgreSQL ou du MySQL), Amazon MSK (qui fait tourner du Kafka), Amazon Elasticache (pour Redis).
• Le risque : Le moteur est standard, donc la migration est plus simple. Cependant, la manière de gérer les sauvegardes, la sécurité et les réseaux reste propre à AWS. 
   

Même quand un service managé utilise de l'Open Source, l'hyperscaler cherche à vous rendre captif via ses outils de gestion et ses tarifs de transfert de données. 

Replacer le besoin au centre de l’architecture

La domination des hyperscalers a popularisé une certaine vision de l’informatique : celle d’une infrastructure "sans limites", capable de scaler automatiquement sur plusieurs régions du globe et d’offrir des services de haute disponibilité clé en main. Ce récit a séduit de nombreuses organisations en promettant de s'affranchir des complexités liées à l'administration système.

Un retour à une ingénierie de "juste besoin" 

• L’illusion du "tout automatique" : Si ces services managés facilitent le démarrage, nous observons parfois que l’absence de compétences système lors de la conception mène à des infrastructures inutilement complexes. Cette complexité peut paradoxalement fragiliser le maintien en condition opérationnelle (MCO) ou laisser subsister des zones d'ombre en matière de sécurité.
• La haute disponibilité à l'échelle européenne : Contrairement à une idée reçue, il est tout à fait possible de construire des architectures hautement disponibles, résilientes et réparties sur plusieurs datacenters en restant au sein de l'écosystème souverain. Certes, cela demande une configuration plus fine des outils (souvent basés sur des standards Open Source), mais cela garantit une maîtrise totale de la chaîne de production.
• Le rôle de l'expert système : Plutôt que de déléguer la logique d'infrastructure à des algorithmes propriétaires, le choix d'un hébergeur souverain permet de remettre l'ingénierie au service du projet. On passe d'une consommation de services "sur l'étagère" à une infrastructure sur-mesure, dimensionnée pour les besoins réels de l'application, sans la surcouche de complexité propre aux besoins des géants du web mondial. Par ailleurs, l'usage des hyperscalers nécessite une maîtrise technique pointue qui, si elle n'est pas présente en interne, doit être apportée par des profils experts.

Chez Codéin, nous gérons des plateformes générant plus d'un million d'euros de chiffre d'affaires par heure. Ces infrastructures ne sont pas sur AWS, mais sur OVHcloud.  La clé ?  Une architecture optimisée, un PRA (plan de reprise d'activité) et un PCA (plan de continuité d'activité) pensé par des ingénieurs.

×

Nos experts installent et pilotent eux-mêmes les technologies Open Source :

• L'intelligence de l'infrastructure appartient à Codéin et au client, pas à l'algorithme d'AWS.
• Puisque vous utilisez des outils standards (non modifiés par l'hébergeur), vous pouvez déplacer l'infrastructure d'OVHcloud vers un autre  hébergeur facilement.
• Au lieu de payer un service automatisé, vous payez des experts Codéin pour une configuration optimisée et un support humain direct.

Migrer vers du souverain la méthode Codéin

Il convient de distinguer deux typologies de plateformes lors d’une sortie d’hyperscaler : celles s’appuyant sur des standards ouverts et celles intrinsèquement liées à l’écosystème du fournisseur.

Les architectures "Standards" : La migration par translation

Le premier cas concerne les plateformes utilisant des services managés basés sur des technologies Open Source (ex: un RDS MySQL, un ElastiCache Redis). Dans ce cas, la migration s'apparente à une bascule d'infrastructure à périmètre fonctionnel identique : on change le support, mais pas la logique.

• L'enjeu : Il s'agit de reconstruire une architecture miroir chez l'hébergeur souverain en s'appuyant sur les briques que nous maîtrisons (Linux, MariaDB, HAProxy …).
• La méthode : L’effort repose essentiellement sur l’infogéreur qui déploie des briques compatibles et robustes. Une fois l'infrastructure cible validée, la migration se résume à une synchronisation de données et une bascule de flux (DNS/IP). 
   

Les architectures "Cloud Native" : Le défi du Vendor Lock-in

Le second cas est plus complexe : il concerne les applications conçues spécifiquement pour consommer des services propriétaires (ex: AWS DynamoDB, SQS, Lambda, ECS ou des API de stockage non S3-compatibles).

• La problématique : L'application subit un "vendor lock-in" (enfermement propriétaire). Le code source lui-même est dépendant d'API spécifiques au fournisseur.
• La méthode : La migration nécessite une phase d'audit applicatif profonde. Il ne suffit plus de déplacer des données ; il faut parfois "dé-tricoter" le code pour remplacer les appels API propriétaires par des standards ouverts.
• L'impact : Cette transition peut engendrer des coûts de développement significatifs et nécessite une collaboration étroite entre les développeurs (Dev) et l'infogéreur (Ops) pour ré-architecturer l'application vers un modèle agnostique et souverain.

L'humain au cœur du système

La souveraineté n'est pas qu'une question de serveurs, c'est une question de compétences. Avec Codéin : 

• Zéro Offshore : 100% de nos experts sont à Montpellier ou Strasbourg.
• Proximité : Un interlocuteur unique, expert et joignable, sans système de tickets anonymisé.
• Une architecture dimensionnée pour vos pics de charge réels.

FinOps : Passez de la facture aléatoire au budget maîtrisé

La souveraineté n'est pas forcément source d’économie mais de lisibilité. Chez les clouds US, la facture est une variable aléatoire (frais de requêtes, bande passante, frais de sortie de données).

En combinant cloud européen et ingénierie sur-mesure, vous payez des ressources facilement quantifiables (cpu, ram, stockage) et une prestation d’infogérance détaillée avec des engagements.

Savoir que votre facture sera de 2 000 € chaque mois est plus précieux en termes de gestion qu'une promesse de "scalabilité" qui peut faire décoller la note à 5 000 € !

Tableau comparatif hyperscaler vs cloud souverain européen

Conclusion : Quel choix pour votre infrastructure ?

Le choix de votre hébergement ne doit pas être dicté par “la mode” ou par la pression du choix qu'on ne pourra pas remettre en cause. Les hyperscalers offrent une puissance indéniable mais ils imposent des contraintes de dépendance technique et une opacité juridique qui peuvent devenir des freins stratégiques pour une entreprise européenne.

Choisir la souveraineté avec Codéin ou tout autre infogéreur européen, c'est avant tout faire le choix de la maîtrise. il ne s'agit pas de renoncer à la performance, mais de privilégier une infrastructure dimensionnée pour vos besoins réels. Un RPO (perte de données admissible) ou un délai de rétablissement (RTO) proche de zéro ne sont pas systématiquement requis.

Chez Codéin, nous concevons les architectures de nos clients selon des indicateurs précis : les SLA pour la disponibilité, le RPO pour l'intégrité des données et le RTO pour la reprise d'activité. Cette approche repose sur des standards open source et un pilotage assuré par des experts joignables. elle permet non seulement de sécuriser vos données face aux lois extra-territoriales, mais aussi d'optimiser vos coûts et de garder un contrôle total sur votre facture.

Chaque système d'information ayant ses propres spécificités. l’important est de choisir une infrastructure qui reste au service de votre business, et non l’inverse.

Si vous vous interrogez sur la pertinence de votre architecture actuelle ou si vous souhaitez challenger vos choix d'infrastructure, nos ingénieurs système sont à votre disposition pour partager leur expérience. 

Contactez-nous pour en discuter.