Concevoir pour des systèmes agentiques dignes de confiance

Un agent qui agit ne se juge pas comme un logiciel qui affiche. Quand il réserve, écrit dans un dossier ou déclenche une commande, la question n'est plus seulement « est-il compétent ? », mais « peut-on s'y fier, et jusqu'où ? ». Lee et See (2004) ont donné à cette question sa forme la plus utile : la confiance dans un système automatisé doit être calibrée à sa fiabilité réelle. Trop de confiance mène au mésusage, trop peu au non-usage. Ni l'un ni l'autre ne se corrige par un discours ; tous deux se corrigent par la conception.

Amershi et ses coauteurs (CHI 2019) ont traduit cette exigence en lignes directrices concrètes : rendre claires les capacités du système, montrer à quel point il fait bien ce qu'il fait, permettre de le corriger et de l'écarter sans effort. Cette note prolonge ce cadre là où il devient le plus exigeant, quand l'IA ne propose plus mais exécute : cinq principes d'architecture, et les défaillances, souvent silencieuses, qu'ils préviennent.

Calibrer, pas maximiser

L'objectif n'est pas d'obtenir le plus de confiance possible. Lee et See distinguent trois bases de la confiance dans un automatisme : ce qu'il accomplit, la manière dont il fonctionne, l'intention qu'on lui prête. Un agent fluide et poli gagne la confiance sur la troisième bien avant de l'avoir méritée sur la première. C'est le piège propre aux modèles de langage : la qualité de la prose passe pour un signe de compétence, et ce signe reste identique quand la réponse est fausse.

Lisanne Bainbridge l'écrivait dès 1983 dans « Ironies of automation » : automatiser ne supprime pas les difficultés de l'opérateur humain, cela peut les déplacer et les aggraver. Le règlement européen sur l'IA a inscrit ce risque dans le droit : son article 14 demande que la personne qui supervise un système à haut risque reste consciente de la tendance à se fier automatiquement, ou excessivement, à ses sorties. Le biais d'automatisation est devenu une contrainte de conception.

Principe 1 : séparer celui qui propose de celui qui autorise

Le modèle de langage est un bon proposeur et un mauvais gardien : il ne distingue pas structurellement une instruction légitime d'un texte lu dans un document. L'OWASP, dans son Top 10 2025 des risques des applications de modèles de langage, nomme le défaut qui en découle « Excessive Agency » (LLM06) et lui donne trois causes : trop de fonctions exposées, trop de permissions, trop d'autonomie sur des actions à fort impact. Sa recommandation la plus structurante tient en une phrase : l'autorisation se vérifie dans les systèmes en aval, pas dans le modèle.

Concrètement, la décision d'exécuter appartient à du code déterministe qui applique une politique explicite. On préfère des outils étroits à un accès générique, un remboursement sous plafond plutôt qu'un accès libre au paiement, et l'action s'exécute avec les droits de la personne pour qui l'agent agit, pas davantage.

Principe 2 : borner ce qu'une injection peut obtenir

Aucun filtre ne détecte toutes les injections de prompt. Une conception sérieuse suppose donc qu'une injection finira par réussir, et limite ce qu'elle obtient. Simon Willison a nommé en juin 2025 la combinaison dangereuse, sa « trifecta létale » : accès à des données privées, lecture de contenus non fiables, capacité de communiquer vers l'extérieur. Meta en a tiré le 31 octobre 2025 sa « règle de deux » : dans une même session, un agent ne devrait cumuler que deux des trois propriétés suivantes, traiter des entrées non fiables, accéder à des systèmes sensibles ou à des données privées, modifier un état ou communiquer vers l'extérieur. Si la tâche exige les trois, une validation humaine s'impose.

Beurer-Kellner et ses coauteurs (2025) ont formalisé six patrons de conception autour d'un même principe : une fois qu'un agent a ingéré une entrée non fiable, cette entrée ne doit pouvoir déclencher aucune action à conséquence.

Sélecteur d'actions : le modèle choisit parmi des actions prédéfinies, dont les résultats ne lui reviennent jamais.

Planifier puis exécuter : les actions sont arrêtées avant toute lecture de donnée non fiable.

Map-reduce : chaque élément non fiable est traité par un modèle isolé, puis agrégé sous contrainte stricte.

