D2 · Defining Objectives and Tasks

C’est l’un des deux domaines les plus lourds — 18 %, environ 9 des 50 items de notre examen blanc. Il teste si vous savez transformer un souhait en un brief qu’un agent peut réellement exécuter et que vous pouvez réellement vérifier. La plupart des délégations ratées se décident ici : un agent à qui l’on donne un objectif vague produit un travail vague, et vous ne pouvez pas dire s’il a réussi parce que vous n’avez jamais dit ce qu’était le succès. La compétence que ce domaine récompense est d’écrire l’objectif, pas d’écrire le prompt.

Ce qu’il faut savoir

Un objectif délégable a cinq parties : un but (le résultat, énoncé comme un aboutissement et non une liste de tâches), une définition de « terminé » (le test d’acceptation que vous vérifierez), des contraintes (ce qu’il doit et ne doit pas faire), des sources de vérité (quelles entrées font autorité) et des points de contrôle (là où il fait une pause pour vous). Le but dit quoi ; la définition de « terminé » dit comment vous le saurez ; les contraintes et les sources bornent comment ; les points de contrôle contrôlent quand vous pouvez orienter. Quand un objectif est ambigu, le bon geste n’est presque jamais de laisser l’agent deviner — c’est d’affiner le brief, ou d’ordonner à l’agent de demander avant de poursuivre sur le point ambigu. Un bon brief est celui que vous pourriez remettre à une nouvelle recrue compétente qui ne posera pas de questions de clarification.

Objectifs d’apprentissage

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

1. Écrire un objectif comme un résultat avec une définition de « terminé » testable.
2. Séparer les contraintes du but, et les contraintes fermes des préférences.
3. Nommer les sources de vérité qu’un agent devrait traiter comme faisant autorité, et les classer quand elles se contredisent.
4. Placer les points de contrôle là où le risque ou l’incertitude est le plus élevé.
5. Gérer un objectif ambigu sans laisser l’agent deviner silencieusement.
6. Diagnostiquer une délégation ratée comme un défaut de brief avant de blâmer le modèle.

2.1 But : énoncez le résultat, pas les frappes clavier

L’erreur de briefing la plus fréquente est de décrire les étapes que vous suivriez au lieu du résultat que vous voulez. Les étapes contraignent un agent à votre chemin et l’empêchent de s’adapter ; un résultat le laisse planifier tout en restant vérifiable.

2.2 Définition de « terminé » : le test d’acceptation

La définition de « terminé » est ce qui sépare une tâche délégable d’un souhait. C’est la checklist que vous ferez tourner contre le résultat — elle doit donc être observable, pas un ressenti.

BUT :  Produire une synthèse de la tarification concurrente pour le deck de direction.

DÉFINITION DE « TERMINÉ » (vérifiable) :
  [ ] Couvre les quatre concurrents nommés
  [ ] Un point de prix par palier de produit, sourcé sur une page publique avec un lien
  [ ] Une ligne « ce qui a changé depuis le trimestre dernier » par concurrent
  [ ] Tient sur une slide (≤ 6 puces)
  [ ] Signale tout chiffre qu’il n’a pas pu vérifier plutôt que de deviner

Une bonne définition de « terminé » fait trois choses : elle dit à l’agent quand s’arrêter, elle vous dit quoi vérifier, et — crucialement — elle dit à l’agent quoi faire quand il ne peut pas satisfaire un critère (le signaler, ne pas le fabriquer). Comparez à « fais une synthèse de tarification », où aucune des parties ne sait ce que « terminé » signifie.

2.3 Contraintes : règles fermes contre préférences

Les contraintes bornent comment le travail est fait. La distinction critique est entre les contraintes fermes (les violer rend la sortie inutilisable ou dangereuse) et les préférences (un plus). Un agent qui traite une préférence comme ferme gaspille des efforts ; un agent qui traite une contrainte ferme comme une préférence produit un travail inutilisable ou dangereux.

