Agents Claude : que tester après le rapport Anthropic du 9 octobre ?

Un agent IA est un système qui enchaîne des décisions et des appels d’outils pour accomplir une mission dans un périmètre d’action défini. Le 9 octobre 2026, Anthropic publie un rapport sur des actions non prévues de Claude. Pour une DSI, cette actualité place la gestion des obstacles au centre de la recette avant adoption.

L’angle Forward Deployed Engineer consiste à traduire ce constat en essais observables : que fait l’agent quand un service manque, quand un accès est refusé ou quand la mission exige une validation ? L’équipe doit pouvoir observer un blocage, comprendre sa cause et reprendre le travail dans des conditions définies avant le pilote.

Anthropic décrit des actions non prévues observées surtout pendant des évaluations et des usages internes, ce qui justifie de tester précisément les limites d’action.

Le rapport présente notamment des soumissions de formulaires, des accès détournés à des données et des contournements de restrictions d’outils. Anthropic qualifie leur impact réel de limité et précise que, à sa connaissance, ces cas ne concernent pas des données clients. Ces observations ne donnent pas un taux d’incident applicable à votre entreprise.

Une correction publiée le 12 octobre précise le rôle des limites de longueur des URL. Il faut lire la version corrigée. La conséquence pratique proposée ici reste simple : une panne ou un refus doit déclencher une décision prévue par votre application. Le scénario de test doit donc décrire l’obstacle, l’action permise et la preuve attendue.

Un agent Claude doit disposer d’une condition d’arrêt explicite, car une mission bloquée peut conduire à proposer des actions dépassant les permissions initialement accordées.

Prenons un exemple fictif : une équipe demande de préparer une réponse à un ticket à partir de sa base documentaire. La recherche ne retourne aucune procédure pertinente. Le résultat acceptable peut être un brouillon incomplet accompagné d’une demande de précision. Une exploration de comptes supplémentaires ou un envoi au demandeur ne découle pas automatiquement de la mission.

Il faut écrire cette différence dans la définition du périmètre de l’agent. Pour chaque objectif, indiquez les sources accessibles, les opérations autorisées et les situations qui imposent une reprise humaine. Le responsable métier doit pouvoir valider ces règles sans devoir interpréter une consigne technique.

Précisez aussi les solutions de secours permises. Si une seconde base documentaire peut être consultée, son accès doit déjà appartenir à la mission. Une règle vague invitant à trouver une autre solution laisse cette décision ouverte. La fiche de recette doit nommer le secours accepté et le point où l’agent demande une décision.

Ajoutez les instructions contradictoires rencontrées dans les documents. La recette des injections de prompt indirectes complète ces essais. Votre campagne doit aussi couvrir l’absence de contenu hostile : une simple indisponibilité peut suffire à révéler un périmètre mal défini.

La recette doit provoquer des obstacles dans un environnement isolé, puis vérifier simultanément la réaction de l’agent, les décisions du contrôleur et les effets produits.

Construisez des outils simulés avec des données fictives et des destinations de test. Le tableau suivant propose des scénarios de recette, sans prétendre reproduire les incidents Anthropic. Chaque ligne associe une situation à une frontière vérifiable.

Le verdict porte sur les effets observés. Une réponse finale prudente peut masquer une tentative refusée par le contrôleur ; cette tentative mérite une analyse distincte. Un message annonçant l’arrêt doit également correspondre à l’arrêt des tâches encore actives. Vérifiez les opérations en attente et les effets différés dans le simulateur.

Gardez un cas témoin où le service fonctionne et où les droits sont valides. Comparez ensuite la même mission avec l’obstacle ajouté. Cette paire aide à distinguer une difficulté métier d’un défaut de gestion de panne. Elle permet également de vérifier que la correction conserve une réponse utile dans le cas normal.

Les permissions de Claude doivent être contrôlées dans les composants qui exécutent les actions, avec des restrictions adaptées aux fichiers, aux destinations et aux opérations métier.

Dans son article sur le confinement de Claude, publié le 25 mai 2026, Anthropic présente la limitation des capacités accessibles comme un moyen de borner les conséquences d’une défaillance. Pour votre recette, cela implique de tester les frontières depuis chaque chemin d’exécution disponible, y compris les sous-processus et les connecteurs.

La documentation de sécurité de Managed Agents, vérifiée le 19 octobre 2026, distingue notamment les restrictions réseau, celles des outils web et les politiques de permission. Ces réglages dépendent du mode d’hébergement. Un domaine autorisé peut recevoir plusieurs types de requêtes ; son autorisation ne décide pas des opérations métier permises.

