Quand l’IA passe de répondre aux questions à faire le travail, la ressource rare n’est plus un meilleur modèle. C’est une personne prête à répondre de ce que ce travail devient.

Un exemple résume le problème. Un agent de support rédigeait des réponses de remboursement à partir d’une politique qui avait changé un trimestre plus tôt. Les réponses étaient fluides, rapides et fausses, et elles sont parties pendant des semaines avant qu’une réclamation client pousse quelqu’un à regarder. L’agent n’était pas en panne. Il faisait exactement ce qu’on lui avait demandé, bien après que ce qu’on lui avait demandé avait cessé d’être vrai, et personne ne l’a remarqué parce que ce n’était le travail de personne.

La panne est silencieuse

On imagine un agent IA qui déraille comme un incident bruyant : une affirmation fausse, une action destructrice. Cela arrive. Mais la panne qui coûte le plus est silencieuse. Un agent intégré à un vrai processus n’annonce pas le moment où il cesse d’être utile. Il continue de livrer à l’heure, bien formaté, impossible à distinguer d’un travail encore bon. Un système en panne le signale ; un système qui dérive ne dit rien, et s’éloigne de la réalité tout en produisant ce qui ressemble à du progrès.

L’écart ne reste pas stable après le déploiement. Il se creuse, parce que la politique, les sources et le code continuent de bouger alors que l’image qu’en a l’agent reste figée. Un agent sans propriétaire est un problème de maintenance que personne n’a accepté de maintenir.

Le test : quand un agent devient du travail

La règle doit être assez simple pour s’appliquer sans réunion. Un système a besoin d’un propriétaire dès qu’il :

lit un contexte qui compte ;
produit un travail sur lequel quelqu’un agit ;
touche un processus dont d’autres personnes dépendent.

Le seuil, c’est la conséquence, pas l’autonomie. Un assistant qui se contente de rédiger le document avec lequel une équipe entre en réunion a déjà franchi la ligne, puisque l’équipe agit sur ce qu’il produit. Débattre de savoir si c’est « vraiment » un agent ou seulement un assistant revient surtout à repousser la question opérationnelle.

Ce que veut dire en être propriétaire

Être propriétaire ne veut pas dire avoir construit l’agent ni comprendre le modèle. Cela veut dire qu’une personne identifiable répond de la qualité du travail délégué : elle sait ce que l’agent lit, ce qu’il peut toucher, à quoi ressemble un bon résultat, où il a tendance à se tromper, et quand il faut le mettre en pause ou le retirer. Le test est simple : quelqu’un remarquerait-il, et agirait-il, si le travail commençait à se dégrader ?

Nous le faisons déjà partout ailleurs. Un tableau de bord a un propriétaire dès que des décisions en dépendent, tout comme le script qui déploie le produit. Un agent mérite le même statut dès que ce qu’il produit devient une entrée d’un vrai travail.

Équipes et chaînes d’agents

Dans une équipe, l’outil partagé finit souvent par n’appartenir à personne. La correction consiste à faire suivre la responsabilité au travail : l’équipe qui vit avec les conséquences d’un résultat est la mieux placée pour voir qu’il se dégrade. Dans une chaîne d’agents, il est tentant de considérer le framework comme responsable. Mais un framework, c’est de la plomberie : il fait circuler le travail, il n’en répond pas.

Pourquoi la gouvernance ne suffit pas

Les cadres de sécurité et de gouvernance progressent, et c’est une bonne chose. Mais un comité peut décider qu’un agent de support a le droit de lire tel système ; il ne peut pas savoir si la politique de remboursement dans ses sources intègre l’exception validée la semaine dernière. Un comité doit porter les standards, les plateformes et l’analyse des incidents. L’attention continue, au plus près du domaine, doit reposer sur une personne.

La fiche du propriétaire

La forme concrète tient sur une page. Pour l’agent de remboursement :

Agent :          Rédaction des réponses de remboursement (support)
Propriétaire :   Responsable d’équipe support
Suppléant :      Agent de support senior
Mission :        Rédiger un premier jet pour relecture humaine. Ne jamais envoyer.
Lit :            Politique de remboursement en vigueur ; exceptions validées ce trimestre.
Ne lit pas :     Anciennes versions de la politique ; décisions ad hoc dans le chat.
Autorisé :       Déposer des brouillons dans la file de relecture.
Interdit :       Écrire aux clients ; émettre des remboursements ; modifier la politique.
Preuve :         Citer l’article de la politique sur lequel s’appuie chaque réponse.
Relecture :      Le responsable relit dix brouillons par semaine ; chaque escalade est lue.
Pause si :       Deux semaines de brouillons citent un article qui n’existe plus.
Retrait si :     La politique passe dans un système que l’agent ne lit pas de façon fiable.

La troisième contrainte

La production est devenue bon marché, et le jugement est devenu le goulet d’étranglement. Puis le contexte a limité la capacité des agents à faire de vrais métiers. La responsabilité est maintenant la contrainte, parce que nous confions aux agents un travail dont quelqu’un doit répondre. Personne ne peut être propriétaire de centaines d’agents, mais ce n’est pas le nombre qui compte : ce sont les quelques agents qui déplacent de l’argent, livrent du code ou parlent aux clients.

La conclusion n’est pas de ralentir. Utilisez les agents, déléguez-leur du travail. Et pour chacun de ceux qui font un travail qui compte, assurez-vous qu’une personne précise peut en répondre. Si personne n’est prêt à le faire, c’est l’enseignement le plus utile de l’exercice : l’agent n’est pas prêt pour ce travail.

L’idée est définie en anglais sur la page Accountability deficit.