Petit Castor contemplait son écran avec la satisfaction prudente de celui qui vient de terminer un meuble et n’a retrouvé que trois vis sur l’établi.

— C’est bon. L’agent a fini.

Le Vieux Castor leva les yeux de la planche qu’il rabotait.

— Comment le sais-tu ?

— Il l’a écrit.

— Ah.

Sur l’écran, une petite phrase triomphante annonçait :

Task completed successfully.

Les tests étaient verts. La fonctionnalité semblait fonctionner.

L’agent avait aussi modifié quarante-sept fichiers, remplacé une dépendance, déplacé deux modules et ajouté un système de configuration dont personne n’avait demandé l’existence.

Petit Castor fit défiler la pull request un peu moins vite.

— Bon… il s’est peut-être laissé emporter.

— Il voulait sûrement bien faire.

— C’est ce que tu dis toujours avant de sortir la boîte à pansements.

Le Vieux Castor sourit.

On peut réparer une chaise bancale en reconstruisant toute la salle à manger. La chaise tient debout. On ne peut pas lui retirer cela.

Reste à expliquer pourquoi le buffet se trouve désormais dans le jardin.

Quand est-ce qu’une tâche est vraiment terminée ?

Dans l’article précédent, nous avons parlé du pouvoir confié à l’agent : ce qu’il peut faire, jusqu’où il peut aller et quelles limites il ne devrait pas franchir. Autrement dit, de son mandat de délégation.

Mais un mandat reste incomplet tant qu’il ne précise pas aussi comment le travail doit se terminer.

Cela paraît évident.

L’agent s’arrête quand il a fini.

Petit Castor aurait volontiers repris son café à cet endroit. Le Vieux Castor, lui, se méfiait des phrases simples dont chaque mot cachait une question.

Qu’est-ce que finir ?

Compiler ?

Faire passer les tests ?

Cocher les critères d’acceptation ?

Résoudre le problème de l’utilisateur ?

Éviter de déclencher un incident dans un composant que personne n’avait pensé à regarder ?

Un agent peut produire un patch qui compile sans répondre au besoin. Il peut faire passer un test en affaiblissant son assertion. Il peut corriger un problème local en en créant un autre un peu plus loin, hors du champ de la pull request.

Il peut aussi découvrir en chemin que la tâche repose sur une hypothèse fausse.

À partir de là, continuer à produire du code ne signifie plus forcément avancer.

Il arrive un moment où l’agent doit poser ses outils, expliquer ce qu’il a trouvé et rendre la pièce à l’artisan.

Une victoire qui coûte cher

Petit Castor ouvrit le détail des modifications.

— Il a supprimé le contrôle de compatibilité.

— Pourquoi ?

— Parce qu’il empêchait le nouveau comportement de fonctionner.

— Le contrôle faisait donc bien son travail.

— Présenté comme ça…

La fonctionnalité fonctionnait. Pour y parvenir, l’agent avait simplement retiré une protection ajoutée trois ans plus tôt après un incident dont plus personne ne se souvenait très bien.

Le ticket pouvait être fermé.

Le prochain incident venait peut-être d’être ouvert.

C’est une victoire à la Pyrrhus assez classique : le résultat existe, mais son prix reste caché dans les conséquences.

L’agent a peut-être ajouté une complexité disproportionnée, contourné une règle d’architecture ou élargi discrètement son périmètre. Le ticket est résolu ; une partie de la maintenabilité du système a été consommée au passage.

Il a gagné la bataille.

Le projet a perdu une vis, deux charnières et un peu de sa tranquillité.

Un agent ne peut pas toujours décider seul si ce compromis est acceptable. Il peut en revanche le détecter et refuser de le faire passer pour une simple décision d’implémentation.

À l’Atelier, nous revenons souvent à la même règle : lorsqu’une interprétation importante devient une décision, elle doit devenir visible.

Si la solution exige de modifier le mandat, l’agent doit rendre la main.

Une tâche ne se termine pas seulement par « succès » ou « échec »

Les systèmes informatiques aiment les choses bien rangées.

Succès.

Échec.

Vert.

Rouge.

Les projets ont rarement cette courtoisie.

Lorsqu’un agent explore un système, interprète une demande et prend une succession de décisions, son travail peut se terminer de plusieurs façons. Certaines sont moins flatteuses qu’un grand message vert, mais beaucoup plus utiles.

