AWS vs Azure vs Google Cloud : comment choisir en 2026

La plupart des comparatifs cloud alignent trois colonnes de services et distribuent des étoiles. Le procédé a deux défauts : le tableau est périmé six mois après sa publication, et il ne répond pas à la question que vous vous posez.

AWS, Azure et Google Cloud ont convergé. Calcul, stockage objet, bases managées, Kubernetes, files de messages, observabilité : les trois savent faire, et les écarts d’il y a cinq ans se sont refermés sur l’immense majorité des cas d’usage d’entreprise. Choisir sur une case cochée, c’est optimiser un critère qui ne discrimine plus.

La vraie question n’est pas « lequel est le meilleur », mais « lequel pour quel contexte ». Le contexte, lui, ne se périme pas : compétences de l’équipe en place, contrats déjà signés, exposition réglementaire, capacité à sortir. Cet article ne traite que de ces critères-là.

Une plateforme que personne ne sait exploiter à trois heures du matin coûte plus cher que celle qui perd le comparatif de deux points. C’est le critère le plus souvent relégué en fin de dossier alors qu’il devrait l’ouvrir.

Ce qui prend des mois à maîtriser, ce ne sont pas les services : c’est le modèle transverse de chaque plateforme. Le découpage des périmètres — comptes et unités d’organisation chez AWS, abonnements et groupes d’administration chez Azure, projets et dossiers chez Google Cloud — structure la facturation, les quotas, l’isolation de sécurité et le rayon d’explosion d’une erreur. Les modèles d’autorisation et de réseau diffèrent tout autant dès qu’on sort du schéma simple.

Les questions utiles avant de trancher :

• Combien de personnes de l’équipe ont déjà tenu une astreinte en production sur cette plateforme ?
• Combien ont diagnostiqué un incident de routage ou une erreur d’autorisation sans ouvrir un ticket au support ?

Un déficit de compétence se rattrape par la formation, mais pas quand il faut former pendant qu’on migre et qu’on continue à livrer. C’est cette configuration qui fait déraper les migrations, bien avant le choix du fournisseur.

La négociation cloud ne commence pas à zéro. Elle commence avec les contrats en cours, qui déplacent l’équation bien plus que l’écart de tarif public entre deux fournisseurs.

• Un accord d’entreprise Microsoft. Si vous détenez des licences Windows Server ou SQL Server avec Software Assurance, l’Azure Hybrid Benefit permet de les réutiliser plutôt que de repayer la licence dans le prix de l’instance. Sur un parc conséquent, cette seule ligne peut dépasser tout le gain d’une optimisation technique.
• Un engagement de consommation pluriannuel déjà négocié, chez Microsoft comme chez AWS ou Google. Consommer ailleurs n’ajoute pas seulement une facture : cela peut vous exposer à un manquement sur celle que vous avez déjà signée.
• L’annuaire d’entreprise. Un parc déjà sous Microsoft 365 bascule sur Azure avec un gain d’exploitation réel : un seul modèle d’authentification, une seule gouvernance des accès, un seul endroit où couper les droits d’un partant.

Le prix catalogue arrive après. Les remises d’engagement à un ou trois ans et les conditions commerciales négociées pèsent plus lourd que l’écart de liste entre les trois.

Le sujet est traité comme une case binaire alors qu’il recouvre trois exigences de niveaux très différents. Les confondre mène soit à une sur-contrainte coûteuse, soit à une conformité de façade.

Résidence des données

Les trois fournisseurs exploitent des régions en France et plusieurs autres dans l’Union, avec les garde-fous pour empêcher la sortie de zone. L’exigence la plus simple à satisfaire — à condition d’appliquer ces garde-fous aussi aux sauvegardes, aux journaux et aux accès du support, souvent oubliés du périmètre initial.

Immunité aux lois extraterritoriales

Exigence d’une tout autre nature : héberger dans une région française ne soustrait pas un fournisseur de droit américain à sa propre législation. Si votre analyse de risque porte sur ce point, le sujet n’est pas la localisation du centre de données, mais la structure juridique de l’entité qui opère le service et le chiffrement dont vous seul détenez les clés.

Qualification SecNumCloud

Elle est portée par des offres dédiées, distinctes du cloud public de l’hyperscaler et opérées par des coentreprises de droit français. Leur catalogue et l’état exact de leur qualification évoluent : vérifiez-les auprès de l’ANSSI et du fournisseur à la date de votre décision.

