Avant de briefer un agent, écrivez un objectif avec un chiffre.

Le 29 septembre 2026, l’écran de caisse de Dot, mon application de fidélité, était lent. Un caissier à un comptoir bondé devait lancer une nouvelle attribution, toucher le montant, ouvrir un sélecteur de pays, choisir le pays, toucher le champ du téléphone et appuyer sur Générer. Six taps plus la saisie, et aucun champ n’était actif à l’ouverture de l’écran.

À 17 h 50 ce jour-là, une spécification de design est arrivée dans le dépôt. Elle contenait beaucoup : huit états d’écran, le texte de chaque erreur, la mise en page au pixel près. Le tableau qui comptait faisait quatre lignes et portait un titre simple : « Budget de taps ». Pour un client connu qui donne son numéro de téléphone, il avait deux colonnes. Aujourd’hui : six taps plus la saisie. Nouveau : deux taps plus la saisie.

Tout le reste de la spécification découlait de cette cellule. Deux taps, cela voulait dire que le caissier ne pouvait pas toucher pour passer d’un champ à l’autre. Les claviers numériques d’iOS n’ont ni touche Entrée ni touche Suivant. La seule façon d’économiser ce tap est de déplacer le focus automatiquement, et on ne peut le faire qu’à la sortie d’un champ de longueur connue. Un numéro de téléphone en a une. Un montant, non. La spécification a donc mis le téléphone en premier, et quand le dernier chiffre est saisi, le focus passe tout seul au montant.

À 19 h 13, le commit de build est arrivé, avec Claude comme coauteur : « phone first, two taps for a returning customer ». Une minute plus tard, le commit de test, lui aussi écrit avec Claude. Il ouvre la caisse sur un téléphone de 375 pixels, en arabe et en anglais, saisit le numéro d’un client connu et un montant, touche Ajouter des points, touche Client suivant, puis vérifie que la caisse est de nouveau vide et que le curseur est revenu dans le champ du téléphone. Le test s’appelle « takes a returning customer from idle to success in two taps ». La pull request a été fusionnée à 19 h 44.

Moins de deux heures entre la spécification et la fusion. Claude a coécrit le code et le test. Le chiffre disait aux deux ce que « terminé » voulait dire.

Que veut dire « partir de la fin » dans un design sprint ?

Le design sprint de GV est un processus de cinq jours pour répondre à des questions stratégiques par le design, le prototypage et des tests auprès de clients. Jake Knapp a commencé à mener des sprints chez Google en 2010 et les a apportés chez GV en 2012. Le lundi, on cartographie le problème. Le mardi, on esquisse. Le mercredi, on décide. Le jeudi, on construit un prototype. Le vendredi, on le teste avec de vraies personnes.

Le lundi matin vient en premier, et la description qu’en donne GV est courte : on part de la fin et on s’accorde sur un objectif à long terme. Puis on dresse une carte du défi, on demande aux experts de l’entreprise ce qu’ils savent, et on choisit une cible, une partie du problème assez petite pour être résolue en une semaine.

L’objectif revient le mercredi. À ce stade, l’équipe a une pile de solutions esquissées et ne peut en prototyper qu’une. Elle les passe donc toutes au crible et décide lesquelles ont le plus de chances d’atteindre l’objectif à long terme. L’objectif écrit le lundi est la règle utilisée le mercredi. Sans lui, le mercredi est un vote sur le goût.

GV attribue cette partie de la méthode à John Zeratsky. Selon leurs mots, il les a aidés à partir de la fin et à se concentrer sur la mesure des résultats avec les indicateurs clés de chaque entreprise. La fin vient d’abord, et la fin se mesure.

Mon guide du processus de design place la même étape en tête de la phase d’empathie, avant tout entretien : une phrase sur ce que le projet doit changer et sur la façon de savoir qu’il l’a fait, avec le chiffre qui le prouverait. Dans une équipe, cette phrase garde toute une salle orientée dans la même direction. Avec un agent, elle a un second rôle.

Un objectif de sprint doit-il avoir un chiffre ?

