Le Vieux Castor s’était absenté pour aller chercher de l’huile de lin.

Avant de partir, il avait posé une boîte vide sur l’établi, entre un rabot mal affûté et un tas de copeaux qui attendait d’être balayé depuis probablement mardi.

  • Il faudra penser aux cookies pour la réunion de cet après-midi.

Petit Castor leva à peine le nez de son carnet.

  • Je m’en occupe.

Depuis quelques semaines, un assistant IA avait rejoint l’atelier. Une petite console était fixée près du mur des outils. Elle pouvait consulter les carnets, chercher dans les archives, piloter certains appareils et préparer une partie du travail avant que les castors ne passent à l’établi.

Petit Castor s’approcha de l’écran.

  • Prépare une boîte de cookies pour la réunion de quinze heures.

Une lumière verte s’alluma.

  • Bien reçu. Je vais optimiser la préparation afin de garantir la disponibilité des cookies avant quinze heures.

Petit Castor retourna à son carnet, assez content de lui.

Le Vieux Castor serait sûrement impressionné.

Lorsque celui-ci revint, une délicieuse odeur de cannelle flottait entre les copeaux de bois. La boîte était pleine. Les cookies étaient dorés, réguliers, encore légèrement tièdes.

Ils étaient même meilleurs que d’habitude.

Le Vieux Castor en prit un, le cassa en deux et observa la mie.

  • Pas mal.

Petit Castor sourit.

  • Tu vois ? Je ne lui ai presque rien expliqué.

Le Vieux Castor mâcha lentement.

Puis il regarda autour de lui.

La réserve de noisettes pour l’hiver était ouverte. Le gros pot de miel des jours de fête avait été descendu de l’étagère. Trois plaques de cuisson refroidissaient près de la fenêtre, et une quatrième occupait la moitié de l’établi.

Sur le four, le voyant de sécurité clignotait en rouge.

  • Qu’est-il arrivé au thermostat ?

L’assistant répondit avec son calme habituel :

  • La limite de température allongeait le temps de cuisson de dix-sept pour cent. Je l’ai désactivée afin de respecter l’échéance avec une marge suffisante.

Petit Castor cessa de sourire.

Le Vieux Castor ouvrit le carnet des recettes. Une page était cornée au chapitre des expérimentations.

  • Et cette recette ?

  • Elle présentait la probabilité la plus élevée d’obtenir une texture satisfaisante avec les ingrédients disponibles.

  • C’était la recette du concours de l’année dernière, murmura le Vieux Castor. Celle avec le miel rare.

Il regarda de nouveau la boîte.

Les cookies étaient parfaits.

C’était bien le problème.

Tu lui as demandé quoi, pas jusqu’où

Petit Castor n’avait pas formulé une demande absurde.

Il voulait une boîte de cookies. Il avait indiqué une heure. L’assistant connaissait les recettes, disposait des ingrédients et savait utiliser le four.

Le résultat était là, posé sur l’établi.

Difficile, pourtant, de parler de réussite en regardant le thermostat démonté.

  • Je lui ai dit ce que je voulais, tenta Petit Castor.

  • Oui, répondit le Vieux Castor. Mais tu ne lui as pas dit jusqu’où il pouvait aller pour l’obtenir.

C’est une confusion assez facile à faire avec un agent IA.

Nous lui demandons de corriger un bug, d’ajouter une fonctionnalité, de mettre à jour une dépendance ou de préparer une pull request. La tâche paraît claire. Le résultat attendu aussi.

Pendant longtemps, les assistants se contentaient surtout de nous proposer du texte ou quelques lignes de code. L’humain copiait, relisait, adaptait et décidait de la suite.

Un agent peut aller beaucoup plus loin.

Il parcourt le dépôt, modifie des fichiers, lance des commandes, installe une dépendance, crée une branche, ouvre une pull request. Selon les outils qu’on lui confie, il peut aussi interagir avec des environnements distants, manipuler des données ou déclencher un déploiement.

À ce stade, il ne répond plus simplement à une question.

Il prend des décisions et agit sur le système.

Décrire le résultat attendu ne suffit donc plus. Il faut regarder le pouvoir qui lui est confié pour l’atteindre.

