Une synchronisation entre deux outils est fiable quand elle repose sur quatre mécanismes : l’idempotence, pour qu’un message reçu deux fois ne crée pas deux commandes ; la reprise automatique des erreurs temporaires, avec des délais croissants ; la mise à l’écart des erreurs définitives dans une file que quelqu’un traite ; et la supervision, avec des alertes compréhensibles par les métiers. Sans ces mécanismes, une intégration fonctionne en démonstration puis produit, en production, des doublons, des trous et des erreurs silencieuses.
Cet article explique chacun de ces mécanismes sans jargon, pour qu’un dirigeant ou un responsable métier sache quoi exiger d’une intégration, qu’elle soit développée sur mesure ou construite avec une plateforme du marché.
Pourquoi les synchronisations échouent-elles ?
Une synchronisation relie deux systèmes par un réseau, et chacun peut défaillir à tout moment. Les pannes ne sont pas des exceptions : ce sont des conditions normales de fonctionnement, que la documentation de Microsoft qualifie de « transitoires » quand elles se corrigent d’elles-mêmes, comme une coupure réseau momentanée ou un service saturé.
| Situation | Ce qui se passe | Conséquence sans protection | Parade |
|---|---|---|---|
| Coupure réseau, service indisponible | L’envoi échoue | Donnée jamais transmise | Nouvelles tentatives automatiques |
| Réponse perdue après un traitement réussi | L’émetteur croit à un échec et renvoie | Doublon (commande, facture) | Idempotence |
| Messages livrés dans le désordre | La modification arrive avant la création | Erreur ou donnée écrasée par une version ancienne | Numéro de version, état complet dans le message |
| Donnée refusée (format, règle métier) | L’outil cible rejette | Message bloqué ou rejoué à l’infini | File d’erreurs à traiter |
| Webhook jamais reçu | L’émetteur abandonne après ses tentatives | Trou silencieux | Réconciliation périodique |
| Changement de version d’une API | Un champ disparaît ou change | Erreurs en série, souvent un lundi matin | Tests, alertes, contrats d’interface |
Nous présentons les différentes façons de connecter des outils dans notre article sur les API, webhooks et iPaaS. Ici, la question est différente : une fois la connexion choisie, comment la rendre robuste ?
L’idempotence : le mécanisme qui évite les doublons
Une opération est idempotente quand l’exécuter plusieurs fois produit le même résultat que l’exécuter une seule fois. « Mettre le statut de la commande 4521 à expédiée » est idempotent : le répéter ne change rien. « Ajouter 10 unités au stock » ne l’est pas : chaque répétition ajoute 10 unités.
Pourquoi est-ce essentiel ? Parce que la plupart des systèmes de messages garantissent une livraison « au moins une fois », jamais « exactement une fois ». Le modèle du consommateur idempotent décrit par Microsoft le dit clairement : il est impraticable de garantir une livraison unique dans un système distribué ; la solution durable consiste à rendre le récepteur capable d’ignorer les doublons.
Concrètement, trois techniques se combinent :
- Un identifiant unique par opération, transmis avec chaque message et conservé par le récepteur. Si l’identifiant a déjà été traité, le message est ignoré.
- Des écritures par clé métier (« crée ou mets à jour le client dont le SIREN est X ») plutôt que des créations aveugles.
- Des messages qui portent un état complet (« le stock est de 140 ») plutôt qu’une variation (« +10 »), quand c’est possible.
Un détail fait souvent la différence : l’enregistrement de l’identifiant et la modification des données doivent se faire dans la même transaction. Sinon, une panne entre les deux étapes recrée le doublon que l’on voulait éviter.
Reprise sur erreur : réessayer, mais pas n’importe comment
Toutes les erreurs ne se valent pas. La première décision consiste à les classer :
- Erreur temporaire : délai dépassé, service indisponible, limite de débit atteinte. Réessayer a de bonnes chances de réussir.
- Erreur définitive : donnée invalide, client inconnu, droits insuffisants. Réessayer ne servira à rien tant qu’une personne n’a pas corrigé la cause.
Des délais croissants, avec un peu d’aléa
Pour les erreurs temporaires, la bonne pratique est d’augmenter le délai entre chaque tentative (quelques secondes, puis quelques dizaines, puis quelques minutes), jusqu’à un nombre maximal. Les ingénieurs d’Amazon recommandent dans leur Builders’ Library d’ajouter une part d’aléa à ces délais, pour que des centaines de messages en échec ne reviennent pas tous à la même seconde et ne saturent pas à nouveau le service. Ils rappellent aussi que des nouvelles tentatives empilées à plusieurs niveaux peuvent multiplier la charge jusqu’à 243 fois dans leur exemple, et aggraver la panne au lieu de la résorber.
Le disjoncteur
Quand un service est durablement indisponible, continuer à l’appeler gaspille des ressources. Le modèle du « disjoncteur » suspend les appels pendant un temps, puis teste prudemment si le service est revenu. Les messages s’accumulent pendant ce temps dans une file d’attente, et partent quand le service répond à nouveau.
La file des messages en erreur
Les erreurs définitives, et les erreurs temporaires qui ont épuisé leurs tentatives, vont dans une file dédiée, souvent appelée « file de lettres mortes ». Chaque message y est conservé avec sa cause d’échec. Une personne habilitée peut corriger la donnée dans l’outil source, puis rejouer le message d’un clic. C’est ce qui transforme une erreur silencieuse en tâche visible et traitable.
Webhooks : les règles du récepteur
Les webhooks ont un fonctionnement particulier : c’est l’émetteur qui décide quand envoyer et combien de fois réessayer. La documentation de Stripe, une référence en la matière, résume bien les règles valables pour la plupart des plateformes :
- Accuser réception immédiatement, avant tout traitement long, puis traiter le message en arrière-plan dans une file. Sinon l’émetteur considère l’envoi comme échoué et le renvoie.
- Vérifier la signature de chaque message, pour s’assurer qu’il vient bien de l’émetteur attendu et n’a pas été modifié, et rejeter les messages trop anciens pour se protéger du rejeu.
- Gérer les doublons en conservant les identifiants des événements déjà traités.
- Ne pas dépendre de l’ordre d’arrivée : Stripe précise ne pas garantir que les événements arrivent dans l’ordre où ils ont été produits.
- Prévoir l’absence de message : en production, Stripe réessaie pendant trois jours au maximum. Au-delà, l’événement n’arrivera plus.
L’initiative Standard Webhooks, portée par plusieurs éditeurs, propose des conventions communes pour l’envoi et la signature des webhooks. Si vous exposez vous-même des webhooks à vos clients ou partenaires, par exemple depuis un SaaS, s’en inspirer évite de réinventer ces règles.
La réconciliation : le filet de sécurité
Même avec tous ces mécanismes, une donnée peut manquer : un webhook abandonné, une modification faite pendant une maintenance, un import manuel. La réconciliation est un traitement périodique qui compare les deux outils sur un périmètre donné (les commandes du jour, les clients modifiés de la semaine) et corrige ou signale les écarts.
C’est le mécanisme le plus souvent oublié, et celui qui donne confiance aux équipes métier. Une synchronisation en temps réel par webhooks, doublée d’une réconciliation nocturne, est une combinaison robuste et courante, par exemple entre une boutique Shopify et un ERP, ou entre HubSpot et un outil de facturation.
Superviser : des alertes que les métiers comprennent
Un journal technique que personne ne lit ne protège de rien. Une supervision utile se construit à deux niveaux :
| Niveau | Ce qu’on mesure | Exemple d’alerte |
|---|---|---|
| Technique | Taux d’erreur, temps de réponse, taille de la file d’attente | « Le service de l’ERP ne répond plus depuis 10 minutes » |
| Métier | Volumes attendus, retards, écarts de réconciliation | « Aucune commande transmise à l’entrepôt depuis 14 h » |
| Qualité | Messages en erreur définitive, par cause | « 8 clients refusés : SIREN manquant » |
Chaque échange devrait aussi laisser une trace consultable : quel message, quand, quel résultat, combien de tentatives. Cette traçabilité sert au diagnostic comme aux audits ; nous y consacrons un article sur la journalisation et la traçabilité.
La checklist à exiger de toute intégration
Avant de mettre en production une synchronisation, développée en interne, par un prestataire ou sur une plateforme d’intégration, vérifiez ces points :
- Chaque message porte-t-il un identifiant unique, et le récepteur ignore-t-il les doublons ?
- Les erreurs temporaires sont-elles réessayées automatiquement, avec des délais croissants et une limite ?
- Les erreurs définitives sont-elles isolées dans une file consultable, avec leur cause, et peut-on les rejouer ?
- Les webhooks reçus sont-ils authentifiés par signature, et traités en arrière-plan ?
- Une réconciliation périodique compare-t-elle les deux outils ?
- Des alertes métier préviennent-elles la bonne personne, avec un message compréhensible ?
- Chaque échange est-il journalisé et consultable pendant une durée définie ?
- Que se passe-t-il quand l’API d’un éditeur change de version ? Qui est prévenu, et comment teste-t-on ?
Ces exigences s’appliquent à tous les flux, d’une synchronisation CRM et ERP à un échange EDI avec la grande distribution. Ce sont elles que nous intégrons par défaut dans nos projets d’intégration et d’API.
Vos synchronisations produisent des doublons, des trous ou des erreurs que personne ne voit avant le client ? Décrivez vos flux dans notre diagnostic de projet : nous identifions avec vous les mécanismes qui manquent et l’ordre dans lequel les mettre en place.
