Le test oublié des agents IA : savoir s’arrêter, puis reprendre

Un agent semble efficace quand les données sont complètes et les outils disponibles. Le travail réel introduit d’autres situations : une connexion échoue, un résultat devient incertain ou un humain intervient entre deux étapes. Préparer ces cas aide une entreprise à savoir quand poursuivre, quand suspendre et comment reprendre sans répéter une action.

Une tâche est lancée, puis l’écran affiche une erreur. L’action a-t-elle échoué avant d’être exécutée ou après avoir été prise en compte ? Si personne ne sait répondre, relancer immédiatement peut aggraver le problème. Cette incertitude constitue un test plus instructif qu’une démonstration réalisée dans des conditions idéales.

Pour une petite entreprise qui automatise une partie de son fonctionnement, l’arrêt n’est donc pas un détail technique réservé aux développeurs. C’est une décision d’organisation : quel travail peut attendre, qui doit être prévenu et quelle information faut-il conserver pour repartir correctement ?

L’automatisation se prépare aussi autour des exceptions

Le parcours de Kristin Zapasnik, fondateur de Verslomatika et spécialiste de l’intégration de l’IA et de l’automatisation des processus d’entreprise, illustre l’élargissement des usages. Il travaille avec l’IA depuis 2022 ; elle l’a d’abord aidé à modifier du code. En 2026, il déclare confier à des agents le développement et la maintenance de ses projets.

Le service Verslomatika comprend l’analyse des processus, la préparation et le calibrage des agents, les connexions aux outils, les tests et l’entretien. Dans l’organisation décrite, le propriétaire définit le plan et les priorités. Le coordinateur de l’activité choisie répartit les tâches entre spécialistes, chacun intervenant dans le périmètre de ses connaissances, de ses outils et de ses accès.

Prévoir trois raisons de suspendre

Une première suspension concerne l’information : deux sources se contredisent ou la donnée indispensable manque. Une deuxième concerne les accès : l’outil ne répond pas ou la permission nécessaire n’existe pas. Une troisième concerne l’effet de l’action : le système ne peut pas confirmer ce qui a réellement été fait.

Ces catégories appellent des réponses différentes. Une donnée manquante peut nécessiter une question au partenaire ; une panne peut demander une intervention technique ; un effet incertain exige de rechercher une confirmation avant de répéter l’action. Les rassembler sous un vague statut « erreur » empêche de choisir le bon geste.

• Avant l’arrêt : conserver la tâche, le dernier état confirmé et la cause de suspension.
• Pendant l’attente : désigner le responsable et indiquer l’information attendue.
• Avant la reprise : vérifier ce qui a changé et si l’action a déjà eu lieu.
• Après la reprise : confirmer le résultat et garder la trace de l’incident.

Simuler un incident sans toucher à un client

Un essai peut se dérouler sur un dossier clairement séparé de l’activité réelle. On retire volontairement une information ou on simule une indisponibilité, puis on observe la réaction. L’objectif n’est pas d’obtenir une réponse élégante. Il est de voir si le processus évite d’inventer une donnée et transmet une demande compréhensible au bon responsable.

Kristianas indique utiliser les agents pour les courriels clients, les échanges avec les partenaires, les stocks et la coordination des livraisons. Dans ces tâches, une suspension doit laisser assez de contexte pour que quelqu’un puisse reprendre. Le message utile explique ce qui manque ou ce qui reste incertain, au lieu de se limiter à annoncer que l’automatisation a rencontré un problème.

Le produit physique impose sa propre confirmation

Dans son activité Memory Casting, les kits de moulage de mains sont destinés aux couples et aux familles. Les opérations matérielles restent réalisées par des personnes et des partenaires. Lorsqu’un état numérique ne correspond pas à une confirmation physique, la bonne reprise passe par la vérification de cette étape, et non par une succession de messages automatiques.

Un autre exemple concerne le contenu. Topdovanos, portail du même propriétaire, publie un guide de Noël en lituanien sur les kits de moulage de mains. Il associe comparaisons, vidéos, préparation et questions fréquentes. La chaîne de travail décrite utilise l’IA pour la recherche, la rédaction et la structure, avec une relecture avant publication programmée sur le serveur.

Les idées cadeaux pour couples sont plus faciles à comparer lorsque le contenu du kit et le déroulement de l’activité sont expliqués.

Reprendre la bonne version du travail

Imaginons qu’un texte soit corrigé alors que sa publication est programmée. Le test de reprise doit vérifier quelle version a été approuvée et laquelle sera rendue publique. La même logique vaut pour une réponse client modifiée par une personne après la préparation d’un brouillon. Le système ne devrait pas écraser cette intervention par simple reprise de sa tâche initiale.

À la fin de l’essai, l’équipe doit pouvoir raconter simplement ce qui s’est passé : où le travail s’est arrêté, qui l’a repris et comment le résultat a été retrouvé. Ce récit révèle les informations manquantes et les gestes devenus inutiles. Il donne aussi au dirigeant un moyen de décider quelles tâches peuvent continuer et lesquelles demandent encore une correction.