Infrastructure cloud : tout savoir pour bien choisir

Quand un client me demande de migrer son site ou son application vers le cloud, la première question que je pose est toujours la même : savez-vous ce que vous achetez réellement ? Parce que derrière le mot « cloud », il y a une infrastructure physique bien réelle, des serveurs, du stockage, du réseau, simplement gérés par quelqu’un d’autre. Et ce quelqu’un d’autre vous facture chaque heure de calcul, chaque gigaoctet stocké, chaque requête réseau. Comprendre ce qu’est une infrastructure in cloud computing, c’est la condition pour ne pas se retrouver avec une facture mensuelle qui explose sans raison apparente.

En dix ans de freelance à Paris, j’ai accompagné des dizaines de migrations cloud, de la startup qui déployait son MVP sur une instance EC2 à 8 €/mois jusqu’à la PME industrielle qui consolidait ses serveurs on-premise vers Azure. Ce que je partage ici, ce sont les vrais repères dont vous avez besoin pour prendre une décision éclairée, pas le discours marketing des hyperscalers.

Qu’est-ce qu’une infrastructure cloud exactement

Une infrastructure cloud désigne l’ensemble des ressources informatiques (serveurs, stockage, réseau, logiciels de virtualisation) mises à disposition à la demande via Internet. Contrairement à une infrastructure on-premise où vous achetez, installez et maintenez vos propres machines, le cloud externalise cette couche matérielle chez un fournisseur spécialisé. Vous consommez de la puissance de calcul comme vous consommez de l’électricité : à l’usage, sans vous soucier de la centrale.

Concrètement, quand vous louez un serveur virtuel chez AWS, Azure ou OVHcloud, vous utilisez une fraction d’un serveur physique hébergé dans un datacenter. La couche de virtualisation découpe cette machine en plusieurs instances indépendantes. C’est ce mécanisme qui permet l’élasticité : ajouter des ressources en quelques clics, sans acheter de matériel. Si vous hésitez encore entre garder vos serveurs en interne ou passer au cloud, j’ai détaillé ce comparatif dans mon article sur on-premise vs cloud computing.

Ce modèle repose sur trois niveaux de service définis par le NIST (National Institute of Standards and Technology) : IaaS (Infrastructure as a Service), PaaS (Platform as a Service) et SaaS (Software as a Service). Quand on parle d’infrastructure cloud au sens strict, on se situe au niveau IaaS, la brique la plus basse.

Les 4 composants d’une infrastructure cloud

Toute infrastructure cloud, qu’elle soit hébergée chez AWS, Azure, Google Cloud ou un fournisseur européen, repose sur quatre piliers fondamentaux. Les comprendre vous permet de dimensionner correctement votre projet et d’éviter le sur-provisionnement.

1. Le compute (puissance de calcul)

C’est le cœur du système : les processeurs virtuels (vCPU) et la mémoire vive (RAM) alloués à vos applications. Chez AWS, ce sont les instances EC2 ; chez Azure, les Virtual Machines ; chez OVHcloud, les instances Public Cloud. Le choix du type d’instance (general purpose, compute optimized, memory optimized) dépend de votre charge. Un site WordPress classique tourne confortablement sur 2 vCPU et 4 Go de RAM. Une application d’intelligence artificielle peut exiger 64 vCPU et 256 Go de RAM, comme je l’explique dans mon article sur Nvidia et le cloud computing.

2. Le stockage

Trois grandes familles coexistent : le stockage bloc (disques SSD/NVMe attachés aux instances), le stockage objet (Amazon S3, Azure Blob Storage) pour les fichiers statiques et les sauvegardes, et le stockage fichier (NFS/SMB managé). La différence de coût est significative : le stockage objet coûte environ 0,023 €/Go/mois chez AWS, contre 0,10 €/Go/mois pour un disque SSD haute performance.

3. Le réseau

