Comment dimensionner vos instances IaaS pour éviter de payer jusqu’à 60% trop cher ?

Cette ligne sur la facture cloud qui double sans raison apparente, ce sentiment diffus que votre infrastructure est un monstre incontrôlable qui dévore le budget… En tant que responsable cloud, vous connaissez cette situation. On vous a sûrement conseillé de « mieux négocier avec les fournisseurs » ou de « surveiller les coûts » via des tableaux de bord complexes. Ces approches, bien que valables, ne traitent que les symptômes d’un mal bien plus profond : le surdimensionnement chronique et l’achat par inertie.

La vérité est que le gaspillage cloud n’est pas une fatalité technique, mais le symptôme d’une culture d’ingénierie qui privilégie la sécurité maximale (« au cas où ») à l’optimisation financière. Le résultat ? Des dizaines d’instances tournant à 10% de leur capacité, mais payées à 100% de leur prix. C’est une érosion silencieuse et continue de votre EBITDA. La véritable question n’est donc pas « quel fournisseur est le moins cher ? », mais « comment puis-je payer uniquement pour ce que je consomme réellement ? ».

Cet article n’est pas une énième liste d’astuces. C’est une feuille de route stratégique, le raisonnement d’un architecte cloud et consultant FinOps pour diagnostiquer le gaspillage, quantifier l’invisible et implémenter une culture de la mesure durable. Nous allons déconstruire les erreurs les plus coûteuses et vous fournir les outils pour transformer votre gestion du cloud, passant d’un centre de coût réactif à un levier de performance agile et maîtrisé.

Pour vous guider dans cette démarche d’optimisation, nous avons structuré cet article en plusieurs points clés. Chaque section aborde une facette du problème et apporte une solution concrète et chiffrée, vous permettant de construire pas à pas votre propre stratégie de rightsizing.

Pourquoi migrer votre application Windows 2008 en IaaS plutôt qu’en PaaS ?

Face à une application legacy comme celles tournant sur Windows Server 2008, dont le support est terminé, le dilemme est constant. La moderniser en la réécrivant pour une plateforme PaaS (Platform as a Service) est l’idéal théorique : plus de gestion d’OS, scalabilité native, etc. Cependant, cette refonte représente un coût de développement initial considérable et un risque projet non négligeable. L’alternative pragmatique est la migration « lift-and-shift » vers une infrastructure IaaS (Infrastructure as a Service). On déplace simplement la machine virtuelle existante dans le cloud d’un fournisseur.

Cette approche IaaS présente un avantage majeur : la rapidité et la limitation des risques. L’application continue de fonctionner dans un environnement qu’elle connaît, sans modification de code. C’est la solution de continuité la plus directe. Cependant, elle ne résout pas l’obsolescence technique et vous rend responsable de la sécurité d’un OS non supporté. Pour arbitrer, la seule méthode rigoureuse est de réaliser une analyse du Coût Total de Possession (TCO) sur 3 à 5 ans. Cette analyse, comme l’a fait l’entreprise Present dans son projet de migration, permet de quantifier les coûts directs (licences, instances) et indirects (maintenance, risque de sécurité, coût d’opportunité) de chaque scénario.

Comme le souligne Eric Bodilsen du Monde Informatique en partenariat avec Claranet, l’exercice est complexe :

Établir un TCO sur un projet de migration est très compliqué car cela dépend de beaucoup de facteurs. Il faut avoir une approche pragmatique et prendre en compte la maturité des entreprises à basculer dans le cloud.

– Eric Bodilsen, Le Monde Informatique, en partenariat avec Claranet

Pour une application critique mais dont l’évolution fonctionnelle est gelée, l’IaaS est souvent le choix le plus rentable à court et moyen terme. Il permet de sortir d’une infrastructure physique vieillissante sans engager un budget de développement incertain. Le PaaS reste l’objectif, mais l’IaaS est une étape intermédiaire viable et financièrement sensée.

Comment choisir entre une instance 4 vCPU ou 8 vCPU sans gaspiller 400 €/mois ?

Le choix de la taille d’une instance est l’un des points les plus critiques et les plus sujets au gaspillage. Par peur de la panne ou du ralentissement, le réflexe est de surdimensionner : « prenons l’instance 8 vCPU, au moins on sera tranquilles ». C’est ce que l’on appelle l’achat par inertie. Le problème est que vous payez pour de la puissance de calcul que vous n’utiliserez peut-être jamais. Si l’utilisation moyenne de votre CPU ne dépasse jamais 15%, payer pour les 85% restants est une destruction pure et simple de valeur.

