Le Guide Pragmatique pour une Infrastructure Sans Dépendance

265 milliards d'euros.

C'est ce que l'Europe verse tous les ans aux hyperscalers américains (Source : Cabinet Asterès). À peu près l'équivalent de 1,5% du PIB européen qui saute l'Atlantique. Et pendant ce temps, plus de 80% de la dépense cloud des entreprises européennes reste sous la juridiction du CLOUD Act.

En 2025, les recherches sur les providers de cloud européens ont explosé. Le signal est clair : les entreprises en Europe commencent à se poser des questions sur l'emprise américaine.

Mais entre la prise de conscience et les actions, il y a un gouffre. Et ce gouffre, c'est souvent la peur.

La peur d'une interruption de services. La peur d'une perte de productivité. La peur de perdre le contrôle. La peur d'aller vers une autre usine à gaz — ou justement de démonter celle qu'on a mis en place, dans laquelle on a beaucoup dépensé, beaucoup investi.

C'est se dire : "tout ça va partir à la poubelle" pour aller vers quelque chose de nouveau. Quelque chose qu'on ne maîtrise pas forcément. Quelque chose pour lequel on n'a pas encore de contrat. Quelque chose où il y a beaucoup de flou et d'incertitude.

Et les entreprises n'aiment pas l'incertitude.

Pourtant, en 2026, il y a un tournant. Beaucoup d'alternatives open source sont déjà matures et ont fait leurs preuves depuis pas mal d'années.

On a des réglementations européennes qui arrivent : NIS2, DORA, Data Act. Elles sont maintenant là, applicables.

Et surtout, les éditeurs eux-mêmes ont trahi la confiance en changeant leurs licences. On est passé de l'open source au premium, au freemium, appelez ça comme vous voulez — mais en tout cas, ils ont choisi de faire plus d'argent. HashiCorp, Redis, MinIO... La liste s'allonge.

Cet article n'est pas un manifeste idéologique pour l'open source. Ce n'est pas dire aux entreprises "jetez tout, il n'y a pas de question".

C'est juste un guide pragmatique. C'est essayer de se poser les bonnes questions :

• Est-ce qu'on a tout ce qu'il faut côté open source pour faire du souverain ?

• Est-ce qu'on a tous les outils nécessaires aujourd'hui pour avoir une prod qui tourne avec tout l'outillage requis ?

• Peut-on faire du CI/CD, du monitoring, de la sécurité, tout ce dont on a besoin de manière autonome, souveraine, sans dépendre d'acteurs extérieurs ou de gros acteurs américains ?

1. Pourquoi 2026 est l'Année du Choix Stratégique

1.1 Le mur réglementaire

Si vous travaillez dans un secteur critique défini par NIS2, vous êtes probablement concerné. Et pas un petit peu.

La directive prévoit maintenant la responsabilité personnelle des dirigeants en cas de manquement aux obligations de cybersécurité.

On a été témoins de pas mal d'incidents ces dernières années, voire ces derniers mois, et ça va de plus en plus crescendo. On voit de plus en plus de fuites de données arriver. Et avec l'explosion de l'intelligence artificielle, les attaques sont de plus en plus crédibles, de plus en plus difficiles à déceler. C'est pour ça qu'on se retrouve aujourd'hui devant une avalanche de fuites et d'attaques.

Voici le calendrier qui s'impose aux entreprises françaises et européennes :

Le Data Act est particulièrement intéressant. Il impose aux fournisseurs cloud de faciliter le switch (changement de fournisseur) vers d'autres prestataires. Autrement dit, l'Europe légifère contre le vendor lock-in pour permettre aux entreprises d'avoir plus de possibilités et de faciliter le changement.

1.2 Le piège économique du cloud

Les budgets cloud explosent. +20 à 30% par an en moyenne.

C'est un peu dû à ce qu'on voit en ce moment avec l'IA. Les fournisseurs de services cloud sont obligés de scaler pour encaisser les charges supplémentaires liées à l'IA. Ils ont besoin de plus en plus de machines pour faire tourner des modèles de plus en plus gourmands.

