La Description : bien construire

Objectifs

À l’issue de cette leçon, vous serez capable de :

• Traduire un besoin utilisateur en instruction précise pour l’IA grâce à la chaîne de Description
• Repérer une défaillance de description qui se propage, et remonter jusqu’au maillon qui a cédé
• Exprimer une intention par des tests qui disent exactement à l’IA à quoi ressemble la réussite

La Description ne se résume pas au prompt

Dans la leçon précédente, vous avez pris le temps de comprendre le problème avant de toucher à un outil : brief du problème, tests d’acceptation, répartition entre ce que vous gardez et ce que vous déléguez. Il faut maintenant transformer tout cela en quelque chose sur quoi l’IA peut agir.

La plupart des formations traitent la Description comme du prompt engineering. Ce cours la voit autrement : comme une compétence de haut niveau, qui couvre tout ce qui permet de résoudre le problème que vous avez défini. Elle restera pertinente bien après les astuces qui changent d’un modèle à l’autre.

La chaîne de Description

Avant l’implémentation, il faut définir le besoin. La chaîne de Description compte quatre étapes, liées aux capacités de votre boîte à outils, avec le builder comme traducteur au cœur de chacune. Prenons le projet fil rouge.

1. La parole de l’utilisateur. C’est ce qu’une vraie personne dit : « Je veux voir le temps d’attente avant d’aller au centre de santé. » Écoutez le ton, l’émotion. La phrase porte un contexte que la personne n’a pas formulé : cela fait déjà deux heures, il y a un enfant dans la voiture, elle hésite entre ce centre et les urgences à l’autre bout de la ville. Votre empathie sert à percevoir ce qui n’est pas dit. La parole de l’utilisateur est vraie, mais ce n’est encore que de la matière première : elle n’est pas constructible.

2. L’exigence produit. Vous transformez ce besoin brut en quelque chose de mesurable : « Les patients consultent une estimation du temps d’attente sur une page web adaptée au mobile, mise à jour toutes les cinq minutes. » Regardez ce que vous venez de faire : vous avez tranché. Adaptée au mobile, et non une application. Une estimation, et non un temps exact. Toutes les cinq minutes, et non en temps réel. Chacun de ces choix est un arbitrage fondé sur votre travail d’empathie. Des critères clairs et concrets aident l’IA à mieux faire son travail quand viendra l’implémentation.

3. La spécification technique. On entre dans la construction : « Une application web qui interroge l’API du centre pour obtenir les données d’attente et les affiche dans une interface responsive, rafraîchie toutes les cinq minutes. » C’est implémentable : un ingénieur, ou une IA, pourrait commencer à construire à partir de là. Mais il reste des zones ouvertes : quelle stack ? Comment gérer les erreurs ? Que se passe-t-il si l’API tombe ?

4. L’instruction à l’IA. Précise, contextualisée, avec ses contraintes et ses cas limites : la stack utilisée, la forme des données, le comportement en l’absence de données, les tests à réussir. Donnez à l’IA des éléments qu’elle peut vérifier elle-même : elle travaille alors plus efficacement, et plus longtemps.

Ce que l’IA ne peut pas entendre

Les builders qui décrivent soigneusement tous les aspects du problème obtiennent les meilleurs résultats : plus la Description est réfléchie, meilleur est le résultat. Car l’IA n’entend pas ce que l’utilisateur n’a pas dit. Elle ne peut pas décider qu’une estimation est la bonne exigence parce que des temps exacts mettraient le personnel sous pression. Elle ne peut pas savoir que la réactivité compte parce que les patients consultent la page en route. Vous, vous le savez. Votre travail consiste à transmettre ces éléments intacts quand vous décrivez à l’IA ce dont vous avez besoin.

Quand la traduction casse

Quand un maillon cède, l’échec a une signature : le code fonctionne, mais le produit, non. Les tests passent et l’utilisateur reste frustré. Ce n’est pas un bogue, c’est une défaillance de description, et elle se situe généralement en amont du prompt.