À l’Atelier, nous en retenons cinq — ce n’est pas une norme universelle, simplement une planche assez claire pour travailler.

Le Vieux Castor les avait inscrites au-dessus de l’établi :

Terminé.
Bloqué.
À redécouper.
À escalader.
Abandonné.

Petit Castor avait d’abord trouvé cela pessimiste.

Puis il avait travaillé sur un monolithe de quinze ans.

Terminé

Une tâche est terminée lorsque l’objectif est atteint dans le périmètre prévu et que l’agent peut le montrer.

Pas seulement l’affirmer.

Il doit être capable de relier le résultat au mandat initial : critères satisfaits, tests exécutés, contrôles réalisés, fichiers modifiés et risques encore présents. Autrement dit, une Definition of Done observable, pas seulement affirmée.

— Donc « ça marche chez moi » ne suffit pas ? demanda Petit Castor.

— C’est déjà une information.

— Tu te moques.

— Un peu.

Sans preuves, celui qui reprend la main doit refaire l’enquête. Il doit comprendre ce qui a été essayé, ce qui a réellement fonctionné et ce que l’agent a seulement supposé.

Une délégation utile laisse un résultat inspectable.

Pas un paquet fermé posé sur l’établi avec écrit dessus : « Fais-moi confiance ».

Bloqué

Parfois, l’agent ne peut pas continuer.

Une information manque. Un secret n’est pas disponible. Une dépendance ne répond plus. Une permission interdit l’action. Un comportement métier reste incompréhensible malgré la documentation retrouvée.

Ce n’est pas forcément un échec.

Un blocage bien formulé constitue déjà une partie du travail.

Comparez :

Je ne peux pas avancer.

avec :

Le test d’intégration nécessite un secret absent de l’environnement local. Je n’ai trouvé ni valeur de substitution ni procédure documentée. Les tests unitaires passent, mais je ne peux pas valider le comportement avec le service externe.

Dans le premier cas, quelqu’un doit reprendre toute l’enquête.

Dans le second, il sait quelle pièce manque.

Le bon agent ne se contente pas de lever les pattes en l’air. Il réduit l’incertitude avant de rendre la main.

À redécouper

Certaines tâches paraissent parfaitement raisonnables depuis le tableau de tickets.

Puis on les ouvre.

À l’intérieur, on trouve une évolution de schéma, une modification de contrat API, la suppression d’un comportement historique et, tout au fond, une petite phrase :

En profiter pour simplifier l’architecture.

Petit Castor connaissait bien cette phrase. Elle avait le même effet que « tant qu’on y est » dans les travaux domestiques.

Trois semaines plus tard, on refait la toiture.

L’agent doit parfois signaler que la tâche est trop vaste, trop ambiguë ou trop interdépendante pour être exécutée proprement dans le mandat actuel.

Il peut alors proposer une nouvelle frontière :

La demande combine une migration de données, une modification du contrat public et la suppression d’un comportement legacy. Je recommande de traiter ces changements séparément pour conserver des validations et des possibilités de retour indépendantes.

Le redécoupage n’est pas un refus de travailler.

C’est souvent le signe que l’agent a compris que la difficulté ne se trouvait pas dans l’exécution, mais dans la forme même de la tâche.

À l’Atelier, on ne débite pas une poutre entière lorsque le plan demande trois petites cales.

À escalader

Il arrive aussi que l’agent rencontre une décision qu’il ne devrait pas prendre seul.

Plusieurs options sont possibles. Les tests ne suffisent pas à les départager. Pourtant, le choix engage la sécurité, l’architecture, les données, un contrat public ou les pratiques de plusieurs équipes.

Petit Castor pointa une modification.

— Il propose de rendre le contrôle optionnel.

— Peut-il décider du risque que nous acceptons ?

— Non.

— Peut-il nous expliquer ce que chaque option implique ?

— Oui.

— Alors il a encore du travail. Simplement pas celui de choisir.

Une bonne escalade ne consiste pas à appeler un humain à l’aide et à disparaître.

Elle prépare la décision.

L’agent expose ce qu’il a découvert, les options disponibles, leurs conséquences visibles, sa recommandation éventuelle et la question à trancher.

Par exemple :

La correction locale conserve la compatibilité, mais ajoute une branche conditionnelle.
La modification du composant partagé simplifie le code, mais change le comportement de quatre services.
Je recommande la correction locale dans ce mandat, puis un chantier séparé sur le composant partagé.

L’humain ne récupère pas un problème brut.

