Situation

Actuellement les DSI doivent gérer deux mouvements parallèles

• Déploiement du Cloud
• Souveraineté (Maintien ou Renforcement)

☁️ Déploiement / Adoption du Cloud

✅ Une dynamique massive et irréversible

• On assiste à une bascule généralisée des infrastructures On Premise vers les hyperscalers (AWS, Azure, GCP...).

 - Une transposition brute, avec peu de transformation

• Dans de nombreux cas, la migration consiste à reproduire des architectures historiques (héritées du monde PME ou datacenters privés) sans adaptation au modèle cloud.
• L’analyse d’impact est minimale, et les modèles d’exploitation finalement peu revus.

-  Des promesses standardisées…

Le Move to Cloud est présenté comme une solution universelle aux problématiques :

• d’extensibilité (élasticité à la demande),
• de résilience (tolérance aux pannes),
• de coût (optimisation et paiement à l’usage).

👑 Souveraineté

📐 Définition de la souveraineté (best effort)

La souveraineté informatique, au niveau d'une DSI, désigne la capacité de l'organisation à maîtriser l’accès, l’usage, la localisation, l’évolution et la sécurité de ses données, systèmes et infrastructures numériques, indépendamment des intérêts ou contraintes imposés par des tiers extérieurs (fournisseurs, partenaires, juridictions étrangères).

Elle repose sur plusieurs piliers :

• Indépendance réglementaire : respecter les cadres légaux applicables (ex : RGPD) sans subir de lois extraterritoriales (ex : Cloud Act).
• Réversibilité et portabilité : pouvoir quitter un fournisseur sans perte de service ni enfermement technologique.
• Diversification des fournisseurs : éviter la dépendance tarifaire ou contractuelle à un acteur unique.
• Maîtrise technique : capacité à comprendre, faire évoluer, maintenir ou réinternaliser les systèmes critiques.
• Contrôle des données et applications : garantir leur disponibilité et qui y accède.
• Autonomie stratégique : capacité à comprendre et piloter les technologies mises en œuvre, pour faire des choix éclairés, évolutifs, et rester maître des trajectoires numériques de l’organisation.

Une organisation peut être opérationnelle sans être souveraine.
Elle est souveraine lorsqu’elle peut choisir, changer, comprendre, et reprendre le contrôle si nécessaire.

🚨 Problème

Le move to cloud, tel qu’il est mis en œuvre aujourd’hui (via l’adoption des hyperscalers et de leurs services managés), va frontalement à l’encontre des principes de souveraineté.

L’adoption du cloud est en général couplée avec le déploiement de nouveaux services managés qui atomisent ce qui était fait jusqu’alors par une palette restreinte d’outils maîtrisés.
Ce morcellement fonctionnel augmente la dépendance technologique, dilue la compétence, et complexifie la réversibilité.

Cette approche introduit de nouveaux points de dépendance, génère une résilience artificielle, et alourdit la facture globale. Les impacts se concentrent autour de quatre problématiques majeures :

• Vendor lock-in (by design)
• Coûts réels en forte hausse
• Dépendance réglementaire accrue
• Résilience limitée et illusion de redondance

 1. Vendor lock-in par design

Les services managés des hyperscalers — en particulier les plus critiques (bases de données, stockage, queues) — sont spécifiques, optimisés et souvent propriétaires.

Deux cas fréquents :

• Services non disponibles ailleurs : ex. AWS SQS, Azure Storage, etc.
• Services open source modifiés : ex. AWS Aurora, Azure PostgreSQL, nécessitant migration en cas de sortie.

👉 Plus on s’intègre à un écosystème propriétaire, plus la sortie devient complexe, coûteuse, voire impossible sans rupture.

 2. Coûts réels en forte hausse

Malgré les promesses d’optimisation, l’adoption des hyperscalers induit une hausse globale du coût d’exploitation, pour plusieurs raisons :

a. Baisse du ratio performance / prix :

• Mutualisation extrême des ressources (CPU, stockage, réseau)
• Virtualisation systématique (y compris du stockage local) introduisant de la latence et dégradant les performances unitaires
• Coûts opaques et variables du stockage, traffic réseau et même des IO dont la consommation est pratiquement non mesurable.

b. Hausse des coûts indirects :

