Votre feuille de route FinOps est aussi une feuille de route de modernisation

Lors de l’AWS Summit Toronto de juin 2026, deux conversations se déroulaient en parallèle.

Dans les salles de conférence, AWS parlait de modernisation : délaisser les versions désuètes de bases de données, adopter de nouvelles générations d’instances, migrer les charges de travail x86 vers Graviton, mettre en place des architectures sans serveur et actualiser les grappes Kubernetes avant l’entrée en vigueur des frais de soutien prolongé.

À quelques mètres de là, nous présentions à des clients les recommandations de Stable fondées sur leurs propres environnements AWS. Les listes se ressemblaient étonnamment :

• Mettre à niveau une base de données Amazon RDS arrivée à l’étape du soutien prolongé
• Migrer une charge de travail x86 vers Arm
• Faire passer des volumes Amazon EBS de gp2 à gp3
• Transférer les anciennes données Amazon S3 vers une classe de stockage mieux adaptée
• Mettre à niveau une grappe Amazon EKS avant l’application de frais supplémentaires

AWS parlait de modernisation. D’autres y voyaient d’abord des économies sur les coûts infonuagiques. Pour le client, le travail à réaliser demeurait le même. Ce chevauchement révèle une réalité importante de l’optimisation des coûts infonuagiques : une grande partie de ce que les entreprises qualifient de FinOps est en fait de la modernisation exprimée en termes financiers.

Votre facture AWS mesure l’écart qui se creuse avec la plateforme

Un environnement AWS peut continuer de très bien fonctionner même si les services et l’architecture qui le soutiennent prennent de l’âge. Les applications tournent, les bases de données demeurent stables et il est rarement urgent d’interrompre le développement de produits pour moderniser l’infrastructure. Pendant ce temps, AWS lance de nouvelles générations d’instances, de nouveaux services gérés et de nouveaux modèles tarifaires qui rendent l’environnement en place relativement plus coûteux.

AWS propose sans cesse des façons plus récentes, et souvent plus efficaces, d’exécuter les mêmes charges de travail : familles d’instances actualisées, services gérés, options sans serveur et classes de stockage moins coûteuses. Parallèlement, les anciennes versions des bases de données et de Kubernetes finissent par sortir du soutien standard et coûtent alors plus cher à conserver.

L’architecture n’est pas nécessairement moins bonne qu’au moment de sa conception. C’est plutôt sa position par rapport à la plateforme AWS qui change. Avec le temps, l’écart de coût entre l’architecture actuelle et celle que l’entreprise pourrait exploiter devient visible.

Une revue de code ne signalera toutefois pas une ancienne famille d’instances si l’application fonctionne toujours correctement. Les outils de surveillance ne présenteront pas la version d’une base de données comme un enjeu financier tant que celle-ci demeure en santé. Une revue d’architecture pourrait relever le problème, mais ce type d’exercice est périodique et souvent reporté.

La facture AWS, elle, continue de rendre cet écart visible mois après mois. Voilà entre autres pourquoi la FinOps est devenue une fonction opérationnelle aussi utile : elle traduit les conséquences financières d’une architecture vieillissante en une liste de décisions d’ingénierie bien concrètes.

FinOps Lite : le travail qui se cache derrière les économies faciles

La plupart des programmes d’optimisation des coûts infonuagiques commencent par deux catégories bien connues.

La première est l’optimisation tarifaire : Savings Plans, instances réservées, ententes d’entreprise et autres rabais liés à une utilisation prévisible. Ces mesures peuvent générer des économies importantes sans aucune modification de l’architecture.

La seconde est l’entretien de l’environnement infonuagique : supprimer les volumes Amazon EBS non rattachés, retirer les répartiteurs de charge inactifs, arrêter les instances inutilisées, libérer les adresses Elastic IP abandonnées et nettoyer les ressources qui n’ont plus d’utilité.

Ces deux catégories sont importantes. Toutes deux ont leur place dans un environnement AWS bien géré.

Une fois les engagements et les ressources inutilisées pris en charge, les possibilités restantes exigent toutefois généralement un jugement d’ingénierie.

Une charge de travail devrait-elle migrer vers Graviton? Une base de données devrait-elle utiliser une capacité allouée ou un modèle sans serveur? Redis pourrait-il être remplacé par Valkey? Les données consultées rarement devraient-elles passer à une autre classe de stockage Amazon S3? Vaut-il mieux mettre la base de données à niveau maintenant ou continuer de payer les frais de soutien prolongé?

Un tableau de facturation ne suffit pas pour trancher. Il faut comprendre l’application, ses profils de trafic, ses exigences opérationnelles, les risques de migration et sa durée de vie prévue.

C’est ici que la FinOps devient de la modernisation. Les rabais et les engagements réduisent le prix de l’infrastructure déjà en place. La modernisation transforme l’infrastructure elle-même.

Le soutien prolongé rend la dette de modernisation explicite

Les frais de soutien prolongé en sont l’un des exemples les plus clairs.

AWS facture des frais supplémentaires aux clients qui continuent d’utiliser certaines versions d’Amazon RDS, d’Amazon Aurora et d’Amazon EKS après la fin du soutien standard. La ressource peut continuer de fonctionner normalement, mais le maintien d’une version désuète comporte désormais un coût bien visible.

