Dans ce carnet
Pour éviter les doublons dans une automatisation, donnez à chaque événement un identifiant stable et vérifiez si l’action attendue a déjà été réalisée. Un filtre sur les données reçues peut aider, mais il ne garantit pas à lui seul qu’un envoi ou une création ne sera effectué qu’une fois.
Le scénario semble simple : un formulaire arrive, une fiche est créée, une confirmation est envoyée. Puis quelqu’un clique deux fois, le service relance sa notification ou une exécution échoue au milieu. Le vrai test commence alors : que se passe-t-il quand la même demande revient ?
Pourquoi une automatisation crée-t-elle des doublons ?
Parce que recevoir un événement et effectuer son action ne constituent pas toujours une seule opération. Un service peut avoir créé la fiche alors que votre outil n’a jamais reçu la réponse de confirmation. Une relance peut alors créer une seconde fiche.
Un autre cas est plus banal : deux lignes identiques arrivent dans le même fichier. Il faut distinguer ce doublon interne au lot d’une demande reçue à nouveau le lendemain. Les deux problèmes ne se traitent pas forcément au même endroit.
Enfin, deux demandes ressemblantes peuvent être légitimes. Une personne peut s’inscrire à deux ateliers avec la même adresse. Supprimer tout ce qui partage un e-mail supprimerait alors une vraie inscription.
« Est-ce la même personne ? » et « Est-ce la même action à effectuer ? » sont deux questions différentes. La seconde doit guider votre protection contre les doublons.
Quel identifiant choisir pour reconnaître une demande ?
Préférez l’identifiant fourni par le système à l’origine de l’événement : numéro de commande, identifiant de soumission ou identifiant de notification. Gardez le même lors d’une relance. Un nouvel identifiant aléatoire à chaque tentative empêche de reconnaître la répétition.
Pour une inscription, une clé comme inscription:FORM-1042 peut convenir si FORM-1042 désigne bien une soumission unique. Si le formulaire ne fournit pas cet identifiant, il faut définir une règle avec le responsable du processus. Associer un e-mail et un atelier peut être pertinent dans certains cas, mais pas si plusieurs inscriptions de cette personne à cet atelier sont autorisées.
| Soumission | Atelier | Décision attendue |
|---|---|---|
| FORM-1042 | SQL | Créer une inscription |
| FORM-1042 | SQL | Reconnaître la répétition |
| FORM-1043 | Excel | Créer une autre inscription |
Dans cet exemple, les trois lignes peuvent concerner la même personne. On attend deux inscriptions, pas une seule et pas trois. Conservez ces trois événements comme test de base : une modification du scénario ne doit pas changer ce résultat.
Que permet le bloc Remove Duplicates dans n8n ?
Il peut retirer des éléments répétés dans l’entrée courante ou comparer des éléments à ceux d’exécutions précédentes. Ces usages sont distincts dans la documentation officielle de n8n.
- Pour nettoyer un lotUtilisez « Remove Items Repeated Within Current Input », puis comparez les champs qui identifient votre événement. Le choix « Selected Fields » permet de ne pas comparer toute la ligne.
- Pour repérer un événement déjà vuÉtudiez « Remove Items Processed in Previous Executions ». Vérifiez le champ comparé ainsi que les réglages d’historique disponibles dans votre version.
- Pour sécuriser l’action finaleContrôlez aussi le système qui crée la fiche ou effectue l’envoi. Avoir vu un événement ne prouve pas que son traitement a réussi.
Voici le piège : le filtre peut mémoriser une demande, puis l’étape suivante échouer. Si vous la bloquez définitivement au prochain passage, elle risque de ne jamais être traitée. Utilisez le filtre comme un outil de tri, pas comme une preuve de livraison.
Si vous découvrez l’outil, faites d’abord le tutoriel pour créer votre première automatisation n8n. Ajoutez ensuite ces tests à un scénario qui fonctionne déjà sur une demande simple.
Comment empêcher deux créations quand une demande revient ?
La protection la plus solide se situe au niveau du service qui réalise l’action : il doit pouvoir reconnaître une opération déjà demandée, ou refuser deux enregistrements portant la même clé. On parle d’idempotence lorsqu’une répétition ne produit pas un nouvel effet indésirable.
Certains services acceptent une clé d’idempotence. Stripe documente ce mécanisme pour ses requêtes : la même clé permet de retrouver le résultat d’une demande précédente selon les règles de son API. Ce comportement n’est pas universel : vérifiez la documentation du service utilisé, notamment la durée de conservation et les contraintes sur les paramètres.
Pour une base de données, une contrainte d’unicité sur l’identifiant de soumission peut empêcher deux créations concurrentes. Une simple séquence « chercher, puis créer si absent » est insuffisante si deux exécutions cherchent en même temps et ne trouvent encore rien.
Réduisez les exécutions simultanées si votre outil le permet, conservez un journal durable et prévoyez une vérification des cas incertains. Cela améliore la maîtrise du scénario sans garantir à lui seul une action exactement unique.
Pour un envoi d’e-mail, une panne entre l’envoi réel et l’enregistrement de sa réussite laisse une incertitude. Avant de renvoyer, cherchez une trace chez le fournisseur. Si elle manque, faites remonter le cas plutôt que d’affirmer qu’il n’est rien parti.
Que faut-il noter pour reprendre après une erreur ?
Conservez l’identifiant de l’événement, l’état du traitement, l’heure de la tentative et la référence renvoyée par le service final. Trois états lisibles peuvent suffire pour commencer : « en cours », « terminé » et « à vérifier ».
Ne marquez « terminé » qu’après confirmation de l’action. Un état « en cours » trop ancien doit déclencher une vérification : sinon une interruption peut laisser la demande bloquée indéfiniment. Gardez les informations nécessaires au diagnostic, sans recopier inutilement toutes les données personnelles.
Séparez également les étapes. Si la fiche existe mais que l’e-mail a échoué, la reprise doit viser l’e-mail. Rejouer aveuglément tout le scénario recréerait peut-être la fiche.
Quels tests faire avant de laisser tourner le scénario ?
Testez les répétitions et les interruptions avec des données fictives et une destination de test. Le parcours sans erreur est nécessaire, mais il ne suffit pas.
- Envoyez deux fois la même soumission : une seule inscription doit exister.
- Envoyez une autre soumission de la même personne : elle doit rester autorisée.
- Faites échouer l’étape finale : la demande doit rester visible et récupérable.
- Relancez après une réussite : aucune seconde création ne doit apparaître.
- Déclenchez deux tentatives proches : vérifiez la protection contre les créations simultanées.
Quand considérer le test comme réussi ?
Vous obtenez les deux inscriptions attendues du jeu fictif. Pour chaque tentative, vous pouvez expliquer ce qui a été créé, ignoré ou placé « à vérifier ». Une erreur reste traçable et sa reprise ne recrée pas les étapes déjà terminées.
Le choix entre Make, Zapier et n8n vient ensuite : quelle que soit la plateforme, l’identifiant, la gestion des reprises et les possibilités du service final restent déterminants.
Trois questions pratiques
Un filtre suffit-il pour garantir zéro doublon ?
Non. Il peut nettoyer des entrées, mais l’action finale, les relances et les exécutions simultanées doivent aussi être prises en compte.
Peut-on utiliser l’e-mail comme identifiant ?
Seulement si votre règle métier interdit réellement plusieurs opérations avec cet e-mail. Un identifiant de soumission évite souvent de confondre personne et demande.
Faut-il tout reconstruire ?
Commencez par ajouter un identifiant stable, un journal des résultats et les cinq tests ci-dessus. Renforcez ensuite l’étape qui produit l’effet réel : création, envoi ou mise à jour.
À propos de ce carnet
Les exemples et jeux de données sont fictifs et conçus pour l’apprentissage. Les sources techniques sont liées dans les sections concernées et ont été consultées le 27 septembre 2026. Publication en ligne le 27 septembre 2026.
.avif){kind=icon}