La bonne approche n’est pas de deviner, mais de mesurer. Avant de provisionner, analysez la charge de travail d’une application similaire ou, si l’instance existe déjà, analysez son historique d’utilisation sur au moins deux semaines. Les outils de monitoring des fournisseurs cloud (CloudWatch, Azure Monitor) sont vos meilleurs alliés. Une instance qui ne dépasse jamais 20% d’utilisation CPU n’a aucune raison d’avoir 8 vCPU. La passer à 4 vCPU n’aura, dans 99% des cas, aucun impact sur la performance perçue par l’utilisateur, mais divisera son coût par deux.

Comme le montre cette vue des circuits d’un processeur, la puissance brute n’est pas tout. Il faut l’adapter au besoin réel. Pour les applications avec des pics de charge très ponctuels et imprévisibles, le surdimensionnement n’est pas la solution. La réponse moderne et efficiente est l’auto-scaling. Il est plus intelligent de configurer un groupe de 2 instances à 4 vCPU qui peut automatiquement s’étendre à 3 ou 4 instances pendant un pic de 30 minutes, plutôt que de payer pour une unique instance monstrueuse de 16 vCPU qui tourne à vide 23h30 par jour.

AWS EC2 vs Azure VM vs Google Compute : lequel pour une PME avec support en français ?

La guerre des trois grands du cloud (AWS, Microsoft Azure, Google Cloud Platform) est souvent présentée sous l’angle de la performance brute ou du prix catalogue. Pour une PME, et particulièrement en France, d’autres critères sont tout aussi, voire plus, importants. En effet, alors qu’une étude IDC France révèle que 73% des DSI français priorisent l’optimisation des coûts, l’écosystème et la facilité de gestion priment souvent sur le dernier centime d’euro par heure.

Le choix dépend largement de la culture et des compétences internes de l’entreprise. Une PME historiquement équipée en solutions Microsoft (Windows Server, Office 365, Active Directory) aura une transition beaucoup plus fluide et rentable vers Azure, grâce aux licences hybrides et à l’intégration native. Pour les startups et les entreprises centrées sur la donnée et le machine learning, Google Cloud offre souvent des outils plus innovants et une politique de prix agressive sur certains services. AWS, le leader du marché, bénéficie de la plus grande maturité, de la gamme de services la plus étendue et d’une immense communauté, mais sa complexité peut être un frein pour une petite équipe.

Au-delà du fournisseur, ce sont les outils de gouvernance des coûts qui feront la différence. Un comparatif des outils natifs d’optimisation montre leurs limites respectives :

Pour une PME, le critère du support en français est décisif. Les trois acteurs majeurs ont fait d’énormes progrès, mais la qualité du support local, la documentation et la disponibilité de partenaires certifiés francophones peuvent varier. Azure et Google ont historiquement un ancrage européen fort, ce qui peut être un avantage. En définitive, le « meilleur » cloud est celui qui s’aligne sur vos compétences, s’intègre à votre existant et vous offre un écosystème de support avec lequel votre équipe est à l’aise.

L’erreur qui coûte 8000 € : 20 instances de dev oubliées allumées pendant 6 mois

C’est un grand classique, presque un rite de passage dans le monde du cloud : l’instance « zombie ». Un développeur lance une machine pour un test ponctuel, est interrompu, part en week-end, et l’instance est oubliée. Multipliez ce scénario par une équipe de 20 personnes sur 6 mois, et vous obtenez une facture de plusieurs milliers d’euros pour des ressources absolument inutiles. Ce n’est pas une fiction ; c’est la réalité de nombreuses entreprises, et c’est ce que j’appelle la dette technique visible sur la facture. Un rapport de Flexera montre que les entreprises gaspillent en moyenne 27% de leurs dépenses cloud, en grande partie à cause de ces ressources oubliées.

Cette erreur n’est pas la faute d’un développeur négligent, mais le symptôme d’une absence de gouvernance. Sans une politique claire de « tagging » (étiquetage) des ressources, il est impossible de savoir à qui appartient une instance, à quel projet elle est liée, et si elle est encore nécessaire. Sans revue régulière, ces instances s’accumulent comme de la poussière dans un coin du data center virtuel.

La solution n’est pas de blâmer, mais d’automatiser et de responsabiliser. La mise en place d’une gouvernance FinOps de base passe par plusieurs étapes cruciales :