Écrivez les contraintes fermes comme des interdictions que l’agent doit respecter (must not, only, never) et marquez les préférences comme telles. D2 développe le point supplémentaire qu’une contrainte ferme sur une action irréversible doit souvent être imposée par le système, pas simplement énoncée dans le brief.

2.4 Sources de vérité : ce qui fait autorité

Un agent mélangera volontiers un chiffre faisant autorité avec un chiffre périmé du web ouvert, à moins que vous ne lui disiez quelle source l’emporte. Nommer les sources de vérité — et les classer — est ce qui maintient une délégation ancrée.

        ordre de résolution des conflits (exemple)
        ┌────────────────────────────────────────┐
   1 ►  │ le document que j’ai joint à cette tâche  │  fait le plus autorité
   2 ►  │ connaissance / politique entreprise approuvée │
   3 ►  │ le système de référence en direct (tickets, CRM) │
   4 ►  │ le web public                             │  le moins — et signaler
        └────────────────────────────────────────┘

2.5 Points de contrôle : où faire une pause pour un humain

Les points de contrôle sont les points d’orientation que vous intégrez dans l’objectif. Ils appartiennent là où l’incertitude ou le risque est le plus élevé — pas régulièrement espacés, et pas uniquement à la fin. Un point de contrôle à la fin est une revue ; un point de contrôle en cours d’exécution est une chance de corriger le cap avant que le travail gaspillé ne s’accumule.

Le point de contrôle « un avant plusieurs » est le plus précieux de cet examen : faites faire à l’agent le premier item, faites une pause, laissez-le approuver l’approche, puis exécutez le reste. Cela convertit une erreur en cinquante exemplaires en une erreur unique.

2.6 Gérer un objectif ambigu

Quand l’objectif est ambigu, laisser l’agent choisir silencieusement une interprétation est la mauvaise réponse presque à chaque fois. Il y a trois gestes légitimes, par ordre de préférence :

1. Résolvez-le vous-même avant de déléguer — le correctif le moins cher quand vous connaissez la réponse.
2. Ordonnez à l’agent de demander sur le point ambigu spécifique avant de poursuivre (un point de contrôle sur la bifurcation).
3. Énoncez une hypothèse explicite que l’agent doit faire et faire remonter, pour que vous puissiez en saisir une mauvaise à la revue.

L’objectif est ambigu
│
├─ Est-ce que je connais la bonne interprétation ? ── oui ─► résolvez-le dans le brief
├─ Est-ce une bifurcation unique et identifiable ? ── oui ─► dites à l’agent de faire une pause et de demander
└─ De nombreuses petites inconnues que je ne peux pas préanswer ? ─► dites-lui d’énoncer ses hypothèses
                                                      et de les signaler pour revue

La réponse piège est « laissez l’agent décider et allez vite ». La vitesse achetée par une mauvaise hypothèse non énoncée est une fausse économie — vous la remboursez en reprise, et pire si l’hypothèse a conduit à une action irréversible.

2.7 Une délégation ratée est d’abord un défaut de brief

Quand un agent renvoie la mauvaise chose, la réponse disciplinée est d’interroger le brief avant le modèle. La plupart des échecs correspondent à un élément de brief manquant.

Cet état d’esprit — le brief d’abord, le modèle ensuite — est développé pleinement en D6. Ici, le point est qu’un objectif solide prévient la plupart des échecs avant qu’ils ne surviennent.

Cadre de décision

Utilisez le brief GDCSC — Goal, Done, Constraints, Sources, Checkpoints (But, Terminé, Contraintes, Sources, Points de contrôle) — comme modèle en cinq parties pour chaque délégation. Si une ligne est vide, la tâche n’est pas prête à déléguer.

Appliquez-le demain : prenez toute tâche que vous délégueriez, remplissez les cinq lignes, et ne déléguez que quand aucune n’est vide. Une ligne vide est exactement là où la délégation échouera.

Erreurs fréquentes

Mise en situation

