Le système anti-hallucination à quatre couches : comment LucidFlow garde ses recommandations IA fiables

Demandez à un LLM générique de transformer un processus métier et vous obtiendrez une réponse confiante, bien rédigée, qui contient environ 60 % d'invention. Il nommera des outils d'automatisation qui n'existent pas ou dont il aura inventé les prix. Il citera des pourcentages de ROI sans aucune base arithmétique. Il recommandera des patterns qui ne s'appliquent pas à votre secteur parce que le modèle les a vus fonctionner dans des contextes sans rapport. La sortie se lit magnifiquement et n'est exploitable que si vous en savez déjà assez pour vérifier chaque phrase : auquel cas vous n'aviez pas besoin de l'IA.

LucidFlow a été construit spécifiquement pour éviter ce mode d'échec. La couche de transformation IA est contrainte, validée et transparente sur quatre couches : chacune attrapant un type différent d'hallucination. Aucune couche seule ne suffit ; les quatre ensemble produisent un système où chaque recommandation est défendable par construction. Vous n'avez pas à vérifier la sortie ; le système l'a vérifiée avant de vous la montrer.

La première couche est une base de connaissances curée de 100 patterns d'automatisation IA vérifiés. Chaque pattern a un ID stable, une description, des conditions de déclenchement sous lesquelles il s'applique, des entrées et sorties attendues, des prérequis, un à trois outils recommandés avec de vraies URL et de vraies fourchettes de prix mensuels, et trois variantes de niveau de maturité (Companion / Automation / Agent) avec des profils coût-précision-risque distincts. La Knowledge Base est éditée par des humains et maintenue comme de la donnée, pas générée par l'IA.

Le choix de conception est radical pour 2026 : l'IA ne peut pas inventer de patterns. Lorsque le moteur de transformation évalue une tâche, son univers de recommandations possibles correspond exactement aux 100 patterns de la Knowledge Base, pas davantage. Si votre tâche n'en correspond à aucun, le système renvoie « aucun pattern correspondant » plutôt que d'en inventer un. C'est la ligne de code la plus importante de toute la pile de transformation IA, le refus de fabriquer.

• Les patterns de la Knowledge Base sont versionnés : chaque entrée a un historique de révisions. Lorsque l'outillage ou le prix d'un pattern change, la Knowledge Base est mise à jour ; le moteur IA reflète immédiatement le changement sur chaque nouvelle recommandation.
• Les références d'outils sont canoniques : chaque outil de la Knowledge Base a une vraie URL. Si un outil ferme ou si l'URL renvoie un 404, le pattern est marqué pour relecture.
• Les prix sont bornés en fourchettes : chaque outil porte un prix mensuel minimum et maximum en USD, parce que la tarification réelle varie selon le plan et le nombre de sièges. Les prix à valeur unique sont interdits.

La deuxième couche est le classifieur de tâches, le composant qui apparie une tâche précise de votre BPMN à un pattern de la Knowledge Base. Le classifieur est contraint : il lit la description de la tâche et le contexte du processus, note chaque pattern de la Knowledge Base pour son applicabilité et renvoie la meilleure correspondance si la note dépasse un seuil. Si aucun pattern ne dépasse le seuil, le classifieur renvoie « aucun pattern applicable » et la tâche n'obtient pas de recommandation Intelligize : renvoyant alors l'évaluation ESSII vers Éliminer, Simplifier, Standardiser ou Intégrer.

Le classifieur ne génère jamais de recommandation. Il ne fait que classer et sélectionner. C'est la différence mécanique entre « IA qui recommande » et « IA qui fabrique », le classifieur ne peut pas inventer un pattern parce que l'espace des patterns est clos. Chaque recommandation vue par l'utilisateur est un pointeur vers une entrée de la Knowledge Base qu'un humain y a placée délibérément. Le travail de l'IA est d'apparier, pas d'écrire.

La troisième couche tourne après l'assemblage du plan et avant qu'il soit montré à l'utilisateur. Chaque plan de transformation passe par six règles de validation indépendantes, chacune attrapant un type différent d'incohérence.