• Tagging obligatoire : Aucune ressource ne peut être créée sans être étiquetée avec un propriétaire, un centre de coût et une date d’expiration.
• Rapports par équipe : Créez des tableaux de bord où chaque chef de projet peut voir en temps réel la consommation de son équipe. La transparence est le premier pas vers la responsabilisation.
• Scripts de nettoyage : Automatisez des scripts qui détectent et signalent (ou arrêtent directement) les instances non étiquetées ou celles dont la date d’expiration est passée.

Combattre les instances zombies n’est pas une chasse aux sorcières, mais la mise en place d’une hygiène de base de l’infrastructure. C’est le geste le plus simple pour récupérer une part significative du budget gaspillé.

Comment économiser 40% en éteignant vos instances de dev la nuit et le weekend ?

C’est peut-être l’optimisation la plus simple, la plus rapide à mettre en place et avec le retour sur investissement le plus spectaculaire. Vos environnements de développement, de test ou de staging sont-ils utilisés à 3 heures du matin un dimanche ? Dans 99% des cas, la réponse est non. Pourtant, vous les payez 24/7. Une semaine contient 168 heures, mais une semaine de travail standard en compte environ 40. Vous payez donc pour 128 heures de « temps de veille » par semaine, pour chaque instance non-critique.

Le calcul est rapide. En automatisant simplement l’extinction de ces ressources en dehors des heures ouvrées (par exemple, de 20h à 8h en semaine, et tout le week-end), vous pouvez réduire leur temps de fonctionnement de 168 heures à environ 40-50 heures par semaine. Des stratégies concrètes de réduction des coûts cloud montrent qu’il est possible de réaliser de 65% à 75% d’économie sur le budget alloué à ces instances. Pour un parc moyen, cela se chiffre en dizaines de milliers d’euros par an.

Ce n’est pas une théorie. Une étude de cas concrète rapporte qu’une PME a réussi à économiser 1200 euros par mois simplement en appliquant cette logique à ses serveurs de développement. Cette pratique, connue sous le nom de « Cloud Parking » ou « Office-hours Shutdown », est un pilier du FinOps. Sa mise en œuvre est relativement simple :

1. Identifier les cibles : Listez toutes les instances qui ne sont pas liées à la production et qui n’ont pas besoin de tourner en continu (dev, test, staging, pré-production, intégration continue…).
2. Automatiser l’arrêt : Utilisez les outils natifs des fournisseurs (AWS Instance Scheduler, Azure Automation, Cloud Scheduler de GCP) ou des scripts pour programmer l’arrêt automatique des instances chaque soir.
3. Automatiser le démarrage : Programmez le redémarrage de ces mêmes instances chaque matin, un peu avant l’arrivée des équipes.

Cette approche est un « quick win » par excellence. Elle ne demande pas de ré-architecture, n’impacte pas la production et génère des économies immédiates et mesurables. C’est la première action à mettre en place dans toute démarche d’optimisation des coûts cloud.

Comment détecter les serveurs utilisés à moins de 20% de leur capacité ?

Identifier les serveurs sous-utilisés est le point de départ de toute stratégie de « rightsizing ». Le défi n’est pas tant de trouver des outils pour le faire, mais de définir les bons seuils et la bonne méthodologie pour éviter les faux positifs. Une instance qui connaît un pic d’utilisation à 90% une fois par mois ne doit pas être traitée de la même manière qu’une instance qui plafonne constamment à 15%. La clé est d’analyser les métriques sur une période suffisamment longue pour être représentative, généralement entre 14 et 30 jours.

Les fournisseurs cloud proposent des outils pour vous y aider. Le Recommender de Google Cloud ou l’AWS Compute Optimizer peuvent suggérer des redimensionnements. Cependant, pour un contrôle plus fin, il est essentiel de définir vos propres règles de détection. Une approche éprouvée consiste à se concentrer sur deux métriques principales : l’utilisation du CPU et de la RAM. Des seuils d’alerte peuvent être configurés pour identifier automatiquement les candidats au redimensionnement.

Le livre blanc d’AWS sur le dimensionnement approprié recommande de cibler les instances dont l’utilisation maximale du processeur et de la mémoire est inférieure à 40% sur une période de quatre semaines. C’est un excellent point de départ. Pour aller plus loin, une analyse plus fine peut être mise en place via des outils de supervision comme Prometheus ou Datadog, couplée à des scripts d’automatisation.