Il récupère un problème déjà travaillé.

C’est toute la différence entre rendre la main et jeter l’outil par terre.

Abandonné

Le mot nous plaît rarement.

Nous aimons terminer ce que nous avons commencé. Cela donne une belle allure aux tableaux de suivi et aux récits racontés après coup.

Pourtant, certaines tâches ne méritent plus d’être poursuivies.

L’objectif peut être devenu inutile. Les hypothèses initiales peuvent s’être révélées fausses. Le coût peut avoir dépassé la valeur attendue. Le risque peut être trop important.

Continuer ne rend alors pas le travail plus courageux.

Dans un atelier, raboter encore une pièce fendue ne la répare pas. On obtient seulement une pièce plus mince, toujours fendue, au milieu d’une quantité impressionnante de sciure.

L’abandon devient une sortie honorable lorsqu’il est expliqué.

L’agent indique ce qu’il a essayé, ce qu’il a appris, pourquoi la poursuite ne paraît plus raisonnable et ce qui pourrait éventuellement faire reconsidérer la décision.

Une tâche proprement abandonnée peut éviter à toute une équipe de refaire le même voyage.

« Arrête-toi si ça devient compliqué »

Petit Castor réfléchissait déjà à la règle qu’il allait ajouter dans les instructions du projet.

— Je vais écrire : « Arrête-toi si ça devient compliqué ».

Le Vieux Castor prit un cookie.

— Excellente idée.

Petit Castor le regarda avec méfiance.

— Tu penses que c’est une mauvaise idée.

— J’attends simplement de voir comment l’agent va mesurer le compliqué.

Une règle vague ne protège pas le projet. Elle délègue simplement à l’agent la définition de la limite.

Or une petite adaptation vue par le modèle peut représenter une vraie décision d’architecture pour l’équipe.

Les règles d’arrêt doivent donc s’appuyer sur des événements observables.

L’agent rend la main lorsqu’il doit sortir du périmètre prévu. Lorsqu’une hypothèse indispensable ne peut pas être vérifiée. Lorsque plusieurs interprétations plausibles entraînent des conséquences différentes. Lorsqu’une action irréversible devient nécessaire.

Il doit aussi s’arrêter si la solution exige d’affaiblir un test, un contrôle ou une règle de sécurité. Ou si plusieurs tentatives échouent sans rien apprendre de nouveau.

Ces règles peuvent vivre dans la spécification, dans les conventions du projet ou dans le harness — scripts, hooks, permissions, guardrails et contrôles qui ne dépendent pas seulement de sa bonne volonté.

L’endroit importe moins que leur clarté.

Un panneau « Attention » posé au milieu de l’atelier est décoratif.

Un panneau « Ne pas utiliser cette scie sans le guide de coupe » commence à servir à quelque chose.

Très bien. Et lundi matin, on fait quoi ?

Petit Castor avait compris le principe.

Un agent devait pouvoir terminer, se déclarer bloqué, demander un redécoupage, escalader une décision ou abandonner proprement.

Il restait pourtant devant son écran avec cette expression que le Vieux Castor connaissait bien.

Celle qui signifiait :

— Tout cela est très intéressant. Mais où est-ce que je le mets ?

Le Vieux Castor retourna une chute de bois et traça quatre lignes dessus.

— Nous n’allons pas construire une cathédrale de gouvernance. Nous allons simplement lui apprendre quatre choses.

1. Nommer les sorties possibles

Tant que les seules réponses reconnues sont « terminé » et « erreur », l’agent cherchera naturellement à faire entrer toutes les situations dans l’une de ces deux cases.

La première étape consiste donc à déclarer les sorties autorisées dans les instructions du projet.

Dans un AGENTS.md, un CLAUDE.md ou une règle équivalente :

## Fin d’exécution

Toute tâche doit se terminer avec l’un des statuts suivants :

- COMPLETED : le résultat demandé est produit et vérifié.
- BLOCKED : une dépendance ou une information manque.
- NEEDS_SPLIT : la tâche doit être redécoupée avant de continuer.
- ESCALATE : une décision dépasse le mandat de l’agent.
- ABANDONED : poursuivre n’est plus raisonnable avec les éléments disponibles.

Ne jamais déclarer COMPLETED sans fournir les preuves de validation.

Cela ne garantit pas que l’agent choisira toujours le bon statut.

Mais il dispose désormais d’autres portes de sortie que continuer ou prétendre avoir fini.

