Tier 3 · Guard & build3.115 min

Des garde-fous que vous pouvez rédiger

Rows of golden autumn vines below cloud-draped high-country hillsAgents at Work — CC BY 4.0

Si vous avez suivi la formation « Travailler avec Claude », vous vous êtes fixé quatre règles : comment vérifier, ce que vous ne copierez pas, relire avant l’envoi, et rester celui qui décide. Deux d’entre elles sont devenues des habitudes — des gestes que vous effectuez, sur le moment, devant votre clavier.

Un agent rompt cet équilibre, et il est important de bien comprendre comment. L’agent agit sans surveillance. Vous n’êtes pas devant le clavier lorsqu’il s’exécute ; il n’y a pas de moment où une habitude peut se déclencher. Ainsi, chaque garde-fou qui se trouvait auparavant dans votre tête doit désormais être intégré dans l’agent et appliqué par la configuration — car « je vérifierai ça sur le moment » n’est pas une option lorsqu’il n’y a personne à ce moment-là.

C’est là tout l’enseignement : les quatre mêmes règles, transférées de votre esprit vers le code.

Des habitudes aux règles écrites

1. Ce qu’il doit vérifier — et comment il signale un doute. Votre habitude de vérification devient les instructions de l’agent. Dites-lui, par écrit, de présenter ses preuves, d’indiquer clairement quand il n’est pas sûr, et de ne jamais combler une lacune par une supposition assurée. Un agent qui renvoie « Je n’ai pas trouvé cela — je te le signale » fait son travail ; celui qui invente une réponse plausible pour donner l’impression d’avoir terminé est dangereux. Vous ne pouvez pas vérifier sur le moment, vous construisez donc un agent qui met en évidence ce qui doit être vérifié.

2. Ce qu’il ne doit jamais toucher ni envoyer. Votre règle « ce que je ne collerai pas » devient une limite stricte dans le code — et c’est là que le principe du « privilège minimal » du niveau 2 devient une règle écrite, et pas seulement un paramètre. Précisez clairement ce qui est interdit : les données personnelles qu’il ne doit pas transmettre, les comptes sur lesquels il ne doit pas écrire, les actions qu’il ne doit pas entreprendre. Avec une personne, « ne collez pas les données des clients » est un rappel. Avec un agent, cela doit être un mur, car il n’y a personne à qui le rappeler.

3. S’arrêter et attendre — la barrière comme règle qu’il ne peut franchir. « Vérifier avant l’envoi » cesse d’être une tâche dont il faut se souvenir et devient un obstacle infranchissable que l’agent ne peut contourner. Les verbes contraignants — envoyer, payer, publier, rejeter, valider — se trouvent de l’autre côté d’ une barrière où l’agent se prépare puis attend une personne. Pas « vérifie généralement avec moi ». Impossible d’avancer sans moi. Concevez le système de sorte que l’ action par défaut soit « s’arrêter », et que pour aller de l’avant, l’intervention d’un humain soit nécessaire.

4. Le système reste consultatif là où cela compte. « Restez celui qui décide » est la règle sous-jacente à toutes les autres, et c’est le Point d’ancrage n° 3 — vous en répondez. Lorsqu’une décision a un poids — de l’argent, les droits d’une personne, un engagement écrit —, l’agent présente les éléments de preuve et une personne décide. Si vous ne pouviez pas défendre un résultat sans dire « c’est l’agent qui l’a fait », la barrière de sécurité n’était pas en place.

Pourquoi une règle écrite et appliquée l’emporte sur une bonne intention

Il y a une raison de préférer une règle que le système fait respecter à celle que vous avez l’intention de respecter. Une barrière de sécurité écrite peut être lue, vérifiée, transmise à celui qui exploitera l’agent par la suite, et — c’est le sujet de la prochaine leçon — testée. Une bonne intention ne peut être aucune de ces choses. Lorsqu’un agent s’exécute une centaine de fois pendant que vous dormez, « je vais garder un œil dessus » n’est pas une barrière de sécurité ; les règles que vous y avez intégrées et les freins que vous avez mis en place, eux, le sont.

Et rédigez-les de manière à pouvoir les assumer pleinement. Si une règle de sécurité est quelque chose que vous ne pourriez pas dire à voix haute à la personne concernée par l’agent, c’est le signe qu’il faut modifier cette règle, et non la dissimuler.

La phase de développement

Avant qu’un agent ne s’approche de quoi que ce soit en production, consignez ses garde-fous par écrit — clairement, sous quatre rubriques que vous pouvez défendre :

Restez suffisamment concis pour que cela se lise en une minute et suffisamment précis pour pouvoir le tester. Ces quatre éléments constituent le contrat régissant le fonctionnement de l’agent — et, ce n’est pas un hasard, ce sont vos quatre principes fondamentaux transformés en règles de développement : apprenez ce qu’il fait, améliorez-le au fur et à mesure, veillez à ce qu’il reste performant, et assurez-vous qu’il serve la personne de l’autre côté.

Prenez l’agent que vous allez créer. Écrivez sa ligne « il ne doit jamais… » — la seule action que, s’il la commettait de son propre chef, vous regretteriez le plus. Maintenant : s’agit-il actuellement d’un obstacle dans la configuration, ou simplement de quelque chose que vous espérez qu’il ne fera pas ?

Suivant

Les garde-fous écrits constituent une affirmation. Les tests permettent de vérifier s’ils tiennent la route — et, pour les agents en contact avec des personnes, de détecter les biais que la conception seule ne peut pas repérer.

En marquant cette leçon comme terminée, vous enregistrez votre progression sur cet appareil — pas de compte, pas de suivi.

Partagé librement, en toute bonne foi. Si cela vous a été utile, un koha destiné à couvrir les coûts de développement et de fonctionnement est le bienvenu.

Laisser un koha →

Utile ? Partagez cette leçon avec un collègue.