Une part de votre travail de builder est donc une enquête. Quand ce que vous avez construit manque sa cible, remontez la chaîne :

Les tests, forme la plus précise de description

Vos tests d’acceptation sont eux aussi une description, peut-être la plus puissante : un test bien écrit décrit une intention sans ambiguïté possible, puisqu’il passe ou ne passe pas. Quand vous donnez à l’IA des tests en même temps que votre prompt, vous ne lui dites pas seulement quoi construire : vous lui dites comment vous saurez qu’elle a réussi. Cela change ce que vous obtenez.

Et si un test passe alors que l’utilisateur est mécontent, ce n’est pas un échec : c’est l’information la plus utile qui soit. Votre test décrivait la mauvaise intention, et vous savez maintenant où chercher dans la chaîne.

À vous de jouer

Le projet « temps d’attente », partie 2. Reprenez votre brief du problème, votre plan de délégation et vos tests d’acceptation.

1. Écrivez l’exigence produit. Un paragraphe. Partez du besoin de votre brief et cadrez-le en quelque chose de mesurable. Chaque adjectif doit être une décision défendable : si vous écrivez « rapide », dites à quel point ; si vous écrivez « simple », décrivez ce que « simple » veut dire pour un patient qui consulte la page sur son téléphone, sur un parking.
2. Écrivez la spécification technique. Une demi-page : ce qui est construit, comment c’est structuré, les composants et la façon dont ils communiquent. Travaillez ici en mode augmentation : partagez votre exigence produit avec l’IA, demandez-lui de proposer une approche technique, puis contestez tout ce qui ne respecte pas vos contraintes.
3. Resserrez vos tests. Réécrivez vos tests d’acceptation pour que chacun puisse être réussi ou échoué par du code. Ajoutez au moins deux cas limites : centre fermé, absence de données, temps d’attente nul.
4. Écrivez vos prompts et construisez. Rédigez les instructions qui transforment votre spécification en code fonctionnel, avec vos contraintes, vos choix de stack et vos tests. Construisez une première version.
5. Faites une démonstration. Trouvez un partenaire qui joue un patient : il a un enfant malade et dix minutes devant lui. Donnez-lui votre version et regardez-le l’utiliser, sans rien expliquer ni aider.

Les tests passent-ils ? Le patient est-il satisfait ? Si les deux réponses divergent, à quel maillon de la chaîne revenez-vous ?

Questions de réflexion

• Quelle traduction de la chaîne de Description vous vient le plus naturellement ? Laquelle avez-vous tendance à expédier ?
• Lors de la démonstration, où était le plus grand écart entre ce que vous vouliez et ce que votre partenaire a vécu ?

Sources officielles : Description & building great things (Claude Academy, vidéo et sa transcription)

Points clés à retenir

• La chaîne de Description relie la parole de l’utilisateur à l’exigence, à la spécification technique, puis à l’instruction à l’IA : le prompt n’est qu’un maillon
• Le builder est le traducteur à chaque étape : l’IA n’entend pas ce que l’utilisateur n’a pas dit
• Un code qui marche pour un produit qui ne marche pas, c’est une défaillance de description : cherchez le maillon qui a cédé en amont
• Les tests sont la forme la plus précise de description ; un test qui passe face à un utilisateur mécontent signale une intention mal décrite
• Chaque étape demande des arbitrages que l’étape précédente n’a pas faits pour vous

Crédits et licence — Adaptation française de la leçon « Description & building great things » du cours « AI Fluency for Builders » de Claude Academy, l’académie d’Anthropic, créé par Anthropic en partenariat avec CodePath. Les supports d’origine sont © 2026 Anthropic, publiés sous licence CC BY-NC-SA 4.0 ; cette adaptation, qui les traduit et les remanie, est diffusée sous la même licence.