• Besoins accrus en consultants spécialisés et certifications éditeurs
• Perte de productivité liée à la multiplication d’outils complexes et à l’atomisation des compétences
• Double peine : on paie plus cher les ressources, et on paie plus cher les personnes capables de les maîtriser

💬 "Je paie mes VMs plus cher, et je dois en plus payer des experts certifiés pour comprendre la complexité induite par le fournisseur."

🧮 Comparaisons trompeuses

Cette augmentation des coûts relatifs est difficile à établir lorsqu’on compare les hyperscalers à une infrastructure OnPremise, en raison de la dispersion de nombreux coûts cachés :

• facilities,
• bande passante,
• support technique interne,
• interconnexions réseau, etc.

En revanche, la comparaison devient beaucoup plus lisible et défavorable lorsqu’on la fait avec des hébergeurs nationaux qui proposent une offre IaaS équivalente sur le plan technique :

• ✅ Mise à disposition d’infrastructures multi-datacenters ou multi-AZ
• ✅ Bande passante incluse ou optimisée localement
• ✅ Location au mois ou à la journée
• ✅ Provisioning rapide en quelques minutes

👉 À périmètre fonctionnel égal, les hyperscalers sont significativement plus coûteux, en particulier pour les workloads transactionnels ou critiques.

📊 Exemple comparatif : coût mensuel d'une base de données managée ou hébergée

🔍 Observations

• Le coût des services managés AWS est très supérieur à celui d’un serveur dédié chez un hébergeur européen, à performance largement supérieure.
• Les services managés facturent souvent chaque élément séparément : stockage, I/O, trafic sortant, réplication, etc.
• Les offres hyperscalers reposent sur une tarification complexe, souvent non prévisible à l’avance sans benchmark précis.
• Les performances mesurées montrent une latence plus élevée et une dégradation significative des tps, malgré un prix bien plus élevé.

Conclusion : les promesses d’élasticité et de simplicité ne suffisent pas à compenser l’écart de coût et de performance, surtout sur des workloads transactionnelles stables. La valeur ajoutée des hyperscalers n’est pas “automatique” — elle se paie, et cher.

🧠 Le mythe de la flexibilité “à la demande”

Un des arguments les plus fréquemment mis en avant en faveur des hyperscalers est leur flexibilité tarifaire : la possibilité de ne payer que ce qu’on consomme (“on demand”).
En pratique, cet avantage est souvent théorique.

Dès qu’une charge devient un minimum récurrente (même quelques jours par mois), le tarif “à la demande” devient rapidement plus coûteux que la location mensuelle chez un hébergeur.

💬 Exemple : dans le cas ci-dessous, à partir de 3 à 4 jours d’utilisation par mois, il devient plus rentable de louer un serveur dédié qu’une VM à la demande.

#📊 Comparatif simple : location à la demande vs mensuelle

Même si les machines virtuelles Azure reposent sur des processeurs haut de gamme, leurs performances restent fortement conditionnées par le stockage, proposé en option. Même les offres de stockage Azure les plus performantes peinent à rivaliser avec la réactivité des SSD locaux proposés par les hébergeurs traditionnels.

🧩 Point Matriochka

Définition :Le point Matriochka est atteint lorsqu’un discours rationnel et argumenté met en lumière les incohérences de la justification économique des hyperscalers, révélant une accumulation de coûts cachés gigogne, dissimulés sous des couches de remises flatteuses et des discours marketing bien huilés.

Point Matriochka

On entend souvent que l’écart de prix entre les hyperscalers et les hébergeurs traditionnels s’explique par l’intégration des coûts de facilities et des équipes techniques. Un argument recevable, à condition que le passage au cloud ait réellement entraîné :

1. la fermeture effective de toutes les infrastructures existantes,
2. une réduction durable et significative des effectifs techniques,
3. et la prise en compte comptable des ressources décommissionnées.

Spoiler : ce n’est que rarement le cas.

En pratique, on assiste surtout à une superposition des coûts, partiellement masquée par des remises spectaculaires dont le seul but est de cimenter le lock-in.Par exemple :

• Deux années d’hébergement totalement gratuites offertes par Azure à un acteur du CAC40
• Azure for Startup: 230K€ de crédits gratuits (en 4 tranches 5K€ + 25K€ + 50K€ + 150 K€)

 3. Dépendance réglementaire accrue

