Claude ne sauve pas un mauvais cahier des charges : pourquoi l'IA livre des résultats convaincants mais faibles

Les longs prompts, les rôles et les formules magiques comme think carefully ne garantissent pas une bonne réponse de l'IA. À partir de son travail avec Claude, l'auteur examine pourquoi le modèle accélère souvent la production de texte plausible sans aboutir à un résultat utile quand la tâche elle-même n'est pas définie.

Pourquoi ça ne marche pas

Le grief principal est simple : l'IA conteste rarement une mauvaise formulation. Un designer, un analyste ou un développeur reviendraient en général avec des questions de clarification, alors que le modèle comble plus souvent lui-même le contexte manquant et livre une réponse assurée. L'utilisateur a donc l'impression que le travail avance vite, alors que ce qui s'accélère n'est pas la production d'un résultat de qualité, mais celle d'un texte qui paraît convaincant. D'où la fatigue après de longues itérations : on passe une heure à réécrire ce qu'on aurait dû obtenir au premier ou au deuxième essai.

« Un prompt n'est pas une prière ».

L'auteur relie cela à un renversement du coût des actions. Autrefois, faire coûtait cher, tandis que réfléchir et discuter coûtait relativement peu. Désormais, l'IA produit en quelques secondes cinq variantes d'une analyse, d'un courrier ou d'une stratégie, et la discussion de la tâche par une équipe de plusieurs personnes devient la partie la plus coûteuse du processus. Naît alors l'illusion qu'on peut sauter l'étape d'une définition correcte de la tâche et passer directement à la génération. Mais un long prompt ne remplace pas un objectif clair, et les formules magiques ne guérissent pas l'absence de structure.

Quatre questions avant le chat

Plutôt que de chercher la formulation parfaite, l'auteur propose de revenir à la discipline de base de l'analyse métier et de dresser une cartographie de la tâche avant de commencer. Sa logique repose sur l'approche As-Is, To-Be, Gap : ce que nous avons aujourd'hui, ce que doit être le résultat et ce qui sépare l'un de l'autre. Ce cadre sert non seulement aux recherches complexes, mais aussi aux tâches quotidiennes comme l'analyse de la concurrence, la préparation de la structure d'un article ou le dépouillement d'entretiens utilisateurs. L'enjeu est de décrire non pas un vague espoir d'une bonne réponse, mais un chemin concret pour y arriver.

• Entrée : quelles données, quels liens, documents, hypothèses et observations vous avez déjà au départ.
• Étapes : quelles actions le modèle doit exécuter, dans l'ordre, sans un « analyse » flou.
• Sortie de chaque étape : ce qui doit précisément en résulter à chaque pas — tableau, liste, matrice, brouillon.
• Résultat final : à quoi ressemble le travail terminé et selon quel critère vous l'accepterez sans l'impression d'un « ça a l'air correct ».

En pratique, cela change aussi le format d'interaction avec le modèle. Plutôt qu'un seul prompt géant, mieux vaut construire une chaîne de plusieurs étapes avec recette intermédiaire : d'abord la collecte des faits, puis la comparaison, ensuite la recherche de segments vides et seulement après les conclusions. Dans l'exemple de l'analyse concurrentielle, cette approche transforme une demande abstraite en une suite de petites tâches, où il est plus facile de repérer une erreur plus tôt que dans le texte final.

Comment on l'assemble dans Claude

Pour son usage, l'auteur a empaqueté cette approche dans un skill Claude dédié. Celui-ci vérifie d'abord ce qui est réellement demandé : une réponse ponctuelle ou un prompt réutilisable. Vient ensuite la carte As-Is, To-Be, Gap, après quoi le système évalue la complétude de la demande selon plusieurs éléments obligatoires : objectif, audience, format, contraintes et contexte. Si des données manquent, le modèle ne génère pas aussitôt un beau texte, mais pose des questions de clarification.

L'étape clé est le Confirmation Gate : avant de travailler, l'IA montre comment elle a compris la tâche et attend une confirmation explicite. Le prompt final est ensuite assemblé dans un gabarit structuré selon le schéma Context, Role, Instructions, Style, Parameters. L'auteur insiste à part sur l'importance des contraintes négatives, des exemples few-shot et de l'itération ciblée sur une erreur précise, plutôt que sur une impression que « c'est mieux ».

Si le résultat est trop générique, il faut corriger non pas l'humeur de la demande, mais la règle : ajouter des métriques, interdire les formules banales, exiger un format de réponse net. Ce mode rapproche le prompting non pas de la divination créative, mais d'un réglage d'ingénierie du processus.

Ce que cela signifie

La conclusion principale est dure mais utile : l'IA amplifie non seulement les bonnes décisions, mais aussi une mauvaise définition de la tâche. Pour les équipes, c'est le signal d'arrêter de mesurer l'efficacité au nombre de variantes générées et de commencer à exiger une cartographie de la tâche, une recette intermédiaire et des critères de complétude. Plus la génération devient bon marché, plus la clarté de pensée devient chère — et c'est elle qui rapporte désormais le plus.