D6 · Reliability and Iteration

Vaut 16 % — environ 8 des 50 items. Ce domaine de clôture teste si vous savez rendre une délégation fiable, pas simplement réussie une fois. Un brief qui a marché aujourd’hui par chance échouera demain sur une entrée légèrement différente. La fiabilité vient du fait de nommer les échecs précisément (une taxonomie), de les rendre visibles (l’instrumentation), et d’itérer le brief sur la cause réelle plutôt que de deviner. Elle rassemble toute la piste : chaque échec ici remonte à un manque dans l’objectif (D2), le contexte et l’accès (D3), les limites (D4) ou la vérification (D5).

Ce qu’il faut savoir

Les échecs d’agent tombent dans une petite taxonomie : objectif mal compris, contexte manquant, mauvais outil ou accès, complétion partielle silencieuse et dérive sur les longues exécutions. Chacun a un correctif différent et une cause amont différente, donc nommer l’échec est la première étape pour le corriger. L’instrumentation signifie exécuter les délégations de sorte que les échecs soient visibles — capturer le plan, la piste de preuves, les points de contrôle et les résultats — car vous ne pouvez pas itérer sur un échec que vous ne pouvez pas voir. Itérer un brief de délégation signifie changer une chose à la fois selon la cause diagnostiquée : affiner l’objectif, ajouter le contexte manquant, ajuster l’accès, ajouter un point de contrôle, ou renforcer la vérification. La discipline est : diagnostiquez la cause, changez le brief (pas le modèle, d’ordinaire), et retestez — transformant un succès chanceux en un succès répétable.

Objectifs d’apprentissage

À la fin de cette page, vous devriez être capable de :

1. Classer un échec d’agent à l’aide de la taxonomie à cinq modes.
2. Tracer chaque mode d’échec jusqu’à sa cause amont et le domaine qui le corrige.
3. Instrumenter une délégation pour que les échecs soient visibles plutôt que silencieux.
4. Itérer un brief en changeant une chose diagnostiquée à la fois et en retestant.
5. Distinguer une délégation fiable d’une qui a réussi par chance.
6. Décider quand le correctif est le brief, le contexte, les limites, ou (rarement) le modèle.

6.1 La taxonomie des échecs

Un débogage vague (« l’agent n’a pas marché ») mène à des correctifs vagues (« essayez un meilleur modèle »). Une classification précise mène à des correctifs précis. Apprenez ces cinq modes par cœur — la plupart des items d’examen vous demandent d’en nommer un et de choisir son correctif.

   L’agent a échoué. Quel mode ?
   ├─ mauvaise chose ?      ─► OBJECTIF MAL COMPRIS       → affiner le but (D2)
   ├─ générique / hors marque ? ─► CONTEXTE MANQUANT      → fournir le contexte (D3)
   ├─ calé / mauvaises données ? ─► MAUVAIS OUTIL/ACCÈS   → corriger le provisionnement (D3)
   ├─ « terminé » mais non ? ─► COMPLÉTION PARTIELLE SILENCIEUSE → ajouter vérif. de « terminé » (D2/D5)
   └─ dégradé avec le temps ? ─► DÉRIVE                   → points de contrôle/périmètre (D4)

6.2 La complétion partielle silencieuse, examinée

Ce mode mérite son propre traitement parce que c’est le plus dangereux : l’agent rapporte un succès alors qu’il n’a fait qu’une partie du travail, donc rien ne signale un problème. C’est l’échec pour attraper lequel la vérification de D5 existe.

Le correctif de fiabilité est un brief qui rend le silence impossible : « traite les N items ; pour tout item que tu ne peux pas compléter, liste-le et pourquoi ». Combinée à la vérification de couverture de D5, la complétion partielle silencieuse devient une complétion partielle attrapée.

6.3 Dérive sur les longues exécutions