À un moment donné, il faut payer la facture. Et qui paye ? Les entreprises qui détiennent des contrats sur ces plateformes cloud.

La négociation ? C'est pas forcément possible. On n'a pas le choix.

Il y a des entreprises qui payent de plus en plus et qui sont bloquées par des contrats d'engagement. Elles ne peuvent plus sortir, tout le système tourne dessus. Tout migrer coûterait trop cher, donc on préfère payer et subir les hausses.

C'est ça, le vendor lock-in (enfermement fournisseur) : ce n'est pas qu'on ne peut pas partir, c'est que partir coûte trop cher.

Les entreprises qui ont des réservations sur trois, quatre, cinq ans s'en sortent un peu mieux. Elles ne subissent pas de plein fouet les augmentations successives pour le moment. Mais attention aux renouvellements de contrats qui peuvent s'avérer douloureux. N'hésitez pas à négocier au moment des renouvellements.

L'open source change un peu l'équation. Ce n'est pas parce que c'est gratuit à l'installation — en vrai, ce ne l'est pas tout à fait. Mais parce que ça donne un effet de levier de négociation.

Quand vous pouvez partir, bizarrement, on vous propose de bonnes réductions.

1.3 Les trahisons de 2023-2024

C'est peut-être un des arguments les plus concrets qu'on va avoir.

Regardez le tableau ci-dessous, et vous allez voir ce qui s'est passé en termes de licences pour tous ces produits open source qui ont petit à petit migré vers des solutions payantes :

C'est à peu près le même pattern. C'est toujours la même chose.

L'éditeur construit une communauté sur une licence open source permissive. Il devient dominant. Et puis du jour au lendemain, on voit un rug pull (retournement de situation) : on change les règles du jeu une fois que tout le monde est dépendant. On ne peut plus faire marche arrière.

La BSL (Business Source License) de HashiCorp est particulièrement vicieuse : le code est visible, vous pouvez l'utiliser en interne, mais vous ne pouvez pas proposer un service concurrent. Traduction : si vous êtes un cloud provider européen qui veut proposer du Terraform managé, c'est terminé.

La leçon ? Si c'est pas Apache 2.0, MIT, ou une vraie licence OSI, méfiez-vous. Le "source-available" n'est pas de l'open source.

2. Comprendre les Licences : Le Vrai du Faux

Avant de parler outils, il faut parler licences. C'est moins sexy, mais c'est fondamental. Une erreur de licence peut vous coûter très cher.

Vraiment Open Source (OSI-Approved)

Ces licences sont approuvées par l'OSI (Open Source Initiative). Vous pouvez utiliser, modifier, redistribuer le code :

• Apache 2.0 ✅ - La plus permissive, parfaite pour l'entreprise

• MIT ✅ - Ultra-simple, aucune contrainte

• BSD (2/3-clause) ✅ - Similaire à MIT

• MPL 2.0 ✅ - Copyleft (obligation de redistribuer sous la même licence) fichier par fichier

• GPL/LGPL ✅ - Copyleft, attention si vous distribuez du code

• AGPL ✅ - Copyleft fort, s'applique même pour les services réseau

Source-Available (PAS Open Source)

Ces licences ressemblent à de l'open source, mais ne le sont pas :

• BSL (Business Source License) ❌ - HashiCorp, MariaDB

• SSPL (Server Side Public License) ❌ - MongoDB, Elastic (avant 2024)

• Elastic License ❌ - Elastic

• FSL (Functional Source License) ❌ - MinIO, Sentry

La règle d'or : Allez sur opensource.org/licenses. Si la licence n'y est pas, vous n'êtes pas en open source. Point.

Le cas particulier de l'AGPL

L'AGPL mérite un paragraphe. C'est une vraie licence open source (OSI-approved), mais avec un copyleft très fort : si vous modifiez le code et que vous l'utilisez pour fournir un service réseau, vous devez publier vos modifications.

