Automatiser l’extinction cloud : scheduler, tags ou plateforme FinOps ?

Trois familles reviennent souvent : le script planifié, la règle basée sur les tags et la plateforme FinOps ou cloud management qui orchestre plusieurs politiques. Elles peuvent coexister, mais elles ne répondent pas au même besoin.

Le script planifié convient lorsque le périmètre est petit, stable et bien connu. La règle par tags apporte plus de souplesse si les équipes acceptent de décrire leurs ressources avec des attributs fiables. La plateforme devient pertinente lorsque plusieurs équipes, comptes, projets ou environnements doivent partager des règles, des exceptions et des preuves de décision.

Un script qui éteint les ressources de développement chaque soir peut produire un gain immédiat sur des environnements clairement non critiques. Il est lisible, testable et ne demande pas forcément d’outillage supplémentaire. Pour une PME ou une équipe produit unique, c’est souvent le premier niveau raisonnable.

Son défaut apparaît lorsque les exceptions se multiplient. Une ressource doit rester active pour une démonstration, une autre héberge une recette longue, une troisième exécute un traitement différé. Si ces cas particuliers sont ajoutés directement dans le script, l’automatisation devient une connaissance locale difficile à auditer.

Cette option doit donc rester attachée à un périmètre explicite : comptes de test, plages horaires connues, ressources non persistantes, règle de notification avant arrêt et procédure simple pour suspendre temporairement l’extinction.

Le marquage des ressources rapproche l’automatisation de la logique FinOps : chaque ressource porte son application, son environnement, son propriétaire, son centre de coût et éventuellement sa fenêtre d’usage. Une politique peut alors arrêter les ressources taguées comme non permanentes, alerter lorsqu’un tag manque ou refuser une exception sans date de fin.

Cette approche évite de maintenir une liste manuelle, mais elle déplace l’effort vers la discipline de création. Un tag absent peut suffire à laisser tourner une ressource indéfiniment. Un tag trop permissif peut provoquer une extinction non souhaitée. Les équipes doivent donc traiter les tags comme une partie du contrat d’exploitation, pas comme une décoration administrative.

Le sujet rejoint directement une démarche de maîtrise des coûts cloud avec une démarche FinOps : attribuer la dépense ne suffit pas, il faut aussi relier la ressource à une décision d’usage.

Une plateforme FinOps prend de la valeur lorsque l’organisation dépasse le bricolage local. Elle peut centraliser les règles, afficher les économies potentielles, historiser les exceptions, produire des vues par équipe et faire apparaître les ressources qui ne respectent pas la politique prévue.

Elle ne remplace pourtant pas la décision. Si personne ne sait distinguer un environnement de recette actif d’un service de production mal tagué, l’outil ne fera qu’automatiser l’incertitude. Avant d’investir dans une plateforme, il faut vérifier que les équipes savent nommer les propriétaires, classer les environnements, accepter des règles par défaut et traiter les exceptions.

1. Semaine 1 : observer. Lister les ressources non permanentes, leurs horaires réels d’usage et les équipes concernées.
2. Semaine 2 : choisir un périmètre pilote. Commencer par un environnement de développement ou de test qui peut être recréé ou redémarré sans impact métier.
3. Semaine 3 : notifier avant de couper. Envoyer les alertes d’extinction sans action automatique pour repérer les faux positifs.
4. Semaine 4 : activer l’arrêt automatique. Appliquer la règle sur un périmètre stable avec journalisation des décisions.
5. Semaine 5 : traiter les exceptions. Ajouter une date de fin, un motif et un responsable à chaque dérogation.
6. Semaine 6 : étendre avec prudence. Ajouter de nouveaux projets uniquement si les règles précédentes restent compréhensibles.

Le premier critère est la criticité. Une base de test jetable ne demande pas les mêmes garde-fous qu’un environnement de préproduction utilisé pour valider une mise en production. Plus la ressource est proche d’un processus métier, plus l’automatisation doit être visible, réversible et documentée.

Le deuxième critère est la capacité de redémarrage. Éteindre une machine est acceptable si l’état utile est conservé ailleurs, si le redémarrage est testé et si les dépendances sont connues. Une extinction qui économise peu mais fragilise la reprise n’est pas une bonne décision FinOps.

Le troisième critère est la fréquence des exceptions. Une règle simple avec deux exceptions se pilote facilement. Une règle qui nécessite chaque semaine des contournements, des messages privés et des relances manuelles indique que le périmètre n’est pas encore prêt.

L’extinction réduit le temps d’exécution. Elle ne règle pas à elle seule les volumes inutiles, snapshots anciens, adresses réservées, images obsolètes ou services créés puis abandonnés. Pour les environnements temporaires, l’automatisation doit parfois aller jusqu’à la suppression contrôlée, comme dans une logique d’environnements éphémères avec durée de vie explicite.

La suppression demande toutefois un autre niveau de preuve : savoir ce qui doit être conservé, ce qui peut être détruit, comment récupérer les journaux utiles et qui valide la fin d’usage. C’est une décision de cycle de vie, pas seulement une action nocturne.

• Chaque ressource concernée a un propriétaire identifiable.
• La plage d’extinction est connue des équipes qui utilisent l’environnement.
• Les traitements planifiés, tests longs et démonstrations sont recensés.
• Le redémarrage a été testé au moins sur le périmètre pilote.
• Les exceptions ont une date de fin et un motif lisible.
• Les actions d’arrêt sont journalisées pour expliquer une interruption.
• Une procédure permet de suspendre temporairement la règle sans la désactiver partout.
• Les coûts évités sont rattachés à un périmètre projet ou applicatif, pas seulement à une ligne technique.

Pour un premier périmètre, le script planifié suffit si les ressources sont peu nombreuses et si l’équipe peut assumer la maintenance. Pour une organisation où les environnements sont créés par plusieurs équipes, les tags deviennent le socle naturel. Pour un SI cloud déjà distribué entre projets, comptes et responsables budgétaires, une plateforme FinOps peut apporter de la cohérence, à condition que les règles soient déjà comprises.

Le meilleur signal n’est pas la sophistication de l’outil. C’est la capacité à répondre calmement à trois questions : pourquoi cette ressource tourne-t-elle, qui paie son usage et que se passe-t-il si elle s’arrête ce soir ? Lorsque ces réponses existent, l’automatisation devient un levier FinOps solide plutôt qu’un pari sur la facture du mois suivant.