Sur une longue exécution non observée, un agent peut graduellement dévier — perdant le fil de l’objectif, sur-élaborant, ou étant tiré hors tâche par quelque chose qu’il a trouvé. La dérive est une fonction de la durée et du manque d’ancrage.

   exécution courte             longue exécution sans ancrage
   ────────────────             ───────────────────────────
   objectif reste net       │   objectif se brouille lentement
   sortie reste sur la tâche│   sortie dévie / sur-élabore
   facile de garder le cap  │   chaque étape dérive un peu plus loin
                            │   → ajoutez des points de contrôle ; cadrez l’exécution ;
                            │     découpez en délégations plus courtes

Les correctifs de la dérive sont structurels, pas motivationnels : des points de contrôle qui réancrent à l’objectif, le cadrage de l’exécution en morceaux plus courts et bornés, et le motif un→plusieurs pour qu’un motif dérivant soit attrapé après un item. Dire à l’agent « reste concentré » est une limite respectée et ne tiendra pas sur une longue exécution.

6.4 Instrumentation : vous ne pouvez pas corriger ce que vous ne pouvez pas voir

L’instrumentation signifie exécuter les délégations de sorte que leur comportement soit observable — le plan, les étapes et outils utilisés, les points de contrôle, la piste de preuves, et le résultat contre la définition de « terminé ». Sans elle, un échec n’est que « ça n’a pas marché », et vous devinez le correctif.

L’état d’esprit : traitez une délégation comme un processus que vous pouvez inspecter, pas une boîte noire qui émet une réponse. Quand elle échoue, l’instrumentation vous dit dans quel mode de la taxonomie vous êtes — ce qui vous dit le correctif.

6.5 Itérer le brief : un changement à la fois

L’itération est disciplinée, pas frénétique. La règle est diagnostiquer, changer une chose, retester. Changer plusieurs choses à la fois signifie que vous ne saurez pas laquelle a corrigé (ou laquelle a empiré), et la fiabilité ne s’accumule jamais.

   1. OBSERVEZ   l’échec (via l’instrumentation)
   2. CLASSEZ    (taxonomie)
   3. TRACEZ     jusqu’à la cause amont (quel domaine)
   4. CHANGEZ    exactement une chose dans le brief/contexte/accès/limites
   5. RETESTEZ   sur la même entrée, puis sur une entrée variée
   6. répétez jusqu’à la fiabilité sur des entrées variées

Le modèle est le dernier levier, pas le premier — la plupart des échecs sont des défauts de brief, de contexte, d’accès ou de limites. Saisir un modèle plus grand avant de diagnostiquer est le plus fréquent anti-motif de fiabilité.

6.6 Fiable contre chanceux

Une délégation qui a marché une fois a pu marcher par chance : l’entrée s’est trouvée facile, l’ambiguïté s’est résolue dans le sens que vous vouliez. La fiabilité signifie qu’elle marche sur des entrées variées, y compris les délicates.

Le test de fiabilité : relancez la délégation sur une entrée différente, plus difficile. Si elle satisfait encore la définition de « terminé », le brief est fiable ; si elle échoue, vous avez trouvé la prochaine chose à itérer. Un succès unique est une hypothèse, pas un résultat.

Cadre de décision

Utilisez la boucle LEARN pour transformer toute délégation ratée ou chanceuse en une fiable : Locate (localiser le symptôme), Examine (examiner l’instrumentation), Attribute (attribuer à un mode de la taxonomie), Revise (réviser une chose), retester sur une Nouvelle entrée (New input).

Appliquez-le demain : la prochaine fois qu’une délégation déçoit, résistez à changer le modèle. Faites tourner LEARN, changez une chose diagnostiquée, et prouvez la fiabilité sur une seconde entrée.

Erreurs fréquentes

Mise en situation

Scénario. Sofia a mis en place un agent sur ChatGPT Work pour trier les factures fournisseurs entrantes de son équipe : extraire le montant, le faire correspondre à un bon de commande, et produire une table de synthèse pour approbation. Il a marché magnifiquement sur son premier test — une facture propre, correspondance parfaite. Elle l’a déployé pour les cinquante factures de la semaine. Les résultats sont un désastre : certains montants sont faux, plusieurs factures manquent entièrement de la table bien que l’agent ait rapporté « toutes les factures traitées », et les entrées ultérieures dérivent vers une mise en forme incohérente et un commentaire éditorial occasionnel sur les fournisseurs. Son réflexe est de conclure que les agents « ne sont pas assez fiables pour la finance » et d’essayer le modèle le plus capable.

