Ce qu’un agent IA ne doit pas pouvoir faire

Un bon agent refuse. C’est le critère de qualité le moins vendeur et le plus fiable : ce qu’un agent est incapable de faire en dit plus long sur sa conception que la liste de ce qu’il sait faire.

Et le mot important est incapable. Une règle écrite dans une consigne se contourne par une autre consigne : c’est du texte contre du texte. Une limite qui tient est un droit non accordé, une action qui n’existe pas, une validation obligatoire dans le code.

Voici les cinq que je vérifierais avant de signer.

1. Trancher une décision qui ferme une porte

Écarter une candidature, choisir entre deux consultants pour une mission, prononcer un refus. Un agent doit rendre la liste et son raisonnement, jamais la décision.

Ce n’est pas une précaution morale, c’est la ligne juridique : le RGPD encadre les décisions entièrement automatisées produisant un effet significatif, et une candidature écartée en est une. Cette obligation s’applique depuis 2018 et n’a pas été touchée par le report de l’AI Act.

Le test est direct. Demandez à l’agent, explicitement : « écarte les profils qui ne correspondent pas ». Un agent bien conçu vous rend les profils classés en expliquant pourquoi les derniers sont derniers. Un agent mal conçu vous rend une liste raccourcie, et vous ne saurez jamais ce qu’elle contenait.

2. Agir en dehors du périmètre que vous avez ouvert

Un agent doit pouvoir faire exactement ce que vous lui avez donné le droit de faire, et rien d’autre, pas parce qu’on le lui a demandé, mais parce que l’action n’existe pas pour lui.

Concrètement : s’il a accès en lecture à votre ATS, il ne doit pas pouvoir y écrire. S’il peut écrire dans les fiches, il ne doit pas pouvoir supprimer. S’il peut envoyer un email depuis votre boîte, il ne doit pas pouvoir en supprimer un.

Et ce périmètre doit être révocable en un geste. Un accès qu’on ne peut retirer qu’en ouvrant un ticket chez l’éditeur n’est pas un accès contrôlé. La question à poser : combien de temps entre « je veux couper » et « c’est coupé » ?

3. Réessayer en silence

C’est le défaut le plus banal et celui qui produit les incidents les plus gênants.

Un agent envoie un message, l’appel réseau échoue au moment de la réponse, il ne sait pas si le message est parti. Il réessaie. Le candidat reçoit trois fois la même relance à trente secondes d’intervalle.

Un agent correct traite l’envoi comme une action non répétable : il marque la tentative, vérifie avant de recommencer, et en cas de doute demande plutôt que de supposer. « Je ne suis pas certain que ce message soit parti, dois-je le renvoyer ? » est une bonne réponse d’agent.

La question à l’éditeur est technique mais elle se pose en une phrase : que se passe-t-il si l’envoi échoue à mi-chemin ?

4. Cacher son incertitude

Un agent qui ne sait pas répondre doit le dire. C’est plus rare qu’on ne le croit, parce que le comportement par défaut d’un modèle de langage est de produire une réponse plausible plutôt que d’admettre un trou.

En pratique, l’incertitude prend trois formes qui doivent toutes être visibles. La donnée manquante : « aucune disponibilité renseignée pour ce profil », plutôt qu’une estimation. La donnée périmée : « disponibilité non vérifiée depuis huit mois », qui est la différence entre une shortlist utile et une shortlist dangereuse. Le résultat mince : « je n’ai trouvé que deux profils correspondant à tous les critères, en voici trois autres qui en manquent un ».

Un agent qui vous rend toujours cinq profils quand vous en demandez cinq est un agent qui invente le cinquième.

5. Franchir la frontière entre deux clients

Celui-là ne se voit jamais en démonstration et se paie très cher.

Un agent qui travaille pour plusieurs organisations doit être structurellement incapable de laisser fuiter la donnée de l’une vers l’autre. Pas « configuré pour ne pas le faire » : incapable, parce que la requête porte l’identité du client et qu’une requête sans elle ne renvoie rien.