Le réseau cloud comprend les réseaux virtuels (VPC), les load balancers, les pare-feu, les passerelles VPN et la bande passante sortante. C’est souvent le poste le plus sous-estimé. Chez AWS, la bande passante entrante est gratuite, mais la sortante est facturée à partir de 0,09 $/Go au-delà du premier Go gratuit. Sur un site à fort trafic, cela chiffre vite.

4. La virtualisation et l’orchestration

La couche logicielle qui rend tout cela possible : hyperviseurs (KVM, Hyper-V, Xen), conteneurs (Docker, Kubernetes), et outils d’orchestration qui automatisent le déploiement, la mise à l’échelle et la récupération après panne. Sans cette couche, pas d’élasticité ni de haute disponibilité. Les projets d’automatisation industrielle s’appuient d’ailleurs sur ces mêmes principes d’orchestration.

Cloud public, privé, hybride : lequel choisir

Ce choix structurant dépend de trois critères : votre budget, vos contraintes réglementaires et votre besoin de contrôle. Voici comment je guide mes clients.

En pratique, 80 % de mes clients freelances et PME partent sur du cloud public, souvent OVHcloud ou Scaleway pour rester en France, parfois AWS quand ils ont besoin de services managés avancés. Le cloud privé reste réservé aux structures soumises à des obligations réglementaires fortes (santé avec la certification HDS, secteur bancaire). L’hybride, lui, séduit les entreprises qui veulent garder leurs bases de données critiques on-premise tout en profitant de l’élasticité du cloud pour les pics de charge, comme je l’analyse dans mon comparatif cloud ou on-premises.

Les trois leaders du marché cloud en 2026

Le marché mondial de l’infrastructure cloud est dominé par trois acteurs qui captent à eux seuls plus de 65 % des dépenses selon les données du cabinet Synergy Research Group. Mais leadership mondial ne signifie pas meilleur choix pour votre projet.

AWS (Amazon Web Services)

Leader historique avec environ 31 % de parts de marché en 2026. Plus de 200 services, 33 régions géographiques dont une en France (Paris, eu-west-3). Points forts : la profondeur du catalogue, la maturité des services managés (RDS, Lambda, ECS), la documentation. Point faible : la complexité tarifaire, il faut un tableur pour comprendre ce que vous allez payer. Je recommande AWS pour les projets qui ont besoin de services spécifiques introuvables ailleurs.

Microsoft Azure

Deuxième acteur mondial avec environ 25 % de parts de marché. Avantage décisif pour les entreprises déjà dans l’écosystème Microsoft (Active Directory, Office 365, SQL Server). Deux régions en France (Paris et Marseille). Azure brille sur les environnements hybrides grâce à Azure Arc et sur l’intégration avec GitHub Actions pour le CI/CD. Point faible : l’interface du portail est parfois confuse et la documentation moins homogène qu’AWS.

Google Cloud Platform (GCP)

Troisième avec environ 11 % de parts de marché, mais en croissance rapide. Reconnu pour l’excellence de ses services data et IA (BigQuery, Vertex AI), la qualité de son réseau mondial et Kubernetes (GKE), puisque Google est à l’origine du projet. Une région en France (Paris). Point faible : le catalogue de services est moins large qu’AWS, et le support commercial pour les PME françaises reste perfectible.

En France, je recommande aussi de considérer OVHcloud (certifié SecNumCloud, datacenters en France, tarifs transparents) et Scaleway (Instances à partir de 3 €/mois, excellente API, datacenter parisien). Pour les projets soumis au RGPD strict, ces alternatives européennes offrent une souveraineté des données que les hyperscalers américains ne peuvent pas garantir, malgré leurs régions européennes. La CNIL rappelle régulièrement les précautions à prendre lors du recours à des services cloud non européens.

Exemples concrets d’infrastructure cloud en production

Pour que ce ne soit pas que de la théorie, voici trois cas réels tirés de mes missions récentes (données anonymisées).

