Choisir une tâche réelle et une limite claire
Un agent d’intelligence artificielle peut sembler fiable tant que le réseau répond, que les fichiers sont accessibles et que chaque outil retourne le résultat attendu. La vraie question apparaît lorsque l’une de ces conditions disparaît. Avant de lui confier une tâche quotidienne, choisissez un scénario réel et assez étroit pour être testé en une heure. Il peut s’agir de préparer un brouillon de réponse, de classer une demande de service ou de remplir une fiche d’inventaire. Définissez ensuite la frontière du test. L’agent peut lire certains documents et produire une proposition, mais il ne doit pas envoyer de message, modifier un dossier officiel ni engager une dépense. Notez le résultat normal, la personne responsable et l’action qui exige une approbation. Cette limite évite de confondre autonomie et permission. Elle permet aussi d’observer une panne sans risquer qu’un essai touche un client, un employé ou une donnée de production.
Préparer quatre pannes simples à reproduire
Créez quatre cartes de test. Sur la première, retirez l’accès au document principal. Sur la deuxième, rendez un outil indisponible, par exemple en utilisant une adresse de test qui retourne une erreur. Sur la troisième, fournissez une information contradictoire dans deux fichiers. Sur la quatrième, faites attendre l’approbation humaine plus longtemps que prévu. Chaque carte doit préciser le déclencheur, le comportement attendu et ce qui constituerait un échec. Le bon comportement n’est pas toujours de terminer la tâche. Si le prix d’un produit manque, l’agent devrait signaler l’information absente au lieu de l’inventer. Si deux procédures se contredisent, il devrait identifier les passages concernés et transférer la décision. Si l’outil de courriel ne répond plus, il devrait conserver le brouillon sans multiplier les envois. Une panne réussie est donc une panne contenue : l’agent s’arrête au bon endroit, explique ce qu’il sait et laisse une trace utile pour la reprise.
Observer les décisions, pas seulement le résultat final
Pendant l’exercice, consignez chaque étape dans une feuille simple : heure, action demandée, outil appelé, réponse reçue, décision prise et intervention humaine. Vous cherchez des signes précis. L’agent répète-t-il la même action sans limite? Remplace-t-il une donnée manquante par une supposition? Change-t-il d’objectif après une erreur? Affiche-t-il une réussite alors que l’étape importante a échoué? Ces comportements peuvent rester invisibles si l’équipe regarde uniquement le dernier message. Fixez des limites mesurables avant le test. Par exemple, pas plus de deux nouvelles tentatives, arrêt après cinq minutes sans réponse, aucun envoi sans identifiant d’approbation et aucun champ obligatoire rempli par déduction. Ajoutez un coût maximal ou un nombre maximal d’appels lorsque l’agent utilise des services facturés. Une limite explicite transforme une impression de fiabilité en critère vérifiable. Elle empêche aussi une boucle silencieuse de consommer du temps et des ressources pendant que personne ne regarde l’écran.
Tester l’arrêt, la reprise et le retour au manuel
Le bouton d’arrêt doit être accessible à une personne qui n’a pas construit l’automatisation. Demandez-lui d’interrompre l’agent pendant une étape, puis vérifiez ce qui reste : brouillon, journal, fichier temporaire ou action partiellement exécutée. L’état doit être compréhensible sans relire toute la conversation. Une mention claire comme « en attente d’approbation » vaut mieux qu’un statut vague qui laisse croire que la tâche est terminée. Rétablissez ensuite l’outil et reprenez le scénario. L’agent doit éviter de recommencer les actions déjà complétées, surtout un envoi, une réservation ou une création de dossier. Testez aussi le parcours manuel. Un employé doit pouvoir récupérer les données nécessaires et finir le travail sans dépendre du même service en panne. Mesurez le temps de reprise et notez les informations qui ont manqué. Si le retour au manuel exige l’aide du développeur ou un accès inconnu de l’équipe, le processus n’est pas encore prêt pour un usage régulier.
Transformer l’exercice en condition de mise en service
À la fin, classez chaque observation dans trois groupes : acceptable, à corriger avant le lancement ou à surveiller après le lancement. Une correction prioritaire touche généralement une action irréversible, une donnée sensible, une boucle sans limite ou une fausse confirmation. Pour chaque point, nommez un responsable et une date. Rejouez seulement les cartes touchées après la modification, puis répétez l’exercice complet avant d’augmenter les permissions de l’agent. Conservez une fiche d’une page avec le propriétaire du processus, les outils utilisés, les limites de tentatives, les actions interdites, le moyen d’arrêt et la procédure manuelle. Refaites le test lorsqu’un modèle, une consigne, une source de données ou une intégration change. Dans une petite organisation, cet exercice trimestriel peut tenir dans une réunion de 60 minutes. Son objectif n’est pas de prouver que l’agent ne tombera jamais en panne. Il sert à confirmer que la panne reste visible, limitée et récupérable par les personnes qui devront réellement la gérer.
