Votre gouvernance IT a été conçue pour du logiciel qui ne change pas. Les agents changent chaque jour.
Vous avez déjà une gouvernance IT, et elle est bonne à ce pour quoi elle a été construite : du logiciel déterministe, des releases sous contrôle du changement, la même entrée produisant la même sortie. Elle vous a bien servi pendant des décennies, et l'instinct de l'étendre aux agents est raisonnable.
Sauf qu'un agent n'est rien de ce que cette gouvernance suppose. Il est probabiliste, il dérive à chaque mise à jour de modèle, et il agit sur du contexte vivant qu'aucune note de release ne capte. Plaquer un contrôle du changement conçu pour du code figé sur quelque chose qui change chaque jour ne tient pas, et prétendre le contraire, c'est ainsi qu'un projet qui a l'air gouverné produit un système ingouvernable.
L'erreur n'est pas que la gouvernance IT soit faible. C'est que vous lui demandez de répondre à une question qu'elle n'a jamais été conçue pour poser. Le contrôle du changement demande « qu'est-ce qui a changé, qui l'a approuvé, et quand l'avons-nous livré ? ». Cette question n'a pas de réponse quand le changement est une mise à jour de modèle que vous n'avez pas livrée et que le comportement a bougé tout seul.
L'unité de gouvernance doit changer
La gouvernance déterministe gouverne des releases. La gouvernance des agents doit gouverner des décisions.
Cela ressemble à une subtilité. C'est tout l'enjeu. Dans un monde centré sur la release, une fois un build testé et livré, chaque exécution de ce build est supposée correcte parce que le build est correct. L'unité que vous signez est la release, et la release est stable.
Un agent n'a pas de release stable à signer. Deux exécutions du même agent sur le même document peuvent diverger, et le modèle derrière lui peut être différent la semaine prochaine. Ce que vous gouvernez ne peut donc pas être le build. Ce doit être chaque décision que l'agent prend : ce qu'il a décidé, sous quelle autorité, sur quelles entrées, et contre quelle politique. La gouvernance passe d'un gate qu'on franchit une fois à une discipline qui tourne en continu, sur chaque décision, pendant toute la vie du système.
Ce n'est pas un PDF de politique. C'est un contrôle d'ingénierie, avec un propriétaire et une piste d'audit.
Les agents gagnent leur autonomie, ils ne démarrent pas avec
Le mécanisme central est l'autonomie graduée. Un agent ne démarre pas autonome. Il gravit une échelle, et les evals, les tests qui mesurent s'il franchit un seuil, sont le gate de confiance à chaque barreau.
| Barreau | Rôle | Ce que cela veut dire | Exemple |
|---|---|---|---|
| Ombre | L'agent observe | Il propose, n'agit jamais. Les evals de référence fixent le seuil. | Il rédige la note de crédit ; une personne écrit celle qui part. |
| Supervisé | Humain dans la boucle | Il n'agit qu'après approbation humaine de chaque étape. | Il prépare le paiement ; une personne clique sur approuver. |
| Guidé | Humain sur la boucle | Il agit de façon autonome ; les personnes traitent les exceptions. | Il fait l'entrée en relation de bout en bout ; les personnes revoient les cas signalés. |
| Total | Autonome | Il tourne de bout en bout dans un rayon d'action borné et documenté. | Il rapproche les grands livres la nuit ; les décisions à conséquence exigent toujours un visa. |
Lisez l'échelle attentivement, parce que deux propriétés en font plus qu'un tableau de maturité.
D'abord, un barreau se gagne, il ne se planifie pas. L'agent monte seulement quand il franchit le seuil d'evals du niveau suivant, et le seuil est fixé à l'avance, sur la référence propre au processus. C'est l'inverse d'un plan de lancement qu'on presse pour tenir une date.
Ensuite, un barreau se perd automatiquement. Si la surveillance de la dérive détecte que la performance est sortie du seuil, l'agent est rétrogradé sans attendre qu'une personne le remarque. L'autonomie n'est pas une permission accordée une fois puis oubliée. C'est un état que le système doit continuellement justifier.
À mesure que l'agent fait ses preuves, les personnes passent d'approbateurs à traiteurs d'exceptions. C'est un gain d'efficacité réel, et il est borné par la responsabilité, par conception. La matrice d'autonomie et le kill-switch sont documentés, testés, et portent un journal de dérogation immuable. Le rayon d'action d'un agent « Total » n'est pas « tout ce qu'il décide de faire ». C'est un périmètre borné et écrit, avec les décisions à conséquence toujours routées vers une personne.
Les evals sont le seuil de confiance, pas une case cochée au lancement
Le mot « eval » est utilisé de façon lâche, il vaut donc la peine d'être concret sur ce qu'il fait ici.
Un eval n'est pas un test de recette unique qu'on exécute avant la mise en service puis qu'on archive. C'est la mesure permanente qui décide, en continu, si l'agent mérite l'autonomie qu'il détient. C'est ce qui convertit « on pense que ça marche » en « il a franchi le seuil à 09h14 aujourd'hui, et voici le score qui a autorisé ce barreau ».
Cela compte parce que les systèmes probabilistes se dégradent en silence. Une mise à jour de modèle améliore un comportement et en régresse un autre. Un déplacement de la distribution d'entrée, de nouveaux formats de documents, un nouveau motif de fraude, éloigne l'agent des cas sur lesquels il a été validé. Sans eval vivant et surveillance de la dérive, rien de cela n'est visible avant d'atteindre un client ou un régulateur. Avec eux, la rétrogradation est automatique et l'enregistrement montre exactement quand et pourquoi.
Evals plus surveillance de la dérive, c'est ce qui vous permet de dire la phrase qu'un comité des risques a besoin d'entendre : l'autorité de l'agent n'est pas supposée, elle est mesurée, et elle est révoquée dès que la mesure baisse.
Cela se place à côté de votre gouvernance IT, pas au-dessus
L'objectif n'est pas de remplacer ITIL. C'est de nommer les responsabilités si proprement que personne ne suppose que l'autre couche couvre une brèche.
| Sujet | Votre gouvernance IT | Gouvernance des agents |
|---|---|---|
| Releases déterministes, infra, accès | Elle en est propriétaire | Elle la consomme |
| Dérive du modèle et du comportement, au jour le jour | Pas conçue pour | Elle en est propriétaire (evals, surveillance de la dérive) |
| Preuves par décision | Pas son unité de travail | Elle en est propriétaire (piste de preuves) |
| Autonomie et rayon d'action | Sans objet | Elle en est propriétaire (échelle, kill-switch) |
Votre gouvernance IT continue de faire ce qu'elle fait excellemment : infrastructure, accès, releases déterministes. La couche de gouvernance des agents se place à côté et prend en charge ce que la gouvernance déterministe n'a jamais été construite pour tenir : la dérive, les preuves par décision et l'échelle d'autonomie. Deux systèmes, des coutures propres, aucune couverture supposée.
Le mode d'échec à éviter est le silencieux : un projet qui a l'air gouverné parce qu'il est passé par le comité de changement habituel, et qui est ingouvernable en pratique parce que ce comité n'a aucun moyen de voir une mise à jour de modèle ou de mesurer la dérive. Il a passé le mauvais gate.
La question à apporter à votre prochaine revue n'est donc pas « est-ce passé par le contrôle du changement ? ». C'est : pour un système qui change chaque jour, qui est propriétaire de la dérive, où sont les preuves par décision, et pouvons-nous rétrograder un agent automatiquement dès qu'il sort de son seuil ? Si la réponse honnête est « notre processus de release suppose qu'il reste testé », vous n'avez pas encore de gouvernance des agents. Vous avez une gouvernance déterministe pointée sur un système probabiliste, et les deux ne vont pas ensemble.
Si vous voulez voir à quoi ressemble une autonomie gagnée sur l'un de vos processus, prenez rendez-vous.