Le cadran d'autonomie

La crainte qui fausse la conception

L'objection la plus courante à la remédiation autonome n'est pas de la paranoïa. C'est de la reconnaissance de schémas. La plupart des dirigeants de plateformes ont, à un moment ou à un autre, vu un outil d'automatisation s'emballer : un script qui a mis une région hors service, un processus fournisseur qui a touché le mauvais cluster, un système de remédiation dont l'équipe de soutien n'a pas su expliquer après coup ce qui s'était réellement passé. Les cicatrices laissées par ces incidents façonnent la façon dont les équipes sérieuses évaluent toute plateforme qui propose d'agir sur l'infrastructure de production.

La bonne réponse à ces cicatrices n'est pas de promettre que cela n'arrivera jamais. Tout système qui touche à la production finit par casser quelque chose, et un fournisseur qui prétend le contraire n'a soit jamais opéré à grande échelle, soit n'est pas honnête. La bonne réponse consiste à concevoir le modèle d'autonomie de manière à ce que, lorsque quelque chose tourne mal, le rayon d'impact soit borné et la récupération rapide, et à laisser le client décider dès le départ de l'ampleur de l'autonomie à accorder.

L'autonomie n'est pas binaire

L'erreur que commettent la plupart des plateformes de remédiation autonome est de traiter l'autonomie comme un interrupteur. Soit la plateforme agit sur l'infrastructure du client, soit elle n'agit pas. Le problème avec ce cadre, c'est que les environnements de production ne sont pas homogènes. Un cluster de développement, un environnement de préproduction et une charge de travail de production essentielle aux revenus ont des tolérances radicalement différentes à l'action autonome. Un modèle qui applique la même posture d'autonomie à tous ces environnements se trompe pour au moins deux des trois, peu importe la position de l'interrupteur.

L'architecture qui résout ce problème consiste à traiter l'autonomie comme une enveloppe configurable plutôt qu'un paramètre global. Le client décide quels paliers d'environnement peuvent se déployer automatiquement et lesquels nécessitent une approbation humaine. Il définit quels seuils de dépenses ou de risque déclenchent une escalade. Il précise quelles charges de travail ne sont jamais touchées sans autorisation explicite, et qui sont les approbateurs pour chaque catégorie de changement. La posture d'autonomie s'harmonise avec la gouvernance que l'équipe de plateforme applique déjà aux changements pilotés par des humains, parce que le modèle de risque sous-jacent est le même.

C'est le modèle selon lequel Jetscale fonctionne. Chaque changement passe par le pipeline de gestion des changements déjà en place chez le client : plan et apply Terraform, Git, CI/CD, promotion entre environnements, les propres portes d'approbation du client. La plateforme ne dépasse jamais ces garde-fous pour toucher directement à l'infrastructure; elle génère la pull request qui y entre. Cela signifie que chaque mécanisme de sécurité auquel l'équipe fait déjà confiance (révision du plan, essai à blanc, déploiement progressif, fenêtres de changement, limites de rayon d'impact) entre en jeu par défaut. L'action autonome, dans cette conception, signifie génération autonome de PR. Le fait qu'une PR se fusionne automatiquement ou attende un humain est une politique que le client rédige, et non un comportement livré par le fournisseur.

Une récupération sur des rails déjà éprouvés par l'équipe

La question de fond que se posent les acheteurs n'est pas se trompera-t-elle un jour? C'est que se passe-t-il quand cela arrive? La réponse qui rend l'autonomie défendable, c'est que la récupération emprunte les mêmes rails que tout autre retour en arrière d'infrastructure : revert Git, retour en arrière Terraform, revue post-incident sur la même piste d'audit que l'équipe utilise déjà pour tout autre changement.

Parce que chaque action de Jetscale est un commit Git, chaque action est réversible par les ingénieurs qui savent déjà comment faire un revert. Il n'y a pas de procédure de récupération distincte à apprendre, pas de billet de soutien à ouvrir chez le fournisseur, pas de processus opaque à naviguer pendant que la production est dégradée. L'étape Surveiller de la boucle Recommander, Déployer, Surveiller, Apprendre guette les régressions après le déploiement et, au palier autonome, peut déclencher un retour en arrière automatisé avant même qu'un humain ne soit alerté. Le délai moyen de récupération est borné par des outils que l'équipe utilise déjà, pas par le temps de réponse d'un fournisseur.

Mériter d'augmenter le cadran

Le modèle qui fonctionne pour l'infrastructure autonome est celui de la confiance progressive. Commencez avec le cadran à zéro : chaque changement exige une révision et une approbation humaines. Observez comment la plateforme se comporte dans votre environnement. Évaluez la qualité des recommandations, le respect des politiques, le taux de régression. À mesure que la confiance s'accumule, élargissez l'enveloppe d'autonomie : déploiement automatique en développement, puis en préproduction, puis dans les paliers de production à moindre risque, en gardant les charges de travail les plus sensibles sous approbation humaine explicite indéfiniment, si c'est ce qu'exige la gouvernance.

L'objectif n'est pas l'autonomie maximale pour elle-même. C'est une posture d'autonomie qui correspond à la tolérance au risque réelle de chaque environnement. Certaines équipes opteront pour une automatisation poussée sur la majeure partie de leur parc. D'autres maintiendront indéfiniment une approbation humaine aux couches les plus sensibles. Les deux sont des configurations valides de la même plateforme, car les deux reflètent des décisions éclairées sur les endroits où l'autonomie ajoute un effet de levier et ceux où elle ajoute du risque.

Une infrastructure autonome bien conçue n'est pas un saut dans le vide. C'est un cadran que le client tourne lui-même, sur des rails auxquels il fait déjà confiance, avec des procédures de récupération qu'il connaît déjà.