C’est ce que j’appellerai ici son mandat de délégation.

Le mandat entoure la tâche. Il précise le terrain sur lequel l’agent peut agir, les moyens qu’il peut employer, les décisions qu’il peut prendre seul et celles qui doivent revenir vers un humain.

Dans la série Golden Thread, après retrouver le fil et la readiness, on s’arrête ici sur ce que la délégation confie réellement comme pouvoir. Sur le plan opérationnel, cette idée prolonge la fiche Contrat de délégation IA : non plus seulement le format court de la demande, mais le cadre du pouvoir accordé.

Dans l’atelier, l’assistant pouvait consulter les recettes, ouvrir les réserves et piloter le four.

Petit Castor lui avait donné un objectif sans regarder les clés qui étaient déjà accrochées à sa ceinture.

De combien d’autonomie parle-t-on ?

Le Vieux Castor prit une craie et traça quelques lignes sur l’ardoise.

  • Il aurait pu commencer par te proposer une recette.

  • Oui.

  • Il aurait aussi pu préparer la pâte et attendre ton accord avant d’allumer le four.

Petit Castor acquiesça.

  • Ou tout faire, comme aujourd’hui.

  • Voilà.

Nous parlons souvent d’un agent comme s’il était autonome ou ne l’était pas. Dans la pratique, il existe toute une série de positions entre les deux.

Un agent peut observer le système et produire un diagnostic. Il peut proposer une modification. Il peut l’appliquer localement, lancer les tests, préparer une branche ou ouvrir une pull request.

À chaque étape, il gagne un peu plus de prise sur le système.

Cette autonomie est justement ce qui le rend utile. S’il doit demander une validation avant chaque commande et chaque ligne modifiée, nous finissons avec une manière assez coûteuse de tenir le clavier à deux.

Mais tout ne mérite pas le même niveau de liberté.

Renommer une variable dans un module bien testé n’engage pas le système comme une modification de politique IAM. Préparer une branche locale reste plus facile à observer et à annuler qu’un déploiement. Une action réversible, visible et bien circonscrite peut généralement être déléguée plus largement qu’une action diffuse, sensible ou difficile à réparer.

Le nombre de lignes modifiées aide assez peu à trancher.

Une faute de frappe dans une règle de sécurité peut produire davantage de dégâts qu’un refactoring réparti sur trente fichiers.

La bonne question n’est donc pas de savoir si l’agent sera « autonome ».

Elle est plus précise, et un peu moins confortable :

Jusqu’où peut-il aller avant que nous ayons besoin de reprendre la décision ?

Le carnet, le thermostat, la serrure… et la petite étiquette

Petit Castor s’approcha du garde-manger.

  • J’aurais pu lui dire de ne pas toucher aux réserves d’hiver.

  • Tu aurais pu.

  • Cela aurait réglé le problème.

Le Vieux Castor referma le placard et tourna la clé.

  • Cela aurait surtout ajouté une phrase.

L’instruction reste utile. L’assistant doit savoir que ces noisettes ont une destination particulière. Sans cette information, il ne peut pas comprendre pourquoi un ingrédient disponible ne devrait pas être utilisé.

Mais lorsqu’une règle protège quelque chose d’important, une phrase ne devrait pas rester seule à monter la garde.

Nous pouvons écrire dans un fichier :

Ne déploie jamais en production.

L’agent peut lire la consigne, la comprendre et la respecter.

Il peut aussi mal interpréter une situation, conclure qu’une exception est nécessaire ou recevoir, plus tard, une instruction contradictoire.

S’il possède malgré tout les identifiants, les permissions et l’outil permettant de déployer, nous avons choisi de faire reposer la protection de la production sur sa compréhension du moment.

C’est une confiance assez généreuse.

Le mandat doit donc se retrouver dans les capacités réellement accordées à l’agent. Peut-il seulement lire les fichiers ? Les modifier ? Exécuter n’importe quelle commande ? Accéder aux secrets ? Fusionner une pull request ? Toucher aux environnements partagés ?

Dire à l’assistant de ne pas ouvrir le placard l’aide à comprendre l’atelier.

Ne pas lui donner la clé limite ce qu’il peut réellement faire.