La contrainte réglementaire — DORA, NIS2, hébergement de données de santé, doctrine cloud du secteur public — ne désigne presque jamais un fournisseur. Elle désigne un périmètre, des exigences de réversibilité et des clauses de sortie. Conséquence pratique : il est tenable d’avoir la majorité du système d’information sur un hyperscaler et d’isoler la fraction réellement sensible sur une offre qualifiée — à condition d’avoir tracé la frontière à la conception.

C’est le domaine où les trois plateformes ne se ressemblent pas, donc le seul où un comparatif de services garde un sens : un entrepôt analytique découplant stockage et calcul et du silicium d’entraînement dédié côté Google ; une proximité contractuelle et technique avec les modèles OpenAI et l’outillage décisionnel Microsoft côté Azure ; un catalogue de modèles multi-éditeurs et des puces maison côté AWS.

C’est aussi le critère le plus volatil du dossier. Un modèle exclusif chez l’un arrive chez les autres en quelques mois. Bâtir un choix de plateforme à dix ans sur la disponibilité d’un modèle à six mois est une erreur d’échelle de temps. Ce qui dure : le modèle de facturation de l’entrepôt analytique — au volume scanné ou au cluster provisionné, ce qui change entièrement la structure de coût selon votre profil de requêtes — et la maturité des outils de gouvernance.

La couche analytique est par ailleurs de plus en plus portable. Les grandes plateformes de données du marché s’exécutent sur les trois clouds, et les formats de table ouverts sur stockage objet ont nettement réduit l’adhérence. Traitez donc l’IA et la data comme un critère de second tour, pour départager deux plateformes déjà éligibles.

Ce qui fait déraper une facture cloud n’est presque jamais le prix horaire du calcul, mais des postes absents de tout comparatif parce qu’ils dépendent de votre architecture.

• Le trafic sortant. Facturé au gigaoctet chez les trois. La réglementation européenne a supprimé les frais dus lorsqu’un client quitte définitivement un fournisseur — avancée réelle pour la réversibilité, sans effet sur le trafic sortant du quotidien. Pour une application qui sert des médias ou une API très consommée, c’est le premier poste de surprise.
• Le trafic entre zones et entre régions. Chaque échange qui traverse une frontière de zone peut être facturé, selon des règles qui diffèrent entre fournisseurs et ont changé plusieurs fois. Un maillage de services bavard réparti sans réflexion sur trois zones coûte parfois plus cher que le calcul qu’il fait tourner.
• Les passerelles de sortie managées. Une passerelle NAT facturée à l’heure et au gigaoctet traité peut dépasser le coût des instances qui l’utilisent — typiquement un cluster Kubernetes qui retélécharge ses images à chaque montée en charge.
• Le stockage dormant et les journaux. Instantanés orphelins, volumes détachés, environnements de recette laissés allumés, frais de récupération des classes froides, et une ingestion de logs facturée au volume qui grimpe silencieusement à chaque nouveau service.

L’écart de prix catalogue entre les trois est du bruit face à ces postes : une architecture mal dessinée coûte plus cher chez le moins cher qu’une architecture propre chez le plus cher. Nos deux missions FinOps documentées — −52 % de coûts cloud sur un périmètre bancaire mobile à service constant, −61 % de facture AWS pour une startup SaaS en série A — n’ont impliqué aucun changement d’hyperscaler. Voir notre guide FinOps.

Le multi-cloud arrive en comité avec trois justifications : éviter la dépendance, conserver un levier de négociation, améliorer la résilience. Les trois résistent mal à l’examen.

Le coût réel

Il ne se limite pas à faire les choses deux fois : deux jeux d’infrastructure as code, deux modèles d’identité et de réseau, deux astreintes, deux courbes de compétence dans une équipe qui n’en maîtrisait déjà pas une. Le poste le plus cher est ailleurs : le plus petit dénominateur commun. Pour rester portable, on renonce aux services managés qui font l’intérêt économique du cloud. Vous payez deux clouds pour n’en utiliser correctement aucun.

Le gain réel

Le levier de négociation se retourne souvent : les remises viennent de l’engagement en volume, et répartir la consommation fragmente cet engagement, donc dégrade les deux remises. Quant à la résilience, une panne de région se traite par du multi-région chez le même fournisseur, sans commune mesure de coût avec un actif/actif inter-clouds — que très peu d’organisations testent réellement, et qu’un basculement non testé ne protège de rien.

Quand c’est justifié

