Un formulaire reçu, une ligne ajoutée à un tableau, puis une fiche client créée : l’automatisation fonctionne parfaitement en démonstration. Quelques semaines plus tard, le même contact apparaît cinq fois et certains messages partent en double. Le problème n’est pas toujours le connecteur. C’est souvent l’absence de règles de reprise et d’unicité.
Sans code ne signifie pas sans architecture. Dès qu’un flux modifie des données commerciales ou déclenche une communication, il doit être pensé comme un petit système d’information.
En bref : utilisez des identifiants stables, des contrôles d’entrée, des reprises sûres et des journaux d’exécution.
Une exécution peut échouer après avoir déjà agi
Imaginez qu’une API crée bien une commande mais que la réponse réseau n’arrive jamais à l’automatisation. Le flux pense avoir échoué et recommence. Sans contrôle, une seconde commande apparaît. C’est la raison pour laquelle les opérations doivent être conçues pour être idempotentes lorsque c’est possible : une répétition avec la même clé métier ne doit pas reproduire indéfiniment le même effet.
Utilisez un identifiant stable par événement, stockez le résultat déjà obtenu et séparez les étapes de lecture des étapes qui écrivent. Les appels vers des services tiers peuvent être ralentis ou limités ; une stratégie de nouvelle tentative avec attente progressive évite d’aggraver une panne.
Les données entrantes doivent être considérées comme imparfaites
Une adresse e-mail peut être absente, un numéro de téléphone mal formaté, une devise incohérente et une pièce jointe plus volumineuse que prévu. Validez les champs indispensables avant d’enregistrer. En cas d’anomalie, envoyez le dossier dans une file de correction plutôt que de lui inventer une valeur par défaut.
Documentez les transformations : majuscules, formats de date, arrondis, fuseaux horaires et correspondances de statuts. Une mauvaise conversion silencieuse est souvent plus grave qu’une erreur visible, parce qu’elle entre dans les indicateurs sans être repérée.
Menow a déjà abordé le fonctionnement d’une plateforme d’automatisation dans son dossier sur les workflows avancés. La différence ici tient à la fiabilité des données et à la reprise sur erreur.
Pourquoi relancer un scénario peut créer deux commandes
Les outils d’automatisation reprennent parfois une requête après un délai d’attente. Le premier appel a peut-être déjà été traité, mais la confirmation s’est perdue. Si le scénario réessaie sans contrôle, il risque de créer un deuxième dossier, envoyer un nouveau message ou facturer à nouveau. C’est le problème classique de l’idempotence : répéter une opération doit produire le même résultat métier, pas une deuxième opération.
Exemple fictif : pour une commande portant l’identifiant CMD-1042, enregistrez une clé stable associée à l’événement source. Avant la création d’un enregistrement, recherchez cette clé dans la destination. Si elle existe déjà, mettez à jour l’état ou ignorez l’événement, selon la règle métier définie. Évitez de comparer seulement le nom et l’adresse : deux clients peuvent partager ces champs.
Ce qu’il faut journaliser
Conservez l’identifiant de l’événement, l’heure, le résultat HTTP, le nombre d’essais, le statut final et les erreurs de validation. Prévoyez une file d’échec consultable et un mode « simulation » avant de connecter les comptes de production. La sécurité des données compte également : un jeton API ne doit jamais être copié dans les descriptions visibles d’un scénario ou les notifications envoyées à l’équipe.
La maintenance commence le jour du lancement
Chaque flux doit avoir un responsable, un journal d’exécution consultable, une politique de conservation des données et une procédure d’arrêt. Gardez séparés les secrets d’API et les données métier ; un export de workflow ne devrait pas devenir une manière de diffuser des identifiants.
Avant la mise en service, rejouez volontairement des événements identiques, simulez une erreur 429, une erreur 500 et une perte de connexion. Si le système récupère sans créer de doublon, vous avez testé quelque chose de bien plus utile que la simple réussite d’un scénario heureux.
Le test qui révèle un mauvais flux
Envoyez deux fois exactement le même événement de test, puis vérifiez le nombre de fiches créées et de messages envoyés. Reproduisez ensuite une erreur réseau juste après l’écriture dans la base cible. Si la reprise crée de nouveaux objets, le problème d’unicité existe déjà : il ne sera pas corrigé par un simple tableau de bord plus joli.
Documenter la logique pour ne pas devenir dépendant de son propre scénario
Les automatismes commencent souvent par une personne qui comprend tout le parcours. Six mois plus tard, cette personne quitte le projet et personne ne sait pourquoi une branche conditionnelle contourne une étape. Un schéma simple, les champs attendus et le comportement en cas d’échec doivent être documentés au même titre que les identifiants de connexion.
Distinguez les erreurs transitoires des erreurs définitives. Si un service distant renvoie 429, respecter l’indication de délai avant nouvelle tentative évite d’accumuler les demandes. Si une donnée obligatoire est absente, réessayer cinquante fois n’a aucun intérêt : l’événement doit être envoyé dans une file à corriger. Cette séparation réduit le bruit opérationnel.
Enfin, définissez une procédure de rejeu contrôlé. Reprendre une série d’événements sans date de coupure ni identifiant de déduplication peut produire les dommages que l’automatisation était censée éviter.
Je suis Marie Prigent, passionnée du monde numérique, des gadgets high-tech et des dernières tendances en matière de son et de télévision. J’explore les domaines du streaming, de la réalité augmentée, du home-cinéma et des appareils intelligents. En outre, je suis une adepte des podcasts et des médias sociaux, où je partage mes découvertes et conseils.