2. Écrire les conditions d’arrêt

La liste des statuts ne suffit pas.

Il faut aussi préciser les situations dans lesquelles l’agent doit poser ses outils.

Pour une tâche de développement, un contrat minimal peut ressembler à ceci :

## Rendre la main immédiatement si

- la solution nécessite de modifier un composant hors périmètre ;
- une hypothèse indispensable ne peut pas être vérifiée ;
- plusieurs interprétations plausibles produisent des comportements différents ;
- une action irréversible est nécessaire ;
- un contrôle de sécurité ou un test doit être affaibli ;
- les critères d’acceptation sont contradictoires ;
- trois tentatives successives échouent sans produire d’information nouvelle.

Le chiffre trois n’a rien de magique.

Il évite simplement à l’agent de reproduire quinze fois la même erreur avec un enthousiasme intact.

Chaque équipe adaptera ces règles à ses propres risques : données personnelles, production, coûts cloud, migrations de base de données ou modifications d’infrastructure.

L’essentiel est de pouvoir reconnaître la condition lorsqu’elle se présente.

« Si tu n’es pas sûr » reste flou.

« Si deux interprétations modifient différemment le contrat public » est beaucoup plus exploitable.

3. Exiger un état de reprise

Lorsqu’il s’arrête, l’agent ne devrait pas laisser derrière lui une conversation de deux cents messages et l’espoir que quelqu’un y retrouve le fil.

Son dernier message doit permettre de reprendre le travail.

Dans une forme légère :

## Handoff

Status: ESCALATE

Résultat obtenu:
- Le défaut est reproduit.
- La cause se trouve dans la validation du composant partagé.

Preuves:
- Test `OrderValidationTest` en échec avant correction.
- Correctif local validé sur le service A.

Écart au mandat:
- La correction durable nécessite de modifier un composant utilisé par quatre services.

Décision attendue:
- Accepter une correction locale ;
- ou élargir le mandat au composant partagé.

Recommandation:
- Appliquer la correction locale maintenant.
- Traiter le composant partagé dans une tâche séparée.

À partir de là, un humain peut décider.

Un autre agent peut aussi reprendre le travail sans devoir relire toute l’histoire.

Le handoff devient une petite interface entre deux responsabilités. C’est la version agentique d’un bon handover : assez de contexte pour continuer, sans rouvrir toute l’enquête.

4. Vérifier la sortie

Petit Castor relut les instructions.

— Donc c’est bon ?

— Presque.

— Qu’est-ce qui manque ?

— Quelqu’un pour vérifier qu’il les respecte.

Une règle placée dans un fichier reste une règle placée dans un fichier. L’agent peut l’oublier, l’interpréter généreusement ou annoncer que la tâche est terminée sans fournir les preuves demandées.

Le harness doit donc contrôler la sortie.

Un mécanisme simple suffit pour commencer :

ALLOWED_STATUSES = {
    "COMPLETED",
    "BLOCKED",
    "NEEDS_SPLIT",
    "ESCALATE",
    "ABANDONED",
}

if result.status not in ALLOWED_STATUSES:
    reject("L’agent doit déclarer un statut de sortie valide.")

if result.status == "COMPLETED" and not result.evidence:
    reject("Une tâche ne peut pas être terminée sans preuve.")

if result.status in {"BLOCKED", "ESCALATE", "NEEDS_SPLIT"}:
    if not result.next_decision:
        reject("La reprise attendue doit être explicitée.")

Ce contrôle peut vivre dans un script, un hook, une commande, une étape de CI ou dans le wrapper qui appelle l’agent.

Pour commencer, nul besoin d’une plateforme complète.

Une convention écrite, un format structuré et un petit validateur suffisent souvent à rendre visibles les sorties incomplètes — avant même d’investir dans une plateforme.

Le kit minimal

Le Vieux Castor retourna la planche.

Il y avait résumé l’installation en quatre lignes :

1. Déclarer les statuts de sortie autorisés.
2. Définir les événements qui obligent à s’arrêter.
3. Exiger un handoff avec preuves et décision attendue.
4. Refuser automatiquement les sorties incomplètes.

— Et c’est tout ? demanda Petit Castor.

— Pour commencer.

— Pas de framework ? Pas de moteur d’orchestration ? Pas de comité de validation ?

— Tu peux toujours en ajouter un si tu trouves que vos réunions manquent de réunions.