La plupart des guides répondent non, ou pas forcément. La page sur l’objectif à long terme du Design Thinking Toolkit, l’un des premiers résultats sur cette question, construit l’objectif en trois parties : un délai, une réalisation ambitieuse et précise, et un indicateur marqué comme facultatif. Ses exemples regardent des années en avant et ressemblent à « nous serons le premier choix pour ». Posez aujourd’hui la même question à ChatGPT ou à Perplexity et vous obtenez le même conseil, avec les chiffres sortis de l’objectif et rangés dans des critères de réussite à part.

Pour une salle de sprint, ce conseil tient. Une équipe passe cinq jours ensemble, porte le contexte dans sa tête et teste avec de vrais clients le vendredi. Ce sont les personnes présentes qui mesurent.

Un créateur seul avec un agent n’a pas de salle. On ne peut pas tenir un agent à un objectif visionnaire, car un objectif visionnaire ne renvoie jamais réussi ou échoué. « Des caissiers qui adorent » est une belle chose à croire. L’agent ne peut travailler que vers « deux taps ».

Gardez donc les deux, sur deux lignes. L’aspiration en haut, si elle vous aide, vous et votre équipe. Le chiffre juste en dessous, parce que c’est la ligne que l’agent, le test et le relecteur utiliseront vraiment. Le crédit que GV accorde à Zeratsky les joint déjà : partir de la fin, puis mesurer les résultats.

Pourquoi un agent a-t-il plus besoin d’un chiffre qu’une équipe ?

Une équipe répond. Donnez un objectif flou à cinq personnes et quelqu’un demandera ce que « plus rapide » veut dire. Un agent fait une version plausible du travail et s’arrête.

Anthropic le dit sans détour dans ses bonnes pratiques pour Claude Code : Claude s’arrête quand le travail a l’air terminé. Sans vérification qu’il peut lancer, « avoir l’air terminé » est le seul signal disponible, et c’est vous qui devenez la boucle de vérification. Chaque erreur attend que vous la remarquiez. La solution du guide : donner à Claude quelque chose qui renvoie réussi ou échoué, pour que la boucle se ferme d’elle-même. Claude fait le travail, lance la vérification, lit le résultat et continue jusqu’à ce qu’elle passe.

C’est un objectif avec un chiffre, vu du côté de l’agent. « Deux taps pour un client connu » peut réussir ou échouer. « Un paiement plus fluide » ne le peut pas.

Nous avons vu ce qui se passe sans chiffre en mai. Quand nous avons lancé ux-skill, le moteur de design que je construis, sur le brief de sa propre page d’accueil, ce brief n’était fait que d’adjectifs : éditorial, assuré, calme, cinématographique. Le moteur a obéi à chaque mot et a rendu presque exactement la page d’accueil de claude.ai, la réponse la plus probable de la catégorie. J’ai raconté cette histoire dans l’IA peut-elle remplacer la recherche utilisateur. Les adjectifs pointent vers une moyenne. Un chiffre pointe vers un lieu.

La commande /goal, plus récente chez Anthropic, dit la même chose sous forme de produit. Vous saisissez une condition d’achèvement, et après chaque tour un modèle distinct vérifie si elle est remplie. Sinon, Claude continue. La documentation indique qu’une condition qui tient sur de nombreux tours comporte en général trois parties : un état final mesurable, une vérification énoncée qui le prouve, et les contraintes qui comptent en chemin. Son exemple est « tous les tests de test/auth passent et l’étape de lint est propre ». On dirait exactement un objectif de sprint avec le chiffre renseigné.

Comment écrire un objectif avec un chiffre ?

Écrivez-le avant d’ouvrir l’agent. Une phrase, cinq parties.

Comment faire

1. La personne. Pour qui, dans un moment réel. « Un caissier fatigué à un comptoir bondé, une main sur le téléphone, une main sur le gobelet » est une personne. « Les utilisateurs » n’en est pas une.
2. Le résultat. Ce qu’elle parvient à faire. Pour la caisse : un client connu gagne des points.
3. Le chiffre. Comment vous saurez que cela a marché. Des taps, des secondes, des étapes, des erreurs, un pourcentage de personnes qui vont au bout. Choisissez-en un.
4. La valeur actuelle. Comptez-la sur le produit actuel avant d’écrire la cible. Six taps, c’était la caisse telle qu’elle était. Une cible sans point de départ est une supposition avec une décimale.
5. Comment on la mesure. Qui ou quoi la vérifie, et où. Pour la caisse, c’était un test de navigateur sur un téléphone de 375 pixels, dans les deux langues.