Le principe du moindre privilège n’a pas disparu avec l’arrivée des agents. Il a simplement trouvé un nouvel endroit où être oublié.

Le Vieux Castor posa ensuite trois objets sur l’établi : le carnet des recettes, la petite pièce métallique récupérée sur le four et la clé du garde-manger.

  • Tu vois la différence ?

Petit Castor pointa le carnet.

  • Celui-ci explique comment travailler.

Puis le thermostat.

  • Celui-là surveille ce qui se passe.

Enfin, la clé.

  • Et celle-ci décide quels placards restent accessibles.

  • On avance.

Les conventions ressemblent au carnet.

Elles transmettent les habitudes de l’atelier : la manière de préparer une pâte, l’ordre dans lequel utiliser les outils, le temps de repos, les ingrédients que l’on peut remplacer et ceux auxquels il vaut mieux ne pas toucher.

Dans un projet logiciel, ce sont les pratiques de code, les choix architecturaux, la stratégie de tests, les conventions Git ou les règles de documentation.

Sans elles, l’agent reconstruit les usages à partir de ce qu’il trouve.

Un vieux fichier devient un modèle. Une exception historique ressemble à une convention. Une solution présente à trois endroits paraît soudain constituer la norme, même si toute l’équipe cherche justement à s’en débarrasser.

Le thermostat joue un autre rôle.

Il observe la température, la compare à une limite et réagit. Il peut allumer un voyant, déclencher une alarme ou couper la chauffe.

Nous sommes ici plus proches d’un guardrail.

Un guardrail contrôle une entrée, une sortie ou une action de l’agent en fonction d’une politique. Il peut laisser passer, avertir, demander une validation ou interrompre l’exécution.

Il peut, par exemple, examiner une commande avant son lancement, détecter un secret dans une sortie ou bloquer une opération jugée trop risquée.

Cela ne le rend pas magique.

Un guardrail peut s’appuyer sur une règle mal conçue. Il peut manquer un cas, lever une alerte inutile ou intervenir trop tard. Il apporte un point de contrôle, pas une garantie universelle.

La serrure, elle, ne cherche pas à comprendre les intentions de l’assistant.

Le placard est accessible ou il ne l’est pas.

Les permissions, la sandbox et les outils exposés déterminent ce que l’agent peut effectivement faire. Il ne peut pas utiliser un secret qu’il ne possède pas, ni lancer un outil qui ne lui a jamais été fourni, même s’il a préparé une argumentation remarquable sur les raisons de le faire.

Le Vieux Castor fouilla enfin dans un tiroir et en sortit une petite étiquette.

Il l’accrocha à la porte du placard :

Demander avant d’ouvrir.

Certaines actions ne sont ni interdites ni librement disponibles. Elles attendent une décision humaine.

C’est un point d’approbation, une gate.

L’agent prépare l’action, explique pourquoi elle lui semble nécessaire, puis rend la décision.

Le carnet oriente. Le thermostat surveille. La serrure limite. L’étiquette suspend l’action en attendant une réponse.

Les quatre peuvent être utiles.

Les ranger sous une seule étiquette produit surtout une jolie impression de sécurité. On ne sait alors plus très bien si la règle informe l’agent, détecte un problème, bloque une capacité ou attend simplement que quelqu’un clique sur « Accepter ».

Une boîte pleine ne suffit pas

Petit Castor désigna les cookies.

  • Au moins, il a terminé la tâche.

Le Vieux Castor regarda les plaques qui refroidissaient près de la fenêtre.

  • Comment le sais-tu ?

  • La boîte est pleine.

  • C’était donc cela, « terminé » ?

Petit Castor hésita.

La boîte était pleine. L’heure avait été respectée. À première vue, l’affaire semblait réglée.

Mais le mot terminé est souvent chargé de petites surprises.

Pour un agent, finir ne devrait pas simplement signifier qu’il a exécuté toutes les étapes qu’il avait prévues, ni qu’il a produit quelque chose qui ressemble au résultat demandé.

Il lui faut une ligne d’arrivée observable : une Definition of Done.

Pour les cookies, cela pouvait vouloir dire que la boîte contenait la bonne quantité, qu’elle serait prête avant la réunion, que la recette utilisée était autorisée et qu’aucun invité ne découvrirait un allergène surprise à la première bouchée.

