Guider le raisonnement

Pourquoi un modèle si savant se trompe sur un calcul simple

Sofia prépare le budget d'une campagne : remise de 15 %, marge de 35 %, TVA... Elle colle tout dans le chat, demande « quel est le budget final ? » et obtient un chiffre faux. Comment un système capable de disserter sur la physique quantique peut-il rater un calcul de pourcentages ?

Parce qu'un modèle de langage ne « calcule » pas : il prédit du texte, mot après mot. Quand tu exiges une réponse immédiate, tu lui demandes de produire le résultat d'un raisonnement... sans faire le raisonnement. Sur un problème à étapes multiples, c'est comme exiger d'un humain qu'il réponde de tête, instantanément, sans brouillon. Les erreurs ne sont pas une fatalité du modèle : elles sont une conséquence de la façon de demander.

La parade est simple et c'est l'une des techniques les plus documentées du prompt engineering : donner au modèle le droit — et l'instruction — de poser son brouillon avant de conclure.

Chain-of-thought : raisonner avant de répondre

Sur un problème logique, mathématique ou multi-étapes, ajoute « raisonne étape par étape avant de répondre ». Le modèle pose alors son raisonnement explicitement : il identifie les données, déroule les calculs intermédiaires, puis conclut. Chaque étape écrite conditionne la suivante, ce qui réduit fortement les erreurs par rapport à une réponse directe. C'est le chain-of-thought (chaîne de pensée).

Un produit coûte 80 €. Avec une marge de 35 % sur le prix de vente, quel est le prix de vente ?
Raisonne étape par étape, puis donne le résultat final.

Cet exemple est piégeux à dessein : une marge de 35 % sur le prix de vente ne se calcule pas comme 80 × 1,35. En réponse directe, beaucoup de modèles tombent dans le piège. En raisonnement guidé, le modèle pose l'équation (prix de vente = coût / (1 − 0,35)) et trouve 123,08 €. Le brouillon n'est pas un luxe : c'est lui qui évite l'erreur.

flowchart LR
  Q["Problème multi-étapes"] --> E1["Étape 1 : poser les données"]
  E1 --> E2["Étape 2 : calculer"]
  E2 --> V["Vérifier la cohérence"]
  V --> R["Ligne finale : Réponse"]

Bénéfice secondaire, au moins aussi précieux que la justesse : le raisonnement est auditable. Quand la réponse est fausse, tu vois à quelle étape l'erreur s'est glissée — une donnée mal lue, une formule inversée — et tu corriges précisément ce point au lieu de relancer au hasard en espérant mieux.

Séparer réflexion et réponse

Le raisonnement complet est utile pour vérifier, mais encombrant à utiliser : Sofia ne va pas coller quinze lignes de calcul dans son email au directeur financier. La bonne pratique consiste à demander les deux, clairement séparés : d'abord la réflexion, puis une conclusion isolée et concise.

Calcule le budget final de la campagne :
- 3 publications sponsorisées à 450 € pièce
- remise négociée de 15 % sur le total
- prestation de l'agence : 20 % du montant après remise

Raisonne étape par étape en posant chaque calcul.
Termine par une ligne « Réponse : » avec uniquement le montant final en euros.

Tu obtiens à la fois la rigueur (le raisonnement, que tu peux vérifier en dix secondes) et l'utilisable (la conclusion, que tu peux copier telle quelle). Cette séparation est une habitude à prendre sur toute tâche analytique : analyse puis recommandation, diagnostic puis correctif, comparaison puis verdict.

La décomposition : découper les gros problèmes

Le chain-of-thought aide sur un problème d'une dizaine d'étapes. Mais certains travaux sont trop gros pour un seul prompt, même bien guidé : analyser 40 réponses à un sondage, rédiger un dossier complet, comparer trois prestataires sur huit critères. La technique reine ici est la décomposition : découper le travail en sous-tâches, et les traiter une par une, chaque réponse nourrissant la suivante.

Pour son bilan de campagne, Sofia ne demande plus « analyse ces résultats et rédige le bilan ». Elle enchaîne : 1) « liste les 5 enseignements principaux de ces chiffres », 2) « pour chaque enseignement, propose une action concrète », 3) « rédige maintenant le bilan en suivant ce plan ». Trois prompts courts, chacun vérifiable, au lieu d'un prompt monstre dont la sortie est invérifiable en bloc.

La décomposition a un avantage caché : elle te garde dans la boucle. Entre chaque étape, tu peux corriger, réorienter, écarter une mauvaise piste — avant qu'elle ne contamine toute la suite. Un prompt unique géant, lui, ne t'offre aucun point de contrôle intermédiaire.

L’auto-critique : faire vérifier la copie

Dernière technique de la famille : demander au modèle de critiquer sa propre réponse. Après une première sortie, enchaîne avec : « Relis ta réponse. Vérifie chaque calcul et chaque affirmation. Liste les erreurs ou faiblesses éventuelles, puis donne une version corrigée. » Le modèle repère souvent ses propres fautes lors de cette relecture — exactement comme un humain qui se relit à froid.

Tu peux aussi intégrer la vérification d'avance dans le prompt initial : « avant de donner ta réponse finale, vérifie la cohérence de chaque étape ». C'est ce que fait la case « Vérifier la cohérence » du diagramme plus haut. Attention toutefois : l'auto-critique améliore, mais ne garantit rien. Un modèle peut valider avec aplomb une erreur qu'il vient de commettre. Pour tout chiffre ou fait critique, la vérification finale reste humaine.

Quand guider le raisonnement — et quand s’abstenir

Ces techniques ont un coût : des réponses plus longues, plus lentes, plus chères en contexte. Les dégainer sur tout serait contre-productif. Voici la carte des usages :

Note enfin que les modèles récents dits « de raisonnement » appliquent une forme de chain-of-thought en interne, sans qu'on le demande. Même avec eux, ces réflexes restent utiles : exiger le détail des étapes rend la réponse vérifiable, et la décomposition garde le contrôle humain sur les gros travaux. La technique évolue, le principe — ne jamais accepter une conclusion invérifiable — demeure.

Les limites : un raisonnement plausible n’est pas un raisonnement juste

Un dernier avertissement, qui vaut pour tout ce chapitre. Le chain-of-thought produit un raisonnement plausible — pas nécessairement juste. Le modèle peut dérouler des étapes impeccables en apparence et glisser une erreur au milieu, avec la même assurance tranquille. La fluidité du texte n'est pas une preuve de validité.

Le réflexe professionnel : vérifier les étapes critiques (les chiffres, les faits datés, les affirmations surprenantes), pas seulement lire la conclusion. Le raisonnement explicite ne remplace pas ton jugement — il le rend simplement possible, là où une réponse sèche t'obligeait à croire sur parole. C'est exactement pour cela qu'on l'exige.