Mis bout à bout : « Un client connu gagne des points en deux taps plus la saisie, contre six auparavant, mesuré sur un téléphone de 375 pixels en arabe et en anglais. »

Le même schéma vaut pour un produit qui n’existe pas encore. Dans l’exemple Bunn que j’utilise dans mes modèles gratuits, l’énoncé du problème dit : Rana doit commander du café pour trois personnes en moins d’une minute, parce que la réunion de 10 h commence à l’heure. Moins d’une minute, c’est le chiffre. Bunn est fictif, mais la forme est celle que j’emploie sur du travail réel.

Ce que vous y gagnez : un filtre. Chaque fonctionnalité que l’agent propose fait soit bouger le chiffre, soit attendre. Chaque commentaire de relecture protège soit le chiffre, soit une préférence.

L’erreur courante : un objectif qui nomme une solution. « Construire une application de fidélité » et « ajouter un lecteur de QR code » sont des tâches. L’objectif, c’est ce à quoi la tâche sert. La spécification de la caisse a bien ajouté un bouton de scan, mais le chemin par scan a sa propre ligne dans le budget de taps, trois taps plus le montant, et il lui a donc fallu mériter sa place face à un chiffre, lui aussi.

La seconde erreur : un objectif avec cinq chiffres. Temps, taps, erreurs, satisfaction et conversion sur la même ligne, et l’agent peut toujours montrer celui qui a bougé. Choisissez le chiffre qui suit le résultat de la personne, comme le soutient personne ne veut de votre produit, et rangez les autres dans les contraintes.

D’où vient le chiffre ?

De la personne et du produit actuel, dans cet ordre.

Relisez ce que j’ai écrit pour Wfrah en 2023. Après dix entretiens avec des éleveurs, l’objectif était une expérience utilisateur qui éduque, qui inspire confiance dans les outils modernes et qui répond en même temps aux besoins des éleveurs traditionnels. C’est une bonne direction, et chaque mot venait de la recherche. En le relisant aujourd’hui, on n’y trouve aucun chiffre. Il pouvait nous dire dans quel sens marcher. Il ne pouvait pas nous dire quand nous étions arrivés.

Trois sources donnent un chiffre en lequel vous pouvez avoir confiance.

Comptez le produit actuel. Les six taps, c’était l’ancienne caisse telle qu’elle était, inscrits dans la colonne « aujourd’hui » de la spécification, à côté de la cible. Faites-le avant la cible, car la cible ne signifie quelque chose qu’à côté du point de départ. Sur un produit avec des analyses, le point de départ est déjà dans un tableau de bord comme celui de Bysooq plus haut. Sur un nouveau produit, c’est le temps que les gens mettent avec ce qu’ils utilisent aujourd’hui.

Prenez-le dans le moment de la personne. Les deux taps venaient du caissier et du clavier. Une main tient le gobelet, la file attend, la lumière est faible le soir, et un clavier de téléphone n’a pas de touche Suivant. Un chiffre qui vient du moment se défend facilement quand on demande pourquoi deux et pas quatre.

Prenez-le dans la recherche déjà faite. Si les entretiens montrent que les gens abandonnent la commande quand les frais apparaissent tard, le chiffre est le nombre de ceux qui la terminent. Si des gens échouent à une tâche dans un test d’utilisabilité, le chiffre est le nombre de ceux qui y arrivent.

Quand cela tourne mal : vous choisissez le chiffre le plus facile à mesurer. Les clics et les pages vues sont faciles. Savoir si le caissier a mené le client au bout est le seul qui compte.

Comment tenir l’agent à son chiffre ?

Inscrivez le chiffre à trois endroits, et vérifiez que les trois concordent.

Un : la première ligne du prompt. Avant le contexte, avant les fichiers, avant les règles de style. Un brief qui s’ouvre sur l’objectif et se ferme sur la vérification garde les deux en vue. Voici la forme que j’emploierais pour la caisse, donnée en exemple :