Cette détection n’est pas une fin en soi. Une fois qu’une instance est identifiée comme sous-utilisée, une analyse humaine est nécessaire pour confirmer que le redimensionnement est sans risque. L’instance est-elle liée à un plan de reprise d’activité qui justifie sa taille ? Sert-elle à un batch annuel qui n’a pas encore eu lieu ? La communication entre l’équipe FinOps et les équipes de développement est ici cruciale pour transformer la détection en économie réelle.

Pourquoi 10 serveurs utilisés à 15% peuvent tenir sur 2 serveurs à 70% ?

Ce principe, connu sous le nom de consolidation de charge de travail (workload consolidation), est l’un des concepts les plus puissants mais aussi les plus contre-intuitifs de l’optimisation d’infrastructure. L’idée reçue est que pour héberger 10 applications, il faut 10 serveurs. Cette vision est héritée du monde physique où chaque machine était dédiée à une tâche. Dans le cloud, cette logique est une source de gaspillage massif.

La plupart des applications n’utilisent pas leurs ressources de manière constante. Elles ont des pics et des creux. Un serveur qui héberge une application de reporting interne peut tourner à 60% de CPU le matin, puis tomber à 5% le reste de la journée. Un autre serveur, pour une API externe, aura peut-être des pics aléatoires. Si chacun est sur son propre serveur dimensionné pour son pic maximal, 90% du temps, vous payez pour de la capacité inutilisée. La probabilité que les 10 applications atteignent leur pic d’utilisation maximal au même instant est quasiment nulle.

La consolidation consiste à regrouper ces charges de travail non corrélées sur un plus petit nombre de serveurs plus grands et mieux remplis. En « mutualisant » les ressources, les pics des uns sont absorbés par les creux des autres. Le résultat est une utilisation moyenne beaucoup plus élevée (par exemple, 70-80%) sur les serveurs consolidés, et une réduction drastique du nombre total de machines à payer. Cette stratégie est au cœur de technologies comme la virtualisation avec VMware ou la conteneurisation avec Docker et Kubernetes.

Bien sûr, la consolidation n’est pas sans risque. Elle demande une bonne isolation entre les charges de travail pour qu’une application défaillante n’impacte pas les autres (c’est le rôle des conteneurs ou des VM). Elle exige aussi une supervision plus fine. Cependant, le gain financier est tel qu’il justifie largement l’investissement technique. C’est passer d’une gestion en « silos » coûteuse à une gestion en « pool » de ressources, beaucoup plus efficiente.

Pourquoi vous payez 40% trop cher pour vos serveurs et votre cloud ?

Si après avoir lu les points précédents, vous avez le sentiment de payer trop cher, vous avez probablement raison. Le chiffre de 40%, ou même 60% de surcoût, n’est pas une exagération. Il est le résultat cumulé des erreurs que nous venons de détailler : le surdimensionnement par inertie, les instances zombies, le refus de la consolidation et l’ignorance des stratégies d’extinction. Ce n’est pas un problème isolé ; c’est un phénomène global. Un rapport récent a estimé que le gaspillage des ressources cloud a atteint 135 milliards de dollars en 2024, soit près de 30% des dépenses globales.

La cause racine de ce gaspillage n’est pas technique, elle est culturelle. C’est le passage d’un modèle d’achat d’investissement (CAPEX), où l’on achetait des serveurs physiques pour 5 ans, à un modèle de coût opérationnel (OPEX), où l’on paie à la minute. Les réflexes du premier modèle persistent dans le second : on « achète » une instance comme on achetait un serveur, en prévoyant large pour ne pas avoir à en racheter un autre. C’est une erreur fondamentale de paradigme. Le cloud n’est pas un data center moins cher, c’est une plateforme d’agilité qui demande une gestion dynamique.

Adopter une culture de la mesure et du FinOps n’est plus une option, c’est une nécessité pour toute entreprise qui veut rester compétitive. Cela signifie que chaque décision d’infrastructure doit être guidée non pas par la peur, mais par la donnée. Cela implique de donner aux équipes de développement les outils et la responsabilité pour gérer leurs propres coûts. C’est un changement profond, mais les bénéfices, tant financiers qu’opérationnels (agilité, performance), sont immenses.

Pour mettre en pratique ces conseils, l’étape suivante consiste à initier un audit de votre infrastructure. Commencez dès aujourd’hui à identifier les instances les moins utilisées en appliquant les seuils de détection. Chaque euro économisé sur une infrastructure surdimensionnée est un euro qui peut être réinvesti dans l’innovation et la valeur ajoutée pour vos clients.