• Une obligation réglementaire ou contractuelle explicite et opposable.
• Un héritage subi : fusion, acquisition, filiale installée ailleurs. Le sujet devient la trajectoire de convergence.
• Un service précis, sans équivalent acceptable, consommé depuis un socle mono-cloud assumé. Le cas le plus fréquent et le plus sain.

Notre règle : mono-cloud par défaut, multi-cloud par exception documentée et chiffrée. Ce qu’il faut protéger n’est pas la capacité à basculer demain matin — personne ne le fait — mais celle de sortir en dix-huit mois sans réécrire le système.

La dépendance à un fournisseur ne se mesure pas en téraoctets à déplacer, mais en jours-homme de réécriture. Trois niveaux, qui n’appellent pas la même vigilance :

1. L’infrastructure banalisée — machines virtuelles, stockage objet, base relationnelle managée, Kubernetes. Sortie coûteuse mais bornée, et surtout estimable à l’avance.
2. Les services managés propriétaires — orchestration serverless, base NoSQL maison, bus d’événements, entrepôt analytique. Sortir n’est pas migrer : c’est réécrire. C’est aussi là que se trouve la valeur que vous êtes venu chercher.
3. Les données et les identités. Le niveau le plus lourd : il touche toutes les applications d’un coup.

Le bon arbitrage n’est pas de bannir le propriétaire — ce serait payer le prix du cloud sans en avoir les bénéfices. C’est savoir ce que vous engagez et l’écrire : nous documentons chaque dépendance forte dans une décision d’architecture datée, avec l’estimation du coût de sortie au moment du choix. Trois ans plus tard, la discussion en comité part d’un chiffre plutôt que d’une opinion.

Trois mesures peu coûteuses préservent la sortie : l’infrastructure as code intégrale — une infrastructure non décrite ne se reconstruit nulle part ; les données dans des formats ouverts sur stockage objet ; l’isolation des bibliothèques propriétaires derrière une interface applicative — pas une couche d’abstraction universelle, juste un point unique à réécrire.

La suppression réglementaire des frais de transfert règle le poste le moins cher d’une migration ; la réécriture et la double exploitation pendant la bascule restent à votre charge. Nos stratégies de migration détaillent ce chiffrage.

Aucune ligne ci-dessous ne repose sur un prix ni sur une fonctionnalité : ce sont les critères qui tiendront encore dans deux ans.

Votre contexte	Ce qui pèse dans la décision
Système d’information déjà sous Microsoft, annuaire unifié, applications .NET, accord de licence en cours	Azure part avec une avance d’exploitation réelle : identité unique, réutilisation des licences, un seul interlocuteur contractuel.
Produit SaaS, petite équipe, besoin d’un catalogue large et de profils disponibles	AWS reste l’écosystème le plus dense en outillage tiers, en contenus et en candidats sur le marché français.
L’analytique et l’IA sont au cœur du produit, pas en support	Google Cloud mérite une évaluation sérieuse — en gardant en tête que c’est le critère le plus volatil du dossier.
Contrainte de souveraineté forte, secteur sensible	Aucun des trois n’y répond seul. Le travail porte sur le périmètre à isoler, l’offre qualifiée et les clauses de sortie.
L’équipe est déjà compétente et outillée sur une plateforme	Cette plateforme, sauf raison écrite et chiffrée du contraire. Ce critère prime sur tous les autres.
Aucune contrainte particulière ne se dégage	Prenez celle que l’équipe saura exploiter et engagez-vous dessus. L’indécision coûte plus cher que le mauvais choix.

Nous opérons sur les trois plateformes : Azure chez Neuflize OBC et Société Générale CIB, AWS pour une startup SaaS en série A, Google Cloud pour France TV. Notre neutralité n’est pas une posture commerciale — elle vient de ce que nous constatons dossier après dossier : le fournisseur est rarement la variable qui explique le résultat.

Ce qui l’explique : le dimensionnement, le découpage des comptes et des abonnements, la qualité de l’infrastructure as code, la discipline de facturation, et la capacité de l’équipe à exploiter ce qu’elle a déployé.

Si la question du fournisseur est réellement ouverte chez vous, elle se tranche en quelques jours de cadrage : inventaire des contrats, cartographie des compétences, analyse réglementaire, estimation du coût de sortie sur les trois hypothèses. Pas en trois mois d’étude comparative dont la conclusion sera périmée avant d’être présentée.

Découvrez notre expertise Cloud et FinOps ou parlez-nous de votre contexte — 45 minutes, avec un associé, sans engagement.