Stratégie multi-cloud pour PME : éviter le vendor lock-in sans se compliquer la vie

Selon le rapport Flexera State of the Cloud 2024, 70% des entreprises utilisent désormais deux clouds publics ou plus. Parmi les PME, ce chiffre est souvent le résultat d'une accumulation organique plutôt que d'une décision stratégique : un SaaS critique qui tourne sur AWS, une infrastructure Azure parce que vous utilisez M365, un projet pilote IA sur GCP. Bienvenue dans la réalité multi-cloud.

Ce billet n'est pas un plaidoyer pour le multi-cloud à tout prix. C'est un guide pragmatique pour les CTOs et DevOps de PME qui se retrouvent dans cette situation — intentionnellement ou non — et qui veulent en tirer le meilleur parti sans se noyer dans la complexité.

Pourquoi les PME se retrouvent multi-cloud sans l'avoir décidé

La vérité est que la plupart des PME deviennent multi-cloud par accident, par accumulation de décisions tactiques prises isolément :

• L'intégration SaaS : Votre CRM Salesforce tourne sur AWS. Votre outil de collaboration Teams est sur Azure. Votre data warehouse est sur GCP via BigQuery. Chaque décision était logique prise isolément — ensemble, vous êtes multi-cloud.
• L'héritage historique : L'entreprise a migré son infra sur Azure il y a 3 ans parce qu'elle utilisait Windows Server et Active Directory. Puis le CTO a lancé un projet ML sur AWS SageMaker parce que "c'est là où sont les meilleurs modèles". Et voilà.
• Les acquisitions : Vous rachetez une startup dont toute l'infra est sur GCP. Migrer vers votre stack Azure prendrait 18 mois. En attendant, vous gérez les deux.
• Les projets pilotes qui restent : "On teste juste GCP pour ce projet IA" — deux ans après, le projet IA est en production et personne ne veut le migrer.

Ce multi-cloud accidentel n'est pas forcément mauvais — mais il est risqué si vous ne le reconnaissez pas et ne le gérez pas activement.

Multi-cloud intentionnel vs accidentel : les différences qui comptent

La distinction est fondamentale. Le multi-cloud accidentel se caractérise par l'absence de gouvernance centrale, des équipes qui ne savent pas ce qui tourne où, des coûts difficiles à attribuer, des identités gérées en silo dans chaque provider, et une sécurité fragmentée. C'est là que les brèches arrivent.

Le multi-cloud intentionnel, lui, repose sur une stratégie claire : chaque cloud est choisi pour ce qu'il fait mieux, une couche d'abstraction unifie la gestion, les identités sont fédérées, les coûts sont visibles et maîtrisés. C'est la différence entre subir et choisir.

Le passage de l'accidentel à l'intentionnel ne nécessite pas forcément de tout migrer. Il nécessite un inventaire honnête de ce que vous avez et une décision consciente sur ce que vous voulez garder.

