Depuis des années, la diapositive incontournable des comités de direction est toujours la même : « Nous ne voulons pas de verrouillage des fournisseurs. Nous allons opter pour du multi-cloud ». En langage simple, cela signifie : tripler la complexité et doubler la facture. Et, pour couronner le tout, quand un aspect critique échoue, personne ne se porte responsable. Ce qui était promis comme une indépendance se transforme, bien trop souvent, en dettes techniques avec un surcoût premium.

Ce rapport analyse la critique — de plus en plus acceptée — de la stratégie multi-cloud telle qu’elle est appliquée concrètement, dans le contexte européen de souveraineté numérique, et propose une alternative réaliste : cloud privé moderne basé sur une virtualisation ouverte et européenne, avec Proxmox comme socle technologique, et des fournisseurs 100 % européens, voire espagnols, comme Stackscale, alignés avec cette vision.

Le mythe fondateur : « éviter le lock-in »

La promesse semble prudente : en répartissant les charges sur plusieurs hyperscalers, on réduit les risques de dépendance et on augmente la résilience. Le problème, c’est que cette indépendance est rarement atteinte. Les applications réelles s’accrochent à des services gérés précis ( files d’attente, datastores, gestion des identités, serverless, IA, analytics). Finalement, les éléments qui rendent chaque fournisseur compétitif sont précisément ceux qui créent des liens.

La conséquence est bien connue dans la pratique : portabilité théorique, dépendance concrète. Oui, Kubernetes facilite… jusqu’à ce que l’application nécessite la base de données X, le feature flag Y ou l’embedding Z en IA. Migrer n’est plus seulement déplacer des conteneurs : c’est repenser les services, réécrire les intégrations, et reprendre la certification compliance. Le coût, financier comme organisationnel, apparaît lorsque la théorie laisse place à la réalité.

Les trois factures méconnues du multi-cloud

1) Une complexité opérationnelle chronique

Chaque nuage a sa propre sémantique : réseaux, sécurité, identité, observability, billing, quotas, limites molles et rigides. Multiplier les clouds multiplie les matrices de défaillance et les vecteurs d’incident. Là où il y avait un runbook, il y en a maintenant trois ; là où existait un tableau de bord, il faut désormais gérer quatre outils et un pont de surveillance que personne ne veut maintenir durant le week-end.

2) Des équipes « apprenant tout, maitrise de rien »

Atteindre l’excellence sur AWS, GCP ou Azure demande des années. Essayer de maîtriser trois en même temps tend à dégrader le niveau général. Les talents seniors se dispersent ; le mid-level se révèle frustré ; le on-call s’épuise. La pire conséquence : sécurité diffuse, coûts incontrôlés et temps de réponse rallongés.

3) Des coûts financiers invisibles dans le pitch

La promesse de « optimisation des prix en comparant les fournisseurs » se heurte à la réalité des dépenses Egress, interconnexions, charges de gestion, duplication d’outils et contrats minimaux. Le bon marché s’évapore en lignes de frais. En pratique, beaucoup d’entreprises finissent par payer autant à trois fournisseurs qu’en optimisant leurs dépenses sur un seul, tout en négociant de meilleurs tarifs à long terme.

Quand la théorie se heurte à la réalité opérationnelle

Dans une crise, personne ne fait appel aux « trois » fournisseurs. Lorsqu’un service tombe en panne et menace la rentabilité, on appelle celui qui supporte réellement la charge. Si les données résident sur la nuage A, le traitement des paiements sur B et l’orchestration sur C, l’incident devient une quête de responsable. Les SLA deviennent de la poésie, et le temps de récupération — seul paramètre critique — s’envole. La réalité finale est bien connue : architecture Frankenstein, difficile à auditer, coûteux à sécuriser et mal gouverné.

Le multi-cloud est-il toujours une mauvaise idée ? Pas forcément. Mais la marge est étroite.

Il existe des cas justifiés :

• Réglementations et compliance avec des exigences explicites de séparation des charges ou salvaguardes juridiques.
• Continuité des activités avec des plans sérieux d’active-standby entre fournisseurs, données répliquées et exercices de basculement mesurés par RTO et RPO, pas par diaporama.
• Fusions-acquisitions : des groupes avec des activités héritées, où l’hétérogénéité est un dommage collatéral transitoire.
• IA et workloads spécialisés : choisir un fournisseur uniquement pour un accélérateur spécifique ou une capacité de formation unique, en assumant consciemment le lock-in par valeur.