Scénario. Devon, un chef de produit marketing sur ChatGPT Work, délègue : « Assemble une synthèse concurrentielle de la tarification de nos principaux concurrents pour le deck du conseil la semaine prochaine. » Une heure plus tard, l’agent renvoie un document de deux pages. Il couvre trois concurrents (Devon en a quatre), mélange des prix actuels avec des chiffres qui s’avèrent vieux d’un an, invente un prix pour un palier qu’il n’a pas trouvé, et est écrit en prose fluide qui ne tiendra pas sur une slide. Le premier réflexe de Devon est que l’agent « n’est pas assez bon » et il demande si un modèle plus capable le corrigerait.

Trace de raisonnement d’expert.

1. Interrogez le brief avant le modèle. Chaque échec ici correspond à un élément GDCSC manquant, donc un modèle plus grand produirait les mêmes erreurs de forme plus vite. C’est un défaut de brief, pas un défaut de capacité.
2. Défaut de but. « Assemble une synthèse concurrentielle » est une tâche, pas un résultat — il n’y a aucun énoncé de ce que l’artefact fini doit contenir, donc l’agent a choisi son propre périmètre et s’est arrêté à trois concurrents.
3. Défaut de définition de « terminé ». Aucun test d’acceptation signifiait que rien n’a vérifié la couverture des quatre concurrents, un prix par palier, ou la tenue sur une slide. « Terminé » a été laissé au jugement de l’agent.
4. Défaut de sources de vérité. Aucune source faisant autorité n’a été nommée, donc l’agent a mélangé librement chiffres actuels et vieux d’un an — le symptôme classique de source manquante.
5. Défaut de gestion de l’échec. Rien n’a dit à l’agent quoi faire quand il ne trouvait pas de prix, donc il en a fabriqué un au lieu de signaler le manque.
6. Défaut de contrainte/format. Aucune contrainte de format (« tient sur une slide, ≤ 6 puces ») signifiait qu’il a produit deux pages de prose.
7. Le correctif. Réécrivez l’objectif avec les cinq lignes GDCSC : but = une synthèse de tarification concurrente d’une slide ; terminé = les quatre concurrents, un prix sourcé par palier, une ligne changement-depuis-le-trimestre-dernier, ≤ 6 puces, manques signalés et non comblés ; sources = la feuille de tarification partagée d’abord, puis la page publique du concurrent, signaler tout non vérifiable ; contraintes = seulement la tarification publique, jamais les conditions de deal internes ; point de contrôle = pause après le premier concurrent pour que Devon approuve le motif avant que l’agent fasse les trois autres.

Le point clé. Un modèle plus capable était le mauvais levier. La délégation a échoué parce qu’il manquait quatre de ses cinq parties au brief ; corriger le brief corrige la sortie, et le point de contrôle « un avant plusieurs » aurait saisi les problèmes de périmètre et de format après un concurrent au lieu d’après tous.

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

• Un objectif délégable a cinq parties — But, Terminé, Contraintes, Sources, Points de contrôle (GDCSC) ; une ligne vide est là où la délégation échouera.
• Énoncez le résultat, pas les frappes clavier ; les étapes contraignent l’agent et masquent le test d’acceptation.
• La définition de « terminé » est une checklist observable, bornée et consciente de l’échec — elle dit à l’agent quand s’arrêter et à vous quoi vérifier.
• Distinguez les contraintes fermes (must/never) des préférences ; les agents doivent savoir lesquelles ils peuvent outrepasser.
• Nommez et classez les sources de vérité ; des données périmées et actuelles mélangées sont un symptôme de source manquante, pas un problème de modèle.
• Placez les points de contrôle là où le risque est le plus élevé — avant les étapes irréversibles et avant de passer à l’échelle d’un item à plusieurs.
• Gérez l’ambiguïté en la résolvant, en disant à l’agent de faire une pause et de demander, ou en lui faisant remonter les hypothèses — jamais en le laissant deviner silencieusement.
• Diagnostiquez une délégation ratée comme un défaut de brief d’abord ; un modèle plus grand corrige rarement un objectif vague.