Vous avez soigné votre prompt. Le plan paraît limpide. Et pourtant le résultat rate sa cible. La question naïve, celle que tout praticien se pose en silence, mérite d’être posée franchement : à qui la faute ?
Thariq Shihipar, développeur chez Anthropic, avance une réponse inconfortable. Avec Fable 5, le dernier modèle de Claude, la limite n’est plus la machine. C’est vous.
Quand la compétence se déplace du prompt vers l’introspection
Pendant des années, on a optimisé le contenant : mieux formuler, découper les consignes, empiler les exemples. Le pari implicite était que le modèle constituait le maillon faible. Shihipar affirme que Fable 5 est le premier modèle où la qualité de sortie bute non plus sur ses capacités, mais sur votre aptitude à clarifier ce que vous ignorez.
Le déplacement est subtil mais profond. La compétence utile n’est plus rédactionnelle, elle devient introspective. Savoir prompter comptait ; savoir ce qu’on ne sait pas compte désormais davantage.
Quatre cases pour cartographier son ignorance
Pour rendre l’idée opérationnelle, Shihipar reprend une grille classique de la gestion du risque et l’applique au travail avec un agent. Elle range votre connaissance d’un problème en quatre cases.
- Les known knowns : ce que vous savez et que vous avez déjà écrit dans le prompt.
- Les known unknowns : les questions que vous savez encore ouvertes, celles que vous identifiez sans les avoir tranchées.
- Les unknown knowns : ce savoir tellement évident que vous ne pensez jamais à le formuler, mais que vous reconnaîtriez aussitôt sous les yeux.
- Les unknown unknowns : ce à quoi vous n’avez pas songé une seconde. La case critique.
Une image aide à la saisir. Un guide de montagne expérimenté ne connaît pas seulement le chemin : il sait deviner les passages qu’il ne connaît pas et prévoit d’y ralentir. Shihipar note que les meilleurs développeurs agentiques (ceux qui pilotent des agents IA) ont peu d’inconnues, mais s’attendent toujours à en rencontrer. Le débutant, lui, croit son plan complet.
Pourquoi trop de précision se retourne contre vous
La tentation inverse guette : tout spécifier, ne rien laisser au modèle. Elle coûte tout aussi cher, prévient Shihipar : la précision excessive nuit autant que le flou.
Trop détailler expose à un travers propre à ces modèles : Fable 5 suit vos instructions à la lettre, y compris quand un changement de cap s’impose. Vous verrouillez une trajectoire que vous auriez dû laisser respirer. Trop rester vague, à l’inverse, laisse le modèle décider selon les conventions du secteur, des choix par défaut rarement taillés pour votre cas précis. « Quand vous ne tenez pas compte de vos inconnues, vous échouez des deux côtés », résume-t-il.
Le point de bascule tient dans un détail souvent négligé : donner à Claude non pas seulement la tâche, mais votre point de départ. Où vous en êtes dans votre réflexion, quelle expérience vous avez du sujet. Sans ce repère, l’agent ne peut pas savoir quelles inconnues valent la peine d’être levées.
Le « blindspot pass », ou comment déléguer le doute
De là vient la technique centrale, celle qui donne son sens à tout le reste. Avant même de programmer, Shihipar demande au modèle de traquer ses angles morts. Il appelle cela un blindspot pass, une passe sur les points aveugles.
Le principe inverse le rôle habituel. Au lieu d’attendre du modèle qu’il exécute, on lui demande d’interroger notre ignorance. L’exemple qu’il donne est parlant : « Je travaille sur l’ajout d’un nouveau fournisseur d’authentification mais je ne connais rien aux modules d’auth de cette base de code. Peux-tu faire une passe sur mes angles morts pour m’aider à repérer mes inconnues pertinentes et mieux te prompter ensuite. »
La manœuvre fonctionne parce qu’un agent moderne dispose d’un avantage brut : il parcourt une base de code et le web à grande vitesse, et en sait plus que l’utilisateur moyen sur la plupart des sujets. Là où un humain seul reste prisonnier de ce qu’il ignore ignorer, la machine peut exhumer les questions qu’on ne pensait pas à poser. Le résultat n’est pas du code : c’est une liste de doutes qu’on ne s’était pas formulés.
Faire parler ce que vous savez sans le savoir
Reste la case la plus retorse, les unknown knowns, ce savoir tacite qu’on n’écrit jamais. Le design visuel en est l’exemple type : vous ne savez pas décrire ce que vous voulez, mais vous le reconnaissez d’un coup d’œil.
La parade de Shihipar consiste à ne pas foncer dans l’implémentation. Il fait générer par Claude plusieurs directions radicalement différentes, sous forme de maquettes HTML, pour réagir dessus. C’est en écartant les propositions qu’on découvre ses propres critères. D’autres procédés servent le même but : l’entretien structuré, où le modèle pose ses questions une à une en priorisant celles dont la réponse changerait l’architecture ; ou l’appui sur des références, le code source d’un projet existant valant mieux qu’une capture d’écran, quitte à ce qu’il soit écrit dans un autre langage.
La séquence de travail s’en trouve renversée. Le plan d’implémentation vise d’abord les parties les plus susceptibles de bouger, modèles de données, interfaces de types, tout ce qui touche à l’utilisateur. Le refactoring mécanique, lui, passe en dernier.
Mieux se connaître plutôt que mieux formuler
L’enseignement dépasse Fable 5. Tant que le modèle était le facteur limitant, progresser voulait dire mieux formuler. Quand il cesse de l’être, progresser veut dire mieux se connaître, ou apprendre à déléguer ce travail de lucidité à la machine elle-même.
C’est une compétence moins spectaculaire que l’art du prompt parfait, et sans doute plus durable. Le prochain gain de productivité ne viendra peut-être pas d’un modèle plus puissant, mais de développeurs capables d’admettre, avant de commencer, tout ce qu’ils ignorent encore.