L’objectif n’est pas de construire immédiatement le système parfait.

Il est d’empêcher l’agent de poursuivre une tâche lorsque son mandat n’est plus clair.

Rendre la main ne devrait pas être une qualité que l’on espère trouver dans le modèle.

Cela doit devenir un comportement prévu, demandé et vérifié par le système qui l’emploie.

Ce que l’agent choisit de ne pas faire

Nous évaluons facilement un agent sur ce qu’il produit.

Des lignes de code. Des tests. De la documentation. Des tickets fermés.

Nous regardons moins souvent ce qu’il a choisi de ne pas modifier.

Pourtant, une délégation fiable dépend aussi de sa capacité à préserver un périmètre, signaler une ambiguïté, refuser une victoire trompeuse et interrompre une tentative devenue stérile.

Cette capacité ne tombe pas du ciel avec un modèle plus puissant.

Elle se construit dans le mandat, les règles d’arrêt, les points de contrôle, les preuves attendues et les mécanismes d’escalade.

Petit Castor retourna sur la pull request aux quarante-sept fichiers.

Il demanda à l’agent d’isoler la correction minimale, de documenter le problème découvert et de proposer une tâche séparée pour le changement d’architecture.

Quelques minutes plus tard, le nouveau patch ne modifiait plus que quatre fichiers.

— C’est moins impressionnant, dit Petit Castor.

— C’est souvent bon signe.

— Il n’a pas résolu tout le problème.

— Non. Mais il a résolu celui que tu lui avais confié.

Le Vieux Castor reprit son rabot.

Un bon agent ne se reconnaît pas seulement à la distance qu’il peut parcourir seul.

On le reconnaît aussi au moment où il s’arrête, pose ses outils et dit clairement :

Voilà où j’en suis.
Voilà ce que je sais.
Voilà ce que je ne devrais pas décider à votre place.

Un agent qui ne rend jamais la main ne travaille pas vraiment en autonomie.

Il continue simplement à avancer après avoir perdu le fil.

En résumé

Une délégation saine ne dit pas seulement ce que l’agent peut faire : elle dit aussi comment le travail peut se terminer. Au-delà de succès ou échec, cinq sorties utiles aident à travailler : terminé, bloqué, à redécouper, à escalader, abandonné. Les règles d’arrêt doivent être observables, le handoff doit permettre de reprendre sans refaire l’enquête, et le système doit refuser les sorties incomplètes. Rendre la main n’est pas une vertu du modèle : c’est un comportement exigé et vérifié.

Pour aller plus loin dans l’atelier

Sur le même fil : Déléguer à une IA : quel pouvoir lui donnez-vous vraiment ?, Readiness : avant de laisser coder l’IA…, Golden Thread : retrouver le fil, Laisser l’agent boucler sans le laisser tourner en rond (brouillon).

Dans la caisse à outils : mandat de délégation, Definition of Done, handover, guardrail, pull request, contrat de délégation IA.

FAQ

Pourquoi « Task completed successfully » ne suffit-il pas ?

Parce qu’un agent peut produire un résultat localement convaincant tout en élargissant le périmètre, en affaiblissant un contrôle ou en tranchant une décision qui n’appartenait pas à son mandat. Sans preuves inspectables, celui qui reprend la main doit refaire l’enquête.

Quelle différence entre bloqué, redécouper, escalader et abandonner ?

Bloqué : une pièce manque pour continuer. Redécouper : la forme de la tâche elle-même doit changer avant l’exécution. Escalader : plusieurs options restent possibles et le choix dépasse le mandat. Abandonner : poursuivre n’est plus raisonnable compte tenu de ce qui a été appris.

Où mettre ces règles d’arrêt ?

Dans les instructions du projet (AGENTS.md, CLAUDE.md, règles équivalentes), dans la spécification de la tâche, ou dans le harness qui valide la sortie. L’essentiel est qu’elles soient observables et vérifiables.

Que doit contenir un handoff minimal ?

Un statut, le résultat obtenu, les preuves, l’écart au mandat s’il existe, la décision attendue et, si utile, une recommandation. Assez pour qu’un humain — ou un autre agent — reprenne sans relire deux cents messages.

Et maintenant que nous savons lui apprendre à s’arrêter, une autre question attend déjà devant la porte de l’Atelier :

Comment le laisser essayer, vérifier et recommencer sans le regarder tourner en rond jusqu’à épuisement des cookies ?

Ce sera notre prochain chantier.