Dans le cas des hyperscalers, l‘éléphant dans la pièce est le Patriot Act.

Pour une PME française, voici les conséquences potentielles du Patriot Act et des textes associés (source ChatGPT-4o):

1. Accès des autorités américaines aux données hébergées aux États-Unis

Le Patriot Act autorise les agences fédérales (comme le FBI, la NSA…) à exiger l’accès à des données détenues par des entreprises américaines même si ces données concernent des étrangers et sont hébergées hors des États-Unis, tant que l'entreprise en question est soumise à la loi américaine.

✅ Exemple concret : Si une PME française utilise Microsoft 365, Google Workspace, Amazon AWS ou Dropbox, les autorités américaines peuvent théoriquement demander l’accès à ses données sans en informer la PME.

2. Obligations de collaboration secrète

Les entreprises américaines ou sous juridiction américaine n’ont pas le droit de révéler qu'elles ont été sollicitées par le gouvernement américain pour fournir des données (via une "National Security Letter").

3. Risques pour la confidentialité des données

Cela entre parfois en conflit avec le RGPD (Règlement Général sur la Protection des Données) européen, qui impose aux entreprises européennes de protéger les données personnelles de leurs clients et salariés.

⚠️ C’est une des raisons pour lesquelles l’UE a invalidé les accords "Safe Harbor" (2015) puis "Privacy Shield" (2020), qui encadraient le transfert de données vers les États-Unis.

 4. Résilience limitée et illusion de redondance

Les architectures proposées par les hyperscalers offrent une redondance intra-plateforme, mais pas inter-opérateur.

• Les services managés ne sont pas portables entre fournisseurs
• Les backups sont souvent stockés dans le même écosystème
• Aucun PRA multi-cloud réaliste n’est envisageable sans replateformage complet

La résilience réelle, c’est la capacité à survivre à la perte d’un Datacenter ou une panne globale. Aujourd’hui, ce n’est plus une hypothèse théorique.

✨ Résolution

Pour concilier souveraineté et agilité cloud, nous proposons une démarche structurée autour de trois leviers d’action :

• Définir un cœur de technologie souverain ou “Sovereign Technological Core” (aka STC)
• Se doter de la capacité à déployer ce cœur n’importe où (on premise, chez un hébergeur ou un hyperscaler)
• Faire évoluer la notion de résilience pour en faire une fonctionnalité courante

Définir un cœur de technologies souverain

Ce cœur constitue une forme de "plus petit commun dénominateur" technologique, déployable partout : on-premise, chez un hébergeur ou dans le cloud public.

📋 Critères retenus pour construire le STC (Sovereign Technological Core)

Pour garantir la souveraineté, nous avons retenu les critères suivants :

🧱 Muppy STC – Évaluation par critère

Voici le Sovereign Technological Core géré actuellement par Muppy (il est enrichi régulièrement).

Ce coeur a vocation à être complété avec les composants nécessaires à chaque client.

🔍 Commentaires associés aux évaluations partielles

🔒 Wireguard / Nebula

Permet de créer des réseaux Wan sécurisés entre les différents fournisseurs.

❗ Docker

Docker n’intègre pas directement de mécanismes de résilience ; c’est Kubernetes qui apporte la résilience et la sécurité.

❗ Kubernetes avec Muppy

Kubernetes est une technologie puissante mais complexe à opérer. C’est Muppy qui le rend maitrisable.

❗ Traefik – Résilience intégrée

La résilience de Traefik dépend de l’architecture de déploiement. Muppy permet de gérer des scénarios avancés, et Traefik Enterprise ajoute la haute disponibilité.

❗ Prometheus – Résilience intégrée

Prometheus ne gère pas nativement la réplication ; elle doit être assurée par des outils complémentaires.

❗ AWS S3

S3 est un protocole, pas une technologie open source dans sa version AWS. Il existe des implémentations compatibles et open source. La résilience d’AWS S3 est forte, mais enfermée dans l’infrastructure du fournisseur. On peut augmenter cette résilience en doublant les sauvegardes et en choisissant un fournisseur S3 distinct de celui qui héberge les workloads. L’API est très simple.

❗ VS Code

VS Code est un outil de développement local qui n’intègre pas de résilience. La version officielle intègre de la télémétrie ; on peut préférer VSCodium pour une alternative plus souveraine.