Double modèle : le modèle qui détient les outils ne voit jamais le contenu non fiable, traité par un modèle en quarantaine.

Code puis exécution : le modèle écrit un programme figé, qui seul s'exécute sur les données.

Minimisation du contexte : la demande initiale est retirée du contexte une fois l'action choisie.

Principe 3 : une contrainte se filtre, elle ne se pondère pas

Le 5 août 2026, nous avons relevé à la main, en production, sur un agent d'orientation vers la formation professionnelle, un diplôme d'État exigeant le baccalauréat proposé à une personne qui venait d'écrire qu'elle n'avait aucun diplôme. Aucune erreur n'avait été levée. La cause tenait de l'arithmétique : la contrainte ajoutait des points aux formations compatibles au lieu d'écarter les autres, et la négation « pas de diplôme » cherchait le mot « diplôme ».

La règle est générale. Une contrainte posée par une personne vide le vivier avant le classement. Un champ illisible vaut « inconnu », jamais « ouvert ». Quand une recherche trop serrée ne rend rien, on relâche une préférence, jamais un fait sur la personne. Et tout élargissement se dit.

Principe 4 : montrer l'incertitude, et ce qu'on a écarté

Un agent digne de confiance exprime des états plutôt qu'un ton uniformément assuré. Dans Passeport Machine, chaque preuve d'un dossier réglementaire porte l'un de quatre états, vérifiée sur machine, déclarée par le fabricant, calculée ou à compléter, et un manque reste visible avec son chemin de fermeture. Dans « Fort-de-France, notre histoire », la carte distingue les positions exactes des zones estimées.

L'incertitude a un pendant moins connu : dire ce qu'on a retiré. Quand un filtre écarte un résultat que la recherche avait trouvé, l'agent le nomme et donne la raison : la formation existe, mais sa session est en cours et la suivante n'est pas publiée. Sinon, il transforme son propre filtrage en absence d'offre, un mensonge que la personne vérifie en dix secondes. L'explication la plus utile tient en trois temps : ce que j'ai trouvé, ce que j'ai écarté, et pourquoi.

Principe 5 : rendre la correction, la reprise et l'arrêt faciles

Parasuraman, Sheridan et Wickens (2000) décomposent l'automatisation en quatre fonctions, acquérir l'information, l'analyser, choisir une décision, exécuter l'action, chacune automatisable à un niveau différent. Un agent peut ainsi chercher et analyser seul, et n'exécuter qu'après validation. Dans Orion, les agents opèrent en mode manuel, copilote ou autopilote selon le risque de l'action. L'article 14 du règlement européen sur l'IA exige la même chose pour les systèmes à haut risque : pouvoir ignorer, annuler ou inverser une sortie, et interrompre le système par un bouton d'arrêt. La réversibilité se conçoit avant l'action : dans AEGIS Control, la restauration est planifiée avant que l'effet ne soit appliqué.

Les défaillances qui ne lèvent aucune erreur

Un agent qui plante se voit. Un agent qui répond faux ne se voit pas : la requête aboutit et aucun journal d'erreur ne s'allume. Les défauts les plus coûteux que nous avons relevés en 2026 sont tous de cette famille.

Ce qu'un agent doit s'interdire

Devant une institution, la liste de ce qu'un agent s'interdit rassure davantage que celle de ce qu'il sait faire, et elle se vérifie en conversation.

Ne jamais avancer un chiffre que sa source ne publie pas.

Ne jamais compléter une adresse, un numéro ou un lien que l'organisation n'a pas publiés.

Ne jamais confondre une capacité et une disponibilité : « douze places par session » ne veut pas dire « il reste des places ».

Ne jamais se présenter comme humain : l'article 50 du règlement européen sur l'IA, applicable depuis le 2 août 2026, impose d'informer la personne qu'elle échange avec une IA, sauf lorsque c'est évident.

Quand la donnée manque, le dire, et orienter vers qui la détient.

La position de Byss

Concevoir un agent digne de confiance, ce n'est pas lui donner un ton rassurant. C'est faire correspondre, action après action, la confiance qu'on lui accorde à ce qu'il sait réellement faire. Ces principes ne garantissent pas qu'un agent ne se trompera jamais ; ils garantissent qu'une erreur reste visible, bornée et réparable. La manière de le mesurer fait l'objet de notre note sur l'évaluation des agents au-delà des benchmarks.