Pourquoi un audit des coûts cloud est essentiel avant migration
Avant de migrer vers AWS, comprendre où part l'argent dépensé dans votre infrastructure cloud actuelle n'est pas un luxe, c'est une nécessité stratégique. Beaucoup d'organisations découvrent lors d'une migration que 30 à 40% de leur budget cloud finance des ressources sous-utilisées, orphelines ou mal configurées. Cette découverte tardive peut transformer un plan de migration cohérent en cauchemar budgétaire.
Un audit coûts cloud fait avant la transition vous permet de deux choses essentielles. D'abord, il établit une baseline chiffrée et transparente : vous savez précisément combien coûte aujourd'hui chaque composant de votre infrastructure, identifiez les postes qui explosent, et détectez les anomalies évidentes (instances jamais arrêtées, stockage zombie, licences logicielles qui tournent à vide). Ensuite, il vous arme d'arguments solides auprès du CFO et du comité exécutif. Plutôt que de dire « nous allons migrer et économiser un jour », vous pouvez poser sur la table une analyse factuelle : « nous avons identifié 150 k€ par an de surprovisionnement et 85 k€ de ressources orphelines ; en les supprimant ou en les optimisant dès maintenant, on réduit la facturation de 235 k€ avant même de toucher à AWS ».
Cette transparence sur les coûts actuels devient également la boussole de votre stratégie de migration elle-même. Elle vous dit quelles applications sont des hogs budgétaires (et donc des candidats prioritaires à l'optimisation), quelles ressources sont critiques (et donc doivent être répliquées fidèlement vers AWS sans perte de performance), et où les gains potentiels seront les plus importants.
Les cinq fuites budgétaires les plus courantes à détecter
La plupart des audits coûts cloud révèlent des failles qui se répètent d'une organisation à l'autre. Apprendre à les reconnaître vous permet de commencer votre audit avec un oeil entrainé.
La première fuite est le surprovisionnement en puissance de calcul. Une instance AWS (ou un équivalent chez un autre fournisseur) reste souvent configurée avec la taille que quelqu'un a estimée « au cas où » six mois plus tôt, sans jamais être réévaluée. Une t3.2xlarge coûte 3 à 4 fois plus qu'une t3.medium, mais en pratique elle utilise 20% de son CPU et 15% de sa RAM en moyenne. Le coût mensuel peut grimper à 800 ou 1 200€ pour une utilisation réelle qui nécessiterait une t3.small à 120€. Multiplié par une dizaine ou une centaine d'instances, ce gaspillage devient facilement cinq chiffres.
La deuxième catégorie est les ressources orphelines : disques durs détachés mais non supprimés, snapshots de sauvegarde jamais nettoyés, adresses IP statiques réservées mais inutilisées, ou bases de données en standby pour une failover qui n'a jamais eu lieu. Ces objets ne coûtent rien individuellement (quelques euros par mois), mais en accumulation ils représentent souvent 15 à 20% de la facture de stockage.
La troisième fuite, plus subtile, est le transfer de données et la bande passante sortante. Chaque gigaoctet de données qui quitte le datacenter coûte 5 à 12 centimes selon la région et le chemin. Une application qui push des logs vers un tiers, qui réplique des données entre zones, ou qui sert du contenu à des utilisateurs externes sans CDN peut accumuler des centaines d'euros en frais de transfert sans que quiconque le remarque.
La quatrième est le manque de consolidation sur les environnements « à bas usage ». Beaucoup de structures gardent des environnements de développement, staging, ou test isolés avec leurs propres instances, bases de données, et services réseau, même quand ces environnements ne fonctionnent que 30 ou 40 heures par semaine. Un simple plan de shutdown automatisé des ressources hors heures ouvrables peut diviser par 3 à 4 le coût de ces environnements.
Enfin, la cinquième fuite est la licence logiciels. Beaucoup de licences éditeur (Microsoft SQL Server, Oracle, etc.) sont facturées à l'instance ou au vCore, et les organisations ne savent plus quel logiciel tourne où. Une instance qui devait avoir une licence « Development » s'est transformée en serveur de staging critique, puis en secours de production, mais la catégorisation n'a jamais été mise à jour. Vérifier la conformité des licences révèle régulièrement des sous-licences oubliées ou des licences achetées mais jamais mises en place.
Les étapes concrètes d'un audit coûts efficace
Un audit des coûts cloud ne doit pas être une étude de trois mois menée par des consultants externes déconnectés de votre réalité opérationnelle. Voici comment mener un audit efficace en interne, avec ou sans appui externe pour valider les conclusions.
Étape 1 : récupérer les données brutes. Exportez vos 6 à 12 derniers mois de factures cloud au format CSV ou JSON depuis la console de votre fournisseur (AWS Cost Explorer, factures détaillées GCP ou Azure). Ces fichiers contiennent chaque charge, chaque service, chaque région et tag. Importez-les dans un outil d'analyse : un simple Google Sheets suffit pour commencer, mais un outil dédié comme CloudFit, Densify, ou même le Cost Explorer natif AWS offre des dashboards qui accélèrent l'analyse.
Étape 2 : segmenter par dimension stratégique. Ne pas juste regarder « compute » vs « stockage » en agrégé. Découpez par application, par environnement (prod/staging/dev), par équipe responsable, par région géographique, et par type de charge (on-demand vs reserved vs spot). Cela révèle immédiatement quel service dépense le plus et où les anomalies sont localisées.
Étape 3 : identifier les anomalies via le tagging et les ressources sans tag. Allez dans la console de votre fournisseur, listez les instances, disques, snapshots, et bases de données. Cherchez les ressources sans tag (souvent des créations ad hoc dont plus personne ne connaît le propriétaire ou l'utilité). Listez aussi les ressources avec un tag "environment = dev" ou "temporary = true" mais encore actives après 6 mois, celles sans activité réseau depuis un mois, ou avec 0% d'utilisation CPU depuis des semaines. Ces signaux forts indiquent souvent des ressources orphelines.
Étape 4 : confronter l'analyse aux équipes. L'équipe application X doit valider : « oui, cette instance de 2 000€/mois est à nous, et voici son utilisation réelle » ou « non, cette machine n'est plus utilisée depuis la migration du microservice Y il y a quatre mois ». Cette confrontation révèle systématiquement des surprises : une ressource que personne ne pensait encore activer, une autre que tout le monde croyait déjà arrêtée. Elle transforme aussi l'audit d'un exercice purement financier en conversation technique, ce qui crée un contexte pour proposer des optimisations.
Étape 5 : quantifier l'impact des optimisations évidentes. Listez les actions immédiates : « supprimer 47 snapshots orphelines = 3 200€/an », « arrêter les environnements dev entre 19h et 8h = 18 000€/an », « redimensionner 23 instances surdimensionnées = 42 000€/an ». Chiffrez-les. La somme de ces gestes « faciles » révèle régulièrement 100 000 à 300 000€ d'économies annuelles sans effort architectural majeur.
Étape 6 : documenter pour la migration. Créez une feuille d'inventaire pour chaque application significative : nom, coût actuel mensuel, utilisation typique (CPU, RAM, stockage, bande passante), sensibilité à la latence, dépendances critiques. Cette feuille devient le cahier des charges de votre migration : elle dit quoi vous devez reproduire sur AWS, à quel niveau de performance, et surtout quel coût vous ne devez pas dépasser.
Outils et méthodes d'analyse des coûts cloud
Plusieurs approches et outils peuvent accélérer ou automatiser votre audit des coûts cloud. Le choix dépend de votre taille, de votre maturité cloud, et de votre budget pour l'audit lui-même.
Les outils natifs du fournisseur sont le point de départ gratuit et obligatoire. AWS Cost Explorer offre des dashboards interactifs, des filtres par tag, par service, par région, et des alertes sur les anomalies de tendance. Son onglet « Recommendations » suggère déjà des optimisations (unused instances, underutilized reservations, etc.). À utiliser en priorité avant de considérer des outils tiers. GCP BigQuery et Microsoft Azure Cost Analysis offrent des fonctionnalités similaires.
Pour les organisations avec plus de 500 k€ par an de dépenses cloud, un outil tiers comme CloudFit, Optimizely, ou Densify offre des analyses plus approfondies : il ingère votre historique d'utilisation sur mois ou années, détecte des patterns (surprovisionnement saisonnier, pics non expliqués), recommande automatiquement des rightsizing, et modélise l'impact sur votre budget d'une migration vers AWS ou d'une transition vers du reserved capacity. Ces outils coûtent entre 500 et 3 000€ par mois, donc ils doivent être justifiés par des économies réelles de plus de 50 000€ par an.
Pour une approche structurée, un framework maison sur Google Sheets ou Airtable suffit souvent. Importez vos exports de factures, créez des pivots par application, par équipe, par région. Ajoutez une colonne « Utilisation CPU/RAM observée » remplie par vos équipes opérationnelles, et une colonne « Ressource orpheline ou surprovisionnée » pour le diagnostic. Ce template devient rapidement votre outil de décision pendant toute la phase d'audit.
Une méthode complémentaire, mais laborieuse, est l'analyse manuelle des applications. Connectez-vous à votre monitoring (Prometheus, New Relic, DataDog, CloudWatch) et regardez les métriques réelles de chaque application sur les 3 derniers mois : CPU moyen, pics, RAM utilisée, nombre de requêtes par seconde, latence P99. Comparez avec la capacité allouée. Une instance t3.xlarge qui affiche 8% CPU et 12% RAM en moyenne, même avec des pics à 40%, peut fonctionner sur une t3.medium sans risque. Cette analyse prend du temps mais elle produit des recommandations de qualité que les outils automatiques, trop prudents, pourraient manquer.
Enfin, envisagez d'impliquer un auditeur externe pour quelques jours. Un expert en coûts cloud peut flairer les fuites que votre équipe, habituée à l'existant, ne voit plus. Son regard neuf et son checkliste complète accélèrent la phase de détection. Chez Stralya, nous nous appuyons souvent sur cette approche mixte : audit interne rapide + validation externe sur 2-3 jours pour détecter ce qui a été oublié.
Passer de l'audit aux décisions : chiffres et priorisations
Un audit qui aboutit à une simple liste de faits n'a servi à rien. L'objectif est de transformer ces découvertes en décisions chiffrées et en actions priorisées.
D'abord, présentez les découvertes selon deux axes qui parlent à la direction : la réduction de coûts court terme, et les économies liées à la migration elle-même. Le court terme, c'est « nous avons identifié 235 k€ d'économies sans déployer AWS : arrêter les environnements hors horaires, supprimer les ressources orphelines, et redimensionner les instances surdimensionnées ». Ces actions se font en 2 à 6 semaines et ne demandent aucune architecture majeure, juste de la discipline opérationnelle. Elles aussi montrent une volonté d'optimisation avant la grosse migration.
Le second axe est le potentiel AWS : « cette baseline nettoyée nous permet de projeter un coût AWS réaliste et d'identifier les services AWS (reserved instances, savings plans, spot instances pour les charges non critiques, data transfer réduction) qui ajouteront 20 à 30% d'économie supplémentaire après migration ». Cela montre que le coût AWS n'est pas une surprise, qu'il a été budgété en fonction d'une vraie compréhension de votre charge.
Deuxièmement, créez une matrice impact-complexité pour vos optimisations identifiées. Chaque action (supprimer 50 snapshots orphelines, arrêter les dev la nuit, redimensionner instance X, refactoriser la réplication de données) doit avoir un impact estimé (combien cela économise par mois) et une complexité (heures-ing nécessaires, risques, dépendances). Les actions haut impact et basse complexité (quadrant nord-ouest) doivent être faites immédiatement. Les haut impact mais complexe passent dans le backlog de migration. Les bas impact et basse complexité sont des quick wins pour l'équipe.
Troisièmement, attribuez la responsabilité de chaque optimisation. Ne dites pas « arrêter les environnements dev la nuit ». Dites « l'équipe Platform lancera un script de shutdown à 19h00 les jours de semaine (impact : 18 k€/an, complexité : 4 heures, date limite : fin du mois »). Cette granularité transforme l'audit en plan d'action.
Enfin, documentez le plan de migration lui-même en fonction de cette baseline. Si application A coûte 4 000€/mois en prod aujourd'hui et 2 500€/mois en dev, votre design AWS devra budgeter au moins 4 000€/mois en prod (peut-être 3 200€ si vous utilisez AWS Savings Plans). Si l'optimisation révèle que application A est en réalité surdimensionnée et que 2 800€/mois seraient suffisants, notez-le : c'est votre cible AWS, pas 4 000€. L'audit coûts devient alors la fondation de votre stratégie d'achat AWS (reserved instances, spot, etc.).
Audits coûts et migration : comment les interconnecter
L'audit des coûts ne doit pas rester un exercice isolé. Il doit structurer votre migration elle-même.
Premièrement, l'audit vous dit quelles applications sont des candidates prioritaires à la migration. Si application A coûte 3 500€/mois et application B coûte 280€/mois, migrer A en premier crée des retours sur investissement plus visibles et permet de maîtriser les coûts AWS sur un cas d'usage plus significatif avant de lancer la migration complète. L'audit identifie aussi les applications où les frais AWS peuvent être réduits : si application A tourne sur des instances très surdimensionnées, l'utilisation de ressources plus granulaires AWS (Lambda pour les jobs intermittents, ECS pour les conteneurs, Fargate pour ne pas gérer l'infrastructure) peut diviser par 3 son coût.
Deuxièmement, les données d'utilisation réelle (CPU, RAM, bande passante) récupérées lors de l'audit permettent de dimensionner correctement vos ressources AWS dès le départ. Plutôt que de migrer une instance t3.xlarge et découvrir six mois après qu'elle utilise 15% de sa capacité, vous migrez directement une t3.medium, économisant 80% sur ce coût depuis le jour 1. Les équipes AWS qui ne mènent pas d'audit préalable commettent régulièrement cette erreur, et accumulent 6 à 12 mois de surprovisionnement sur AWS avant de réaliser l'erreur.
Troisièmement, l'audit révèle les dépendances et les opportunités de consolidation. Si vous avez quatre bases de données distinctes pour quatre micro-applications, l'audit peut montrer qu'elles utilisent toutes très peu de ressources et qu'une migration vers RDS Aurora Serverless avec un seul cluster suffirait, réduisant les coûts d'opération et les coûts fixes. Ou si vous avez des stockages fragmentés dans plusieurs régions, vous pouvez consolider vers une seule région AWS et utiliser le transfert intra-AWS (gratuit) au lieu de transferts multi-clouds (chers).
Quatrièmement, l'identification des fuites actuelles permet de définir des SLA réalistes post-migration. Si aujourd'hui vous perdez 100 k€ par an en ressources orphelines, promettez aux parties prenantes qu'AWS aura un processus de nettoyage automatisé qui éliminera ce gaspillage. C'est un engagement viable, basé sur des données réelles de votre propre historique.
Enfin, les optimisations court-terme menées avant la migration (arrêter les dev la nuit, supprimer les ressources orphelines, redimensionner les instances) réduisent le budget total à migrer. Si vous réduisez votre baseline de 235 k€, vous n'avez besoin que de 235 k€ moins chers en budget AWS, ce qui rend la business case de migration encore plus solide.