La Chaîne de Pensée

Raisonner étape par étape

La chaîne de pensée (Chain-of-Thought, ou CoT) est une technique qui consiste à demander au modèle de détailler son raisonnement avant de donner sa réponse finale. Au lieu de sauter directement à la conclusion, le modèle explicite chaque étape logique, ce qui améliore significativement la qualité des réponses sur les tâches nécessitant du raisonnement. Avec les modèles Mistral, elle donne d’excellents résultats sur la logique, les mathématiques, l’analyse et la prise de décision.

Pour comprendre pourquoi cela marche, rappelez-vous comment le modèle génère : token par token, chaque token s’appuyant sur tous les précédents. Lorsqu’un modèle doit répondre directement à une question complexe, il n’a que quelques tokens pour « réfléchir » — la réponse doit jaillir presque immédiatement. En lui demandant de détailler son raisonnement, vous lui donnez l’espace nécessaire pour décomposer le problème en sous-problèmes simples, vérifier chaque étape avant de passer à la suivante, repérer les informations pertinentes parmi les données fournies, et au final réduire les erreurs de raisonnement comme les hallucinations. Le raisonnement écrit n’est pas un rapport après coup : c’est le lieu même où le calcul se fait.

Le CoT simple : une instruction suffit

La forme la plus basique consiste à ajouter une simple phrase d’instruction à la fin de votre prompt :

Un restaurant a 15 tables. Chaque table peut accueillir 4 personnes.
Le restaurant est plein à 80%. Combien de personnes sont présentes ?

Raisonnez étape par étape avant de donner votre réponse.

Le modèle produira alors quelque chose comme :

Étape 1 : Capacité totale = 15 tables × 4 personnes = 60 personnes
Étape 2 : Taux de remplissage = 80% = 0.80
Étape 3 : Personnes présentes = 60 × 0.80 = 48 personnes

Réponse : 48 personnes sont présentes dans le restaurant.

Sans l’instruction « raisonnez étape par étape », le modèle pourrait donner directement « 48 » — correct ici — mais il pourrait aussi se tromper sur un calcul intermédiaire sans que vous puissiez identifier où. C’est le second bénéfice du CoT, moins connu mais tout aussi précieux : le raisonnement visible est vérifiable. Quand une réponse vous semble étrange, l’étape fautive saute aux yeux.

Le CoT structuré : guider les étapes

Pour des tâches plus complexes, ne vous contentez pas de demander un raisonnement : prescrivez-le. Imaginons une analyse d’investissement :

Évaluez si cette startup est un bon investissement.

Données :
- CA 2025 : 2.3M€ (croissance +45% YoY)
- Burn rate : 180K€/mois
- Runway : 14 mois
- Marché adressable : 500M€
- Équipe : 22 personnes, 3 fondateurs techniques

Raisonnez selon ces étapes :
1. Analysez la santé financière (CA, burn, runway)
2. Évaluez le potentiel marché (taille, pénétration actuelle)
3. Évaluez l'équipe (compétences, taille)
4. Identifiez les risques principaux (3 max)
5. Donnez votre conclusion avec un score de confiance (faible/moyen/élevé)

En prescrivant les étapes, vous vous assurez que le modèle couvre tous les aspects importants, dans le bon ordre, sans faire l’impasse sur celui qui vous intéresse. Laissé libre, il aurait peut-être glosé longuement sur le marché et expédié l’analyse financière ; guidé, il traite les cinq volets systématiquement.

Quand utiliser la chaîne de pensée — et quand s’en passer

Le CoT est fait pour les tâches où l’on peut se tromper en cours de route : problèmes mathématiques à étapes multiples, estimations, analyse de données (interprétation de métriques, identification de tendances), prise de décision par comparaison d’options, débogage d’un code ou d’un log d’erreur, raisonnement logique et déductions. Dans toutes ces situations, chaque étape intermédiaire est un point de contrôle qui empêche l’erreur de se propager.

À l’inverse, le CoT est inutile — parfois contre-productif — quand il n’y a rien à dérouler. Pour une question factuelle simple comme « Quelle est la capitale de l’Italie ? », il ajoute du délai et des tokens sans rien améliorer. En rédaction créative, le raisonnement structuré peut même brider la créativité. La traduction relève d’un processus plus intuitif que logique, et la reformulation n’exige aucune déduction. Le bon réflexe : demandez-vous si vous-même, pour cette tâche, poseriez un brouillon de calcul. Si non, épargnez-le au modèle.

Le CoT avec few-shot

Combiner la chaîne de pensée avec le few-shot vu à la leçon précédente est particulièrement puissant : au lieu de décrire comment raisonner, vous le montrez via un exemple complet de raisonnement réussi.

messages = [
    {
        "role": "system",
        "content": "Vous êtes un analyste qui raisonne étape par étape."
    },
    {
        "role": "user",
        "content": """Un e-commerce a 10 000 visiteurs/jour, un taux de conversion
de 2.5% et un panier moyen de 65€. Quel est le CA quotidien ?"""
    },
    {
        "role": "assistant",
        "content": """Raisonnement :
1. Nombre de commandes/jour = 10 000 × 2.5% = 250 commandes
2. CA quotidien = 250 × 65€ = 16 250€

Réponse : Le chiffre d'affaires quotidien est de 16 250€."""
    },
    {
        "role": "user",
        "content": """Un SaaS a 5 000 utilisateurs actifs, un taux de churn mensuel
de 3% et un revenu moyen par utilisateur de 49€/mois. Quel sera le MRR
dans 3 mois si aucun nouveau client n'arrive ?"""
    }
]

Le modèle reproduira le même schéma — un bloc « Raisonnement » numéroté, puis une ligne « Réponse » — pour la nouvelle question. Vous obtenez à la fois la rigueur du CoT et la constance de format du few-shot.

Contrôler la verbosité du raisonnement

Parfois, vous voulez le raisonnement mais pas un roman. Le dosage se règle dans l’instruction elle-même. Pour un raisonnement complet, demandez : « Détaillez chaque étape de votre raisonnement avant de conclure. » Pour une version resserrée : « Raisonnez brièvement (2-3 étapes max) puis donnez votre réponse. » Et pour la production, la variante la plus utile sépare raisonnement et réponse par des balises :

Raisonnez entre les balises <raisonnement></raisonnement>
puis donnez votre réponse finale entre <réponse></réponse>.

Cette dernière approche vous donne le meilleur des deux mondes : votre code extrait uniquement le contenu de la balise <réponse> pour l’afficher à l’utilisateur final, tandis que le raisonnement complet reste disponible dans les logs pour le débogage. Quand une réponse en production s’avère fausse, vous ouvrez le log et vous voyez exactement où le raisonnement a déraillé.

Points clés à retenir

• La chaîne de pensée demande au modèle de raisonner avant de répondre — décisive sur la logique, le calcul et l’analyse
• Guidez les étapes explicitement pour les tâches complexes
• Combinez CoT et few-shot pour un maximum d’efficacité
• Inutile pour les questions simples ou la rédaction créative
• Utilisez des balises XML pour séparer raisonnement et réponse en production