Les vrais bénéfices du multi-cloud (quand c'est intentionnel)

Résilience et disponibilité : Un incident majeur sur AWS (comme la panne d'us-east-1 en décembre 2021 qui a impacté Netflix, Spotify, Disney+) ne doit pas mettre votre business à l'arrêt. Avec une architecture multi-cloud, vous pouvez rediriger le trafic vers Azure ou GCP pendant la panne. Cela demande une préparation, mais c'est faisable.

Levier de négociation sur les prix : Les providers cloud savent que vous êtes captif si vous êtes mono-cloud. En démontrant votre capacité à déplacer des workloads, vous avez un levier réel lors des renouvellements de contrats enterprise. Plusieurs PME obtiennent 20-30% de réduction simplement en menaçant crédiblement de migrer.

Le meilleur service par cas d'usage : AWS domine le compute et le stockage (S3 reste la référence). Azure est imbattable pour tout ce qui touche à l'écosystème Microsoft (Entra ID, M365, Teams). GCP est premier sur l'analytique massive (BigQuery) et l'IA (Vertex AI, Gemini). Utiliser le meilleur outil pour chaque usage, c'est du bon sens d'ingénierie.

Conformité et souveraineté des données : Certaines données doivent rester en Canada (réglementations LPRPDE, PHIPA). En ayant plusieurs options, vous pouvez choisir le provider qui offre les meilleures garanties de résidence de données pour chaque type de donnée.

Les vrais défis du multi-cloud (sans faux-semblants)

Le multi-cloud a des coûts réels qu'il faut regarder en face avant de se lancer :

Complexité opérationnelle : Gérer trois consoles différentes, trois CLIs (aws, az, gcloud), trois modèles IAM distincts, trois systèmes de billing — c'est du overhead réel. Une équipe de 3 DevOps peut facilement y passer 40% de son temps si elle n'a pas les bons outils.

Coûts de formation : Les certifications AWS, Azure et GCP sont toutes différentes. Former un ingénieur sur les trois stacks représente 6 à 12 mois d'investissement. Sous-estimez ce coût et vous vous retrouverez avec du code "ça marche je sais pas trop pourquoi" dans trois clouds différents.

Les egress fees inter-cloud : C'est LE piège numéro un. Transférer des données d'AWS vers Azure ou GCP coûte entre 8 et 9 cents par gigaoctet. Pour une PME qui transfère 10 TB par mois entre deux clouds, ça fait 800 à 900 USD par mois — rien que pour les transferts. Concevez vos architectures pour minimiser les flux inter-cloud.

Sécurité unifiée : Chaque cloud a son modèle IAM. AWS IAM, Azure Entra ID (ex-Azure AD), GCP Cloud IAM — trois syntaxes, trois logiques d'accès différentes. Sans une couche d'identité fédérée, vous gérez trois systèmes d'accès séparés, avec le risque de "trou" de visibilité entre les deux.

Stratégies pratiques pour un multi-cloud maîtrisé

1. L'abstraction layer : Terraform et Pulumi

La règle d'or : ne jamais utiliser les consoles cloud directement pour créer de l'infrastructure. Tout passe par du code (IaC — Infrastructure as Code). Terraform et Pulumi sont les deux outils incontournables :

• Terraform (HashiCorp) : le standard de l'industrie. Providers pour AWS, Azure, GCP, et 1000+ autres. HCL comme langage, state file pour suivre l'état réel. Modules réutilisables pour standardiser vos patterns d'infrastructure across clouds. Terraform Cloud ou Atlantis pour l'exécution en CI/CD.
• Pulumi : même concept mais avec des vrais langages de programmation (TypeScript, Python, Go). Idéal si votre équipe préfère coder en Python plutôt qu'apprendre HCL. Particulièrement puissant pour les architectures complexes avec beaucoup de logique conditionnelle.

L'abstraction IaC vous donne un avantage clé : votre infrastructure est versionnable, auditable, et reproductible. Si un cloud fait défaut, vous pouvez re-provisionner dans un autre en modifiant quelques variables de provider.

2. Kubernetes multi-cluster

Kubernetes est le runtime universel du multi-cloud. Un cluster EKS sur AWS, un AKS sur Azure, un GKE sur GCP — vos applications containerisées tournent identiquement sur les trois. La stratégie :

• Fleet management : Google Anthos ou Rancher pour gérer plusieurs clusters depuis une interface unifiée. Azure Arc étend la gestion Azure sur n'importe quel cluster Kubernetes, y compris on-premises et autres clouds.
• Crossplane : provisionnez des ressources cloud (buckets S3, bases de données RDS) via des Custom Resources Kubernetes. Votre infra cloud devient des objets Kubernetes — gérable avec kubectl et GitOps.
• Service mesh : Istio ou Linkerd pour le chiffrement mTLS et la gestion du trafic entre services across clusters. Avec Istio, vous pouvez routez 20% du trafic vers AWS et 80% vers Azure pendant une migration progressive.

3. Identité fédérée : un login pour tous les clouds

Le chaos de l'identité est le premier problème à résoudre dans un environnement multi-cloud. La solution : un fournisseur d'identité unique qui fédère vers tous vos clouds.

• Okta : le standard enterprise. Fédère vers AWS (via IAM Identity Center), Azure (via Entra ID External Identities), et GCP (via Workforce Identity Federation). Un utilisateur, une identité, un mot de passe, une MFA — partout.
• Azure Entra ID (ex-Azure AD) : si vous êtes déjà dans l'écosystème Microsoft, c'est l'option naturelle. Entra ID peut fédérer vers AWS via SAML/OIDC et vers GCP via Workload Identity Federation. Idéal pour les PME qui utilisent M365.
• AWS IAM Identity Center : si AWS est votre cloud primaire, IAM Identity Center (ex-SSO) permet de gérer les accès à tous vos comptes AWS et peut se fédérer vers Azure et GCP en tant que SP (Service Provider).

Quand choisir quoi : le guide décisionnel

La question n'est pas "quel cloud est le meilleur" — c'est "le meilleur pour quoi" :

Choisissez AWS quand : vous avez besoin du meilleur écosystème de services compute (EC2, ECS, EKS, Lambda), du stockage objet le plus mature (S3), du plus grand marché ML (SageMaker, Bedrock), ou de la plus grande couverture mondiale (33 régions). AWS est le bon choix pour la prod principale d'une PME tech qui n'est pas fortement ancrée dans l'écosystème Microsoft.

Choisissez Azure quand : votre entreprise utilise M365 (Outlook, Teams, SharePoint) — c'est une évidence économique, l'intégration est native et les économies sont réelles. Azure est également le choix logique si vous avez un Active Directory on-premises à hybrider, si vous gérez des workloads Windows Server, ou si vous êtes dans un secteur réglementé canadien qui préfère Microsoft pour les engagements contractuels.

Choisissez GCP quand : vous avez des besoins analytiques importants (BigQuery est imbattable à son prix), des projets d'IA/ML qui bénéficieront des TPUs et de Vertex AI, des applications mobiles ou web (Firebase), ou si vous avez besoin d'une infrastructure réseau premium avec faible latence (le backbone réseau de Google est objectivement supérieur pour certains types de trafic).

Outils de gestion multi-cloud

Gérer trois clouds sans les bons outils, c'est la garantie de la complexité qui fait peur. Les outils qui font la différence :

• Google Anthos : plateforme de gestion multi-cloud et hybride de Google. Permet de déployer et gérer des workloads Kubernetes sur n'importe quel cloud ou on-premises depuis une interface unifiée. Fort si GCP est votre cloud primaire.
• Azure Arc : étend les services Azure (governance, policy, monitoring) à n'importe quelle infrastructure — AWS, GCP, on-premises, edge. Particulièrement puissant pour les entreprises centrées sur Azure qui veulent une vue unifiée.
• Crossplane : open-source, CNCF incubating. Provisionnez des ressources cloud depuis Kubernetes. L'infrastructure devient des Custom Resources. Idéal pour les équipes qui vivent dans Kubernetes.
• CloudHealth (VMware Aria) : gestion des coûts et de la gouvernance multi-cloud. Visibilité sur ce que vous dépensez sur chaque cloud, par équipe, par projet, par environnement. Indispensable quand vous atteignez 10k USD/mois de spend cloud.
• Spot.io (NetApp) : optimisation des coûts cloud. Utilise l'IA pour mixer instances Spot/Preemptible avec instances on-demand de manière transparente. Économies typiques de 60-80% sur les workloads batch et non-critiques.

Les erreurs communes qui transforment le multi-cloud en enfer opérationnel

🚨 Vouloir tout répliquer partout
L'erreur classique : "On va déployer la même chose sur AWS et Azure pour la résilience". Résultat : le double des coûts, le double de la complexité, le double des chances de désynchronisation entre les deux. La résilience multi-cloud nécessite une architecture asymétrique — pas du copier-coller. Définissez votre cloud primaire et votre cloud secondaire avec des rôles distincts.

🚨 Sous-estimer les egress fees
Les egress fees inter-cloud sont invisibles dans les estimations de coûts jusqu'au premier vrai bill. AWS facture 8-9 cents/GB pour les données qui quittent ses régions. Azure et GCP pareil. Une architecture naïve qui synchronise des bases de données entre AWS et Azure peut générer des factures de plusieurs milliers de dollars par mois en egress seul. Règle : colocalisez les données avec les services qui les consomment.

🚨 Pas de gouvernance centralisée
Sans gouvernance centrale, chaque équipe crée ses propres comptes cloud, ses propres configurations IAM, ses propres patterns de déploiement. En 18 mois, vous avez 47 comptes AWS, 23 subscriptions Azure, et personne ne sait exactement ce qui tourne. Mettez en place une AWS Organization avec SCPs dès le premier jour, une Azure Management Group hierarchy, et un GCP Organization avec folder structure. Trop tôt pour ça ? Non — c'est exactement le bon moment.

🚨 Ignorer les différences de modèle IAM
AWS IAM, Azure Entra ID et GCP Cloud IAM ont des modèles fondamentalement différents. Une policy AWS "Deny sauf si MFA" ne se traduit pas directement en Azure Conditional Access. Former vos équipes sur les nuances de chaque modèle n'est pas optionnel — c'est la base de la sécurité multi-cloud.

🚨 Pas de plan de sortie
L'un des arguments principaux du multi-cloud est d'éviter le vendor lock-in. Mais si vous n'avez jamais testé votre capacité à déplacer un workload d'un cloud à l'autre, vous avez un lock-in virtuel même avec plusieurs providers. Faites un exercice de portabilité annuel — choisissez un service non-critique et migrez-le d'un cloud à l'autre. Vous apprendrez énormément sur vos dépendances réelles.

Cas concret BOTUM : PME avec AWS prod, Azure M365, GCP analytics

Contexte : éditeur SaaS québécois, 65 employés, 2,4M$ ARR. Stack initiale : tout sur AWS. Après 3 ans de croissance, la situation réelle :

• AWS : prod applicative (EKS + RDS + S3), CI/CD (CodePipeline), CDN (CloudFront)
• Azure (non planifié) : M365 pour toute la collaboration interne (Teams, SharePoint, Outlook), Azure DevOps pour une partie du code. AD hybride entre on-prem et Azure.
• GCP (non planifié) : un projet pilote BigQuery lancé par l'équipe data "pour tester" — devenu le pipeline analytics principal.

Problème : trois clouds, trois équipes séparées, trois billing isolés. L'équipe data ne savait pas que les jobs BigQuery qui lisaient des données depuis S3 généraient 400 USD/mois d'egress AWS. Les identités étaient gérées en silo. Aucune vue consolidée des coûts.

Ce que BOTUM a mis en place :

• Gouvernance unifiée : AWS Organization avec SCPs, Azure Management Group, GCP folder hierarchy. Toutes les dépenses consolidées dans CloudHealth.
• Identité fédérée : Azure Entra ID comme IdP principal (déjà utilisé pour M365). Fédéré vers AWS IAM Identity Center (SAML 2.0) et GCP Workforce Identity Federation. Un login, partout.
• Migration des données BigQuery : au lieu de lire S3 depuis GCP (egress 8 cents/GB), les données sont copiées dans GCS (Google Cloud Storage) en début de nuit via une job Cloud Run. BigQuery lit GCS — zéro egress. Économie : 380 USD/mois.
• IaC unifié : tout Terraform, modules séparés par cloud, state partagé dans S3 avec locking DynamoDB. L'équipe infra gère les trois clouds depuis le même workflow.
• Monitoring unifié : Datadog comme couche d'observabilité commune. Les métriques AWS, Azure et GCP dans un seul dashboard. Alerting unifié.

Résultat après 6 mois :

• Dépenses cloud réduites de 28% (380 USD/mois egress + 15% d'économies Spot.io sur AWS + négociation Azure EA)
• Temps de résolution d'incidents réduit de 45% (monitoring unifié)
• Onboarding nouveaux devs réduit de 3 semaines à 5 jours (IaC + identité fédérée)
• Zéro vendor lock-in : capacité démontrée à migrer les workloads batch d'AWS vers GCP en 2 semaines

Conclusion : le multi-cloud, ça se gère — à condition de le choisir

Le multi-cloud est une réalité pour la plupart des PME en croissance. La question n'est pas "est-ce que je veux être multi-cloud" — c'est souvent déjà le cas. La vraie question est "est-ce que je le gère de manière intentionnelle ou j'accumule de la dette opérationnelle ?"

Les outils existent. Terraform pour l'abstraction infra, Kubernetes pour la portabilité applicative, une identité fédérée pour la sécurité, CloudHealth pour la visibilité des coûts. Aucun de ces outils n'est magique — tous demandent un investissement initial. Mais cet investissement est infiniment inférieur au coût du chaos multi-cloud non géré.

La règle BOTUM : commencez par l'inventaire, définissez le rôle de chaque cloud, fédérez les identités, puis ajoutez les couches d'abstraction. Dans cet ordre. Pas l'inverse.