Pour du self-hosted en interne, aucun problème. Si vous construisez un SaaS dessus, consultez un juriste et faites vous aider.

3. Data Platform Souveraine : La Stack Complète

Passons aux choses sérieuses. Voici comment construire une data platform moderne, performante, et 100% open source.

3.1 Object Storage (Stockage objet) - Bye bye S3

Le stockage objet est la fondation de toute data platform moderne. La référence était MinIO... jusqu'à ce qu'ils passent en FSL.

Recommandé :

À éviter : MinIO post-2024 (FSL = pas open source). Si vous l'utilisez déjà, ça fonctionne, mais planifiez votre sortie.

3.2 Formats Lakehouse (architecture hybride data lake + data warehouse)

Le format de table est ce qui transforme votre data lake en lakehouse avec ACID (Atomicité, Cohérence, Isolation, Durabilité - garanties transactionnelles), time travel (accès aux versions historiques des données), et schema evolution (évolution du schéma sans migration).

Les trois standards :

Mon conseil : Iceberg si vous voulez du multi-engine (Trino, Flink, Spark), Delta Lake si vous êtes "Spark-centric".

Et si vous avez besoin d'interopérabilité ? Apache XTable (ex-OneTable) permet de switcher entre les trois formats sans dupliquer les données.

3.3 Streaming (flux de données en temps réel) & Message Queue (file d'attente de messages)

Recommandés :

À éviter : Redpanda (BSL 1.1). Oui, c'est 10x plus rapide que Kafka. Oui, c'est compatible Kafka API. Mais c'est du source-available, pas de l'open source.

3.4 Orchestration

3.5 Transformation & Processing

3.6 Query Engines (moteurs de requêtes)

3.7 Data Quality (qualité des données)

3.8 Data Catalog (catalogue de données) & Lineage (traçabilité des données)

3.9 BI (Business Intelligence - informatique décisionnelle) & DataViz (visualisation de données)

On a plus que 2 options aujourd'hui. L'écosystème open source s'est bien étoffé ces dernières années.

4. Infrastructure Souveraine

4.1 IaC (Infrastructure as Code - infrastructure programmable)

La situation : HashiCorp a basculé Terraform en BSL en août 2023. Si vous démarrez un nouveau projet, ne partez pas sur Terraform.

Alternatives :

4.2 Secrets Management (gestion des secrets et mots de passe)

Situation : Vault = BSL. Même combat que Terraform.

Alternatives :

4.3 Containers & Kubernetes

Bonne nouvelle : l'écosystème Kubernetes est massivement open source.

4.4 Monitoring & Observabilité (capacité à comprendre l'état interne d'un système)

La stack LGTM (Loki, Grafana, Tempo, Mimir) + Prometheus est devenue le standard open source :

Alternative all-in-one : SigNoz (MIT) - Un Datadog open source avec metrics, logs, traces dans une seule UI.

5. Sécurité Souveraine

La sécurité est peut-être le domaine où l'open source brille le plus. Les outils sont matures, maintenus, et souvent utilisés par les plus grandes organisations.

5.1 IAM (Identity and Access Management - gestion des identités) & Authentification

5.2 SIEM (Security Information and Event Management) & XDR (Extended Detection and Response)

Architecture Wazuh :

5.3 Réseau & VPN

5.4 WAF (Web Application Firewall - pare-feu applicatif web)

5.5 Scanning & Vulnérabilités

5.6 Password Management

6. Le Coût Réel : Parlons FinOps

L'illusion du "gratuit"

Soyons clairs : l'OSS (Open Source Software - logiciel à code source ouvert) n'est pas gratuit. Vous ne payez pas de licence, mais vous payez :

• Compétences : internes ou prestataires

• Infrastructure : serveurs, réseau, stockage

• Maintenance : mises à jour, patches de sécurité

• Support : communauté (gratuit mais lent) ou commercial (payant)

L'option du milieu : Cloud européen + OSS

C'est souvent le meilleur compromis :

• OVHcloud : Managed Kubernetes, Object Storage S3-compatible, Public Cloud

• Scaleway : Instances, Kubernetes Kapsule, PostgreSQL managé

• Clever Cloud : PaaS (Platform as a Service) européen, déploiement simplifié

Vous gardez la souveraineté des données (datacenters en France/UE), vous bénéficiez de l'infrastructure managée, et vous gardez la liberté de partir grâce à l'open source.

Le vrai ROI

Le vrai ROI (Return on Investment - retour sur investissement) de l'open source, ce n'est pas la gratuité. C'est la liberté de partir.

Cette liberté a une valeur :

• Pouvoir négocier vos contrats cloud

• Pouvoir changer de provider en 6 mois, pas 3 ans

• Ne pas dépendre d'un roadmap produit que vous ne contrôlez pas

7. Conclusion : Une Souveraineté Pragmatique (Pas Dogmatique)

L'illusion de la "Dette GAFAM"

Soyons lucides : rester sur AWS, Azure ou GCP en 2026 n'est pas une dette technique en soi. Ces plateformes sont des merveilles d'ingénierie, elles sont stables, elles sont performantes, et elles font tourner une immense partie de l'économie mondiale.

Mettre son entreprise en péril en lançant des migrations pharaoniques uniquement par idéologie serait une erreur stratégique majeure. Si votre business tourne bien, que vos marges sont saines et que vos équipes sont productives sur ces stacks : ne changez rien dans l'immédiat. La souveraineté ne vaut rien si elle tue le business.

La souveraineté ne passe pas que par l'Open Source

On tombe souvent dans le piège binaire : "GAFAM méchants vs Open Source gentil". C'est faux.
La souveraineté numérique passe aussi – et peut-être surtout – par les acteurs technologiques européens.

OVHcloud, Scaleway, Clever Cloud, 3DS Outscale... Avoir peur du Vendor Lock-in américain ne doit pas se transformer en peur de tous les éditeurs. Ces acteurs européens offrent des garanties juridiques (RGPD, protection contre CLOUD Act) que l'Open Source seul ne suffit pas à offrir. Faire confiance à un PaaS propriétaire européen est une forme de souveraineté tout à fait valide.

Attention aux coûts cachés de la "liberté"

L'Open Source supprime le coût de licence, mais il transfère le coût vers l'humain et la maintenance.
Gérer soi-même sa stack data souveraine demande des compétences pointues (et chères). Les "coûts cachés" de l'intégration, des mises à jour de sécurité et de la complexité opérationnelle peuvent parfois dépasser la facture mensuelle d'un service managé.

Le mot de la fin : Avoir le Choix

La stratégie gagnante pour 2026 n'est pas le "tout ou rien", mais l'hybridité pragmatique :

1. Dédiaboliser les GAFAM : Gardez-les pour ce qu'ils font de mieux (commodité, scale infini), mais refusez les services propriétaires qui vous verrouillent (exit DynamoDB, exit BigQuery, bonjour Postgres/Iceberg).

2. Adopter les standards ouverts : C'est votre véritable assurance-vie. Si vos données sont en Iceberg et votre infra en OpenTofu, vous êtes libres, même hébergés chez AWS.

3. Soutenir l'industrie européenne : Testez les clouds locaux pour vos nouveaux projets. Ils ont fait des bonds de géant en UX et performance.

La vraie souveraineté, ce n'est pas de tout construire soi-même. C'est d'avoir la liberté réelle de dire non et de pouvoir partir si les conditions ne vous conviennent plus.

Catalogue des Outils Open Source non recommandés (Licences Non-OSI)

Sources

• ANSSI - SecNumCloud 3.2 : cyber.gouv.fr

• Linux Foundation - World of Open Source EU 2025

• HashiCorp - BSL Announcement (Août 2023)

• Redis - AGPL Return Announcement (Mai 2025)

• NIS2 Directive - EUR-Lex

• DORA Regulation - EUR-Lex

• Data Act - EUR-Lex

Vous avez des questions sur la stratégie de migration ou sur un point technique précis ? Contactez-nous.