Cloud agnostique sur Azure - Liberté ou dépendance?

Une stratégie cloud agnostique ne consiste pas à fuir un fournisseur à tout prix, mais à garder la liberté de déplacer une application, ses données ou au moins son socle d’exploitation sans tout reconstruire. Dans un environnement dominé par Microsoft Azure, l’enjeu est surtout de savoir quelles couches resteront portables et lesquelles peuvent être volontairement liées à l’écosystème Microsoft. Je vais clarifier ce que cela change concrètement, où Microsoft aide vraiment, et à quel moment la recherche de souplesse devient un surcoût inutile.

Ce que recouvre vraiment une stratégie neutre vis-à-vis du cloud

Je préfère parler de neutralité architecturale plutôt que de pure indépendance. Dans la pratique, aucune pile moderne n’est totalement interchangeable: le système d’exploitation, l’orchestrateur, la base de données, l’identité, les API et les outils d’observabilité créent toujours des points d’attache. L’objectif n’est donc pas de tout rendre identique partout, mais de choisir les dépendances qui servent le produit sans enfermer l’organisation.

Notion	Ce qu’elle apporte	Sa limite fréquente
Portabilité	Le code et l’infrastructure peuvent se déplacer avec peu de changements	Elle demande plus de discipline, de tests et de standardisation
Multicloud	Répartit certains services ou certaines charges entre plusieurs fournisseurs	Ne supprime pas la dépendance, elle la répartit
Hybride	Combine datacenter, cloud public et parfois edge dans un même modèle d’exploitation	Augmente la complexité d’intégration et de supervision
Réversibilité	Permet de quitter un fournisseur sans repartir de zéro	Elle n’existe que si la migration est pensée dès le départ

Dans mes projets, je vise surtout une chose: rendre mobile ce qui crée de la valeur, et accepter le spécifique là où le gain opérationnel est net. Cette nuance change tout, parce qu’elle évite deux travers opposés: l’architecture théoriquement parfaite mais trop chère à maintenir, ou le choix ultra-pragmatique qui devient un enfermement discret. C’est précisément ce compromis qui rend l’écosystème Microsoft intéressant dans un projet qui veut rester réversible.

Pourquoi l’écosystème Microsoft peut rester ouvert

Ce qui m’intéresse chez Microsoft, ce n’est pas l’idée d’être “chez Microsoft” à tout prix, mais la capacité à séparer le plan de contrôle de l’exécution. Azure Arc sert à étendre la gouvernance et l’inventaire à des serveurs, clusters Kubernetes et services répartis hors d’Azure; on garde un point de pilotage cohérent sans déplacer forcément les workloads. AKS, de son côté, repose sur Kubernetes, donc sur un standard d’orchestration qui facilite les déploiements portables tant que l’application elle-même reste proprement conteneurisée.

• OpenTelemetry sépare l’instrumentation du backend d’observabilité. Microsoft Learn souligne l’intérêt de pipelines de télémétrie agnostiques vis-à-vis du fournisseur, ce qui permet de changer d’outil sans réécrire l’application.
• Terraform garde l’infrastructure sous forme de code réutilisable. Je le préfère aux séquences de clics ou aux scripts ponctuels dès qu’une équipe veut préserver une vraie capacité de sortie.
• Bicep reste très pertinent si l’objectif est d’aller vite dans Azure avec une syntaxe plus claire que les anciens modèles ARM, mais il répond à un besoin différent de la portabilité maximale.
• Azure Export for Terraform peut aider à reprendre un existant Azure et à le faire basculer vers un modèle plus déclaratif.

Autrement dit, Microsoft peut très bien servir une stratégie ouverte, à condition d’être utilisé comme plateforme de pilotage et pas comme moule unique pour toute l’architecture. Une fois ces briques posées, la question devient celle des couches à standardiser en premier.

Les couches à standardiser en priorité

Je découpe presque toujours le sujet en plusieurs couches, parce que toutes ne méritent pas le même niveau d’indépendance. Si vous tentez de tout abstraire partout, vous payez la complexité sans gagner une vraie liberté. Si vous choisissez les bonnes couches, en revanche, vous obtenez une architecture qui reste vivable dans le temps.

Couche	Ce que je standardise	Pourquoi	Ce que j’évite
Exécution applicative	Conteneurs, manifests Kubernetes, images portables, charts Helm propres	Le workload peut changer de cluster sans réécriture massive	Appeler directement des services très spécifiques depuis le cœur métier
Infrastructure et déploiement	Modules Terraform, variables claires, pipelines reproductibles	Les environnements se reconstruisent de façon prévisible	La configuration dispersée dans le portail ou dans des scripts manuels
Observabilité	OpenTelemetry, logs structurés, métriques standardisées	Le backend de supervision devient remplaçable	L’agent propriétaire au centre de toute la chaîne de diagnostic
Sécurité et gouvernance	RBAC, policy as code, gestion rigoureuse des secrets	L’audit et l’exploitation sont plus cohérents	Des règles éparpillées entre plusieurs consoles sans documentation
Données et contrats	SQL standard, schémas versionnés, contrats d’événements explicites	La migration reste possible sans refonte complète	Les fonctions avancées propres à un seul moteur ou à un seul service