Mais pour tout le reste, un cloud privé solide, bien conçu (multi-zone, multi-région, IaC, observabilité mature) et un cloud privé là où cela a du sens —faible latence, maîtrise des coûts, résidence des données ou exigences en termes de performance— ont généralement une longueur d’avance en simplicité, contrôle et prévisibilité.

L’Europe a besoin d’une autre voie : souveraineté et proximité

Le discours multi-cloud a servi d’excuse pour éviter de prendre des décisions fondamentales : où résident les données, qui assure le support, quelle juridiction s’applique, et quelle dépendance stratégique nous engage. Pour l’Europe et, en particulier, pour l’Espagne, la question est politique, économique et technologique : souhaillons-nous construire une industrie ou la louer ?

Souveraineté numérique n’est pas un slogan : c’est une capacité concrète de opérer, protéger et faire évoluer des infrastructures critiques sans demander permission en dehors de l’UE, en alignement avec le RGPD et des cadres réglementaires de plus en plus stricts. Cela signifie pouvoir parler dans notre fuseau horaire, avec une ingénierie locale et des responsables qui respectent nos lois. Et aussi contribuer à la chaîne de valeur européenne, plutôt que de l’alimenter depuis l’extérieur.

Dans ce contexte, privilégier des entreprises 100 % européennes — voire françaises — n’est pas du protectionnisme naïf, mais une stratégie industrielle. Elle se traduit par de la proximité, des latences prévisibles, des coûts clairs, des contrats transparents, et un écosystème où fournisseur et client peuvent cocréer des solutions. Elle réduit également l’asymétrie de pouvoir de négociation vis-à-vis des hyperscalers.

Une alternative pragmatique : le cloud privé moderne (et ouvert)

Bien loin de l’idéal on-premise, le cloud privé contemporain ne concurrence pas la cloud public : la complète. Pour des charges prévisibles, sensibles, latence-critiques ou sujettes à turbulences de coûts, d’en monter ou utiliser un cloud privé bien conçu permet de reprendre le contrôle sans renoncer à l’élasticité dans des limites raisonnables.

Proxmox comme stack européen et ouvert

Proxmox VE est un hyperviseur open source, développé en Europe, avec un écosystème mature et une capacité concrète à supporter des environnements de production :

• Virtualisation KVM et conteneurs LXC robustes.
• Ceph pour stockage distribué, avec réplication, auto-guérison et scalabilité horizontale.
• Réseaux virtuels avec VLAN, bonding, OVS, et règles de firewall intégrées.
• Sauvegardes cohérentes, réplication et restaurations granulaires (machines virtuelles entières ou disques).
• Automatisation via API et Terraform providers maintenus par la communauté ou des partenaires.

Tout cela avec un licenciamiento prévisible et sans péages par VM ni par API, sans surprises au niveau des dépenses et avec une observation sous contrôle, soit par le client, soit par un fournisseur européen qui l’opère.

Stackscale : cloud privé européen avec support expert

En Espagne, Stackscale (Groupe Aire) opère une infrastructure bare-metal et cloud privé avec support spécialisé sur Proxmox — formation de base, monitoring de l’hyperviseur, sauvegardes de configurations et états de VM, restaurations rapides en cas de panne de la virtualisation — ainsi qu’un stockage centralisé capable de déployer rapidement des charges.

Selon David Carrero Fernández-Baillo, cofondateur et VP Commercial & Marketing, cette approche est complémentaire : « bare-metal lorsqu’il faut une performance maximale ou un contrôle précis des coûts ; clusters Proxmox pour les cas d’élasticité privée et une haute disponibilité ; et connectivité pour intégrer avec des clouds publics lorsque cela apporte une valeur concrète ». En somme, il s’agit d’utiliser chaque composant selon sa meilleure vocation, sans se soucier de la marque, mais en veillant à la souveraineté et au runbook.

Une approche plus honnête que « vouloir être partout à la fois »

Pour la majorité des organisations européennes, qui ne disposent pas d’équipes de plateforme à trois chiffres dans une big tech, cette approche hybride est plus efficace que le multi-cloud générique :