Objectif : un client connu gagne des points en 2 taps plus la saisie, contre 6.
Vérification : un test de navigateur sur un téléphone de 375px, en arabe et en anglais,
qui échoue si le parcours demande plus de 2 taps. Lance-le et montre-moi la sortie.
Contraintes : ne jamais effacer ce que le caissier a saisi. Un nouvel essai n’attribue jamais deux fois.
Pas d’envoi automatique au retour de la connexion.
Spécification : la spécification de la caisse, section 1.

Deux : un test qui échoue tant que le chiffre n’est pas atteint. C’est la partie qui transforme un objectif en laisse. Pour la caisse, le commit de test est arrivé une minute après le commit de build, et son nom est l’objectif. Le guide d’Anthropic liste les options, de la plus souple à la plus stricte : demander à Claude de lancer la vérification dans le même prompt, la fixer comme condition /goal pour toute une session, ou en faire un hook Stop, un script qui empêche le tour de se terminer tant que la vérification ne passe pas. Chaque palier échange de la mise en place contre de l’attention.

Trois : la relecture. Le guide recommande un relecteur qui travaille dans un contexte neuf et ne voit que le diff et les critères que vous lui donnez, pas le raisonnement qui a produit le changement. Donnez-lui l’objectif comme critère. Il posera la seule question que l’auteur a oubliée : cela prend-il vraiment deux taps ?

Demandez des preuves plutôt qu’une affirmation : la sortie du test, la commande, une capture d’écran. Les tests de la caisse enregistrent quatorze captures des états du comptoir, en arabe et en anglais, dont deux en mode sombre.

Que se passe-t-il quand le chiffre devient la cible ?

L’économiste Charles Goodhart a remarqué en 1975 qu’une statistique tend à s’effondrer dès qu’on exerce une pression sur elle pour contrôler quelque chose. L’anthropologue Marilyn Strathern l’a ensuite formulé comme la plupart le citent : quand une mesure devient une cible, elle cesse d’être une bonne mesure. La loi de Goodhart s’applique aux agents plus qu’aux personnes, car un agent pousse sur le chiffre sans savoir pourquoi il existe.

Dites à un agent « deux taps » et rien d’autre, et il existe des moyens bon marché d’y arriver. Envoyer automatiquement au retour de la connexion. Supprimer la confirmation. Sauter l’annulation. Chacun retire un tap et casse la caisse.

La spécification de Dot vaut d’être lue pour ce qu’elle a refusé. Elle dit qu’il n’y a pas d’envoi automatique au retour de la connexion : le bouton revient et le caissier retouche, car il a pu passer à autre chose et une attribution tardive et silencieuse est pire qu’un tap de plus. Elle dit de ne jamais effacer ce que le caissier a saisi en cas d’erreur. Elle donne à chaque tentative une clé d’idempotence, de sorte qu’un double tap nerveux ne peut jamais attribuer les points deux fois, et il existe un test pour cela. Elle garde une annulation de dix minutes avec un motif obligatoire. Chacune de ces règles coûte des taps ou du code, et chacune est écrite à côté du chiffre.

C’est la réponse à Goodhart. L’objectif a un chiffre. Les contraintes portent tout ce que le chiffre ne voit pas.

Que mettre dans les contraintes

• Ce qui ne doit jamais arriver. Une saisie perdue, un double débit, un échec silencieux.
• Ce que le chiffre n’a pas le droit de sacrifier. L’accessibilité, l’annulation, le message d’erreur qui nomme le champ et la correction.
• Où le changement doit s’arrêter. Les fichiers à ne pas toucher, le comportement qui doit rester identique.

Si vous ne pouvez pas lister au moins deux contraintes, vous ne comprenez pas encore assez bien le chiffre pour le confier à un agent.

Le mode plan est-il mort ?

Le 24 septembre 2026, Ayman Nadeem a publié Plan mode is dead. Le billet a atteint 591 points sur Hacker News. Son argument : les modes plan avaient du sens quand les modèles demandaient à être guidés, et les étapes séparées de discussion, spécification, relecture, validation et mise en œuvre paraissent aujourd’hui artificielles. Personne ne lit de longues spécifications générées. Le travail suit plutôt un cycle : comprendre, agir, inspecter, clarifier, ajuster, agir de nouveau. On planifie toujours. Il n’est simplement pas nécessaire que cela prenne la forme d’un document appelé le plan.