Cas 1 : site e-commerce WooCommerce
Un client avec 15 000 visiteurs/jour sur WooCommerce. Infrastructure : une instance OVHcloud B2-15 (4 vCPU, 15 Go RAM) à 26 €/mois, un stockage objet S3 pour les médias (8 €/mois), un CDN Cloudflare Pro (20 $/mois), base MySQL managée (18 €/mois). Coût total : environ 75 €/mois. Avant la migration, le client payait 180 €/mois chez un hébergeur mutualisé premium qui n’arrivait plus à tenir la charge.

Cas 2 : application SaaS B2B
Une startup qui sert 200 clients B2B avec une API Node.js et une base PostgreSQL. Infrastructure AWS : 2 instances t3.medium en auto-scaling group, un RDS PostgreSQL db.t3.medium, un load balancer ALB, S3 pour les assets. Coût mensuel moyen : 350 €/mois, avec des pics à 500 € pendant les périodes de charge. Le tout déployé via Terraform et GitHub Actions.

Cas 3 : environnement hybride PME industrielle
Une PME avec un ERP on-premise (Sage X3) et un besoin de reporting cloud. Infrastructure : serveur dédié Sage conservé sur site, tunnel VPN vers Azure, Azure SQL Database pour le datawarehouse, Power BI pour la visualisation. Coût cloud seul : 120 €/mois. La partie automatisation des processus a été intégrée via des Logic Apps Azure.

Coûts réels d’une infrastructure cloud en 2026

Les tarifs cloud changent constamment, mais voici les fourchettes réalistes que j’observe en mai 2026 pour des projets hébergés en région France.

Le piège classique : se focaliser sur le prix de l’instance et oublier le réseau, le stockage et les services managés. J’ai vu des clients dont la facture AWS était composée à 40 % de frais de bande passante sortante. Mon conseil : activez les alertes de budget dès le premier jour et vérifiez votre consommation chaque semaine. Chez AWS, l’outil Cost Explorer est votre meilleur allié ; chez Azure, c’est Cost Management.

Sécurité et conformité : ce que vous devez vérifier

Externaliser son infrastructure ne veut pas dire externaliser sa responsabilité. Le modèle de responsabilité partagée est clair : le fournisseur sécurise l’infrastructure physique, vous sécurisez ce que vous mettez dessus. C’est un point que je détaille aussi dans mon article sur le SOC en cybersécurité.

Voici la checklist que j’applique systématiquement sur mes projets cloud :

• Chiffrement au repos et en transit : activez TLS 1.3 pour les communications et le chiffrement AES-256 pour les données stockées. Tous les grands fournisseurs le proposent, mais ce n’est pas toujours activé par défaut
• Gestion des accès (IAM) : créez des rôles granulaires avec le principe du moindre privilège. Jamais de clé root dans le code, jamais de credentials en dur
• Sauvegardes automatisées : snapshots quotidiens avec rétention de 30 jours minimum, testées en restauration au moins une fois par trimestre
• Journalisation : activez CloudTrail (AWS), Activity Log (Azure) ou Cloud Audit Logs (GCP) pour tracer toutes les actions sur votre infrastructure
• Conformité RGPD : vérifiez la localisation des données (région France ou UE), signez le DPA (Data Processing Agreement) avec votre fournisseur, documentez votre registre de traitements

Si votre activité relève du secteur santé, exigez la certification HDS (Hébergement de Données de Santé). Pour le secteur public et les OIV, la qualification SecNumCloud délivrée par l’ANSSI est devenue un critère de sélection incontournable. En 2026, OVHcloud et 3DS Outscale sont parmi les rares fournisseurs à l’avoir obtenue. La gouvernance, risque et conformité (GRC) doit faire partie intégrante de votre stratégie cloud.

Migrer vers le cloud : les étapes que je recommande

