Un modèle peut résoudre un problème difficile, expliquer sa démarche avec assurance et pourtant se tromper sur une hypothèse discrète.
Le problème n’est pas seulement mathématique. Il apparaît dès qu’un agent produit un résultat que quelqu’un utilisera ensuite : formule dans un tableur, analyse statistique, décision métier, modification de code ou action sur un compte.
La bonne question n’est donc pas : « le modèle est-il intelligent ? »
La bonne question est : quelle preuve exige-t-on avant d’accepter son résultat ?
Une réponse détaillée n’est pas une preuve
Les modèles de langage optimisent une suite de texte cohérente. Une démonstration élégante peut masquer :
- une condition oubliée ;
- un domaine de définition incorrect ;
- un théorème inventé ;
- un saut logique ;
- une opération exacte appliquée au mauvais problème.
Le ton aide peu. Une réponse fausse peut être formulée avec la même confiance qu’une réponse correcte.
Pour un agent, la longueur du raisonnement n’est donc pas un critère de validation. Ce qui compte est la présence de contrôles indépendants.
L’architecture minimale : générer, tester, décider
Une boucle fiable sépare trois fonctions.
1. Le générateur
Il reformule la mission, choisit une stratégie et produit un candidat. Il peut utiliser un modèle généraliste ou un modèle spécialisé.
2. Le vérificateur
Il ne cherche pas à rendre la réponse plus jolie. Il essaie de la casser :
- recalcul indépendant ;
- tests sur des cas simples et des cas limites ;
- comparaison avec une seconde méthode ;
- contrôle des unités et des invariants ;
- exécution de code ;
- vérification formelle avec un outil comme Lean lorsque l’enjeu le justifie.
3. La règle d’arrêt
Elle décide si le résultat peut être livré, doit être rejoué ou doit remonter à un humain.
Sans règle d’arrêt, l’agent peut continuer à reformuler la même erreur. Sans vérificateur, il transforme une hypothèse en conclusion. Sans preuve conservée, personne ne peut auditer ce qu’il a fait.
Le niveau de preuve doit suivre le risque
Tous les résultats n’exigent pas la même procédure.
| Usage | Contrôle raisonnable |
|---|---|
| Expliquer une notion | Exemple simple et source fiable |
| Préparer une formule de tableur | Recalcul et cas limites |
| Produire une analyse réutilisée par une équipe | Tests reproductibles et revue métier |
| Modifier un système ou déclencher une action externe | Preuve finale et validation humaine |
| Démonstration critique | Vérification experte ou formelle |
Le piège consiste à utiliser le même modèle et la même validation partout. On surcontrôle les tâches triviales et on sous-contrôle les actions sensibles.
Les outils battent souvent un raisonnement plus long
Donner davantage de temps au modèle peut améliorer une réponse, mais cela ne crée pas une garantie.
Un agent peut approfondir une mauvaise représentation du problème. Il peut aussi répéter la même hypothèse fausse dans plusieurs variantes.
Pour une addition, un calculateur est plus fiable qu’un long raisonnement. Pour une identité symbolique, un système algébrique est plus adapté. Pour une preuve importante, un assistant formel apporte un niveau de contrôle que le style du texte ne peut pas fournir.
L’agent utile n’est donc pas celui qui « réfléchit » toujours plus longtemps. C’est celui qui sait quel outil appeler et quand s’arrêter.
Un protocole de test concret
Avant de donner plus d’autonomie à un agent, construis dix cas réels :
- trois cas nominaux ;
- deux entrées ambiguës ;
- deux sources manquantes ou contradictoires ;
- deux actions qui exigent une validation ;
- un cas où le bon comportement est de refuser ou d’escalader.
Pour chaque exécution, conserve :
- le résultat attendu ;
- le résultat réel ;
- les preuves produites ;
- les outils appelés ;
- les validations demandées ;
- les corrections humaines ;
- les actions hors permission.
Un score global ne suffit pas. Un agent qui obtient neuf bons résultats puis publie une fois sans autorisation a échoué sur le contrôle, même si sa moyenne semble excellente.
Un serveur MCP pour rendre ce test réutilisable
J’ai publié un petit serveur MCP open source qui transforme cette méthode en trois outils : génération d’un plan de test, score d’une exécution et scorecard CSV.
Le dépôt est ici : Kryve Agent Evaluation MCP.
Il fonctionne localement sur stdio, n’utilise aucun secret et expose uniquement des outils de lecture. L’objectif n’est pas de certifier un agent, mais de rendre le protocole observable et reproductible.
Pour comprendre comment choisir et connecter ce type de composant, le guide MCP Servers : 8 serveurs MCP indispensables détaille le rôle du protocole, des clients et des permissions.
À retenir
Une sortie plausible n’est pas un résultat vérifié.
La fiabilité vient d’une architecture : sources, outils, contrôles indépendants, preuve finale et règle d’arrêt. Plus l’agent peut agir, plus cette architecture compte.
La version complète, avec les systèmes de preuve formelle et les usages étudiants et professionnels, est disponible dans le guide IA et raisonnement mathématique.
Top comments (0)