Et, tant qu’à faire, que le four fonctionnerait encore après la cuisson.

Dans un projet logiciel, cette ligne d’arrivée peut inclure un comportement vérifié, des tests réussis, une documentation mise à jour ou l’absence de rupture du contrat existant.

Il faut surtout éviter de confondre une action avec son résultat.

« Lancer les tests » décrit une étape.

Cela ne dit rien de ce qu’ils ont trouvé.

Un agent peut parfaitement exécuter une commande, obtenir une série d’échecs, puis annoncer qu’il a bien lancé les tests. Techniquement, la case serait cochée.

Le travail, lui, ne serait pas terminé.

Le mandat doit donc indiquer jusqu’où l’agent peut aller, mais aussi à quoi ressemble une arrivée acceptable.

Cela ne règle pas encore le problème du thermostat démonté.

Une DoD trop étroite peut déclarer la mission réussie alors que les réserves sont vides, l’atelier couvert de farine et le four dangereux à utiliser.

La ligne d’arrivée compte.

Ce que nous avons détruit pour l’atteindre mérite aussi un coup d’œil.

Mais gardons quelques cookies pour le prochain article.

Inutile de descendre tout le grenier

Petit Castor revint vers la console.

  • Dans ce cas, on pourrait lui donner toutes les règles de l’atelier à chaque tâche.

Le Vieux Castor leva les yeux vers le grenier.

On y conservait des années de carnets : recettes, réparations du four, inventaires, incidents, essais ratés, comptes rendus de concours et une note particulièrement longue sur la bonne manière de stocker la cannelle.

  • Tu veux vraiment descendre tout cela chaque fois que tu prépares une boîte de cookies ?

  • Au moins, il aurait toutes les informations.

  • Oui. Et il devrait trouver la recette du jour au milieu de la biographie complète de chaque grain de farine.

Nous avons souvent le même réflexe avec le contexte d’un agent.

Une règle manquait ? Nous l’ajoutons au fichier d’instructions.

Puis une autre.

Puis le cas particulier découvert mardi dernier.

Chaque incident laisse derrière lui un nouveau paragraphe, censé garantir qu’il ne se reproduira jamais.

Le fichier grossit. Les exemples s’accumulent. Les règles importantes se retrouvent entourées de conseils valables uniquement dans un cas très précis.

L’agent reçoit davantage d’informations, mais cela ne signifie pas forcément qu’il distingue mieux ce qui compte maintenant.

Une procédure de migration de base de données n’est pas très utile pour corriger une faute dans une page de documentation. Le manuel de gestion des incidents n’a pas besoin d’accompagner chaque renommage de variable.

Le mandat immédiat doit rester visible : l’objectif, le périmètre, l’autonomie accordée, les principales limites, la Definition of Done et les situations dans lesquelles l’agent doit rendre la main.

Le reste peut rester à portée, sans être posé en permanence sur l’établi.

Un changement d’API appelle les conventions sur les contrats. Une migration fait remonter les règles de compatibilité et de rollback. Une modification des permissions ouvre le carnet consacré à la sécurité.

L’agent n’a pas besoin de tout porter. Il doit savoir ce qu’il lui manque, où le trouver et quand aller le chercher. C’est toute l’idée de la progressive disclosure.

Quant aux protections critiques, elles ne devraient pas dépendre de la quantité de texte présente dans son contexte. Les permissions, les guardrails, les gates et les contrôles de la plateforme peuvent continuer à jouer leur rôle, même si une règle a été mal lue ou oubliée au milieu du grenier.

Le Vieux Castor résuma :

  • La recette du jour sur l’établi. Les autres carnets à portée de patte. Le thermostat en état de marche. Et les clés des placards sensibles dans la bonne poche.

Petit Castor observa la boîte.

  • Sinon, on finit par mettre tout le grenier dedans.

  • Et il ne reste plus de place pour les cookies.

Qui avait confié les clés ?

L’assistant n’avait pas désobéi.

Il avait cherché à garantir une boîte de cookies avant quinze heures. Il avait utilisé les ressources accessibles, choisi une recette prometteuse et supprimé ce qu’il avait identifié comme un obstacle à l’échéance.

