Le théâtre de l'humain dans la boucle
Le faux débat que les équipes continuent d'avoir : automatisation complète versus contrôle manuel complet.
Les équipes hautement performantes ne font ni l'un ni l'autre. Elles automatisent l'exécution déterministe et réservent les décisions humaines aux limites de risque où le jugement modifie matériellement le résultat.
La question n'est pas "les humains devraient-ils être impliqués ?" C'est "où un humain améliore-t-il réellement la décision ?"
L'examen humain ajoute une réelle valeur lorsque :
- Il y a un compromis de risque ambigu
- Une exception de politique est gérée
- Un conflit de priorité inter-équipes nécessite une résolution
- Un incident ayant un impact sur le client est en contexte
Cela n'ajoute pas de valeur pour les vérifications déterministes répétitives qui ont déjà des critères explicites de réussite/échec. Demander des approbations là ne fait pas augmenter la sécurité - cela augmente le temps d'attente.
Définissez les limites d'approbation comme des décisions d'architecture, et non des habitudes. La promotion en production, les dérogations aux contrôles de sécurité, les exceptions temporaires de politique, les contournements de rollback d'urgence - ce sont les vraies limites. Tout le reste devrait être piloté par le workflow.
En 2025 et 2026, une autre limite appartient à cette liste : les changements de confiance en amont.
Si un workflow introduit une nouvelle action tierce, modifie une action d'un épinglage de SHA de commit à une balise mutable, étend la portée du jeton du runner, ou ouvre un nouveau chemin d'exécution porteur de secrets, ce n'est pas une modification de plomberie de routine. C'est un événement de gouvernance. Traitez-le comme tel.
Trois états de gouvernance :
- Succès : toutes les portes automatisées requises ont réussi
- Blocage : porte requise échouée ou violation de politique stricte
- Escalade : preuves automatisées insuffisantes ; décision humaine requise
Lorsque l'escalade est nécessaire, le transfert doit être compact : ce qui a échoué, quelles portes sont impactées, liens vers les preuves, risque opérationnel, options recommandées. Pas de dumps de logs. Les réviseurs ont besoin d'aide à la décision, pas d'archéologie.
Le signe avant-coureur que quelque chose ne va pas : la gouvernance de l'ombre. Des ingénieurs disant "nous avons eu une approbation verbale" sans artefact. Des décisions de réexécution manuelles non reflétées dans les enregistrements de workflow. Des critères de décision différents selon les équipes. Si cela se produit, votre modèle de gouvernance n'est pas suffisamment encodé.
Ne passez pas directement des opérations manuelles à l'autonomie complète. Bâtissez la confiance par les preuves :
- Mode observation - le workflow recommande, les humains décident.
- Mode assisté - le workflow exécute automatiquement les portes à faible risque, les humains approuvent aux limites.
- Autonomie gouvernée - le workflow gère la plupart des chemins, escalade les exceptions définies.
Les récents incidents de la chaîne d'approvisionnement rendent cette progression encore plus importante. Les équipes qui passent directement à "l'automatisation sait quoi faire" découvrent généralement trop tard que l'automatisation exécute aussi joyeusement des dépendances empoisonnées, des balises contrôlées par des attaquants, ou des versions de mainteneur compromises si personne n'a encodé la limite de confiance dans le code source.
Ce que nous avons construit chez Kolsetu : la gouvernance est compilée, non imposée par convention. allow_default_branch=false fait échouer l'exécution si quelqu'un déclenche l'orchestration depuis main ou master - pas d'exceptions, pas de dérogations verbales. Chaque porte se résout en l'un des trois états explicites : passed (réussi), skipped-by-input (ignoré par l'entrée), ou failed (échoué). strict_full_plan=true fait échouer l'exécution si une porte définie ne se résout pas à un état explicite - pas de réussites silencieuses. L'escalade inclut toujours un paquet structuré : ce qui a échoué, quelles portes sont impactées, liens vers les preuves, options recommandées. Le paquet est non négociable, car sans lui, l'escalade devient une alarme incendie sans adresse.
Observabilité conçue pour une seule tâche
Les workflows agentiques sont souvent introduits comme une "automatisation plus intelligente".
Opérationnellement, ils se comportent comme des systèmes distribués - plusieurs étapes, dépendances asynchrones, échecs partiels, réessais, timeouts, transferts humains.
Si votre modèle d'observabilité suppose une seule tâche linéaire, la gestion des incidents sera lente. Et si vous avez construit les portes 8 à 11 de la Partie 2 (couverture linguistique, métriques système, intégrité des enregistrements, hygiène des logs), vous avez déjà créé exactement ce type de dépendance d'état distribué. Les évaluations de couverture linguistique, par exemple, couvrent plusieurs appels, plusieurs langues, un contexte au niveau de la session. Il n'y a pas une seule ligne de log qui vous dit que cela a réussi.
Observez quatre couches :
- Couche d'orchestration - événements de dispatch, transitions de portes, timing
- Couche d'exécution des workers - exécutions de portes individuelles, entrées utilisées, sorties produites
- Couche de sortie/mutation - ce qui a réellement changé et quand
- Couche de décision de gouvernance - décisions de succès/blocage/escalade et leurs preuves
Pour chaque exécution, capturez : l'identité de l'exécution et les ID de corrélation, les transitions de portes avec horodatages, les événements de dispatch et de complétion, les références et hachages d'artefacts, les opérations de sortie effectuées, l'état de décision final et la raison.
Et pour tout workflow pouvant toucher des secrets, des builds, des packages ou des chemins de déploiement, capturez également les preuves de confiance : quels SHA d'action ont réellement été exécutés, quelles versions de package ont été résolues, quels hôtes externes ont été contactés, quelles portées de jetons ont été utilisées, et si l'exécution a franchi une limite d'approbation.
Sans cela, les réessais sont aveugles et les audits sont coûteux.
Construisez pour la relecture, pas seulement pour le réessai.
Le réessai est utile lorsque l'échec transitoire est probable. La relecture est essentielle lorsque vous avez besoin de confiance dans l'analyse causale - réexécuter un segment avec les mêmes entrées, contraintes et contexte de politique pour comprendre pourquoi quelque chose a échoué, et pas seulement qu'il a échoué.
"Ça marche maintenant, on ne sait pas pourquoi" n'est pas un état de récupération acceptable.
Classifiez les échecs de manière cohérente : échec d'entrée, échec de politique, échec de dépendance, échec logique, échec de sortie. Cette classification doit figurer dans vos résumés et alertes.
Ce compartiment d'échec de dépendance n'est plus théorique. Il couvre désormais exactement les scénarios qui continuent de nuire aux équipes : une balise d'action compromise, un artefact de version empoisonné, un accès mémoire suspect du runner, ou un trafic sortant inattendu lors d'une étape de build qui "installe habituellement juste des outils".
Les alertes doivent être exploitables en moins d'une minute : nom de la porte, classe d'échec, ID de corrélation, lien direct vers l'exécution, première action suggérée, et tout signal de confiance anormal (nouvelle destination réseau, dépendance non épinglée, changement de portée de jeton, ou chemin d'exécution inattendu). Si une alerte n'aide pas un ingénieur à faire le premier pas en moins de 60 secondes, elle est incomplète.
Après chaque incident significatif, demandez : cela aurait-il pu être évité par des règles source ? L'échec a-t-il été signalé au bon stade ? Quel champ d'instrumentation unique aurait raccourci le diagnostic ? Codifiez la réponse dans le code source et les tests. Pas en mémoire.
Ce que nous avons construit chez Kolsetu : chaque porte dans le résumé de pré-fusion inclut le nom du workflow, l'ID d'exécution, l'URL d'exécution et le statut. Les entrées de repli des portes sont enregistrées afin que les réviseurs voient ce que l'orchestration a réellement utilisé, et non seulement ce qui a été passé. Lorsque la relecture est nécessaire, les entrées exactes, les contraintes et l'ordre d'exécution des portes sont fixés au moment de la compilation dans le fichier source .md - non reconstruits à partir de la mémoire. Le mode d'échec est explicite : "Arrêter immédiatement à la première défaillance majeure et produire un rapport d'échec concis avec les URL d'exécution et l'action suivante."
Opérationnellement, la leçon de la dernière vague de compromissions de la chaîne d'approvisionnement est simple : si vous ne pouvez pas répondre rapidement à la question "quel code amont exact a été exécuté, avec quelles permissions, et avec quoi a-t-il essayé de communiquer ?", alors votre observabilité n'est pas prête pour l'automatisation en production.
Mesurer l'activité au lieu des résultats
La plupart des équipes mesurent les mauvaises choses :
- Nombre de workflows créés
- Nombre d'exécutions d'agents
- Réduction des commentaires manuels
Ce sont des métriques d'activité. La vraie question est de savoir si la vitesse de livraison s'est améliorée tout en maintenant la qualité et le contrôle.
Modèle de métriques à trois couches :
Couche 1 - Performance de livraison :
- Délai de fusion
- Temps entre la PR prête et la décision finale
- Temps d'attente aux limites de gouvernance
Couche 2 - Qualité et fiabilité :
- Défauts échappés liés aux échecs du processus de fusion
- Taux de réouverture/annulation pour les changements fusionnés
- Fréquence de réexécution des portes échouées
Couche 3 - Risque et gouvernance :
- Taux de violation de politique
- Taux de blocage de détection de menaces
- Taux d'intervention humaine par catégorie
- Nombre d'approbations d'exceptions
Utilisez des indicateurs avancés et retardés. Les avancés (stabilité de passage des portes, défauts d'ambiguïté des invites, latence alerte-action) pour diriger rapidement. Les retardés (taux d'incidents, temps moyen de récupération, confiance des parties prenantes dans la préparation de la fusion automatisée) pour valider la direction.
Établissez une base de référence avant le déploiement : délai de décision de fusion des 30 jours précédents, nombre de points de contact manuels existants, profil d'incidents de la version actuelle. Mesurez à 30/60/90 jours après l'adoption. Cela permet une comparaison équitable et évite les rapports basés sur la narration.
Lorsque les performances s'améliorent, demandez ce qui les a motivées. Conception du workflow ? Changement de comportement de l'équipe ? Volume réduit ? Stabilisation de l'environnement ? N'attribuez pas tout au workflow agentique.
Après 90 jours, un "bon" résultat ressemble à :
- Latence de décision de fusion plus faible
- Moins d'étapes de transfert manuel
- Profil de défauts/annulations stable ou amélioré
- Limites claires pour l'escalade humaine
- Meilleure auditabilité des décisions de publication
Le seul problème ? Si la vitesse s'améliore mais que les signaux de risque se dégradent, vous n'avez pas résolu le problème. Vous l'avez rendu plus rapide à créer.
Et c'est exactement ce que ces incidents récents ont révélé. Beaucoup d'équipes avaient des pipelines rapides. Elles n'avaient pas de pipelines fiables.
Ce que nous avons construit chez Kolsetu : la porte de pré-fusion se termine par un rapport de couverture - 11 portes, chacune avec un statut explicite (réussi / ignoré / échoué). Après 90 jours, nous savons exactement quelles portes échouent le plus souvent, lesquelles sont les plus lentes, et où les réessais se regroupent. Le signal n'est pas "combien de workflows ont été exécutés" - c'est "combien de branches ont passé les 11 portes sans réessai". C'est ce qui est corrélé à la stabilité de la production.
La liste de contrôle complète de la série - les 8 fondations :
- Graphe de portes explicite
- Logique de workflow gérée par source/compilation
- Contrôles de sécurité natifs, non ajoutés après coup - incluant des références immuables, des permissions strictes et des limites de confiance explicites
- Responsabilités d'orchestration et de worker séparées
- Invites écrites comme des protocoles
- Approbations humaines basées sur des limites, non habituelles
- Observabilité rejouable
- Mesurer les résultats, pas l'activité
Boom. Si vous pouvez répondre oui à ces huit points, votre programme de workflow agentique fonctionne comme un système d'ingénierie, et non comme une démo.
Pour en savoir plus :
Virendra Singh Bhalothia
