AWS, Azure et Google Cloud se distinguent par le modèle de service qu'ils proposent, et non par le fournisseur en tant que tel : l'IaaS fournit une infrastructure virtualisée, le PaaS abstrait également le système d'exploitation et le runtime, et le SaaS fournit l'application complète par abonnement. L'erreur la plus courante lors d'une migration est le rehosting massif sans gouvernance FinOps, qui a tendance à alourdir la facture au lieu de la réduire.
Le cloud computing n'est plus une option : c'est devenu la couche d'infrastructure par défaut de toute organisation ayant besoin de monter en charge sans immobiliser de capital dans du matériel. La définition de référence reste celle du NIST (publication spéciale 800-145) : un modèle offrant un accès à la demande, via le réseau, à un ensemble partagé de ressources informatiques configurables (serveurs, stockage, réseaux, applications) qui sont provisionnées et libérées avec une intervention minimale du fournisseur. Les trois grands clouds publics (Amazon Web Services, Microsoft Azure et Google Cloud Platform) concentrent l'essentiel du marché mondial, mais choisir entre eux (ou les combiner) exige de comprendre ce que résout chaque couche de service et où se situent les risques réels.
Modèles de service : IaaS, PaaS et SaaS
La taxonomie classique du NIST distingue trois modèles selon qui gère quoi. En IaaS (infrastructure en tant que service) le fournisseur livre du calcul, du réseau et du stockage virtualisés, et le client gère le système d'exploitation et tout ce qui se trouve au-dessus : machines EC2 sur AWS, Virtual Machines sur Azure ou Compute Engine sur GCP. En PaaS (plateforme en tant que service) le fournisseur abstrait également le système d'exploitation et le runtime : AWS Elastic Beanstalk, Azure App Service ou Google App Engine permettent de déployer du code sans administrer la machine. En SaaS (logiciel en tant que service) on consomme l'application complète par abonnement, comme Microsoft 365 ou Google Workspace.
Le choix du modèle détermine la frontière du modèle de responsabilité partagée, un concept que les trois clouds documentent explicitement et qui constitue la première source d'incidents de sécurité : le fournisseur répond de la sécurité du cloud (hyperviseur, matériel, réseau physique), mais le client répond de la sécurité dans le cloud (configuration IAM, chiffrement des données, application des correctifs du système d'exploitation en IaaS, règles de pare-feu). Supposer que le fournisseur protège ce qui relève en réalité de la responsabilité du client est à l'origine de la plupart des fuites de données dans des buckets S3 ou des blobs Azure mal configurés.
Comparatif pratique : AWS vs Azure vs Google Cloud
Les trois plateformes couvrent les mêmes besoins de base, mais leurs points forts diffèrent. Ce tableau résume les équivalences de services et les critères de sélection les plus pertinents dans des projets réels.
| Service / Critère | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Calcul virtuel (IaaS) | EC2 | Virtual Machines | Compute Engine |
| Conteneurs gérés (Kubernetes) | EKS | AKS | GKE |
| Fonctions serverless | Lambda | Functions | Cloud Functions / Cloud Run |
| Stockage d'objets | S3 | Blob Storage | Cloud Storage |
| Base de données relationnelle gérée | RDS / Aurora | Azure SQL Database | Cloud SQL / AlloyDB |
| Point fort habituel | Étendue du catalogue et maturité | Intégration avec l'écosystème Microsoft et les environnements hybrides | Analytique de données et IA (BigQuery, Vertex AI) |
En pratique, une entreprise fortement investie dans Active Directory et les licences Microsoft rencontre généralement moins de friction avec Azure ; une équipe data qui vit de l'analytique massive a tendance à privilégier BigQuery sur GCP ; et AWS reste le pari sûr en termes d'étendue et de disponibilité régionale. Le prix est rarement le facteur décisif : les trois appliquent un modèle de paiement à l'usage avec des remises sur engagement (Savings Plans chez AWS, Reserved Instances chez Azure, Committed Use Discounts chez GCP) qui peuvent réduire la facture de 30% à 70% par rapport au tarif à la demande.
Stratégies de migration : les 6 R
Migrer vers le cloud n'est pas un acte unique, mais un portefeuille de décisions par application. Le cadre des 6 R (popularisé par Gartner et AWS) ordonne les options : Rehosting (lift and shift, déplacer la machine telle quelle), Replatforming (petits ajustements, par exemple faire passer une base de données à un service géré), Repurchasing (remplacer par un SaaS équivalent), Refactoring (repenser l'application en mode cloud-native), Retain (conserver on-premise ce qu'il ne vaut pas la peine de déplacer) et Retire (éteindre ce qui n'apporte plus de valeur). L'erreur fréquente consiste à faire du rehosting massif en espérant des économies immédiates : déplacer une architecture inefficace vers le cloud a tendance à l'alourdir, car on paie pour des ressources sous-utilisées 24 heures par jour.
Une migration ordonnée commence par un inventaire des dépendances, définit une landing zone avec des comptes/abonnements segmentés par environnement (production, préproduction, bac à sable), établit des politiques d'étiquetage des coûts dès le premier jour et priorise selon la valeur métier et le risque technique. La gouvernance des dépenses (FinOps) doit naître avec le projet, et non s'ajouter à l'arrivée de la première facture surprise.
Infrastructure en tant que code et architectures cloud-native
La différence entre un cloud bon marché et un cloud coûteux ne tient pas au fournisseur, mais à la discipline opérationnelle. L'infrastructure en tant que code (IaC) avec Terraform (multi-cloud), AWS CloudFormation, Azure Bicep ou Google Cloud Deployment Manager transforme l'infrastructure en fichiers versionnés, révisables et reproductibles : on élimine la configuration manuelle irreproductible (le fameux snowflake server) et on permet le déploiement identique des environnements. Sur cette base se construisent les pratiques cloud-native : conteneurs orchestrés avec Kubernetes, fonctions serverless pour les charges event-driven, et architectures découplées via des files d'attente et des événements qui font évoluer chaque composant de façon indépendante.
En matière de conformité, les trois clouds maintiennent des certifications ISO/IEC 27001 (gestion de la sécurité de l'information) et ISO/IEC 27017 (contrôles spécifiques aux services cloud), et proposent des outils pour traiter les données personnelles conformément au RGPD, y compris le choix d'une région européenne pour garantir la résidence des données et la signature d'accords de traitement. La certification du fournisseur ne dispense toutefois pas le client de configurer correctement ses propres contrôles.
FinOps : gouverner le coût comme une discipline
L'élasticité qui rend le cloud attractif est aussi son plus grand piège financier : la facilité à provisionner des ressources transforme la dépense en une variable qui s'emballe sans contrôle si personne ne la surveille. La pratique FinOps (opérations financières dans le cloud) répond à ce défi avec un modèle culturel et opérationnel en trois phases itératives. La phase informer donne de la visibilité sur les dépenses grâce à un étiquetage cohérent des ressources et à des tableaux de bord des coûts par équipe, projet et environnement. La phase optimiser applique des actions concrètes : dimensionner correctement les instances (rightsizing), éteindre les environnements de test en dehors des heures de travail, acheter de la capacité réservée pour les charges stables et exploiter les instances spot pour les travaux tolérants aux interruptions. La phase opérer établit des budgets, des alertes d'écart et une responsabilité claire sur chaque euro consommé.
Le changement d'état d'esprit clé est que, dans le cloud, le coût est une métrique d'ingénierie et pas seulement de finance : la décision d'un développeur de choisir un type d'instance ou une région a un impact direct sur la facture. Les organisations matures intègrent le coût comme un attribut supplémentaire de la qualité du logiciel, au même titre que la performance et la sécurité, et révisent les dépenses avec la même fréquence que les incidents.
Erreurs courantes qui alourdissent le coût et exposent le cloud
- Ressources orphelines : disques, IP élastiques et snapshots que personne ne libère et qui sont facturés mois après mois.
- Surdimensionner les instances : démarrer de grosses machines « au cas où » au lieu de mesurer et d'appliquer l'auto-scaling.
- Permissions IAM trop larges : accorder des politiques avec un caractère générique (
*) au lieu d'appliquer le principe du moindre privilège. - Ne pas chiffrer par défaut : laisser des buckets de stockage d'objets en accès public ou sans chiffrement au repos.
- Oublier le plan de reprise après sinistre : ne jamais tester la restauration des sauvegardes ni définir d'objectifs de RPO/RTO.
Questions fréquentes
Multi-cloud ou fournisseur unique ?
Le multi-cloud réduit le risque de dépendance à un fournisseur unique et permet d'utiliser le meilleur de chaque plateforme, mais il multiplie la complexité opérationnelle, les compétences nécessaires et les coûts de transfert de données entre clouds. Pour la plupart des PME, un cloud principal bien gouverné est plus rentable qu'un multi-cloud mal maintenu.
Le cloud est-il toujours moins cher que des serveurs propres ?
Pas automatiquement. Le cloud transforme l'investissement (CapEx) en dépense opérationnelle (OpEx) et apporte de l'élasticité, mais des charges stables et prévisibles 24/7 peuvent revenir plus cher dans le cloud qu'en réservant de la capacité ou en les maintenant on-premise. L'économie réelle vient du fait de ne payer que ce que l'on utilise et d'éteindre ce dont on n'a pas besoin.
Où résident mes données et qui peut y accéder ?
Les données résident dans la région choisie par le client ; pour respecter le RGPD, il convient de sélectionner des régions de l'UE et de signer l'accord de traitement du fournisseur. Le chiffrement au repos et en transit, ainsi qu'une gestion rigoureuse des clés et des identités, relève de la responsabilité du client.
Qu'est-ce que le vendor lock-in et comment l'atténuer ?
C'est la difficulté de changer de fournisseur du fait de l'utilisation de services propriétaires. On l'atténue en s'appuyant sur des standards ouverts (conteneurs, Kubernetes, formats de données portables) et en isolant la logique métier des API spécifiques à chaque cloud, même si renoncer totalement aux services gérés a aussi un coût d'opportunité.
Conclusion
Il n'existe pas de cloud « meilleur » dans l'absolu : il existe le cloud adapté à une charge de travail précise, une équipe aux compétences données et un cadre de conformité déterminé. La décision technique pertinente n'est pas AWS contre Azure contre Google Cloud, mais la façon dont on gouverne la plateforme choisie : avec une infrastructure en tant que code qui rend chaque environnement reproductible, avec des identités à moindre privilège qui ferment la porte aux fuites, avec une pratique FinOps qui évite la facture surprise et avec des sauvegardes dont la restauration est vraiment testée. Le cloud récompense celui qui automatise et mesure, et pénalise celui qui improvise. Chez Summum Sistemas, nous abordons chaque migration comme un portefeuille de décisions par application (les 6 R), et non comme un déplacement massif, car déplacer le désordre vers le cloud ne produit qu'un désordre plus coûteux.