On n’a pas fiabilisé la science en ajoutant de la puissance cognitive, mais en imposant la réfutabilité de Karl Popper (entre autre)

Le comité de sélection a failli écarter un fournisseur sur la base d'une recommandation impeccable. L'agent avait produit des clauses de responsabilité, une analyse de risque pays, un coût total cohérent. Le problème n'était pas l'absence d'explication. C'était qu'une seule prémisse erronée, une confusion entre une filiale et sa maison mère, soutenait toute la conclusion. L'explication était suffisamment convaincante pour décourager la vérification.

Je tire de ce cas une règle simple: une chaîne de raisonnement lisible ne certifie pas une conclusion. Elle la rend plus facile à examiner, à condition que le système ait prévu les éléments qui permettraient de la rejeter. Un agent ne doit pas être traité comme une autorité qui sait, mais comme un producteur d'hypothèses. Sa sortie n'acquiert un statut exploitable qu'après avoir été confrontée à des prémisses traçables, des tests de réfutation et un niveau de preuve proportionnel au droit d'agir.

1. Le faux sentiment de sécurité

Comme je l'écrivais en juillet 2026, les LLM gagnent réellement en capacité avec le chain-of-thought, mais butent sur le nouveau, le bruit hors sujet et les faux raisonnements causaux [1]. Cette limite ne disparaît pas quand le modèle produit une prose plus longue. Elle change de forme: elle devient plus difficile à contester.

La sortie d'un LLM n'est pas une conclusion. C'est une proposition accompagnée d'une prose rassurante. Les systèmes qui la traitent comme une décision créent un faux sentiment de sécurité. Un LLM seul ne peut pas garantir l'exactitude, la traçabilité ni la cohérence opérationnelle; c'est l'écosystème autour de lui qui doit le faire [2]. Quand une tâche exige un score, un prix ou une estimation de risque, l'agent doit appeler un modèle entraîné pour cette tâche, pas improviser le nombre dans une prose fluide. La frontière doit être visible dans l'architecture: le modèle spécialisé produit l'estimation, le LLM explique le résultat, demande les entrées manquantes et gère les exceptions [3].

2. Le modèle comme générateur d'hypothèses, pas comme juge

Dans une architecture fiable, le modèle n'est pas le tribunal de la vérité. Il est le laboratoire qui formule vite des hypothèses. Le tribunal doit être extérieur: données traçables, règles métier, calculateurs, moteurs de contraintes, contrôles humains et tests reproductibles.

Le LLM doit proposer des hypothèses, rendre explicites les prémisses utilisées, indiquer les sources mobilisées, formuler les observations qui infirmeraient l'hypothèse et, lorsque c'est possible, produire un plan de vérification externe. Il doit aussi accepter l'abstention quand la preuve disponible est insuffisante. Cette séparation rejoint l'idée d'un état épistémique explicite: ce qui est établi, ce qui est douteux, ce qui a été écarté et ce qui reste ouvert. Les mises à jour de cet état ne sont autorisées que si elles sont étayées par des preuves [4]. La position LLM-Modulo de Kambhampati ne promet pas que tout devient fiable; le résultat dépend du vérificateur et de la part réellement formalisable du problème.

3. La falsifiabilité comme exigence de conception

Karl Popper n'a pas fourni une recette de vérité. Il a fourni un critère de démarcation: une proposition n'est pas robuste parce qu'on accumule des confirmations, mais parce qu'on cherche explicitement ce qui pourrait la contredire. Cette idée a une traduction très concrète pour les agents. Chaque conclusion doit être accompagnée de réfutateurs possibles, et le système doit exécuter les contrôles avant d'autoriser l'action.

| Élément | Ce que l'agent produit | Ce que le système vérifie | |---|---|---| | Conclusion | « Écarter le fournisseur X » | Le niveau de confiance ne doit pas masquer l'incertitude | | Prémisses | Filiale, exposition, clauses, prix, juridiction | Provenance, fraîcheur, statut de validation | | Inférences | Pourquoi les prémisses conduisent à la conclusion | Règles, calculs, contraintes et cohérence | | Réfutateurs | Données qui changeraient la conclusion | Existence, accessibilité et exécution des contrôles | | Impact | Décision, coût ou action déclenchée | Niveau de preuve requis avant action | | Journal | Version du modèle, contexte, outils, sources, résultats | Audit, reproductibilité et analyse d'incident |

Un exemple rend la règle opérationnelle. Hypothèse: « Le fournisseur présente un risque de concentration critique. » Réfutateur: « La part réelle du fournisseur dans le périmètre de production est inférieure à 20%, ou un second fournisseur est contractuellement activable sous 30 jours. » Contrôle: interrogation de la base achats et vérification des clauses de continuité. Décision: aucune action automatique tant que le contrôle n'a pas été exécuté.

