Chain of Thought : pourquoi votre IA ne raisonne pas
Chain of Thought : pourquoi votre modèle d'IA ne raisonne pas.
Le Chain of Thought n'est pas de la pensée. C'est la forme statistique de la pensée. Apple, Arizona State et UC Berkeley le prouvent avec des données. Voici ce que cela signifie pour qui déploie de l'IA en production.
Le Chain of Thought (CoT) est une technique qui fait générer aux modèles de langage des étapes intermédiaires avant de répondre. Bien qu'elle améliore les benchmarks, des recherches récentes démontrent qu'il ne s'agit pas d'un raisonnement authentique : c'est une contrainte statistique qui imite la forme de la pensée humaine.
Pour les entreprises qui déploient de l'IA en environnement de production, comprendre cette différence n'est pas un débat philosophique. C'est une décision d'architecture qui affecte la fiabilité, le coût et le risque opérationnel. Chez SIXE, nous concevons des infrastructures critiques depuis plus de 15 ans, avec zéro tolérance à la panne. Cette expérience nous a appris une règle qui s'applique aussi bien à un cluster IBM Power qu'à un agent IA : ne jamais faire confiance à un seul composant pour ce qui ne doit pas tomber.
Qu'est-ce que le Chain of Thought et pourquoi ressemble-t-il à du raisonnement ?
Lorsque vous activez le mode « raisonnement » ou « thinking » dans des modèles comme GPT-5, Claude ou DeepSeek, le modèle génère un monologue intermédiaire avant de répondre : « bien, d'abord j'analyse X... maintenant je considère Y... attendez, laissez-moi vérifier Z... ». Dans la littérature technique, cela s'appelle Chain of Thought (CoT), littéralement « chaîne de pensée ».
Le problème est que ce n'est pas penser. C'est générer du texte avec la forme statistique du raisonnement humain. Le modèle a vu des millions d'exemples de raisonnement étape par étape pendant son entraînement et a appris à reproduire ce schéma. Quand vous lui demandez de « réfléchir », ce qu'il fait réellement est reconnaître la catégorie du problème et remplir le patron statistique le plus adapté.
Un exemple concret : si vous posez à un modèle « raisonneur » un problème de dimensionnement de stockage Ceph avec 12 OSD, réplication 3 et tolérance à la panne de 2 nœuds, il vous renverra quatre paragraphes impeccables avec des formules, des considérations sur les domaines de panne et un chiffre final. Cela ressemble à de la pensée structurée. Ce qu'il a fait, c'est détecter « problème de dimensionnement Ceph » et appliquer le patron statistique vu dans des centaines de documents techniques similaires.
Pourquoi ça marche ? Parce que la plupart du temps, la réponse est correcte. La question est ce qui se passe quand le problème sort du manuel.
Les LLM raisonnent-ils vraiment ? Ce que disent les études
Le CoT fonctionne. Il améliore les benchmarks de manière mesurable. La question pertinente n'est pas s'il fonctionne, mais pourquoi il fonctionne. Et la réponse des études les plus rigoureuses est inconfortable.
Le CoT comme béquille statistique
Une équipe d'Arizona State University a démontré que le CoT excelle lorsque les données du problème se trouvent dans la distribution d'entraînement. Dès que le problème sort de la zone connue, les performances s'effondrent. C'est la différence entre un système qui a mémorisé des solutions et un autre qui comprend véritablement les principes sous-jacents.
Le CoT comme contrainte architecturale
Le CoT n'est pas du raisonnement abstrait : c'est une contrainte qui oblige le modèle à imiter la forme du raisonnement. Forcer le modèle à écrire « premièrement... deuxièmement... par conséquent... » fait que chaque token généré influence le suivant avec plus de cohérence. C'est une astuce architecturale qui améliore la cohérence interne du texte, pas un acte cognitif. L'article Chain-of-Thought Reasoning In The Wild Is Not Always Faithful documente comment le CoT peut donner une image incorrecte du processus réel que suit le modèle pour arriver à ses conclusions.
Le CoT est utile pour de nombreuses tâches. Mais ce n'est pas du raisonnement. C'est de la cohérence formelle avec l'apparence de la logique.
Que sont les « étapes décoratives » du raisonnement IA ?
Un article d'octobre 2025 publié par des chercheurs d'UC Berkeley et UC Davis a introduit le concept de decorative thinking steps (étapes de pensée décoratives), et leur découverte est particulièrement pertinente pour quiconque évalue des modèles d'IA pour la production.
Les chercheurs ont découvert que de nombreuses étapes intermédiaires du CoT sont littéralement décoratives. Le modèle écrit des choses comme « attendez, laissez-moi vérifier... je crois que j'ai fait une erreur... je vais recalculer », puis ignore complètement cette autocorrection et livre la réponse qu'il avait déjà décidée en interne.
La démonstration a été élégante : ils ont délibérément perturbé les étapes intermédiaires (changé des chiffres, altéré la logique) et vérifié si la réponse finale changeait. Dans de nombreux cas, elle ne changeait pas. La conclusion était déjà prise. La chaîne de pensée était générée après coup, comme rationalisation a posteriori.
Un résultat concret de l'étude : sur le dataset AIME, seuls 2,3 % des étapes de raisonnement du CoT avaient une influence causale réelle sur la prédiction finale du modèle. Le reste était de la décoration. (Source : Can Aha Moments Be Fake?, UC Berkeley)
Qu'un modèle explique bien pourquoi il est arrivé à une conclusion ne signifie pas que cette conclusion soit correcte. L'explication est générée en même temps que (ou après) le résultat, et dans de nombreux cas c'est une justification construite sur une réponse prédéterminée.
« The Illusion of Thinking » : l'étude d'Apple qui change tout
Si les étapes décoratives démontrent que le CoT ne garantit pas le raisonnement même quand il donne la bonne réponse, l'étude d'Apple va plus loin : elle montre que lorsque le problème se complique vraiment, les modèles abandonnent.
En juin 2025, Apple a publié The Illusion of Thinking, une étude qui a soumis des modèles de raisonnement de dernière génération à des puzzles classiques d'informatique : la Tour de Hanoï, des problèmes de traversée de rivière et d'autres exercices que tout étudiant de première année résout avec un crayon et du papier.
La découverte la plus significative est la troisième. Les modèles « raisonneurs » ne se contentent pas d'échouer sur les problèmes complexes — ils réduisent l'effort computationnel précisément quand ils devraient l'augmenter. C'est l'équivalent d'un système de monitoring qui cesse de générer des alertes quand l'infrastructure en a le plus besoin.
Il convient de noter que l'article a suscité un débat : une équipe du CSIC à Madrid a répliqué une partie des expériences et a nuancé que certains échecs étaient dus aux limites de tokens de sortie, pas à des limitations cognitives pures. Mais les conclusions de fond — que la performance s'effondre avec la complexité et que le CoT ne passe pas à l'échelle de manière prévisible — ont tenu.
Vaut-il la peine de payer pour des modèles de raisonnement ?
Cela dépend. Et c'est précisément la réponse que la plupart des fournisseurs ne veulent pas vous donner.
Un cas illustrant le risque : une entreprise européenne a monté un agent « raisonneur » pour classifier des tickets de support. La chaîne de pensée générée par le modèle était narrativement impeccable. Le problème est que 30 % des tickets finissaient dans la mauvaise file, et le modèle expliquait avec une éloquence impeccable pourquoi cette classification erronée était la bonne. Narration parfaite, résultat erroné.
Cela se produit parce que nous confondons qualité de l'explication avec qualité de la décision. Ce sont deux choses différentes. Un modèle peut produire un raisonnement formellement impeccable et arriver à une conclusion incorrecte, exactement comme une présentation aux graphiques spectaculaires peut défendre une mauvaise stratégie.
Avant de payer pour des modèles de raisonnement, benchmarkez avec votre cas réel. Les supports marketing des fournisseurs montrent les résultats de leurs meilleurs jours. Vos données, votre casuistique et vos cas limites déterminent si le surcoût est justifié.
L'IA est-elle inutile alors ?
Non. Et il est important de bien le comprendre, car le pendule peut basculer dans l'autre sens tout aussi facilement.
Qu'un LLM ne raisonne pas comme un humain ne signifie pas qu'il soit inutile. Cela signifie qu'il faut comprendre exactement ce qu'il fait pour l'utiliser correctement.
Un système IBM Power10 sous AIX ne « pense » pas aux charges de travail. Il n'a pas d'intuition. Ce qu'il a, c'est une architecture RISC haute performance, une bande passante mémoire qu'un x86 équivalent ne peut égaler, et une fiabilité (RAS) de niveau mainframe. Si vous comprenez ce qu'il fait, vous l'utilisez pour ce qu'il vaut : bases de données critiques, HPC, inférence IA à l'échelle. Sinon, vous l'utilisez comme un serveur x86 coûteux en vous demandant pourquoi il ne performe pas.
C'est exactement la même chose pour les LLM. Ce sont des processeurs de langage extraordinaires. Ils synthétisent, traduisent, rédigent, classifient et extraient des motifs textuels à une vitesse qu'aucune équipe humaine ne peut égaler. C'est réel, cela a une valeur mesurable et cela transforme les opérations dans tous les secteurs.
Ce qu'ils ne sont pas, ce sont des agents pensants dotés d'une compréhension authentique du monde. Et vendre le second quand on a le premier, c'est ce qui crée une bulle d'attentes qui, tôt ou tard, se corrigera.
Comment utiliser l'IA en production sans tomber dans le piège ?
Dans le monde de l'infrastructure critique — IBM Power, AIX, clusters haute disponibilité — il y a un principe qui ne faillit jamais : concevez avec de la redondance. On ne fait jamais confiance à un seul composant pour ce qui ne doit pas tomber.
1. N'utilisez pas l'explication comme garantie de la réponse
L'explication du modèle est générée en même temps que (ou après) le résultat. Souvent c'est une rationalisation a posteriori. Si le système prend des décisions critiques, vous avez besoin d'une vérification indépendante. Peu importe la qualité de l'explication.
2. Benchmarkez avec votre cas réel avant de choisir un modèle
Pour les tâches simples, le modèle bon marché peut surpasser le modèle coûteux. Pour les tâches moyennes, le CoT compense. Pour les tâches très complexes, les deux échouent. Le seul moyen de le savoir est de tester avec vos données réelles, pas celles du fournisseur.
3. Concevez des architectures avec vérification externe
Si votre architecture IA se résume à « je demande au modèle et je fais confiance à sa réponse », vous n'avez pas d'architecture. Un déploiement sérieux d'IA inclut la validation croisée, des règles métier comme couche de contrôle, des alertes quand la confiance du modèle baisse, et des humains dans la boucle pour les décisions critiques.
4. Exigez des preuves, pas des promesses
Le marché de l'IA est rempli d'affirmations extraordinaires sans preuves proportionnelles. Un fournisseur sérieux vous montre des benchmarks sur votre type de données. Un fournisseur moins sérieux vous montre une démo spectaculaire avec des données préparées.
Comment évaluons-nous les modèles d'IA pour les environnements de production ?
Chez SIXE, nous appliquons à l'IA les mêmes critères que nous appliquons depuis plus de 15 ans à tout composant d'infrastructure critique :
- Tests avec les données réelles du client, pas avec des datasets génériques ni des démos préparées.
- Mesure de performance sur les cas limites, pas uniquement sur le cas nominal. Les erreurs n'apparaissent pas dans la médiane, elles apparaissent aux extrêmes.
- Architecture redondante toujours. L'IA est une couche supplémentaire du système, pas le système entier. Elle se complète par des règles métier, de la validation croisée et une supervision humaine là où la décision est critique.
- Sélection du modèle par cas d'usage, pas par le marketing. Un modèle avec CoT peut être parfait pour l'analyse de texte complexe et totalement inutile (et plus cher) pour de la classification simple.
- Infrastructure dimensionnée pour l'inférence. Un modèle d'IA est aussi bon que l'infrastructure qui le soutient. Nous l'avons vérifié de première main avec vLLM sur IBM Power et avec Ceph comme backend de stockage pour l'IA.
Pour les dirigeants pressés
→ Le Chain of Thought n'est pas de la pensée : c'est la forme statistique de la pensée, une contrainte qui améliore la cohérence du texte généré.
→ Apple a démontré que les modèles de raisonnement s'effondrent face aux problèmes complexes et réduisent leur effort précisément quand ils devraient l'augmenter.
→ Seuls 2,3 % des étapes de raisonnement ont une influence causale sur la réponse du modèle. Le reste est de la décoration.
→ Ne payez pas pour du « raisonnement » sans le mesurer sur votre cas d'usage concret avec vos données réelles.
→ N'utilisez jamais l'explication du modèle comme garantie que la réponse est correcte.
→ Concevez avec vérification externe. L'IA est un outil extraordinaire, pas un oracle.
Références et articles cités
Apple Machine Learning Research. The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity. Juin 2025. machinelearning.apple.com
Zhao, C. et al. (Arizona State University). Is Chain-of-Thought Reasoning of LLMs a Mirage? A Data Distribution Lens. Août 2025. arxiv.org/abs/2508.01191
Zhao, J. et al. (UC Berkeley, UC Davis). Can Aha Moments Be Fake? Identifying True and Decorative Thinking Steps in Chain-of-Thought. Octobre 2025. arxiv.org/abs/2510.24941
Arcuschin, I. et al. Chain-of-Thought Reasoning In The Wild Is Not Always Faithful. Mars 2025. arxiv.org/abs/2503.08679
Dellibarda Varela, I. et al. (CSIC, Madrid). Rethinking the Illusion of Thinking. Juillet 2025. arxiv.org/abs/2507.01231
Dernière mise à jour :
Besoin d'évaluer comment intégrer l'IA dans votre infrastructure ?
Chez SIXE, nous concevons des architectures IA avec la même philosophie que nous appliquons à tout système critique : redondance, vérification externe et benchmarks réels. Parlez-nous de votre cas.