Dans un tableau de bord FinOps, ce coût supplémentaire peut apparaître comme une possibilité d’économies annualisées. Sur le plan opérationnel, il s’agit plutôt de la facture d’une modernisation reportée.

Le client paie plus cher parce que la mise à niveau n’a pas été réalisée avant l’échéance du soutien. Pour éliminer ces frais, il faut évaluer la compatibilité, tester la nouvelle version, planifier la migration et gérer le changement de façon sécuritaire. Autrement dit, la recommandation est financière, mais la solution est technique.

Le soutien prolongé n’est que la manifestation la plus directe d’une tendance plus large. AWS a toujours incité ses clients à se tourner vers de nouveaux services et de nouvelles architectures au moyen de ses gains de performance, de ses prix et de ses politiques de soutien. Les technologies plus anciennes deviennent graduellement moins concurrentielles, moins efficaces ou plus coûteuses à maintenir.

Le soutien prolongé transforme cette pression graduelle en poste de facturation. Parler d’une possibilité d’économies est exact sur le plan technique, mais incomplet. L’entreprise ne profite pas d’un rabais astucieux. Elle s’attaque à sa dette de modernisation une fois que celle-ci a commencé à apparaître sur la facture.

Le véritable rôle de la FinOps

La FinOps offre aux organisations un moyen concret de relier les décisions d’ingénierie à leurs résultats financiers. C’est souvent ce lien qui permet aux projets de modernisation d’obtenir le temps et le budget nécessaires.

Une équipe d’ingénierie peut avoir du mal à accorder la priorité à une migration puisque l’environnement actuel fonctionne toujours. L’analyse de rentabilité devient plus claire lorsque la même migration est associée à un coût annuel récurrent, à de futurs frais de soutien ou à une amélioration mesurable de la rentabilité unitaire.

L’angle financier aide à répondre à des questions que les arguments d’architecture ne suffisent pas toujours à trancher.

Combien l’architecture actuelle coûte-t-elle à l’entreprise? Quel rendement peut-on attendre de sa transformation? Quelle migration devrait passer en premier? Combien de temps faudra-t-il pour que les économies absorbent les coûts de mise en œuvre? L’effort d’ingénierie est-il justifié pour une charge de travail appelée à disparaître l’an prochain?

La FinOps permet aux équipes des finances et de l’ingénierie d’évaluer le même problème sous deux angles complémentaires. Les coûts sont visibles, le travail technique est clair et la direction dispose d’assez de contexte pour décider si l’initiative doit être inscrite à la feuille de route.

Un rapport FinOps devrait devenir une feuille de route de modernisation

Un rapport FinOps utile ne se contente pas d’énumérer toutes les économies possibles. Il aide les équipes à distinguer les gains rapides des projets techniques plus importants, puis à évaluer chaque possibilité selon l’effort requis, les risques et le délai de récupération prévu.

Recommander la migration d’une instance vers Graviton ne suffit pas sous prétexte que Graviton pourrait coûter moins cher. L’équipe doit savoir si la charge de travail est compatible, combien elle coûte actuellement, quelles économies sont attendues, quels essais devront être réalisés et si cette migration mérite de passer avant d’autres possibilités.

La même logique s’applique à la modernisation des bases de données, à la hiérarchisation du stockage, à l’adoption du sans serveur et à l’élimination des frais de soutien prolongé.

Agir avant que la facture impose la décision

Pour de nombreuses entreprises, la FinOps ne devient urgente que lorsque la facture AWS force la discussion. Un budget est dépassé, des frais inattendus apparaissent ou la direction commence à poser des questions. La modernisation doit alors se faire sous pression plutôt que dans le cadre d’une feuille de route planifiée.

Une approche plus solide consiste à faire de l’efficacité des coûts une pratique d’architecture continue.

Cela suppose de repérer les familles d’instances vieillissantes avant qu’elles ne deviennent un réel désavantage, de planifier les mises à niveau des bases de données avant le début du soutien prolongé et de vérifier régulièrement si les charges de travail utilisent encore les bons modèles de calcul, de stockage et de bases de données. Il faut également évaluer les nouveaux services AWS en fonction de leur pertinence opérationnelle et financière, et non les adopter simplement parce qu’ils sont nouveaux.

Toutes les recommandations ne valent pas la peine d’être mises en œuvre. Une migration demande du temps, comporte des risques et entre en concurrence avec d’autres priorités. Il est préférable de faire ces arbitrages avant que la hausse des coûts AWS ne force la décision.

Lorsque l’entreprise modernise selon son propre calendrier, les économies sont tout de même au rendez-vous. Elles deviennent alors la preuve d’une architecture plus efficace plutôt que le prétexte urgent qui justifie enfin sa mise à niveau.

Au-delà des économies faciles

Les Savings Plans, les instances réservées et le nettoyage des ressources inutilisées peuvent réduire rapidement le gaspillage. Ils ne répondent toutefois pas à la question plus vaste : l’environnement repose-t-il encore sur les bons services, les bonnes versions et les bons modes d’exploitation AWS?

C’est là que commence le travail FinOps en profondeur. Les recommandations apparaissent peut-être dans un rapport de coûts, mais leur mise en œuvre exige souvent de mettre à niveau, de migrer ou de repenser une partie de l’environnement.

Bien utilisée, la FinOps ne montre pas seulement où l’argent est dépensé. Elle aide les entreprises à déterminer dans quelle direction leur architecture doit évoluer.