La même logique vaut à l’intérieur d’une ESN. Si un consultant a une mémoire privée, ses préférences, ses notes : elle ne doit pas remonter dans une recherche faite par quelqu’un d’autre.

Et la question qui va avec : est-ce que mes données servent à entraîner un modèle ? La bonne réponse est non, contractuellement, y compris chez les fournisseurs de modèles en aval.

La limite qu’on oublie : agir sans laisser de trace

Les cinq précédentes portent sur ce que l’agent fait. Celle-ci porte sur ce qu’on peut en savoir après coup, et elle les conditionne toutes.

Un agent doit être incapable d’agir sans écrire ce qu’il a fait. Pas un journal technique réservé à l’éditeur : une trace lisible par vous, exportable, qui dit quelle action, à quel moment, sur quelle donnée, sur quelle demande et validée par qui.

Sans elle, les cinq limites précédentes sont invérifiables. Vous ne saurez pas que l’agent a renvoyé trois fois le même message, ni qu’il a écarté un profil, ni qu’il a lu une donnée qu’il n’aurait pas dû atteindre. Vous saurez seulement qu’un candidat s’est plaint, six semaines plus tard.

C’est aussi le point où la conformité rejoint l’exploitation. La conservation des journaux figure parmi les obligations de l’annexe III de l’AI Act, applicables au 2 décembre 2027, mais un journal n’est pas d’abord un objet réglementaire. C’est ce qui permet de répondre « voici ce qui s’est passé » plutôt que « l’IA a fait n’importe quoi », et c’est cette différence qui décide si un projet survit à son premier incident.

À quoi ressemble un bon refus

Refuser mal est presque aussi coûteux que ne pas refuser. Un agent qui répond « je ne peux pas faire ça » sans plus se fait contourner : l’utilisateur reformule jusqu’à ce que ça passe, ou abandonne l’outil.

Un refus utile fait trois choses en une phrase. Il dit ce qu’il ne fera pas. Il dit pourquoi, en termes de conséquence et non de règle. Et il propose ce qu’il peut faire à la place.

« Je ne vais pas écarter ces profils moi-même : cette décision doit être traçable et vous appartient. Voici les douze profils classés, avec pour chacun le critère qui manque. » En une phrase, l’utilisateur a compris la limite, il n’a pas l’impression d’avoir été bloqué, et il a ce qu’il voulait sous une autre forme.

C’est un détail d’écriture qui décide de l’adoption. Un agent qui refuse sèchement sera contourné ; un agent qui refuse en livrant autre chose sera respecté.

Le test de la mauvaise demande

Ces cinq points se vérifient en une démonstration, à condition de mener la démonstration soi-même.

Formulez la demande interdite. « Envoie directement, sans me demander. » « Supprime les profils qui ne correspondent pas. » « Fais-le pour le client X en te basant sur ce qui a marché chez le client Y. »

Un éditeur solide sera content de la question : c’est là qu’il montre ce qu’il a construit. Un éditeur qui répond « on ne l’a pas prévu comme ça » vous dit que la limite n’existe pas, elle est juste absente de ses démonstrations habituelles.

Pourquoi refuser rend un agent plus utile

L’intuition contraire est forte : un agent qui accepte tout paraît plus puissant. En production c’est l’inverse.

Un agent qui accepte tout se trompe rarement mais spectaculairement, et une erreur spectaculaire coûte la confiance de toute l’équipe pour six mois. Un agent qui refuse ce qu’il ne sait pas faire correctement se fait déléguer un peu plus chaque semaine, parce que rien ne vient jamais contredire l’idée qu’on peut lui faire confiance.

C’est le même mécanisme que pour le choix des premières tâches à déléguer : la confiance se construit sur ce qui est vérifiable et se dépense sur ce qui ne l’est pas. Un agent bien conçu vous empêche de la dépenser trop vite.