Le STC n’impose pas de contrainte sur les langages / framework de développement
Les applications sont déployées sous forme de conteneurs (Docker ou LXC), une approche naturellement indépendante du langage utilisé.
Muppy STC est actuellement utilisé pour déployer des applications en Python, Go, JavaScript, PHP, Java.

Se doter de la capacité à déployer ce cœur n’importe où en haute disponibilité

Muppy permet le déploiement automatisé du STC en quelques clics, quel que soit le fournisseur (on-premise, hébergeur national ou hyperscaler).

Le contrôle de l’environnement est une condition essentielle à la souveraineté. Muppy facilite ce contrôle en incitant l’utilisateur à concevoir des architectures haute disponibilité multi-datacenters (serveurs, bases, backups, clusters, switchover/failover).

À chaque étape, l’utilisateur garde un accès complet aux paramètres techniques (pas d’effet boîte noire), ce qui permet d’augmenter son niveau d’expertise dans le temps.

Par exemple, le déploiement d’un cluster Kubernetes ou PostgreSQL répliqué se fait en quelques minutes, quel que soit le fournisseur.

Cette approche permet de satisfaire les critères suivants de la définition de la souveraineté :

• Indépendance réglementaire : respect des cadres légaux (ex : RGPD) sans exposition aux lois extraterritoriales (ex : Cloud Act).
• Diversification des fournisseurs : éviter toute dépendance tarifaire ou contractuelle à un seul acteur.
• Maîtrise technique : compréhension, évolution et réinternalisation possible des systèmes critiques.
• Autonomie stratégique : capacité à piloter les choix technologiques, sans subir les trajectoires imposées.

One Click PRA : faire évoluer la résilience en usage courant

L’objectif : faire du switch-over ou du failover une opération simple et courante, non plus exceptionnelle.

L’architecture n’est plus centrée sur un site principal et un site de secours, mais repose sur un maillage distribué de sites répartis chez plusieurs fournisseurs, actionnables à tout moment.

Cette approche permet de satisfaire les critères suivants de la définition de la souveraineté :

• Réversibilité et portabilité : capacité à quitter un fournisseur sans rupture de service.
• Diversification des fournisseurs : réduction de la dépendance à un seul acteur.
• Contrôle des données et applications : garantie d’accès, de disponibilité et de localisation.

📎 Apple ne dépend pas d’un seul fournisseur cloud.
Ses ressources sont réparties entre AWS, Azure et Akamai, afin de garantir une indépendance totale.
Nous n’avons pas inventé ce modèle — nous l’avons simplement rendu accessible.

Application / illustration avec Muppy

Cette dernière partie montre comment les principes de souveraineté deviennent actionnables grâce à Muppy, au travers de cas concrets de déploiement, de gestion et de résilience.

Ces démonstrations visent à rendre tangibles les concepts abordés : déploiement souverain, haute disponibilité, contrôle des données et réversibilité.

Déploiement du cœur technologique souverain

Muppy permet de gérer de manière homogène des volumes importants de ressources réparties chez plusieurs fournisseurs, sans dépendance à une technologie ou un acteur spécifique.

Démonstrations (video en cours de production) :

• Visualisation des hosts, clusters PostgreSQL et clusters Kubernetes
• Installation d’un cluster PostgreSQL
• Mise en oeuvre de la réplication PostgreSQL

Maîtrise technique multi-environnements

Muppy favorise la gouvernance distribuée en permettant de piloter des applications déployées chez plusieurs hébergeurs.

Démonstrations (en cours de production) :

• Gestion de Meta Clusters et Resource Pools
• Déploiement d’applications dans Kubernetes avec muppy meta package (m2p)
• Utilisation de Pack8s pour déployer une application kubernetes en haute disponibilité.

One Click PRA

La résilience devient une capacité quotidienne, actionnable en quelques clics.

Démonstrations en cours de production) :

• Déclenchement en temps réel d’un switchover sur un meta cluster pour basculer une application complète entre 2 fournisseurs.

📝 Auteur : Cyril MORISSE — cmorisse@oursbl.eu — 📅 Avril 2025

📄 Ce document peut être partagé librement, sous réserve de mention de l’auteur.

🔁 Suggestions d'amélioration bienvenues !