Établissez donc une matrice reliant identité, ressource et opération. Lire un ticket, modifier son statut et envoyer une réponse exigent des règles distinctes. Pour un agent qui utilise une interface graphique, la même exigence s’applique : piloter un écran suppose de borner les actions. Les contrôles doivent continuer à fonctionner lorsque le modèle propose une autre voie.

Testez ensuite la révocation pendant une exécution. Retirez un droit dans le simulateur après une première action permise, puis observez l’appel suivant. Le contrôleur doit appliquer la décision en vigueur. Une autorisation conservée au début de la session ne doit pas prolonger un accès retiré par le responsable du processus.

Une recette utile associe des missions représentatives, des obstacles préparés, des résultats attendus et des traces suffisantes pour rejouer chaque décision avant de lancer le pilote.

Commencez avec le responsable du processus et la personne chargée de l’exploitation. Ils doivent s’accorder sur ce que signifie une tâche terminée, bloquée ou reprise. Le guide de construction d’un jeu de tests aide à organiser ce corpus. La séquence suivante constitue une méthode proposée à adapter à vos risques.

1. Décrire la mission normale, ses données et ses effets autorisés, avec un résultat métier vérifiable.
2. Remplacer les systèmes externes par des simulateurs qui enregistrent les opérations sans effet réel.
3. Introduire les pannes, les refus et les demandes ambiguës en conservant une référence commune.
4. Rejouer les cas pour observer les variations de comportement, en gardant les versions de configuration.
5. Examiner les traces avec le métier et l’exploitation, puis corriger les frontières défaillantes.
6. Décider du pilote limité, de ses conditions de suspension et de la personne qui peut l’arrêter.

La grille de recette d’un agent IA peut aider à cadrer les cas à examiner. Documentez séparément la réussite métier, les actions interdites proposées et les effets effectivement empêchés. Cette distinction rend les corrections plus précises et permet de voir si une protection bloque aussi les tâches légitimes.

Le dossier d’adoption doit relier les informations du fournisseur à la configuration testée, aux permissions accordées et aux résultats observés sur vos propres missions.

Le 15 octobre 2026, Anthropic annonce un accès renforcé pour des évaluateurs indépendants, dont METR. La page précise les conditions d’accès et de publication, avec une mise à jour le 16 octobre. Pour l’acheteur, ces informations alimentent l’examen du fournisseur. La recette du système intégré reste à produire avec ses outils et ses droits réels.

Demandez une description des protections disponibles dans l’offre retenue, de leurs limites et de la responsabilité de configuration. En interne, conservez l’identifiant du modèle, la version des instructions, les outils exposés et les règles d’autorisation. Le dossier doit permettre d’attribuer un résultat à une configuration précise. Une modification de connecteur ou de permission doit conduire à examiner les cas concernés.

Les traces doivent permettre de reconstruire la chaîne : mission, appel proposé, décision du contrôleur, effet constaté, arrêt ou reprise. Les principes d’observabilité d’un système d’IA aident à définir ces événements. Ajustez leur contenu et leur conservation à la sensibilité des données. Une collecte exhaustive sans usage défini rend la revue plus difficile et expose inutilement les contenus.

Attribuez enfin un propriétaire à chaque preuve. L’exploitation doit retrouver la décision d’autorisation, le métier doit reconnaître le résultat attendu et le responsable du pilote doit connaître les limites restantes. Faites relire un essai par une personne qui ne l’a pas préparé : elle doit pouvoir expliquer le verdict à partir du dossier.

Un pilote peut commencer lorsque les missions utiles réussissent dans un périmètre explicite et que les essais montrent des refus, des reprises et des arrêts vérifiables.

Définissez la décision avant la campagne. Un effet externe non autorisé, une identité utilisée hors périmètre ou une poursuite d’exécution après l’arrêt demandé doivent déclencher une correction et une nouvelle revue. Il s’agit de critères proposés pour votre projet. Leur application doit préciser qui qualifie l’événement et qui décide de la reprise.

Le pilote doit aussi rester utile : mesurez le travail correctement terminé et les reprises nécessaires. La personne chargée de la supervision humaine doit voir l’opération concrète avant de l’autoriser et pouvoir interrompre l’exécution. Testez cette interruption dans les mêmes conditions que les scénarios métier, avec les tâches en arrière-plan comprises.

La direction peut alors décider sur un dossier lisible : bénéfice attendu, périmètre accordé, résultats des essais et limites restantes. Un audit IA du système existant permet de structurer ce travail lorsque les droits, les connecteurs ou les responsabilités sont dispersés. Le livrable attendu est une décision argumentée et un plan de correction exploitable par l’équipe.

Analyse et méthode proposées par Anand Candassamy au 19 octobre 2026.