Le point le plus sous-estimé, à mes yeux, reste la donnée. Plus vous exploitez les fonctions avancées d’un moteur, plus vous réduisez votre liberté de mouvement; ce n’est pas forcément un mauvais choix, mais il doit être assumé. Sur l’exécution, il faut aussi garder en tête une réalité pratique: Kubernetes suit une fenêtre glissante de trois versions mineures, donc la portabilité n’existe que si les mises à niveau restent disciplinées. Et c’est là que les difficultés reviennent souvent par la porte des services managés.

Là où le verrouillage revient le plus vite

Je ne diabolise pas les services managés; je les utilise souvent. En revanche, je les classe par niveau de dépendance, parce qu’un gain de productivité aujourd’hui peut devenir un coût de sortie important demain. C’est le genre de raccourci qui fait gagner des semaines au début et des mois à la fin.

• Bases de données managées — elles apportent de la disponibilité, des sauvegardes et moins d’exploitation, mais chaque fonction propriétaire utilisée dans le code rend la migration plus coûteuse. Si le cœur métier dépend du moteur, la sortie n’est plus une simple opération technique.
• Serverless et workflows — les fonctions, déclencheurs et connecteurs accélèrent énormément le delivery, mais la logique d’orchestration finit souvent par se confondre avec la plateforme. C’est très efficace pour des automatisations, moins pour un socle applicatif que vous souhaitez garder mobile.
• Messagerie et événements — files, topics, retries et dead-letter queues sont précieux, mais leur sémantique devient vite un contrat implicite. À ce stade, remplacer le service demande plus qu’un changement de configuration.
• Identité et réseau — l’intégration profonde avec l’annuaire, les endpoints privés, les règles réseau et les politiques de sécurité apporte une vraie robustesse, mais elle alourdit aussi la sortie. Ici, la dépendance est souvent invisible jusqu’au jour où elle compte vraiment.
• Observabilité très couplée au portail — dès que le diagnostic repose sur des tableaux de bord ou des agents trop spécifiques, la supervision devient un verrou discret. J’essaie donc de garder au moins le format des données de télémétrie portable.

Quand je dois arbitrer, je réserve ces services aux couches qui ne différencient pas le produit. Si le service apporte surtout du confort d’exploitation, il peut valoir la dépendance; s’il porte la logique métier, je cherche une abstraction plus propre. Le bon niveau d’indépendance dépend donc moins d’un dogme que du rôle du système.

Choisir le bon niveau d’indépendance selon le projet

La vraie question n’est pas “tout portable ou rien”. C’est plutôt: quelle dépendance peut-on accepter sans rendre la sortie douloureuse ? La réponse change selon la maturité du produit, l’exposition réglementaire, la vitesse attendue et la durée de vie du système.

Cas de figure	Niveau que je viserais	Mon critère de décision
MVP ou nouveau produit	Portabilité partielle, surtout sur le runtime et l’infrastructure	La vitesse compte plus que la réversibilité parfaite, mais il faut éviter les impasses visibles
SaaS B2B en croissance	Portabilité forte sur l’application et les données	Je veux pouvoir négocier, pivoter ou migrer sans reconstruire le socle
Secteur régulé ou contrat sensible	Réversibilité élevée et dépendances documentées	Le coût d’une sortie doit rester maîtrisable même en cas de changement stratégique
Outil interne ou projet court	Portabilité limitée, choix plus pragmatiques	La durée de vie et le périmètre ne justifient pas toujours une architecture très abstraite
Organisation déjà très engagée sur Azure	Portabilité ciblée, pas refonte totale	Je protège surtout les couches les plus coûteuses à migrer

• Je standardise en priorité ce qui change souvent.
• Je laisse du spécifique à Azure seulement là où le gain opérationnel est clair.
• Je documente les dépendances réelles, pas celles qu’on imagine.
• Je teste une sortie partielle sur un environnement de validation avant d’en faire une promesse d’architecture.

Quand une équipe adopte cette discipline, Microsoft devient un accélérateur, pas une cage. Il reste alors à formuler le compromis de façon simple et exploitable au quotidien.

Le compromis que je retiens pour un projet Microsoft ouvert

Pour moi, la bonne ligne de crête consiste à utiliser Azure comme plateforme d’exécution et de gouvernance, tout en gardant les fondations applicatives sur des standards ouverts. Cela donne un meilleur équilibre qu’une indépendance totale, souvent plus théorique que rentable.

• Je privilégie un runtime conteneurisé quand la portabilité compte vraiment.
• Je décris l’infrastructure en code, avec des modules lisibles et réutilisables.
• Je normalise l’observabilité avec OpenTelemetry.
• J’utilise Azure Arc quand la gouvernance centralisée simplifie réellement l’opérationnel.
• Je réserve les services très spécifiques aux besoins qui justifient leur dépendance.

Si je devais résumer l’approche en une règle simple, je dirais ceci: garder la liberté de sortir là où la sortie coûte cher, et accepter le spécifique là où il crée une vraie valeur. C’est cette discipline qui permet de travailler avec Microsoft sans confondre efficacité immédiate et enfermement durable.