Comparatif · Reprise après incident
Agent IA en PME : renvoyer une commande sans créer de doublon
Renvoi automatique, validation humaine ou vérification du résultat : comment reprendre une commande fournisseur sans confirmation et éviter les doublons.
Quand un agent IA ne reçoit pas la confirmation d’une commande, il ne doit pas en déduire qu’elle a échoué. La commande peut déjà exister chez le destinataire. Avant toute relance, il faut vérifier son état et les protections du service contre les doublons. Faire approuver une deuxième fois la même action ne règle pas ce problème.
Le Baromètre France Num 2026, enquête auprès de 9 655 TPE-PME, distingue génération de contenu et automatisation des tâches. Ces déclarations ne mesurent pas la fiabilité des envois.
Une commande peut réussir sans que l’agent le sache
Exemple entièrement fictif : l’assistante achats d’une PME de maintenance fait approuver une commande de pièces. L’agent la transmet au portail fournisseur, qui l’enregistre. La connexion coupe avant la confirmation ; l’outil affiche une erreur.
À cet instant, « résultat inconnu » décrit mieux la situation que « commande échouée ». Une relance aveugle peut commander deux fois les pièces. Le fournisseur sera peut-être ravi ; le stock, un peu moins.
Ce mécanisme est documenté par AWS : une modification peut être réalisée avant qu’une erreur soit signalée au demandeur. Il concerne aussi les automatisations classiques. L’IA ne supprime pas les coupures réseau.
Comparer trois façons de reprendre
Ce tableau est une grille Altoriane, sans classement de produits ni résultat de benchmark.
| Dispositif | Ce qu’il apporte | Limite après confirmation perdue |
|---|---|---|
| Renvoi automatique sur erreur | Reprend une tentative interrompue | Peut répéter une action déjà réalisée. |
| Nouvelle validation humaine | Vérifie que la commande reste souhaitée | Sans preuve externe, la personne peut autoriser un doublon. |
| Vérification du résultat et protection contre les doublons | Recherche l’opération initiale et encadre sa reprise | Dépend des capacités du destinataire ; certains cas restent incertains. |
Commande retrouvée : ne pas la recréer. Résultat inconnu : suspendre le renvoi. Absence confirmée selon la procédure du destinataire : reprendre avec les protections documentées. Une recherche vide ne suffit pas : une première tentative peut encore aboutir.
Avec un outil peu traçable, gardez l’IA au brouillon. Une personne vérifie d’abord la commande auprès du fournisseur, puis décide de l’envoi. Notre guide agent IA ou automatisation aide à préciser quelles étapes nécessitent réellement un agent.
L’idempotence : reconnaître une même opération
L’idempotence permet de répéter une demande sans ajouter un nouvel effet au premier. Une clé stable identifie l’opération : chaque nouvelle tentative la conserve ; une véritable seconde commande reçoit une autre clé.
Le destinataire doit appliquer cette protection. La documentation Stripe en donne un exemple officiel pour ses API, avec des règles de paramètres et de conservation des clés. La garantie ne s’étend pas aux autres portails fournisseurs.
Dans son guide pour les systèmes agentiques, AWS recommande aussi de transmettre la clé aux systèmes externes compatibles et de protéger les tentatives concurrentes. Le statut local « à faire » ne prouve pas qu’aucune commande n’est partie.
Quelle preuve demander après l’incident ?
Préparez une fiche de reprise : référence interne, version approuvée, destinataire, pièces jointes, identifiant de l’opération, statut externe et responsable du contrôle. Datez la preuve et notez la durée documentée de protection contre les doublons, si elle existe.
Une trace d’envoi du mail ne prouve pas l’acceptation de la commande par le fournisseur. Choisissez la preuve correspondant à l’étape : dépôt du message, commande enregistrée ou acceptation commerciale. Si le résultat demeure inconnu, suspendez la relance et faites vérifier le dossier par la personne désignée.
La prépublication scientifique ReliabilityBench, déposée en janvier 2026, évalue deux modèles et deux architectures d’agents dans quatre domaines simulés, avec notamment des pannes d’outils. Elle invite à tester les incidents et l’état final, au-delà d’une réponse réussie. Elle ne mesure pas les doublons dans les PME françaises.
Tester la reprise avant de connecter les vrais envois
Sur un environnement d’essai, faites simuler une confirmation perdue après enregistrement, deux tentatives simultanées et un redémarrage. Exigez la preuve d’une seule commande, ou un statut incertain bloqué. Testez aussi une véritable seconde commande : la protection doit permettre de la distinguer d’une relance.
Méthode proposée par Altoriane. Évaluez avec l’équipe le temps de reprise et la lisibilité des traces : la fiche France Num hébergée par la CNIL recommande de contrôler les sorties et d’examiner la qualité du travail. Le contrôle doit permettre de comprendre ce qui s’est passé.