Le cloud computing a cessé d'être une option pour devenir la couche d'infrastructure par défaut de toute organisation qui doit passer à l'échelle sans immobiliser de capital dans le matériel. La définition de référence reste celle du NIST (publication spéciale 800-145) : un modèle qui offre un accès à la demande, via le réseau, à un ensemble partagé de ressources de calcul 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 as a service), le fournisseur livre du calcul, du réseau et du stockage virtualisé, 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 (platform as a 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 (software as a 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 est la source numéro un des incidents de sécurité : le fournisseur répond de la sécurité de le cloud (hyperviseur, matériel, réseau physique), mais le client répond de la sécurité dans le cloud (configuration de l'IAM, chiffrement des données, application des correctifs du SE en IaaS, règles de pare-feu). Présumer 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 environnements hybrides | Analyse 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'analyse massive tend à valoriser BigQuery de GCP ; et AWS reste le pari sûr par son étendue et sa disponibilité régionale. Le prix est rarement le facteur décisif : les trois appliquent un modèle de paiement à l'usage avec des remises liées à l'engagement (Savings Plans sur AWS, Reserved Instances sur Azure, Committed Use Discounts sur 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 vers 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 n'est pas rentable de déplacer) et Retire (éteindre ce qui n'apporte plus de valeur). L'erreur fréquente est de faire un rehosting massif en espérant des économies immédiates : déplacer une architecture inefficace vers le cloud finit souvent par la rendre plus chère, car on paie 24 heures sur 24 des ressources sous-utilisées.
Une migration ordonnée commence par un inventaire des dépendances, définit une landing zone avec des comptes/abonnements ségrégués par environnement (production, préproduction, sandbox), é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 de la dépense (FinOps) doit naître avec le projet, et non s'ajouter à l'arrivée de la première facture surprise.
Infrastructure as 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 as code (IaC) avec Terraform (multi-cloud), AWS CloudFormation, Azure Bicep ou Google Cloud Deployment Manager transforme l'infrastructure en fichiers versionnés, relisables et reproductibles : on élimine la configuration manuelle non reproductible (le fameux snowflake server) et on rend possible le déploiement identique d'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 au moyen de files d'attente et d'é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 (management de la sécurité de l'information) et ISO/IEC 27017 (contrôles spécifiques aux services cloud), et offrent 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 de la donnée et la signature d'accords de traitement. La certification du fournisseur n'exonère cependant 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 fait du coût 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 par un modèle culturel et opérationnel en trois phases itératives. La phase informer donne de la visibilité sur la dépense grâce à un étiquetage cohérent des ressources et à des tableaux de bord de coût 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 tirer parti des instances spot pour les tâches tolérantes aux interruptions. La phase opérer établit des budgets, des alertes d'écart et une responsabilité claire sur chaque euro consommé.
Le changement de mentalité 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 de qualité du logiciel à part entière, au même titre que la performance et la sécurité, et révisent la dépense avec la même cadence que les incidents.
Erreurs courantes qui renchérissent 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'autoscaling.
- Permissions IAM trop larges : accorder des politiques avec joker (
*) 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 la reprise après sinistre : ne jamais tester la restauration des sauvegardes ni définir d'objectifs de RPO/RTO.
Foire aux questions
Multi-cloud ou fournisseur unique ?
Le multi-cloud réduit le risque de dépendance à un seul fournisseur 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é rend davantage qu'un multi-cloud mal entretenu.
Le cloud est-il toujours moins cher que d'avoir ses propres serveurs ?
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 conservant 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èvent de la responsabilité du client.
Qu'est-ce que le vendor lock-in et comment l'atténuer ?
C'est la difficulté à changer de fournisseur en raison de l'usage 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 de 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 concrète, à une équipe dotée de 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 as code qui rende 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 réellement testée. Le cloud récompense celui qui automatise et mesure, et punit celui qui improvise. Chez Summum Systèmes, nous abordons chaque migration comme un portefeuille de décisions par application (les 6 R), et non comme un déménagement massif, car déplacer le désordre vers le cloud ne produit qu'un désordre plus coûteux.