1. Choisir un fournisseur principal (public ou privé) et bien le faire : multi-AZ, multi-région si pertinent, IaC, SLOs, error budgets, et maîtriser ses coûts.
2. Intégrer un cloud privé là où le TCO est favorable : données sensibles, charges stables, performances, latence, FinOps.
3. Interagir concrètement avec d’autres clouds uniquement pour des avantages clairs (un accélérateur, une région incontournable, une feature spécifique).
4. Concevoir la sortie dès le départ : données souveraines, formats ouverts, backups hors bande, plans d’exit.
5. Aligner sécurité et compliance avec un cadre unique : identité, clés, logs, SIEM, et runbooks qui ne dépendent pas de plusieurs mondes.

Ce schéma permet de faire de l’indépendance une stratégie tactique et vérifiable, et non un simple mantra. Plus encore, il réduit la dette technique que le multi-cloud accumule jusqu’au jour où un incident critique survient.

Objections courantes… et réponses difficiles

• « Le multi-cloud réduit les coûts grâce à la concurrence ».
  Seulement si l’on suit des métriques de coût par produit, des dépenses contrôlées, et une capacité réelle de négociation. Dans les PME et mid-market, l’effet est souvent inverse.
• « Kubernetes nous rend portables ».
  Kubernetes porte des conteneurs, mais ce qui crée du lien, ce sont les services gérés et les données. La portabilité n’est pas équivalente à un transfert rapide (lift-and-shift)
• « Il est intrinsèquement plus résilient ».
  Pas sans données répliquées entre nuages, tests de basculement, et automatisations fiables. Duplicher les logos ne double pas la résilience.
• « La frontière technologique est plus accessible ».
  Seulement si vous l’utilisez. Posséder trois catalogues ne fait pas un state of the art.

Conclusion : moins d’hype, plus d’architecture et de souveraineté

Nommer les choses par leur nom n’est pas du pessimisme, c’est de la technique prudente. Le multi-cloud aveugle est, trop souvent, la forme la plus coûteuse d’auto-tromperie. L’Europe — et l’Espagne — ne peuvent pas se permettre de payer la complexité importée tout en renonçant à une capacité stratégique propre. Il existe une alternative : combiner judicieusement cloud public et cloud privé ouvert, en favorisant des fournisseurs européens répondant ici, et en construisant des architectures vérifiables capables de résister à l’épreuve du hype.

Dans cette optique, Proxmox offre un noyau européen et ouvert; Stackscale et d’autres acteurs apportent proximité, support et savoir-faire pour en faire une réalité. Il ne s’agit pas d’idéologie, mais d’ingénierie, d’économie et de responsabilité.

Questions fréquemment posées

Quand une stratégie multi-cloud a-t-elle du sens, et quand pas ?
Elle est pertinente dans le cadre de réglementations exigeantes imposant la séparation des charges, de plans de continuité avec données répliquées et des tests de basculement, ou encore pour des avantages techniques uniques (par exemple, un accélérateur IA spécifique). En revanche, elle n’est pas justifiée lorsqu’elle repose sur l’inertie politique ou une peur diffuse du lock-in: elle conduit souvent à des coûts plus élevés et une complexité inutile.

Quel avantage offre un fournisseur 100 % européen ou espagnol face à un hyperscaler ?
Il garantit souveraineté juridique (RGPD et cadre UE), un support local, latences plus stables, des contrats plus transparents, et une capacité de co-création. Enfin, il contribue à développer l’industrie locale et à réduire la dépendance stratégique extérieure.

Pourquoi Proxmox constitue-t-il une solution solide pour un cloud privé moderne ?
Parce qu’il est ouvert, européen et expérimenté : virtualisation KVM + LXC, stockage distribué avec Ceph, réseaux virtuels avancés, sauvegardes et réplication intégrées, API pour automatiser et intégrer avec les outils standards. Cela permet de prévoir les coûts, d’éviter les péages par VM ou par API, et de garder la maîtrise des données et opérations.

Que propose un fournisseur comme Stackscale dans ce cadre hybride ?
Une infrastructure bare-metal et cloud privé avec support expert en Proxmox (formation initiale, monitoring, sauvegardes de configurations et états, restaurations rapides) ainsi qu’une connectivité pour intégrer, lorsque pertinent, avec des clouds publics. La démarche est pragmatique et orientée souveraineté et contrôle.