Vos agents IA sont capables. Ils ne sont pas fiables — et ce n’est pas la même chose.
Il existe une confusion, très répandue et très coûteuse, entre deux notions que tout oppose : la capacité d’un modèle et sa fiabilité.
La capacité, c’est : est-ce qu’il sait faire cette tâche ? La fiabilité, c’est : est-ce qu’il la fait correctement à chaque fois ?
Les travaux de Arvind Narayanan et Sayash Kapoor, chercheurs à Princeton, portent précisément sur cet écart. Leur constat, relayé par la presse économique en mars 2026, tient en une phrase : la fiabilité progresse beaucoup moins vite que la capacité, et l’industrie mesure presque exclusivement la seconde.
Ce travail n’a pas été traduit en français. Il mérite de l’être, parce qu’il donne un vocabulaire utilisable pour décider si l’on confie ou non une tâche à un agent.
Le problème des moyennes
La plupart des modèles sont évalués sur leur précision moyenne sur un ensemble de tâches. C’est une métrique commode et, disent les chercheurs, une métrique qui « autorise des performances extrêmement peu fiables ».
Prenons un exemple. Un agent réussit 90 % des tâches qu’on lui confie. Excellent, en apparence. Mais si les 10 % d’échecs se répartissent au hasard, cela signifie que sur dix factures traitées, une sera fausse — et vous ne savez pas laquelle.
Pour une assistance humaine, c’est acceptable : la personne relit. Pour une automatisation complète, c’est disqualifiant. C’est exactement la distinction que posent les auteurs : l’automatisation sans supervision exige la fiabilité comme préalable absolu, là où l’assistance tolère beaucoup d’incohérence.
Les quatre dimensions de la fiabilité
C’est l’apport le plus directement utilisable de leur travail. Plutôt qu’un score unique, ils décomposent la fiabilité en quatre questions distinctes.
La cohérence. L’agent produit-il le même résultat si on lui soumet deux fois la même tâche ? Cette question surprend souvent : on imagine un système informatique déterministe. Un modèle de langage ne l’est pas. Deux exécutions identiques peuvent suivre des chemins différents et aboutir à des conclusions différentes.
La robustesse. Fonctionne-t-il encore quand les conditions ne sont pas idéales ? Un document mal scanné, un champ vide, une formulation inhabituelle, un format inattendu. C’est-à-dire : la réalité.
La calibration. Sait-il dire qu’il ne sait pas ? C’est, de loin, la dimension la plus importante en entreprise. Un système qui signale son incertitude peut être encadré : on fait valider les cas douteux. Un système qui répond toujours avec le même aplomb ne peut pas l’être.
La sécurité. Quelle est l’ampleur des dégâts quand il se trompe ? Une erreur de classement d’e-mail se corrige en trois secondes. Un paiement envoyé au mauvais fournisseur, non.
Les chiffres
Ils sont éclairants, et ils invitent à la prudence.
Sur un ensemble de tâches générales, l’amélioration de la fiabilité entre générations de modèles représente environ la moitié de l’amélioration de la précision. Sur des tâches de support client, elle n’en représente qu’un septième.
Autrement dit : quand un nouveau modèle est annoncé comme nettement meilleur, il est nettement plus capable. Il n’est que marginalement plus fiable.
Sur les scores mesurés par les chercheurs, les meilleurs modèles du moment atteignaient environ 85 % de fiabilité globale. Mais les sous-scores racontent une autre histoire : sur la calibration — la capacité à dire « je ne suis pas sûr » —, l’un des modèles testés tombait à 52 %. Et sur l’évitement des erreurs catastrophiques, à 25 %.
Ce dernier chiffre est le plus important de tous. Il signifie que, dans ce test, le modèle échouait à éviter l’erreur grave trois fois sur quatre lorsque la situation s’y prêtait.
Ce que ça change, concrètement
Ce n’est pas un argument contre les agents. C’est un argument pour la conception.
Voici ce que nous en tirons, et ce que nous appliquons systématiquement.
Ne jamais demander seulement une réponse. Demander la réponse et le niveau de certitude, champ par champ. En dessous d’un seuil, le cas part en validation humaine. C’est la calibration, traitée par la conception plutôt que par l’espoir.
Ajouter des contrôles qui ne dépendent pas du modèle. La somme des lignes correspond-elle au total ? Ce fournisseur existe-t-il dans la base ? Ce numéro de facture a-t-il déjà été saisi ? Ce sont des vérifications de programmation ordinaire, et ce sont elles qui rendent un flux sûr — pas la performance du modèle.
Borner les conséquences. Un agent qui lit et propose ne présente aucun risque. Un agent qui écrit dans vos systèmes ou envoie des messages doit avoir une liste d’actions autorisées, des plafonds, et une validation humaine sur tout ce qui est irréversible.
Tester la cohérence, pas seulement la justesse. Soumettre vingt fois le même dossier et regarder si les réponses concordent. C’est un test que presque personne ne fait, et qui révèle immédiatement si un flux est mûr pour la production.
Commencer en observation. L’agent propose, un humain valide, pendant quelques semaines. On mesure l’écart. On n’élargit son autonomie que sur les catégories où l’écart est nul.
La phrase à retenir
Un agent capable n’est pas un agent fiable, et c’est la fiabilité qui détermine si vous pouvez le laisser travailler seul.
C’est une distinction ennuyeuse. Elle sépare les automatisations qui tiennent deux ans de celles qu’on débranche au bout de trois mois.