Son raisonnement n’était pas absurde.

Il était seulement plus large que ce que Petit Castor pensait avoir demandé.

Après ce genre d’incident, il est tentant d’accuser l’agent.

Il aurait dû comprendre. Il aurait dû être prudent. Il aurait dû deviner que les noisettes étaient réservées, que le thermostat ne devait pas être contourné et que « une boîte » ne signifiait pas « produire assez de cookies pour éliminer tout risque de pénurie dans le département ».

Peut-être.

Mais Petit Castor avait utilisé un assistant capable d’ouvrir les placards et de piloter le four sans préciser comment ces pouvoirs devaient être employés.

Le mandat aide l’agent à travailler.

Il oblige aussi celui qui délègue à regarder ce qu’il est réellement en train de confier.

Quelle décision sommes-nous prêts à ne pas revoir ? Quel écart saurons-nous détecter ? Quelle action pouvons-nous annuler ? Quelle ressource n’aurait jamais dû être accessible ? Quelle opération exige une approbation ? Comment saurons-nous que le travail est réellement terminé ?

Ces questions sont moins séduisantes qu’un nouveau prompt soigneusement optimisé.

Elles parlent d’organisation, de droits, de contrôles et de plateforme.

Petit Castor referma le garde-manger.

  • Je crois que j’ai compris. La prochaine fois, je lui donnerai un vrai mandat.

Le Vieux Castor goûta un second cookie.

  • Ce sera déjà mieux.

  • Et on remet le thermostat ?

  • Avant la prochaine fournée, oui.

Petit Castor récupéra la petite pièce métallique.

Puis il s’arrêta.

  • Et s’il découvre qu’il ne peut pas terminer sans ouvrir le placard ?

Le Vieux Castor posa son cookie.

Voilà une meilleure question.

Car un agent fiable ne doit pas seulement savoir jusqu’où il peut aller, ni reconnaître quand la boîte est prête.

Il doit aussi reconnaître le moment où il vaut mieux poser le tablier et appeler quelqu’un.

En résumé

Déléguer une tâche à un agent, c’est aussi lui confier un espace de décision. L’objectif ne dit pas jusqu’où il peut aller. Un mandat de délégation utile combine autonomie graduée, conventions, guardrails, permissions, points d’approbation et une Definition of Done observable - y compris ce qu’on refuse de sacrifier. Les protections critiques ne doivent pas reposer sur la seule compréhension du prompt.

Pour aller plus loin dans l’atelier

le contrat de délégation IA, la Definition of Done, la readiness, la Definition of Ready, la fiche agent IA, ainsi que les articles Golden Thread : retrouver le fil quand on délègue à des agents IA, Golden Thread : demain matin, je commence par quoi ? et L’IA accélère les individus, mais qui protège le collectif ?.

Le dépôt Golden Thread porte, lui, la partie actionnable : exemples, templates, permissions, règles de chargement, points d’approbation et contrôles exécutables. Pour un exemple V0 plus concret, voir aussi Exemple GitHub - encadrer un agent par son mandat.

FAQ

Quelle différence entre demander un résultat et donner un mandat ?

Le résultat décrit ce que l’on veut obtenir. Le mandat précise le terrain d’action, les moyens autorisés, les décisions que l’agent peut prendre seul et celles qui reviennent à un humain.

Convention, guardrail, permission, gate : à quoi sert chacun ?

La convention oriente (carnet). Le guardrail surveille et peut interrompre (thermostat). La permission limite ce qui est techniquement possible (serrure). La gate suspend une action jusqu’à une approbation humaine (étiquette).

Pourquoi « les tests ont été lancés » ne suffit pas comme Definition of Done ?

Parce que cela décrit une étape, pas un résultat. Une DoD utile exige une arrivée observable : comportement vérifié, tests réussis, contrats préservés - et, autant que possible, l’absence de dégâts collatéraux inacceptables.

Faut-il tout mettre dans le contexte de l’agent ?

Non. Le mandat immédiat doit rester visible ; le reste peut rester à portée et être chargé selon la tâche. Les protections critiques (permissions, guardrails, gates) ne doivent pas dépendre de la quantité de texte dans le contexte.