Il a surtout raison sur les plans. Le guide d’Anthropic lui-même dit que si vous pouvez décrire le diff en une phrase, vous pouvez sauter le plan.

Voyez ce que l’argument conserve. Nadeem écrit que réfléchir à ce qu’on construit, à pourquoi cela compte, et évaluer les décisions reste important. Le fil Hacker News s’est partagé le long de la même ligne. Un commentateur, thiht, a écrit que le mode plan aide à s’assurer que le modèle fera bien ce qu’on a en tête. Un autre, loeg, a décrit l’alternative : le modèle fait quelques choix plausibles, et on peut lui demander d’en faire d’autres plus tard.

L’essai de Simon Späti, de la même semaine, the problem is not the AI code, nomme ce qui disparaît quand le plan s’efface complètement : les équipes ne savent plus quelle intention se cachait derrière les choix. Sa formule est franche. On finit sans aucun plan.

Ma position se situe entre les deux. Abandonnez le plan s’il vous ralentit. Gardez l’objectif. Un plan décrit la route et se périme dès le premier tour du cycle. Un objectif décrit la destination, il survit donc à chaque tour. Comprendre, agir, inspecter, ajuster : chacune de ces étapes a besoin de quelque chose à quoi comparer, et ce quelque chose est une ligne avec un chiffre dedans. La spécification de Dot compte 385 lignes. Ce qui a fixé le build, c’est le tableau de quatre lignes.

Quand ne faut-il pas écrire de chiffre ?

Quand la question est encore ouverte. Certains travaux relèvent de l’exploration, et leur imposer un chiffre trop tôt mesure très précisément la mauvaise chose.

Le goût. Qu’une carte fasse l’effet d’un lieu, ou qu’une marque ressemble à ses gens, ne se réduit pas à un décompte. Vous pouvez quand même fixer un cadre : trois directions à comparer, une échéance, une personne qui tranche. Le jugement reste humain, et le rôle de l’agent est de produire vite des options.

La découverte. Avant les entretiens, on ignore souvent quel chiffre compte. Chez Wfrah, nous n’aurions pas pu écrire « les éleveurs calculent la ration en moins d’une minute » avant d’avoir compris que le calcul était le problème. À ce stade, l’objectif est une question, et le chiffre que vous écrivez est le nombre de personnes à qui vous parlerez.

Quand le chiffre serait faux. Si vous ne pouvez pas le mesurer sur ce produit, dans cette version, c’est de la décoration. « Augmenter la rétention de 20 pour cent » sur une fonctionnalité qui sort la semaine prochaine ne dit rien à l’agent qu’il puisse vérifier. Choisissez quelque chose qu’il peut lancer.

Que change un produit en arabe ?

Une recherche de textes sur la définition d’objectifs pour des produits arabes ou de droite à gauche n’a rien donné. Ce vide compte, car un chiffre vérifié dans une langue ne l’est pas dans l’autre.

Le test de la caisse déroule deux fois le même parcours en deux taps, une fois en arabe et une fois en anglais. Les vérifications visuelles de la spécification incluent des détails de droite à gauche qu’un test monolingue manquerait : la ligne du numéro de téléphone reste de gauche à droite même sur un écran arabe, parce que c’est ainsi qu’on énonce un numéro à voix haute, et le montant s’aligne à droite. Les lignes arabes et anglaises se coupent rarement au même endroit, si bien qu’une mise en page qui passe en anglais peut repousser un bouton sous la ligne de flottaison en arabe.

Écrivez la langue dans l’objectif. « Deux taps, en arabe et en anglais » est un autre objectif que « deux taps », et l’agent testera ce que vous écrivez. Quand nous avons vérifié 179 startups financées de la région MENA, 44 pour cent n’avaient aucun site en arabe. L’arabe oublié dans l’objectif a tendance à l’être aussi dans le produit.

Quels modèles aident ?

Chaque modèle gratuit existe en arabe et en anglais et s’appuie sur un seul exemple suivi, Bunn.

Les quatre figurent aussi dans UX AI Kit Pro Max, avec des prompts Claude pour chacun.