Préparé avec l’aide de l’IA et relu pour la clarté, la pertinence et les affirmations non étayées.
Dans n8n, les actions en double peuvent apparaître sans qu’un client ait envoyé deux demandes distinctes. Un outil retransmet un événement, une exécution est relancée après une interruption ou deux traitements démarrent presque simultanément. Si chaque passage crée une tâche, l’équipe reçoit deux travaux pour un seul besoin.
L’objectif n’est donc pas seulement de détecter des messages identiques. Il faut définir quelle action a déjà été effectuée pour quelle demande, puis conserver une preuve exploitable. Cette propriété s’appelle l’idempotence : répéter une opération ne doit pas multiplier son effet métier.
1. Définir ce qui constitue réellement un doublon
Commencez par écrire une règle métier précise. « Un client ne peut avoir qu’une tâche » serait trop restrictif : le même client peut demander deux prestations. « Une demande ne doit créer qu’une tâche de qualification » décrit mieux l’effet à protéger.
Distinguez trois situations :
- Événement répété : la même notification arrive à nouveau.
- Demande modifiée : le client complète une demande existante ; une mise à jour peut être nécessaire.
- Nouvelle demande : le client revient pour un autre besoin ; une nouvelle tâche est légitime.
Un numéro de téléphone ou un texte semblable ne suffit donc pas à décider. Si deux canaux produisent des demandes sans référence commune, mieux vaut signaler une ressemblance pour vérification que fusionner automatiquement sur une supposition.
2. Choisir un identifiant stable pour chaque effet
Privilégiez l’identifiant fourni par la source lorsqu’il reste identique lors des retransmissions. Associez-le au nom de cette source afin de ne pas confondre deux références issues d’outils différents. Vérifiez cette stabilité dans votre configuration : elle ne se déduit pas du simple nom du champ.
Si aucun identifiant fiable n’existe, attribuez une référence au premier enregistrement durable de la demande et faites-la suivre dans les étapes suivantes. Une nouvelle référence créée à chaque exécution ne protège pas des répétitions.
Il faut aussi distinguer les actions. La demande fictive « DEM-184 » peut nécessiter une création de tâche, puis une notification interne. Chacun de ces effets possède son suivi. Marquer toute la demande comme « terminée » après la seule création de tâche empêcherait de reprendre correctement une notification échouée.
Une date de réception arrondie ou une comparaison du texte peut aider à repérer des cas suspects, mais risque soit de laisser passer un doublon, soit de bloquer une demande légitime.
3. Protéger l’écriture, pas seulement la vérifier
Le schéma « chercher la tâche, puis la créer si elle manque » convient comme première lecture du processus. Il présente cependant une faiblesse : deux exécutions peuvent chercher simultanément, ne rien trouver et créer chacune une tâche.
La protection doit donc résister aux accès simultanés. Selon les outils connectés, elle peut reposer sur une contrainte d’unicité dans un registre durable, une réservation atomique de l’action ou un mécanisme d’idempotence proposé par le système destinataire. Ces possibilités sont à vérifier pour chaque intégration ; elles ne sont pas universelles.
Le registre conserve au minimum la référence métier, l’action, son état, la date et la référence du résultat créé. Séparez « en cours », « réalisée » et « à vérifier ». Une réservation abandonnée après une interruption ne doit pas bloquer définitivement la demande.
Point délicat : si la tâche est créée mais que son identifiant n’est pas enregistré, une relance aveugle reste dangereuse. Il faut rechercher le résultat dans l’outil destinataire avant de recréer quoi que ce soit. Sans preuve fiable, l’intervention humaine est plus prudente.
4. Exemple hypothétique : une demande reconnue avant création
Imaginons une PME marocaine de maintenance qui reçoit une demande de devis via un formulaire. Le workflow doit créer une tâche pour le chargé de clientèle.
- Il reçoit la référence fictive « DEM-184 » et contrôle les champs nécessaires.
- Il consulte puis réserve de manière protégée l’action « créer la tâche de qualification ».
- Il crée la tâche avec la référence de demande dans un champ consultable.
- Il enregistre l’identifiant de la tâche et marque cette action comme réalisée.
- Lors d’une retransmission, il retrouve cette preuve et ne crée rien.
La sortie utile est alors : « Demande déjà enregistrée ; tâche existante conservée. » Ce n’est pas une erreur. En revanche, une nouvelle adresse ajoutée à cette même demande suit une règle de mise à jour, sans recréer la tâche.
5. Tester répétitions, concurrence et interruptions
Un test avec une seule demande valide ne démontre pas la protection. Préparez plusieurs essais et vérifiez les objets réellement présents dans l’outil cible, pas seulement la couleur de l’exécution n8n.
- Envoyer deux fois le même événement : une seule tâche doit exister.
- Lancer deux traitements rapprochés : un seul doit obtenir le droit de créer.
- Interrompre après création, avant enregistrement du résultat : la reprise doit vérifier l’existant.
- Envoyer une nouvelle demande du même client : elle ne doit pas être bloquée.
- Compléter une demande existante : la tâche doit suivre la règle de modification prévue.
Le guide pour tester un workflow avec des cas métier représentatifs aide à formaliser ces résultats attendus.
6. Choisir le niveau de protection selon le risque
Un doublon de ligne dans une liste interne et une confirmation envoyée deux fois n’ont pas le même impact. Renforcez en priorité les actions visibles par le client, les engagements et les écritures difficiles à annuler.
Un registre durable ajoute de la maintenance : propriétaire, durée de conservation et traitement des états bloqués. Conservez les références assez longtemps pour couvrir les répétitions plausibles ; supprimer trop tôt les preuves rouvre le risque. Pour les états incertains, définissez aussi une procédure de reprise après échec.
Pour discuter de ces protections dans une automatisation n8n sur mesure, vous pouvez présenter à FlowAgent l’action à sécuriser et les outils concernés.