Mesurer avant de couper
La première économie vient toujours du dimensionnement : la plupart des machines sont réservées pour un pic qui n'arrive jamais.
Avant de toucher à quoi que ce soit, nous avons donc commencé par deux semaines d'observation : utilisation réelle du processeur et de la mémoire, heure par heure, pour chaque machine et chaque base de données. Deux semaines, parce qu'une seule ne montre pas les cycles de fin de mois, et que c'est souvent là que se cache le vrai pic.
Le constat est presque toujours le même : des serveurs dimensionnés au moment du lancement, « pour être tranquille », et jamais revus depuis. Une machine qui ne dépasse jamais le quart de sa capacité pendant toute la période peut descendre d'une taille sans que personne ne s'en aperçoive.
Premier levier : le dimensionnement réel
La règle que nous appliquons est simple : on dimensionne pour le pic observé, plus une marge raisonnable, et non pour le pic imaginé. Et on le fait progressivement :
- une taille en dessous à la fois, jamais deux d'un coup ;
- en commençant par les environnements les moins critiques ;
- avec une alerte sur la saturation et un retour arrière prêt, pour chaque changement.
Là où la charge varie fortement dans la journée, la mise à l'échelle automatique fait le reste : peu de machines la nuit, davantage aux heures de pointe. Le service n'est jamais dégradé, puisque la capacité suit la demande au lieu de l'anticiper.
Une fois la charge stable et bien connue, les réservations sur un ou trois ans deviennent intéressantes : le fournisseur accorde une remise importante en échange d'un engagement. Mais on ne réserve qu'après avoir redimensionné, jamais avant. S'engager sur trois ans pour une machine deux fois trop grande, c'est figer le gaspillage.
Deuxième levier : le cycle de vie du stockage
Le stockage est la dépense qui grossit en silence. Journaux applicatifs, sauvegardes, exports, fichiers déposés par les utilisateurs : tout s'accumule, et tout est facturé au même tarif, qu'on le consulte chaque jour ou jamais.
Les fournisseurs proposent pourtant des classes de stockage moins chères pour les données rarement lues, et des règles de cycle de vie qui déplacent ou suppriment automatiquement les fichiers selon leur âge. Nous avons défini, avec les équipes métier et juridique, une durée de conservation pour chaque type de données :
- les journaux techniques restent consultables quelques semaines, puis sont archivés ;
- les sauvegardes suivent une rotation claire : quotidiennes, puis hebdomadaires, puis mensuelles ;
- les exports temporaires sont supprimés automatiquement.
Le point délicat n'est pas technique : c'est d'obtenir une décision écrite sur ce que l'on a le droit de supprimer. Une fois cette décision prise, la règle s'applique toute seule, sans que personne n'ait à y penser.
Troisième levier : éteindre ce qui ne sert pas
Les environnements de développement, de test et de recette n'ont aucune raison de tourner la nuit et le week-end. Pourtant, ils le font presque toujours, par habitude. Une planification qui les arrête le soir et les relance le matin réduit leur coût de plus de moitié, simplement parce qu'une semaine compte bien plus d'heures creuses que d'heures de travail.
La même logique s'applique aux ressources oubliées : disques détachés, adresses IP réservées sans machine, instantanés d'anciens serveurs, environnements de démonstration montés pour un client il y a un an. Un inventaire mensuel, avec un propriétaire nommé pour chaque ressource, suffit à les faire disparaître.
Rendre la facture lisible
Aucun de ces leviers ne tient dans la durée si personne ne sait qui consomme quoi. Nous avons donc étiqueté chaque ressource avec trois informations : le projet, l'environnement et le responsable. La facture, jusque-là une longue liste de lignes techniques, devient un tableau par équipe et par application.
Ce simple changement modifie les comportements. Quand une équipe voit sa propre consommation chaque mois, elle éteint d'elle-même ce qui ne sert plus. Une alerte budgétaire par projet complète le dispositif : un dépassement se découvre en quelques jours, pas à la clôture du trimestre.
Ce que nous n'avons pas fait
Nous n'avons pas changé de fournisseur, ni réécrit l'application, ni réduit la redondance de la production. Les économies qui exigent de prendre un risque sur le service ne sont pas des économies : elles se paient plus tard, au premier incident.
Une facture cloud se pilote comme un budget : on la mesure, on attribue chaque ligne à un responsable, et on la revoit chaque mois.
Le plus gros gain, au fond, n'est pas technique. C'est l'habitude de regarder la facture régulièrement, ligne par ligne, avec quelqu'un qui sait à quoi sert chaque ressource.