1. validateToolsExist : chaque outil référencé dans chaque étape doit être un outil enregistré dans la Knowledge Base pour ce pattern à ce niveau de maturité. Les outils inconnus déclenchent des avertissements ; les patterns indéfinis déclenchent des erreurs.
2. validateCostCoherence, pour chaque étape qui utilise plusieurs niveaux de maturité, le coût doit augmenter de façon monotone : Agent ≥ Automation ≥ Companion. Une étape où Agent est moins cher que Companion signale une erreur d'édition dans la Knowledge Base.
3. validateDependencyOrder, les étapes qui déclarent des prérequis doivent venir après ces prérequis dans l'ordonnancement du plan. Une étape qui exige « données en CSV propre » ne peut pas venir avant l'étape qui produit le CSV.
4. validateRoiRealism, la projection de ROI de chaque étape doit se situer dans une fourchette plausible compte tenu de son coût, de sa durée et de sa fréquence. Une étape qui prétend 90 % de ROI sur un outil à 10 $/mois appliqué à une tâche qui tourne 5 fois par an échoue au réalisme.
5. validatePrerequisites : tout prérequis déclaré dans le plan doit être effectivement satisfait par les étapes précédentes ou par l'état actuel du processus. Les prérequis manquants sont des erreurs, pas des avertissements.
6. validateCoverage : toute tâche automatisable du BPMN source doit apparaître dans le plan, ou être explicitement marquée « non automatisable ». Les omissions silencieuses sont des erreurs parce qu'elles représentent des plans partiels qui se lisent comme complets.

Tout plan qui échoue à au moins une règle au niveau erreur n'est pas montré à l'utilisateur, il est régénéré. Les avertissements sont remontés à l'utilisateur mais ne bloquent pas l'affichage. La distinction compte : les erreurs sont des hallucinations ou des ruptures logiques ; les avertissements sont des défauts revus par un humain, généralement bons mais qui méritent un coup d'œil.

La quatrième couche est la plus trompeusement simple : chaque recommandation arrive avec son raisonnement et un score de confiance. « Automatiser cette tâche avec Claude API à 20 $/mois » est accompagné de « parce que cette tâche correspond au pattern KB-034 (Extraction de Clauses Contractuelles), confiance 0,87, raisonnement : la description de la tâche mentionne 'extraire les termes clés des contrats fournisseurs', ce qui correspond directement à la condition de déclenchement du pattern ; Claude API a été sélectionné parce que son prix de 20 $/mois se situe dans la fourchette recommandée du pattern pour le niveau Companion et qu'il prend en charge le format d'entrée requis ».

La transparence est un contrôle anti-hallucination parce qu'il est difficile d'halluciner du raisonnement pour un pattern précis sans se faire prendre. Si le raisonnement dit « cette tâche correspond au pattern KB-034 » et qu'il n'y a pas de KB-034, l'utilisateur le voit et le signale. Si le raisonnement dit que l'outil prend en charge un format que l'outil ne prend pas en charge, un expert métier le rattrape. En pratique, la transparence crée un artefact relisible qui transforme chaque recommandation en affirmation que l'utilisateur peut inspecter, plutôt qu'en prononcement à croire.

• Couche 1 empêche : les patterns inventés. Si le pattern n'est pas dans la Knowledge Base, il ne peut pas être recommandé.
• Couche 2 empêche : les patterns mal appliqués. Le seuil de score du classifieur écarte les correspondances de faible pertinence.
• Couche 3 empêche : l'incohérence interne. Coûts qui défient l'ordre des niveaux de maturité, dépendances dans le mauvais ordre, chiffres de ROI arithmétiquement impossibles : tous rattrapés ici.
• Couche 4 empêche : la confiance non examinée. En exposant le raisonnement, le système force l'utilisateur à vérifier ; une hallucination qui aurait survécu aux trois premières couches est bien plus susceptible d'être rattrapée à la revue humaine.

Les quatre couches se composent. Une hallucination qui passe la couche 1 est rattrapée à la couche 2 ; celle qui survit aux couches 1 et 2 est rattrapée à la couche 3 ; celle qui survit aux trois est exposée à la revue humaine à la couche 4. Le taux d'échec composé est bien plus bas que ce que suggérerait chaque couche prise seule, ce qui explique pourquoi on peut faire confiance au système pour produire des recommandations qu'un CFO ou un expert métier ne vous renverra pas au visage.