<\/p>\n
Ce que signifient r\u00e9ellement les op\u00e9rations Day 0, Day 1 et Day 2 pour les \u00e9quipes platform<\/b><\/h2>\n
Les \u00e9quipes platform ma\u00eetrisent bien le Day 1. Les pipelines CI\/CD sont construits, les modules Terraform \u00e9crits, le provisionnement automatis\u00e9. La v\u00e9rit\u00e9 inconfortable est que le Day 1 est la partie facile \u2014 il est d\u00e9limit\u00e9 dans le temps. Le Day 2 ne l’est pas, et l’investissement en gouvernance ne correspond presque jamais \u00e0 la dur\u00e9e op\u00e9rationnelle.<\/span><\/p>\n Gartner pr\u00e9voit que<\/span> d’ici 2026, 80 % des grandes organisations d’ing\u00e9nierie logicielle auront constitu\u00e9 des \u00e9quipes platform<\/span><\/a> en tant que fournisseurs internes de services et d’outils r\u00e9utilisables, contre 45 % en 2022. La pression de d\u00e9ployer rapidement ces plateformes cr\u00e9e un sch\u00e9ma o\u00f9 la gouvernance Day 2 est report\u00e9e jusqu’\u00e0 ce que la douleur d’en \u00eatre d\u00e9pourvu soit suffisamment forte pour justifier l’investissement. \u00c0 ce stade, il y a d\u00e9j\u00e0 de la d\u00e9rive \u00e0 corriger, des d\u00e9passements de co\u00fbts \u00e0 expliquer et des lacunes de conformit\u00e9 \u00e0 documenter. Selon<\/span> l’enqu\u00eate de Spacelift aupr\u00e8s de 413 d\u00e9cideurs en infrastructure<\/span><\/a>, 45 % des organisations affirment avoir atteint des niveaux \u00e9lev\u00e9s d’automatisation, mais seulement 14 % d\u00e9montrent les pratiques d’une excellence r\u00e9elle en automatisation d’infrastructure. L’\u00e9cart r\u00e9side presque enti\u00e8rement dans le Day 2.<\/span><\/p>\n Le mod\u00e8le Day 0\/1\/2 ne fonctionne que si la gouvernance est continue sur les trois phases, pas appliqu\u00e9e au provisionnement puis silencieusement abandonn\u00e9e. Cet article couvre ce que chaque phase poss\u00e8de r\u00e9ellement, o\u00f9 la gouvernance s’effondre entre les phases, et \u00e0 quoi ressemble une plateforme con\u00e7ue pour couvrir l’int\u00e9gralit\u00e9 du cycle de vie \u2014 des d\u00e9finitions .forms.yml<\/span> qui encodent la politique Day 0 aux m\u00e9canismes de d\u00e9tection de d\u00e9rive et de gouvernance des co\u00fbts qui rendent le Day 2 g\u00e9rable \u00e0 l’\u00e9chelle.<\/span><\/p>\n <\/p>\n <\/p>\n <\/p>\n Le Day 0 n’est pas une r\u00e9union de planification ; il produit des artefacts d’ing\u00e9nierie : fronti\u00e8res RBAC, templates IaC, politiques de conformit\u00e9, strat\u00e9gie d’identit\u00e9, d\u00e9cisions de topologie r\u00e9seau et structures de d\u00e9p\u00f4ts de catalogue. Tout ce qui suit h\u00e9rite de ces contraintes, ce qui rend leur erreur co\u00fbteuse. Modifier r\u00e9troactivement la segmentation VPC dans un environnement de production ou restructurer une hi\u00e9rarchie de catalogue apr\u00e8s l’import de dizaines de stacks sont le type de correctifs qui prennent des semaines et g\u00e9n\u00e8rent des incidents en chemin.<\/span><\/p>\n Le Day 1 est la fen\u00eatre de d\u00e9ploiement initial. L’infrastructure est provisionn\u00e9e, les services d\u00e9ploy\u00e9s, les pipelines CI\/CD c\u00e2bl\u00e9s. Les contraintes Day 0 doivent arriver ici intactes, encod\u00e9es dans les templates et formulaires avec lesquels les ing\u00e9nieurs interagissent lors du provisionnement.<\/span><\/p>\n Le Day 2 commence au moment o\u00f9 le premier changement post-d\u00e9ploiement est appliqu\u00e9 et dure jusqu’\u00e0 la mise hors service de l’environnement. Il couvre la supervision, le patching, la rotation des secrets, les \u00e9v\u00e9nements de mont\u00e9e en charge, les mises \u00e0 jour de charts Helm, la gestion des co\u00fbts et le travail de nettoyage li\u00e9 \u00e0 la mise hors service propre des environnements. L’appeler une \u00ab\u00a0phase\u00a0\u00bb est g\u00e9n\u00e9reux \u2014 c’est l’\u00e9tat par d\u00e9faut de tout syst\u00e8me en production et la seule phase sans date de fin d\u00e9finie. Une \u00e9quipe qui investit massivement dans les jours 0 et 1, puis traite le Day 2 comme le probl\u00e8me de quelqu’un d’autre, passera la majorit\u00e9 de son temps op\u00e9rationnel dans un \u00e9tat qu’elle n’a jamais con\u00e7u.<\/span><\/p>\n <\/p>\n <\/p>\n Le sch\u00e9ma d’\u00e9chec est coh\u00e9rent : les \u00e9quipes platform appliquent les standards \u00e0 la cr\u00e9ation via des modules Terraform approuv\u00e9s et des portes de pipeline, puis laissent les op\u00e9rations Day 2 retomber dans les tickets. Monter en charge un environnement, faire pivoter un secret, mettre \u00e0 jour un chart Helm ou d\u00e9commissionner un service contourne les m\u00eames garde-fous qui r\u00e9gissaient le provisionnement initial.<\/span><\/p>\n Comme<\/span> le documentent les recherches de Cycloid en platform engineering<\/span><\/a>, la gouvernance qui d\u00e9pend de la revue humaine \u00e9volue lin\u00e9airement avec l’usage. \u00c0 100+ ing\u00e9nieurs, les files de revue deviennent le goulot d’\u00e9tranglement, pas les outils manquants. Une \u00e9quipe data qui provisionne un nouvel entrep\u00f4t d\u00e9clenche une revue d’ing\u00e9nieur platform pour le placement r\u00e9seau Terraform, une revue de s\u00e9curit\u00e9 pour les chemins d’acc\u00e8s aux donn\u00e9es et un contr\u00f4le budg\u00e9taire pour la taille de l’entrep\u00f4t \u2014 tout cela s\u00e9quentiellement, tout cela pour une demande structurellement identique aux vingt pr\u00e9c\u00e9dentes. Ajouter plus de r\u00e9viseurs dans la boucle ne r\u00e9sout pas le probl\u00e8me structurel ; cela ne fait que retarder le moment o\u00f9 la file s’effondre.<\/span><\/p>\n <\/p>\n <\/p>\n Les modes de d\u00e9faillance sont sp\u00e9cifiques et cumulatifs. La d\u00e9rive de configuration entre par les modifications manuelles via la console effectu\u00e9es pour d\u00e9bloquer des incidents \u2014 des modifications qui ne retournent jamais dans le contr\u00f4le de version. L’exposition aux co\u00fbts se construit depuis les ressources sur-provisionn\u00e9es correctement dimensionn\u00e9es au Day 1 mais jamais r\u00e9\u00e9valu\u00e9es \u00e0 mesure que les sch\u00e9mas d’utilisation \u00e9voluent. Les lacunes de conformit\u00e9 \u00e9mergent des politiques appliqu\u00e9es \u00e0 la cr\u00e9ation mais pas \u00e0 la mise \u00e0 jour ni \u00e0 la mise hors service. Un environnement qui a pass\u00e9 sa revue de s\u00e9curit\u00e9 initiale peut accumuler des mois de modifications non gouvern\u00e9es avant que le prochain audit ne r\u00e9v\u00e8le le probl\u00e8me.<\/span><\/p>\n Le plancher op\u00e9rationnel s’effondre quand les runbooks manuels sont le m\u00e9canisme de r\u00e9ponse principal au Day 2. Personne ne veut fouiller une page Notion \u00e0 2h du matin en cherchant la proc\u00e9dure de red\u00e9marrage d’un service qu’il n’a pas \u00e9crit.<\/span> <\/p>\n <\/p>\n Le Day 0 est l\u00e0 o\u00f9 le mod\u00e8le de gouvernance tient la route ou s’effondre silencieusement. Les d\u00e9cisions prises ici n’affectent pas seulement le premier d\u00e9ploiement \u2014 elles contraignent chaque environnement, chaque mise \u00e0 jour et chaque \u00e9v\u00e9nement de mise hors service sur la dur\u00e9e de vie de la plateforme.<\/span><\/p>\n Traiter les livrables Day 0 comme des artefacts d’ing\u00e9nierie durables plut\u00f4t que comme des documents provisoires \u00e0 r\u00e9viser plus tard est ce qui distingue une plateforme qui vieillit bien d’une qui accumule une dette structurelle \u00e0 un rythme pr\u00e9visible.<\/span><\/p>\n <\/p>\n <\/p>\n Les d\u00e9cisions de topologie r\u00e9seau et de segmentation VPC prises pendant le Day 0 sont co\u00fbteuses \u00e0 modifier apr\u00e8s d\u00e9ploiement. Isoler r\u00e9troactivement un niveau de donn\u00e9es provisionn\u00e9 sur le m\u00eame sous-r\u00e9seau que les charges de travail applicatives n’est pas un changement de configuration \u2014 c’est une r\u00e9-architecture avec des implications d’indisponibilit\u00e9. La strat\u00e9gie d’identit\u00e9 et la conception du mod\u00e8le RBAC ont le m\u00eame poids. Un mod\u00e8le RBAC construit autour de comptes de service trop larges ne peut pas facilement \u00eatre durci apr\u00e8s que des dizaines de charges de travail ont \u00e9t\u00e9 d\u00e9ploy\u00e9es dessus. Le choix de la cha\u00eene d’outils IaC entra\u00eene des implications de lock-in qui fa\u00e7onnent l’automatisation Day 2 pendant des ann\u00e9es ; les changements de cha\u00eene en milieu de cycle signifient r\u00e9\u00e9crire le mod\u00e8le de gestion d’\u00e9tat pour chaque environnement existant.<\/span><\/p>\n Cycloid traite Git comme le store d’\u00e9tat autoritatif d\u00e8s le Day 0, o\u00f9 les d\u00e9p\u00f4ts de catalogue, les d\u00e9finitions de Stacks et les fichiers de configuration sont versionn\u00e9s avant qu’un environnement n’existe.<\/span> Les d\u00e9p\u00f4ts de catalogue, les d\u00e9finitions de stacks et les configurations .cycloid.yml<\/span> sont versionn\u00e9s avant qu’un environnement n’existe<\/span><\/a>. Les d\u00e9cisions prises en dehors de Git pendant le Day 0 cr\u00e9ent un \u00e9tat non document\u00e9 que le Day 2 ne peut pas r\u00e9concilier \u2014 la d\u00e9tection de d\u00e9rive n\u00e9cessite un enregistrement canonique de l’\u00e9tat souhait\u00e9 \u00e0 comparer \u00e0 l’\u00e9tat d\u00e9ploy\u00e9 r\u00e9el. Sans lui, la plateforme n’a pas de baseline.<\/span><\/p>\n <\/p>\n <\/p>\n Dans Cycloid, le fichier .forms.yml<\/span> d’une Stack d\u00e9finit quels inputs sont expos\u00e9s \u00e0 l’ing\u00e9nieur qui d\u00e9ploie, quelles valeurs sont born\u00e9es \u00e0 une plage approuv\u00e9e et quelles options sont enti\u00e8rement verrouill\u00e9es. Les d\u00e9cisions de conformit\u00e9 prises pendant le Day 0 d\u00e9terminent ce que les op\u00e9rateurs Day 1 et Day 2 peuvent faire \u2014 non pas via des documents de politique, mais via ce que l’interface permet litt\u00e9ralement.<\/span><\/p>\n <\/p>\n <\/p>\n StackForms lit la configuration .forms.yml<\/span> et ne pr\u00e9sente que des inputs born\u00e9s et approuv\u00e9s<\/span><\/a>. Un ing\u00e9nieur provisionnant un entrep\u00f4t de donn\u00e9es ne choisit pas la classe d’instance dans un champ texte libre \u2014 il choisit parmi un petit ensemble pr\u00e9-approuv\u00e9. L’attachement r\u00e9seau externe n’est pas un choix possible car l’option n’est pas expos\u00e9e. Seuls les \u00e9l\u00e9ments d\u00e9finis dans .forms.yml<\/span> sont rempla\u00e7ables dans la configuration g\u00e9n\u00e9r\u00e9e ; tout le reste reste fix\u00e9 par la d\u00e9finition de la stack. Sous le capot, Terraform continue de tourner. La forme de ce que Terraform peut produire est simplement contrainte avant l’ex\u00e9cution.<\/span><\/p>\n Le compromis m\u00e9rite d’\u00eatre nomm\u00e9 clairement : sur-contraindre les inputs de stack pendant le Day 0 cr\u00e9e l’inflexibilit\u00e9 que les \u00e9quipes contournent via l’acc\u00e8s console et des changements hors bande. Sous-les contraindre recr\u00e9e la charge de revue que la plateforme \u00e9tait cens\u00e9e \u00e9liminer. Le bon calibrage est des inputs suffisamment born\u00e9s pour supprimer la revue manuelle du chemin standard mais suffisamment flexibles pour que les ing\u00e9nieurs n’aient pas besoin de contourner le syst\u00e8me pour faire un travail l\u00e9gitime.<\/span><\/p>\n <\/p>\n <\/p>\n Les d\u00e9cisions de structure organisationnelle sont des livrables Day 0 dans le mod\u00e8le de Cycloid : quelles \u00e9quipes partagent quelles stacks, quels d\u00e9p\u00f4ts de catalogue sont visibles par quelles organisations enfants, quelles credentials sont scop\u00e9es \u00e0 quels environnements.<\/span> Les stacks partag\u00e9es se propagent des organisations parentes aux organisations enfants, jamais l’inverse<\/span><\/a>. Pour une gouvernance optimale, les stacks partag\u00e9es doivent \u00eatre d\u00e9finies au niveau de l’organisation racine pour garantir un acc\u00e8s standardis\u00e9 et une maintenance rationalis\u00e9e. Une hi\u00e9rarchie de catalogue construite sans r\u00e9f\u00e9rence \u00e0 la structure organisationnelle r\u00e9elle signifie que des stacks finissent partag\u00e9es avec des \u00e9quipes qui n’y ont pas acc\u00e8s, ou isol\u00e9es des \u00e9quipes qui en ont besoin.<\/span><\/p>\n La visibilit\u00e9 par d\u00e9faut des stacks h\u00e9rite \u00e9galement du d\u00e9p\u00f4t de catalogue au moment de l’import et ne peut \u00eatre modifi\u00e9e r\u00e9troactivement par lot \u2014 seulement stack par stack. Mal configurer la hi\u00e9rarchie des catalogues au Day 0 signifie la r\u00e9-architecturer plus tard, une stack \u00e0 la fois.<\/span><\/p>\n <\/p>\n <\/p>\n Un Day 1 gouvern\u00e9 diff\u00e8re d’un Day 1 non gouvern\u00e9 d’une mani\u00e8re sp\u00e9cifique et mesurable : l’ing\u00e9nieur qui d\u00e9ploie l’environnement ne peut pas faire des choix qui violent la politique Day 0 parce que ces choix ne lui sont pas disponibles. La gouvernance n’est pas une porte \u00e0 la fin du workflow de provisionnement \u2014 elle est int\u00e9gr\u00e9e dans l’interface qu’il utilise.<\/span><\/p>\n Les m\u00e9canismes qui transportent les contraintes Day 0 jusqu’\u00e0 l’environnement provisionn\u00e9 sont ce qui distingue un IDP d’une collection de modules Terraform envelopp\u00e9s dans un formulaire web.<\/span><\/p>\n <\/p>\n <\/p>\n La relation m\u00e9canique entre le Day 0 et le Day 1 fonctionne ainsi : un StackForm lit le .forms.yml<\/span> d\u00e9fini dans le d\u00e9p\u00f4t de catalogue pendant le Day 0 et ne pr\u00e9sente que des inputs born\u00e9s et approuv\u00e9s \u00e0 l’ing\u00e9nieur qui d\u00e9ploie. Le Terraform sous-jacent s’ex\u00e9cute quand m\u00eame, mais la forme de ce qu’il peut produire est contrainte avant que l’ex\u00e9cution commence. Les ing\u00e9nieurs interagissent avec le formulaire \u2014 ils ne voient pas la sortie brute du plan Terraform et n’ont pas acc\u00e8s aux param\u00e8tres de configuration qui n’ont pas \u00e9t\u00e9 d\u00e9lib\u00e9r\u00e9ment expos\u00e9s.<\/span><\/p>\n Les d\u00e9finitions de stacks et la configuration runtime sont r\u00e9parties dans deux d\u00e9p\u00f4ts. Le d\u00e9p\u00f4t de catalogue contient la d\u00e9finition de stack (.cycloid.yml<\/span>, .forms.yml<\/span>, modules Terraform\/OpenTofu et pipelines). Le d\u00e9p\u00f4t de configuration stocke les inputs utilisateur captur\u00e9s via StackForms pour chaque environnement. Cette s\u00e9paration impose une fronti\u00e8re entre les auteurs de plateforme et les consommateurs de plateforme.<\/span><\/p>\n Le pipeline d\u00e9clench\u00e9 par la soumission d’un StackForm tourne sur la couche CI\/CD de Cycloid, construite sur Concourse et ex\u00e9cut\u00e9e par des workers Cycloid (des workers Concourse configur\u00e9s avec l’outillage Cycloid).<\/span><\/p>\n Les ing\u00e9nieurs platform<\/span><\/a> n’ont plus besoin de passer en revue chaque diff Terraform pour v\u00e9rifier que quelqu’un a choisi le bon module, la bonne classe d’instance ou le bon attachement r\u00e9seau. Ces choix ne sont tout simplement pas disponibles d\u00e8s le d\u00e9part. Les demandes de provisionnement standard cessent de g\u00e9n\u00e9rer du travail de revue parce que la plateforme a d\u00e9j\u00e0 pris les d\u00e9cisions contest\u00e9es.<\/span><\/p>\n <\/p>\n Les StackForms de Cycloid<\/span><\/a> s’int\u00e8grent \u00e9galement avec TerraCost pour afficher une estimation de co\u00fbt d’infrastructure en direct avant que l’ing\u00e9nieur ne valide la configuration. Cette estimation est visible au moment du provisionnement, et la configuration finale est \u00e9crite automatiquement dans le d\u00e9p\u00f4t de configuration Git. La visibilit\u00e9 des co\u00fbts au Day 1 pr\u00e9vient le probl\u00e8me Day 2 de d\u00e9couvrir des environnements sur-provisionn\u00e9s des semaines apr\u00e8s le d\u00e9ploiement quand la revue FinOps rattrape enfin.<\/span><\/p>\n <\/p>\n <\/p>\n Chaque configuration StackForm sauvegarde automatiquement les inputs utilisateur dans le d\u00e9p\u00f4t de configuration. L’\u00e9tat d\u00e9ploy\u00e9 dispose d’un historique Git tra\u00e7able d\u00e8s le moment de la cr\u00e9ation de l’environnement. La d\u00e9tection de d\u00e9rive au Day 2 n\u00e9cessite une v\u00e9rit\u00e9 terrain \u00e0 comparer \u00e0 l’\u00e9tat r\u00e9el de l’infrastructure \u2014 l’enregistrement de commit Git est cette v\u00e9rit\u00e9 terrain.<\/span><\/p>\n Les \u00e9quipes qui provisionnent en dehors du mod\u00e8le gouvern\u00e9 (modifications manuelles via la console, terraform apply<\/span> direct sans pipeline, commandes kubectl<\/span> ad hoc en production) cr\u00e9ent des environnements que l’outillage Day 2 ne peut pas r\u00e9concilier. Il n’y a pas d’enregistrement autoritatif de l’\u00e9tat souhait\u00e9, donc la d\u00e9tection de d\u00e9rive n’a rien \u00e0 mesurer. L’environnement existe, mais du point de vue de la plateforme, sa configuration est un myst\u00e8re.<\/span><\/p>\n <\/p>\n <\/p>\n Cycloid applique la gouvernance \u00e0 deux points distincts, qui servent des objectifs diff\u00e9rents. La premi\u00e8re couche est .forms.yml, qui contraint les inputs au moment du rendu du formulaire. Les ing\u00e9nieurs ne peuvent pas s\u00e9lectionner des valeurs hors des plages pr\u00e9d\u00e9finies parce que ces options ne sont jamais expos\u00e9es dans l’interface. C’est une application au niveau des inputs, pas une \u00e9valuation de politique.<\/span><\/p>\n La deuxi\u00e8me couche est InfraPolicies, \u00e9crites en Rego (le langage de politique d’Open Policy Agent) et \u00e9valu\u00e9es contre la sortie du plan Terraform ou OpenTofu avant l’apply. Ces politiques op\u00e8rent sur le graphe d’infrastructure enti\u00e8rement r\u00e9solu, pas sur l’input utilisateur. Chaque politique est assign\u00e9e un niveau de s\u00e9v\u00e9rit\u00e9 : Advisory, Soft Mandatory ou Hard Mandatory, suivant le m\u00eame mod\u00e8le d’application qu’HashiCorp Sentinel. Cette distinction est importante car elle s\u00e9pare la validation des inputs de l’application policy-as-code au stade du plan.<\/span><\/p>\n <\/p>\n <\/p>\n Le Day 2 est la phase la plus longue de loin, et celle o\u00f9 la dette de gouvernance accumul\u00e9e lors des jours 0 et 1 devient visible op\u00e9rationnellement. Chaque raccourci pris pendant la conception Day 0 et chaque contournement manuel accept\u00e9 pendant le provisionnement Day 1 se manifeste ici \u2014 sous forme de d\u00e9rive, de co\u00fbts inexpliqu\u00e9s, d’un environnement qui se comporte diff\u00e9remment de ce que sa d\u00e9finition de stack indique.<\/span><\/p>\n Le p\u00e9rim\u00e8tre du Day 2 est large : supervision, patching, mont\u00e9e en charge, gestion de la d\u00e9rive de configuration, rotation des secrets, mises \u00e0 jour d’environnement, optimisation des co\u00fbts et mise hors service. Le d\u00e9fi n’est pas de d\u00e9finir ce que le Day 2 inclut. C’est de s’assurer que le m\u00eame mod\u00e8le de gouvernance qui s’appliquait au provisionnement s’applique encore \u00e0 chacune de ces activit\u00e9s.<\/span><\/p>\n <\/p>\n <\/p>\n Cycloid ne fait pas tourner une boucle de r\u00e9conciliation continue comme les contr\u00f4leurs natifs Kubernetes tels que Flux ou Argo CD. La d\u00e9rive est plut\u00f4t remont\u00e9e lors de l’ex\u00e9cution du plan Terraform ou OpenTofu. InfraPolicies \u00e9value l’\u00e9tat planifi\u00e9 par rapport aux contraintes attendues, et les \u00e9carts caus\u00e9s par des modifications manuelles apparaissent comme des diff\u00e9rences de plan. La d\u00e9tection de d\u00e9rive est donc li\u00e9e aux \u00e9v\u00e9nements d’ex\u00e9cution plut\u00f4t qu’\u00e0 une r\u00e9conciliation continue. La plateforme repose sur une \u00e9valuation au moment du plan plut\u00f4t que sur un mod\u00e8le de contr\u00f4leur toujours actif \u2014 ce qui repr\u00e9sente un compromis op\u00e9rationnel diff\u00e9rent.<\/span><\/p>\n La d\u00e9tection de d\u00e9rive de Cycloid<\/span><\/a> alerte quand l’infrastructure d\u00e9ploy\u00e9e diverge de la configuration de stack versionn\u00e9e, donnant aux \u00e9quipes platform l’opportunit\u00e9 de r\u00e9aligner les \u00e9tats avant que la divergence ne se transforme en constat de conformit\u00e9 ou en incident.<\/span><\/p>\n Kubernetes amplifie consid\u00e9rablement la complexit\u00e9 Day 2. Un HorizontalPodAutoscaler mal configur\u00e9 peut provoquer des d\u00e9faillances en cascade sous charge. Les mises \u00e0 jour de cluster, la rotation des certificats et la maintenance des politiques RBAC n\u00e9cessitent une attention continue. Un seul HPA mal configur\u00e9 peut d\u00e9clencher des cha\u00eenes de d\u00e9faillance entre services difficiles \u00e0 retracer a posteriori. La gouvernance Day 2 pour Kubernetes signifie une r\u00e9conciliation continue de l’\u00e9tat du cluster par rapport \u00e0 la politique d\u00e9finie, pas des audits p\u00e9riodiques post-incident.<\/span><\/p>\n <\/p>\n <\/p>\n La lacune de gouvernance que la plupart des impl\u00e9mentations IDP laissent ouverte est visible dans le cycle de vie post-provisionnement. Le libre-service gouvern\u00e9 s’arr\u00eate \u00e0 la cr\u00e9ation. Monter en charge un environnement retombe dans un ticket. Mettre \u00e0 jour un chart Helm se g\u00e8re avec une commande helm upgrade<\/span> directe depuis une machine locale. D\u00e9commissionner un service devient une s\u00e9rie non document\u00e9e de suppressions manuelles dans trois consoles cloud.<\/span><\/p>\n Cycloid s’int\u00e8gre avec HashiCorp Vault pour la gestion des credentials, qui sous-tend les workflows de rotation des secrets d\u00e9crits dans les op\u00e9rations Day 2.<\/span> Les mises \u00e0 jour suivent des workflows de pipeline d\u00e9finis. La mise hors service applique la v\u00e9rification de propri\u00e9t\u00e9 et les r\u00e8gles de nettoyage avant la suppression des ressources. La gouvernance reste coh\u00e9rente sur l’ensemble du cycle de vie, pas seulement \u00e0 la cr\u00e9ation. Quand les op\u00e9rations Day 2 sont trait\u00e9es comme des actions platform de premi\u00e8re classe plut\u00f4t que comme du travail hors bande, la gouvernance reste appliqu\u00e9e sans ajouter de nouvelles boucles de revue.<\/span><\/p>\n <\/p>\n <\/p>\n Le FinOps d’observation et le FinOps op\u00e9rationnel sont deux disciplines diff\u00e9rentes avec des r\u00e9sultats diff\u00e9rents. Un tableau de bord montrant ce qui a \u00e9t\u00e9 d\u00e9pens\u00e9 le mois dernier vous indique ce qui s’est pass\u00e9. Des plafonds budg\u00e9taires attach\u00e9s \u00e0 chaque environnement emp\u00eachent le sur-provisionnement de se produire en premier lieu.<\/span><\/p>\n <\/p>\n Le module GreenOps de Cycloid<\/span><\/a> s’appuie sur le projet open-source Cloud Carbon Footprint, int\u00e9gr\u00e9 dans sa couche de gestion des co\u00fbts cloud FinOps. Les estimations carbone sont d\u00e9riv\u00e9es parall\u00e8lement aux donn\u00e9es de co\u00fbt, en utilisant les m\u00eames inputs d’infrastructure. <\/span>Les ing\u00e9nieurs voient le co\u00fbt estim\u00e9 g\u00e9n\u00e9r\u00e9 depuis le plan Terraform ou OpenTofu avant l’apply. TerraCost analyse le JSON du plan et produit une estimation de co\u00fbt au m\u00eame stade o\u00f9 InfraPolicies est \u00e9valu\u00e9.<\/span> Les plafonds budg\u00e9taires emp\u00eachent la cr\u00e9ation de ressources hors des plages de co\u00fbt approuv\u00e9es, plut\u00f4t que de les signaler pour rem\u00e9diation apr\u00e8s que la d\u00e9pense a d\u00e9j\u00e0 eu lieu.<\/span><\/p>\n L’implication GreenOps suit directement : le calcul sur-provisionn\u00e9 g\u00e9n\u00e8re des \u00e9missions carbone sur-provisionn\u00e9es. Cycloid suit les donn\u00e9es d’empreinte carbone filtr\u00e9es par projet, r\u00e9gion, date et fournisseur depuis le m\u00eame module qui g\u00e8re les donn\u00e9es de co\u00fbt. Le co\u00fbt environnemental des d\u00e9cisions d’infrastructure est expos\u00e9 au m\u00eame point de d\u00e9cision que le co\u00fbt financier \u2014 au moment du provisionnement, avant que l’environnement n’existe.<\/span><\/p>\n <\/p>\n <\/p>\n L’Asset Inventory de Cycloid n’est pas une liste passive de ressources. Il est aliment\u00e9 via le backend HTTP Terraform de Cycloid, o\u00f9 l’\u00e9tat Terraform ou OpenTofu est stock\u00e9 via un token JWT (inventory_jwt<\/span>). Les ressources flux dans l’inventaire directement depuis l’\u00e9tat, en faisant l’enregistrement autoritatif de l’infrastructure g\u00e9r\u00e9e. Cycloid expose \u00e9galement un CLI (cycloid-cli<\/span>) et un provider Terraform (cycloidio\/cycloid<\/span>), permettant aux \u00e9quipes platform de g\u00e9rer les ressources Cycloid de fa\u00e7on programmatique.<\/span><\/p>\nCe qui appartient au Day 0, Day 1 et Day 2<\/b><\/h3>\n
![\"\"](\"https:\/\/www.cycloid.io\/wp-content\/uploads\/2026\/05\/Cycloid-info-16.png\")
<\/p>\nPourquoi les files de revue manuelle s’effondrent \u00e0 100+ ing\u00e9nieurs<\/b><\/h3>\n
Comment la d\u00e9rive de configuration entre dans les environnements de production<\/b><\/h3>\n
![\"\"](\"https:\/\/www.cycloid.io\/wp-content\/uploads\/2026\/05\/Cycloid-info-15.png\")
<\/p>\nOp\u00e9rations Day 0 : RBAC, topologie r\u00e9seau et d\u00e9cisions IaC avant le provisionnement<\/b><\/h2>\n
D\u00e9cisions Day 0 difficiles \u00e0 modifier ult\u00e9rieurement<\/b><\/h3>\n
Comment .forms.yml applique la conformit\u00e9 au moment du provisionnement<\/b><\/h3>\n
![\"\"](\"https:\/\/www.cycloid.io\/wp-content\/uploads\/2026\/05\/Cycloid-info-13.png\")
<\/p>\nHi\u00e9rarchie des catalogues et h\u00e9ritage RBAC dans les organisations enfants<\/b><\/h3>\n
Provisionnement Day 1 : comment StackForms applique la politique Day 0 au d\u00e9ploiement<\/b><\/h2>\n
Comment StackForms lit .forms.yml pour contraindre les inputs Terraform<\/b><\/h3>\n
![\"\"](\"https:\/\/www.cycloid.io\/wp-content\/uploads\/2025\/02\/4040-\u2014-Cost-estimation@3x_0-1.png\")
<\/p>\nPourquoi les configs StackForm sauvegard\u00e9es dans Git sont la source de v\u00e9rit\u00e9 pour la d\u00e9tection de d\u00e9rive<\/b><\/h3>\n
\u00c9valuation des politiques avant apply : bloquer les violations avant terraform apply<\/b><\/h3>\n
Op\u00e9rations Day 2 : d\u00e9tection de d\u00e9rive, gouvernance des co\u00fbts et gestion du cycle de vie<\/b><\/h2>\n
Comment la d\u00e9tection de d\u00e9rive r\u00e9concilie l’\u00e9tat d\u00e9ploy\u00e9 avec les d\u00e9finitions de Stack<\/b><\/h3>\n
![\"\"](\"https:\/\/www.cycloid.io\/wp-content\/uploads\/2026\/05\/Cycloid-info-14.png\")
<\/p>\nGouverner la mont\u00e9e en charge Day 2, les mises \u00e0 jour Helm et la mise hors service via les pipelines<\/b><\/h3>\n
Estimation des co\u00fbts avant d\u00e9ploiement avec TerraCost (et suivi carbone GreenOps)<\/b><\/h3>\n
![\"\"](\"https:\/\/www.cycloid.io\/wp-content\/uploads\/2026\/03\/cycloid-costcontrol.png\")
<\/p>\nL’outillage plateforme qui couvre les trois phases : Stacks, StackForms, Asset Inventory et InfraView ensemble<\/b><\/h2>\n
![\"\"](\"https:\/\/www.cycloid.io\/wp-content\/uploads\/2025\/07\/asset_inventory-1.png\")
<\/p>\n