4. Une hiérarchie de preuves pour les agents

La pyramide des preuves ne s'importe pas mécaniquement depuis la médecine. Elle sert à classer les éléments selon leur capacité à supporter une décision.

| Niveau | Type de « preuve » agentique | Fiabilité attendue | Usage acceptable | |---|---|---:|---| | 0 | Sortie isolée d'un LLM, sans source | Très faible | Idéation, brouillon, reformulation | | 1 | Sortie avec citations non vérifiées | Faible | Orientation de recherche, pas de décision | | 2 | Source primaire identifiée et contrôlée | Moyenne | Analyse assistée avec revue humaine | | 3 | Données internes traçables ou règle métier exécutable | Élevée sur le périmètre défini | Décisions réversibles ou contrôles opérationnels | | 4 | Vérification indépendante par outil, calculateur, moteur de règles ou test | Élevée si le vérificateur est correct | Automatisation bornée | | 5 | Sources indépendantes convergentes, contradiction traitée et décision auditée | La plus élevée disponible | Décisions à fort impact, sous gouvernance humaine |

Deux précisions s'imposent. Un consensus entre agents n'a de valeur que si les sources, méthodes ou modèles sont réellement indépendants. Un résultat de niveau 4 n'est pas universellement fiable: il est fiable par rapport aux propriétés effectivement vérifiées. Un solveur garantit le respect de contraintes formelles, pas la pertinence business des hypothèses qui lui ont été fournies.

5. Trois heuristiques converties en règles de conception

Rasoir d'Occam. La mauvaise interprétation consiste à dire « prenons le workflow le plus simple ». La bonne règle: parmi plusieurs explications compatibles avec les faits, privilégier celle qui ajoute le moins d'hypothèses non vérifiées. En architecture, chaque conclusion doit lister ses hypothèses implicites. Le workflow signale les hypothèses sans source ou sans test. Une explication avec moins d'hypothèses non testées reçoit un statut de priorité supérieur. La simplicité ne supprime jamais une vérification nécessaire. Exemple: « la marge baisse parce que le fournisseur a augmenté ses prix » est plus coûteuse que « la période comptable a changé », si la seconde se vérifie directement dans l'ERP.

Rasoir de Hanlon. Devant une anomalie, le système examine d'abord la qualité de la donnée, les transformations, les permissions, la fraîcheur, les conflits de version et les erreurs de mapping. L'hypothèse d'une action hostile reste possible, mais elle doit être étayée par des indicateurs spécifiques. Les incidents sont classés séparément: erreur de source, erreur de transformation, défaut de modèle, contournement de contrôle, usage malveillant. Cette règle évite des escalades coûteuses, comme la suspension d'un fournisseur ou le signalement de fraude, déclenchées sur une jointure défectueuse.

Standard de Sagan. Plus l'action est difficile à annuler, plus le système doit exiger de preuves indépendantes avant de l'autoriser.

| Impact de l'action | Exemples | Exigence minimale | |---|---|---| | Faible et réversible | Préparer un brouillon, classer un document, suggérer une réponse | Évaluation de qualité et contrôle a posteriori | | Modéré | Créer un ticket, recommander une priorité, déclencher une revue | Sources traçables et validation humaine ciblée | | Élevé | Modifier une donnée de référence, notifier un client, bloquer un processus | Vérification externe, règles de seuil et approbation explicite | | Critique ou difficilement réversible | Paiement, décision RH, conformité, résiliation, sécurité | Sources indépendantes, validation humaine habilitée, journal complet et mécanisme de recours |

6. Pourquoi le LLM-as-Judge ne suffit pas

Un second LLM ne résout pas le problème. L'étiquette de juge ne crée pas l'indépendance. Vérifier une chaîne de raisonnement est une tâche distincte, avec ses propres données, hypothèses et bornes formelles. Un modèle de vérification peut aider à détecter des erreurs, mais il doit être évalué sur des jeux de test, avec une définition explicite de ce qu'il vérifie. Sinon, on remplace une confiance aveugle par une autre. La vérification ne peut pas reposer uniquement sur un modèle qui partage les mêmes biais et le même espace d'hypothèses que le générateur.

7. Conclusion: une discipline sans mécanisme n'est qu'une intention

La qualité d'un agent ne se mesure pas seulement à la qualité de ses réponses. Elle se mesure à sa capacité à exposer les conditions dans lesquelles sa réponse doit être rejetée. Cela suppose des composants techniques: provenance, permissions, journaux d'hypothèses, évaluation en production, mécanismes d'arrêt et responsabilité humaine. La prochaine pièce posera la question: quels contrôles organisationnels et techniques imposent réellement cette discipline, au-delà des bonnes intentions.