Après avoir accompagné plus de 30 migrations, voici la méthodologie en six étapes que j’applique systématiquement. Elle rejoint les bonnes pratiques de gestion de projet que je recommande par ailleurs.

Étape 1 : audit de l’existant (1 à 2 semaines)
Inventoriez toutes vos ressources actuelles : serveurs, bases de données, stockage, dépendances réseau. Mesurez la charge réelle sur 30 jours. Je recommande des outils comme Netdata ou Prometheus pour collecter les métriques CPU, RAM et I/O.

Étape 2 : choix du modèle et du fournisseur (1 semaine)
En fonction de vos contraintes (budget, réglementation, compétences internes), choisissez entre cloud public, privé ou hybride, puis sélectionnez votre fournisseur. Ne choisissez pas AWS « parce que tout le monde le fait » ; choisissez le fournisseur dont les services correspondent à vos besoins réels.

Étape 3 : architecture cible et estimation budgétaire (1 semaine)
Dessinez l’architecture cloud cible avec les services précis. Utilisez les calculateurs officiels (AWS Pricing Calculator, Azure Pricing Calculator) pour estimer le coût mensuel. Ajoutez 20 % de marge pour les imprévus.

Étape 4 : préparation et Infrastructure as Code (1 à 3 semaines)
Codifiez votre infrastructure avec Terraform ou Pulumi. C’est non négociable en 2026. Déployer manuellement via la console, c’est s’assurer qu’on ne pourra jamais reproduire l’environnement à l’identique ni auditer les changements.

Étape 5 : migration progressive (2 à 6 semaines)
Ne faites jamais un « big bang ». Migrez composant par composant, en commençant par les services les moins critiques. Testez chaque composant migré en condition réelle avant de passer au suivant.

Étape 6 : optimisation post-migration (en continu)
Après la migration, analysez vos coûts réels sur 60 jours. Redimensionnez les instances surdimensionnées, activez les Reserved Instances ou Savings Plans sur les ressources stables, supprimez les ressources orphelines (snapshots oubliés, IP élastiques non attachées).

Les erreurs que je vois le plus souvent chez mes clients

En dix ans de pratique, certaines erreurs reviennent avec une régularité déconcertante. Les connaître vous fera économiser du temps et de l’argent.

Surdimensionner « au cas où » : c’est le réflexe on-premise appliqué au cloud. On provisionne une instance 8 vCPU / 32 Go RAM « pour être tranquille » alors que la charge réelle consomme 15 % des ressources. Résultat : des centaines d’euros gaspillés chaque mois. La beauté du cloud, c’est justement de pouvoir commencer petit et scaler.

Ignorer les coûts de bande passante : gratuit en entrée, payant en sortie. Si votre application sert beaucoup de médias ou d’API calls vers l’extérieur, mettez un CDN devant et comprimez vos réponses. Cloudflare en version gratuite suffit souvent.

Ne pas automatiser les déploiements : déployer à la main via la console crée de la dette technique invisible. Le jour où il faut recréer l’environnement (incident, audit, nouveau client), personne ne se souvient des 47 clics effectués il y a six mois. Terraform + Git, c’est la base.

Oublier la stratégie de sortie : le vendor lock-in est réel. Plus vous utilisez de services propriétaires (Lambda, DynamoDB, Cloud Functions), plus la migration vers un autre fournisseur coûtera cher. Privilégiez les standards ouverts (PostgreSQL plutôt que DynamoDB, Kubernetes plutôt que ECS) quand c’est possible, surtout si vous n’avez pas besoin des fonctionnalités spécifiques du service managé.

Négliger la supervision : un serveur dans le cloud tombe en panne aussi. Mettez en place un monitoring dès le jour 1 : Datadog, Grafana Cloud, ou même les outils intégrés (CloudWatch, Azure Monitor). Configurez des alertes sur le CPU, la RAM, l’espace disque et les temps de réponse applicatifs.