Un prospect remplit votre formulaire. L’IA résume sa demande, un dossier est créé dans votre logiciel commercial et un accusé de réception part. Quelques minutes plus tard, le même client reçoit un deuxième message et votre équipe découvre deux dossiers identiques.
Ce scénario peut apparaître après une interruption, une relance manuelle ou la réception répétée du même événement. L’IA peut avoir parfaitement compris le message : c’est l’enchaînement des actions qui demande à être fiabilisé.
Pour une TPE ou une PME, éviter les doublons dans une automatisation IA commence par une question simple : comment le système reconnaît-il ce qu’il a déjà fait ? Voici une méthode de contrôle proposée par Dixie Consulting.
Pourquoi une action peut-elle être exécutée deux fois ?
Une application demande au CRM de créer un dossier. Le CRM le crée, mais sa réponse n’arrive pas à temps. L’automatisation constate une erreur et réessaie. Sans protection adaptée, cette nouvelle tentative peut créer un second dossier.
L’absence de confirmation ne prouve donc pas que l’action a échoué. AWS décrit ce problème dans sa documentation sur les nouvelles tentatives et les opérations dites « idempotentes » : des opérations conçues pour pouvoir être répétées sans ajouter un nouvel effet. Source : AWS.
Dans un processus utilisant l’IA, une même demande peut aussi produire deux brouillons légèrement différents. Comparer uniquement les textes générés constitue alors un mauvais moyen de repérer un traitement répété.
1. Distinguer une demande répétée d’une nouvelle demande
Le même client peut demander deux interventions différentes. Bloquer toutes les demandes associées à son adresse e-mail ferait disparaître du travail légitime.
Il faut définir ce qui identifie la demande et l’action concernées : référence du formulaire, identifiant du message source, numéro de commande, puis opération à effectuer. Ce repère doit rester stable lors d’une nouvelle tentative.
| Situation | Traitement attendu |
|---|---|
| La même demande est reçue à nouveau | Retrouver le traitement existant et son état |
| Le même client formule une nouvelle demande | Créer une demande distincte |
| Le client complète un dossier en cours | Rattacher le complément au dossier identifié |
| Un collaborateur valide une nouvelle version du devis | Identifier explicitement cette version et l’action autorisée |
Lorsque le rapprochement reste ambigu, prévoyez une vérification par l’équipe. L’identité d’un client, à elle seule, ne suffit pas à décider qu’un message est un doublon.
2. Suivre chaque action séparément
Un indicateur global « demande traitée » renseigne peu lorsqu’un parcours comprend plusieurs étapes. Le dossier peut avoir été créé alors que la préparation du devis a échoué.
Prenons un exemple fictif : la demande D-1042 doit créer un dossier, préparer un brouillon de devis et envoyer un accusé de réception. Chaque action possède son propre suivi, avec la référence du résultat lorsqu’il existe.
Nous proposons quatre états compréhensibles par l’équipe : à faire, en cours, confirmée, à vérifier. Le dernier couvre notamment les situations où une action a pu aboutir sans que sa confirmation ait été enregistrée.
Cette organisation complète notre exemple de passage de l’e-mail client au brouillon de devis : elle permet de savoir précisément quelle étape reprendre.
3. Préparer la reprise après une interruption
Avant de cliquer sur « relancer », l’équipe doit pouvoir consulter l’historique : quelle étape a échoué, quelles actions sont confirmées et lesquelles restent incertaines ?
Les possibilités dépendent de l’outil. Make documente, par exemple, une reprise des exécutions incomplètes à partir du module ayant provoqué l’erreur, avec la configuration de cette exécution. Cela suppose d’utiliser le mécanisme prévu ; relancer tout le scénario constitue une autre opération. Source : Make.
Définissez donc une procédure simple : qui examine l’échec, comment retrouver le dossier créé et dans quels cas une vérification manuelle est nécessaire. Un statut incertain doit rester visible jusqu’à sa résolution.
4. Vérifier la protection dans les applications de destination
Deux traitements simultanés peuvent tous les deux constater qu’un dossier n’existe pas, puis essayer de le créer. Une recherche préalable ne suffit donc pas toujours : le prestataire doit prévoir un mécanisme qui empêche ces créations concurrentes.
Certaines interfaces logicielles proposent une clé d’idempotence, conservée pour les nouvelles tentatives de la même opération. Stripe documente ce mécanisme, ainsi que ses conditions et ses limites de conservation. Sa présence dans un service ne signifie pas que vos autres applications le proposent. Source : Stripe.
Demandez quelles protections existent réellement dans votre CRM et votre messagerie. Lorsqu’un envoi a peut-être abouti, prévoyez une recherche de confirmation ou un contrôle humain avant de le répéter. La protection doit être vérifiée pour chaque action externe.
5. Comprendre les limites des filtres « anti-doublons »
Des outils proposent déjà des fonctions utiles. Le module Remove Duplicates de n8n peut comparer les éléments d’une même exécution ou les confronter aux valeurs conservées lors d’exécutions précédentes. Son comportement dépend des champs choisis, du périmètre et de l’historique configurés. Source : n8n.
Mais un élément « déjà vu » n’est pas nécessairement un dossier terminé. Dans notre exemple, un filtre placé à l’entrée pourrait mémoriser D-1042, puis une panne empêcher la création du devis. Si la reprise est ensuite bloquée parce que D-1042 est connu, la demande reste inachevée.
Le filtrage des entrées et le suivi des actions doivent fonctionner ensemble. Faites également vérifier ce qui se passe après un redémarrage ou une remise à zéro de l’historique.
Six tests à réaliser avant la mise en service
Utilisez des demandes fictives et des destinataires de test. Vérifiez les résultats dans les applications concernées, en plus du compte rendu de l’automatisation.
| Test | Résultat à vérifier |
|---|---|
| Présenter deux fois la même demande | Un seul dossier et un seul accusé de réception |
| Déclencher deux traitements simultanément | La protection empêche les créations concurrentes |
| Interrompre le parcours après la création du dossier | La reprise retrouve ce dossier et traite les étapes restantes |
| Simuler une confirmation d’envoi perdue | Le doute est traité sans renvoi automatique aveugle |
| Créer deux demandes distinctes pour le même client | Les deux demandes sont conservées |
| Relancer après un redémarrage | Les actions confirmées restent reconnues et les demandes inachevées restent récupérables |
Une consigne à transmettre au prestataire peut résumer votre attente :
Pour chaque demande, montrez-nous comment vous reconnaissez une nouvelle tentative, retrouvez les actions déjà réalisées et reprenez le travail restant. Testons aussi une interruption et deux traitements simultanés.
Partir d’un processus que votre équipe peut suivre
Pour un premier projet, choisissez un parcours limité : une demande, un dossier, un brouillon et une validation clairement attribuée. Ajoutez les étapes lorsque la reprise et le suivi fonctionnent.
Notre guide pour choisir entre automatisation classique et agent IA aide à déterminer le niveau d’autonomie utile.
Vous souhaitez fiabiliser un processus administratif ou commercial ? Dixie Audit IA permet d’examiner les tâches à automatiser et les contrôles à prévoir. Contactez Dixie Consulting pour faire le point sur votre fonctionnement.
