Comparer les fournisseurs cloud : guide pratique pour les entreprises

Pour comparer des fournisseurs cloud, évaluez-les par rapport à vos propres charges de travail, et non à une liste générique de fonctionnalités. Les critères qui tranchent la plupart des choix sont : les régions et la résidence des données, les services managés dont vous avez besoin, les preuves de sécurité et de conformité, les conditions de SLA, le coût total, y compris la sortie de données et le support, les compétences dont vous disposez, et la facilité avec laquelle vous pourrez partir. Validez ensuite la présélection par un pilote.
Points clés
- AWS, Microsoft et Google concentraient ensemble 63 % des dépenses mondiales en infrastructure cloud au T2 2026 (28 %, 20 % et 15 %, selon Synergy Research Group). La plupart des présélections partent de là, mais la part de marché ne choisit pas un fournisseur à votre place.
- Rédigez d'abord les exigences : latence, résidence des données, conformité, objectifs de reprise, budget et compétences de votre équipe.
- Comparez les SLA service par service. Le taux de disponibilité affiché est une formule de crédits, pas une garantie de continuité d'activité.
- Modélisez le coût total avec un usage réel : tarification à la demande ou avec engagement, sortie de données, plans de support et personnel nécessaire pour exploiter la plateforme.
- Menez un pilote de 4 à 8 semaines sur une charge de travail représentative et notez-le avec des pondérations convenues avant que quiconque ne voie les résultats.
- Négociez la sortie dès le départ : formats de données, coûts de transfert et règles de changement de fournisseur du règlement européen sur les données (Data Act).
Qui sont les principaux fournisseurs cloud ?
Trois hyperscalers dominent. Au T2 2026, Synergy Research Group chiffrait la part de marché mondiale de l'infrastructure cloud à 28 % pour Amazon, 20 % pour Microsoft et 15 % pour Google, Microsoft et Google croissant plus vite qu'Amazon (Synergy Research Group, juillet 2026). Le même communiqué note une forte croissance chez les fournisseurs « de second rang » et ceux axés sur les GPU, tirée par l'IA générative.
| Fournisseur | Généralement fort pour | À vérifier de près |
|---|---|---|
| Amazon Web Services (AWS) | Catalogue de services le plus large, écosystème de partenaires mature, nombreuses régions ; choix par défaut courant pour les SaaS et les entreprises numériques | La discipline des coûts : la multiplicité des services et des options tarifaires fait grossir les factures sans optimisation active |
| Microsoft Azure | Organisations déjà sur Microsoft 365, Entra ID, Windows Server et SQL Server ; hybride avec Azure Arc ; avantages de licences | Les services disponibles dans la région choisie ; la correspondance des plans de support avec vos besoins en cas d'incident |
| Google Cloud | Analytique de données (BigQuery), outils d'IA/ML, héritage Kubernetes, performances réseau | La couverture locale en partenaires et en support dans votre pays ; les fonctions d'entreprise dont vous dépendez |
| Fournisseurs européens et régionaux | Souveraineté des données, contrats et support locaux (par exemple OVHcloud en Europe) | L'étendue des services managés ; le risque de reconstruire ce qu'un hyperscaler exploiterait pour vous |
Le tableau décrit des schémas typiques, pas un classement. Votre présélection dépend de vos charges de travail et de vos contraintes.
Quels critères utiliser pour comparer des fournisseurs cloud ?
Sept critères couvrent la plupart des décisions. Pondérez-les pour votre entreprise avant de regarder les fournisseurs.
1. Régions, latence et résidence des données
Vérifiez que le fournisseur dispose de régions là où vos utilisateurs et vos régulateurs en ont besoin, et que les services précis dont vous avez besoin y sont disponibles. Pour les organisations nordiques, cela signifie généralement Stockholm ou une autre région de l'UE ; pour les charges de travail indiennes, Mumbai ou Hyderabad. Mesurez la latence depuis les sites de vos utilisateurs aux 95e et 99e centiles, pas en moyenne. AWS publie sa carte des régions et zones de disponibilité (infrastructure mondiale d'AWS) ; Azure et Google Cloud ont des équivalents.
2. Les services managés que vous utiliserez réellement
Listez les briques de votre architecture : bases de données managées, Kubernetes, serverless, entrepôt de données, identité, services d'IA. Comparez la maturité et les fonctions de ceux-là, pas le nombre total de services. Un fournisseur qui compte 200 services ne vous aide pas si son PostgreSQL managé n'a pas l'extension dont vous dépendez.
3. Sécurité, conformité et responsabilité partagée
Demandez les rapports d'audit à jour (ISO 27001, SOC 2, PCI DSS le cas échéant) et confirmez les services qu'ils couvrent. Cartographiez ensuite le modèle de responsabilité partagée. Les recommandations de Microsoft sont explicites : quel que soit le type de déploiement, vous restez toujours responsable de vos données, de vos terminaux, de vos comptes et de la gestion des accès (Microsoft : responsabilité partagée dans le cloud). AWS et Google appliquent le même principe. Pour les organisations de l'UE relevant de NIS2, le fournisseur entre dans la gestion des risques de votre chaîne d'approvisionnement.
4. SLA et résilience
Lisez le SLA de chaque service que vous utiliserez. Amazon EC2, par exemple, s'engage sur une disponibilité mensuelle de 99,99 % au niveau de la région, avec des crédits de service de 10 %, 30 % ou 100 % selon l'ampleur de la baisse de disponibilité (SLA Amazon Compute). Google et Microsoft publient leurs SLA par service de la même façon. Trois points à vérifier :
- Périmètre. De nombreux SLA exigent un déploiement sur plusieurs zones de disponibilité pour être applicables.
- Recours. Des crédits sur votre facture, généralement plafonnés, et non une indemnisation du chiffre d'affaires perdu.
- Disponibilité composite. Une application qui utilise cinq services est moins disponible que n'importe lequel d'entre eux. Concevez en fonction de vos propres objectifs de reprise ; voir RTO et RPO expliqués.
5. Coût total de possession
Les prix catalogue sont proches d'un hyperscaler à l'autre ; votre facture dépend de la manière dont vous achetez et exploitez. Comparez :
- La tarification à la demande pour les charges irrégulières ou expérimentales.
- La tarification avec engagement pour une base stable. Les Savings Plans d'AWS annoncent jusqu'à 72 % d'économies par rapport au tarif à la demande (AWS Savings Plans) ; les réservations Azure et les remises sur engagement d'utilisation de Google fonctionnent de façon similaire.
- La capacité Spot ou préemptible pour les travaux interruptibles, jusqu'à 90 % de réduction sur AWS (EC2 Spot).
- Les lignes cachées : sortie de données, trafic inter-zones et inter-régions, passerelles NAT, volume de journaux, support premium et stockage des sauvegardes.
- Les personnes : les ingénieurs ou le prestataire de services managés nécessaires pour exploiter et sécuriser la plateforme.
Les licences peuvent faire basculer la comparaison. Si vous exploitez de nombreuses licences Windows Server ou SQL Server, chiffrez Azure Hybrid Benefit et les options équivalentes d'apport de licences existantes des autres clouds avant de décider.
6. Compétences et écosystème
Le cloud que votre équipe connaît déjà sera moins cher à exploiter la première année. Vérifiez la disponibilité de partenaires locaux, d'ingénieurs certifiés sur votre marché du recrutement et la prise en charge des outils que vous utilisez : Terraform, votre CI/CD, votre pile d'observabilité.
7. Sortie et portabilité
Convenez de la façon dont vous partiriez avant de signer : formats d'export, coûts de transfert, délais de préavis et aide pendant la transition. Dans l'UE, le règlement sur les données (Data Act), applicable depuis le 12 septembre 2025, fixe un cadre permettant aux clients de changer de fournisseur de services de traitement de données (Commission européenne : Data Act). L'infrastructure as code et les conteneurs réduisent aussi le coût d'un déménagement ultérieur.
Comment mener pas à pas une comparaison de fournisseurs cloud
- Rédigez une note d'exigences d'une page : charges de travail, utilisateurs et localisations, périmètre de conformité, RTO/RPO, budget, compétences de l'équipe, calendrier.
- Présélectionnez deux ou trois fournisseurs qui satisfont les exigences impératives (région, conformité, service indispensable).
- Convenez des pondérations des sept critères avec l'IT, la sécurité, la finance et le responsable métier, avant toute notation.
- Choisissez une charge de travail pilote : représentative mais non critique pour l'activité, comme un environnement de préproduction ou un pipeline de données.
- Fixez d'avance les critères de réussite, par exemple la latence p95, le taux d'erreur, le temps de rétablissement lors d'un test de basculement et le coût mensuel.
- Menez le pilote pendant 4 à 8 semaines pour observer les tendances hebdomadaires et au moins un cycle de facturation complet.
- Notez, négociez et planifiez les vagues de migration, en incluant le support, les engagements, les conditions de sortie et la formation.
Modèle de matrice de décision
Notez chaque fournisseur de 1 à 10 par critère, multipliez par la pondération et additionnez. Les pondérations ci-dessous sont un exemple pour une entreprise réglementée de taille moyenne ; adaptez-les à la vôtre.
| Critère | Pondération (exemple) | Note fournisseur A | Note fournisseur B | Note fournisseur C |
|---|---|---|---|---|
| Régions et résidence des données | 15 % | |||
| Adéquation des services managés | 15 % | |||
| Preuves de sécurité et de conformité | 20 % | |||
| SLA et résilience | 10 % | |||
| Coût total sur trois ans | 20 % | |||
| Compétences et écosystème de partenaires | 10 % | |||
| Sortie et portabilité | 10 % | |||
| Total pondéré | 100 % |
Liste de contrôle avant de signer
- Les SLA de chaque service de l'architecture, avec les conditions d'obtention des crédits.
- Les rapports d'audit et l'accord de traitement des données couvrant vos régions et vos services.
- Des engagements écrits de résidence des données, y compris les pays depuis lesquels le personnel de support peut accéder aux données.
- Un plan de support dont les délais de réponse correspondent à vos propres objectifs en cas d'incident.
- Des conditions d'engagement adaptées à votre base d'usage, avec de la marge de croissance.
- Un plan de sortie : export des données, frais de transfert, assistance et calendrier.
Un seul cloud ou du multicloud ?
Pour la plupart des organisations de taille moyenne, un cloud principal plus des SaaS est plus simple et moins coûteux à bien exploiter. Le multicloud se justifie quand il y a une raison claire : un parc très Microsoft à côté d'un produit natif AWS, un service d'analytique ou d'IA précis, ou un régulateur qui exige une stratégie de sortie exécutable. Exploiter deux clouds double la base de sécurité, la supervision et les compétences à maintenir.
Exemple : d'un centre de données unique à une architecture AWS multi-AZ
ET Network hébergeait son infrastructure depuis un seul centre de données, avec trop peu de redondance pour une base de clients en croissance. L'entreprise avait besoin de haute sécurité, de haute disponibilité, d'évolutivité et de rapidité de mise sur le marché, ce qui devenait difficile à atteindre avec les seules ressources internes. Opsio a conçu et construit une architecture cloud native multi-AZ sur AWS avec provisionnement automatisé, de l'architecture au déploiement et aux tests, afin que l'équipe interne puisse continuer à la faire évoluer.
Comment Opsio vous accompagne
Opsio est AWS Advanced Tier Services Partner et exploite aussi des services managés Azure et Google Cloud ; nos comparaisons s'appuient donc sur l'exploitation des trois en production. Notre équipe de conseil cloud mène des ateliers d'exigences, des pilotes et des modèles de coût total ; l'équipe de migration planifie ensuite le déménagement par vagues. Pour les questions de résidence et de latence propres à l'Inde, voir choisir un fournisseur cloud en Inde.
Questions fréquentes
Quel fournisseur cloud convient le mieux à une petite ou moyenne entreprise ?
Celui qui s'accorde avec vos outils et vos compétences existants. Les entreprises centrées sur Microsoft trouvent souvent Azure le plus simple ; les éditeurs de produits qui bâtissent sur des piles open source choisissent souvent AWS ; les équipes riches en données examinent de près Google Cloud. Appuyez-vous sur les critères ci-dessus plutôt que sur la part de marché.
AWS est-il moins cher qu'Azure ou Google Cloud ?
Pas en général. Les prix unitaires sont proches, et la facture dépend de l'architecture, des remises d'engagement, des licences et de la sortie de données. Modélisez votre propre charge de travail dans le calculateur de tarifs de chaque fournisseur avant de conclure.
Quel est le facteur le plus important dans le choix d'un fournisseur cloud ?
Pour les organisations réglementées de l'UE et de l'Inde, ce sont généralement la résidence des données et les preuves de conformité, car elles écartent ou retiennent des fournisseurs. Viennent ensuite le coût total et les compétences nécessaires pour exploiter la plateforme.
Combien de temps doit durer l'évaluation d'un fournisseur cloud ?
Quatre à huit semaines de pilote après une courte phase d'exigences, c'est ce qui est habituel. Cela capte les tendances hebdomadaires de trafic et un cycle de facturation complet sans bloquer le projet.
Pouvons-nous changer de fournisseur cloud plus tard ?
Oui, mais cela coûte du temps et de l'argent. L'infrastructure as code, les conteneurs et le refus des services propres à un fournisseur quand ils apportent peu de valeur gardent cette option ouverte. Dans l'UE, le Data Act ajoute des règles sur le changement de fournisseur.
À lire aussi
À propos de l'auteur

Charte éditoriale : Cet article a été rédigé par un praticien certifié, cité ci-dessus. Nous le révisons lorsque la technologie ou la réglementation qu'il traite évolue ; les dates ci-dessus indiquent la dernière mise à jour. Opsio est éditorialement indépendant — nous recommandons des solutions sur leurs mérites techniques, pas sur des relations commerciales.