Trace de raisonnement d’expert.

1. Rejetez le réflexe du modèle-d’abord. Un modèle plus grand produira les mêmes échecs de forme plus vite, car aucun de ces symptômes n’est un problème de capacité brute. Diagnostiquez avant de dépenser.
2. Classez chaque symptôme avec la taxonomie. Montants faux → probablement contexte manquant ou mauvaise source (quel document/champ fait autorité ?) — un problème D3. Factures manquantes avec une affirmation « tout traité » → complétion partielle silencieuse — un problème D2/D5. Entrées ultérieures dérivant vers une mise en forme incohérente et un commentaire éditorial → dérive sur la longue exécution — un problème D4/D6. Trois modes distincts, trois correctifs distincts.
3. Voyez pourquoi le premier test l’a induite en erreur. Une facture propre était le cas chanceux : aucune ambiguïté, exécution courte, aucune échelle. La fiabilité se prouve sur des entrées variées, et elle a sauté cette étape.
4. Instrumentez pour confirmer. Elle examine l’exécution : le journal d’étapes montre que l’agent a lu 43 des 50 factures (confirmant la complétion partielle silencieuse), extrait des montants d’un champ incohérent (confirmant le problème de source), et n’avait aucun point de contrôle sur la longue exécution (expliquant la dérive).
5. Itérez un changement à la fois. Elle ne réécrit pas tout d’un coup. D’abord : corriger la source de vérité — spécifier exactement quel champ contient le montant et quel système contient le bon de commande (D3), et retester. Puis : ajouter une définition de « terminé » exigeant que les 50 soient traitées avec toute facture qu’elle n’a pas pu faire correspondre explicitement listée (D2/D5), et retester. Puis : ajouter un point de contrôle après la première facture (approuver le motif) et cadrer l’exécution pour que la dérive ne puisse pas s’accumuler (D4), et retester.
6. Prouvez la fiabilité, pas la chance. Après chaque changement, elle reteste sur un ensemble varié — une facture propre, une désordonnée, une sans bon de commande correspondant — jusqu’à ce que la délégation satisfasse la définition de « terminé » sur toutes. Ce n’est qu’alors qu’elle est digne de confiance pour l’exécution hebdomadaire.

Le point clé. « Les agents ne sont pas fiables pour la finance » était la mauvaise conclusion. La délégation présentait trois modes d’échec séparés et nommables, chacun avec un correctif au niveau du brief ; un modèle plus capable n’en traitait aucun. La fiabilité est venue de l’instrumentation de l’exécution, de la classification de chaque échec, de l’itération d’un changement à la fois, et de sa preuve sur des entrées variées plutôt que de faire confiance à un succès chanceux unique.

Pièges de l’évaluation

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Essayez avant de révéler.

À retenir

• Apprenez la taxonomie des échecs à cinq modes — objectif mal compris, contexte manquant, mauvais outil/accès, complétion partielle silencieuse, dérive — car nommer le mode pointe vers le correctif.
• Chaque mode remonte à un domaine amont : objectif (D2), contexte/accès (D3), limites (D4), vérification (D5).
• La complétion partielle silencieuse est le mode le plus dangereux ; battez-le avec une exigence de couverture dans la définition de « terminé » plus une vérification de couverture de D5.
• La dérive sur les longues exécutions nécessite des correctifs structurels — points de contrôle et périmètre plus court — pas « rester concentré ».
• Instrumentez les délégations pour que les échecs soient visibles ; vous ne pouvez pas corriger ce que vous ne pouvez pas voir.
• Itérez un changement à la fois, en traçant jusqu’à la cause diagnostiquée ; le modèle est le dernier levier, pas le premier.
• Un succès unique est une hypothèse — prouvez la fiabilité en retestant sur des entrées variées, plus difficiles.
• Utilisez la boucle LEARN (Locate, Examine, Attribute, Revise, New input) pour transformer une délégation chanceuse ou ratée en une fiable.