Le Routeur Cynefin — Classifier les requêtes par TYPE de système, pas par nombre d'étapes

22 juin 2026 · Dream #1 (9.3/10) · HERMYTHOS V2.0 CPR Systems Thinking

Le papier Apple a raison. Et tort.

La semaine dernière, Apple a publié un papier qui a fait l'effet d'une bombe dans le milieu : The Illusion of Thinking. La thèse ? Les Large Reasoning Models (LRMs) s'effondrent au-delà de ~20 étapes séquentielles. Score de précision qui plonge, hallucinations en cascade, raisonnement qui se mord la queue. La communauté s'est emparée du chiffre — « 20 étapes, c'est le mur » — comme s'il s'agissait d'une loi physique.

C'est précisément là que le bât blesse.

Le papier Apple classe les tâches par nombre d'étapes. Une métrique quantitative, uniforme, symétrique. Or une requête de type « checklist » (5 étapes, système Clair) et une requête de diagnostic de panne réseau intermittent (3 étapes, système Chaotique) n'ont rien à voir architecturalement. Même nombre d'étapes, univers de traitement radicalement différent.

Le nombre d'étapes n'est pas la cause de l'échec. C'est un symptôme. La vraie variable, c'est le type de système dans lequel la requête opère.

Cynefin : la grille de lecture que les LRMs attendaient

Le framework Cynefin, développé par Dave Snowden, classifie les problèmes en quatre domaines :

• Clair — cause→effet évident. La réponse est une checklist. (Ex : « Quelle est la syntaxe d'un ConfigMap Kubernetes ? »)
• Compliqué — cause→effet existe, mais nécessite un expert. La réponse est une analyse. (Ex : « Optimise ce pipeline de données qui a 14 étapes de transformation »)
• Complexe — cause→effet émergent, visible uniquement rétrospectivement. La réponse est une expérimentation itérative. (Ex : « Pourquoi la latence de l'API augmente-t-elle de 12% les mardis entre 14h et 14h30 ? »)
• Chaotique — aucune relation cause→effet stable. Il faut stabiliser d'abord, analyser ensuite. (Ex : « La DB corrompue, le load balancer down, et le déploiement en cours — par où on commence ? »)

La thèse du Routeur Cynefin est la suivante : remplacez le décompte d'étapes par une classification systémique en amont du pipeline RAG. Un LLM léger (1-3 étapes, pas 20) analyse la requête entrante, produit un SystemType + un diagnostic DART (Deconstruct, Analyze, Recognize, Test), et route vers le backend approprié.

Architecture concrète : le SystemClassifier

Dans HERMYTHOS V2.0, le CPR (Cognitive Pipeline Router) classifie déjà les requêtes par complexité 1-10 et type de raisonnement. Le Routeur Cynefin ajoute une couche en amont du CPR :

Requête entrante
  → SystemClassifier (LLM léger, 1-3 étapes)
    → SystemType: Clear | Complicated | Complex | Chaotic
    → DART: Deconstruct → Analyze → Recognize → Test
  → CPR (backend routing)
    → Clear  → réponse directe, pas de retrieval complexe
    → Complicated → Composite Retrieval avec décomposition experte
    → Complex → boucle expérimentale Arbor avec feedback utilisateur
    → Chaotic → action immédiate, snapshot d'état, pas de débat

Le seuil des 20 étapes n'est plus un mur absolu. Il devient un symptôme qui dit : « Cette tâche est Complexe, pas Compliquée — décompose-la en expériences itératives au lieu d'essayer de la résoudre en une seule séquence linéaire. »

Pourquoi ça change tout

Le papier Apple suppose implicitement que toutes les tâches RAG vivent dans le même régime — le Compliqué. Mais un runbook de reprise après sinistre (système Clair, 12 étapes) et un diagnostic de corruption mémoire dans un cluster etcd (système Complexe, 8 étapes) n'ont pas la même structure causale. Les traiter avec le même pipeline, c'est comme utiliser un marteau pour visser et un tournevis pour enfoncer un clou.

Le TRIZ nous le dit depuis 1946 : Principe #4 — Asymétrie. Remplacez la symétrie « nombre d'étapes » (métrique uniforme pour toutes les tâches) par l'asymétrie « type de système » (chaque système a son propre protocole).

Et les implications dépassent le RAG : le même SystemClassifier peut router des incidents de sécurité dans VSOCK ZTNA (Chaotique → stabilisation immédiate du mesh), des conflits de mémoire dans BMAM (Complexe → boucle Arbor de résolution de contradictions), ou des requêtes utilisateur dans Co-Manager IA (Clair → réponse directe depuis le runbook).

De la théorie au code

La crate cognitive-pipeline-router d'HERMYTHOS V2.0 est le véhicule naturel de cette idée. Le SystemClassifier est un enum Rust à quatre variants, pas un prompt engineering fragile. Chaque SystemType mappe vers un backend de retrieval spécifique. Le DART est une struct déterministe, pas une « chaîne de pensée » laissée à l'interprétation du LLM.

C'est ça, la différence entre prompt engineering et architecture. Le premier ajoute des instructions au LLM en espérant qu'il comprenne. La seconde change la structure du pipeline pour que le LLM n'ait pas besoin de deviner.

Vous construisez des pipelines RAG qui classent vos requêtes par nombre d'étapes ?
Parlons architecture →