Synchronisation temps réel ou batch : comment trancher

Temps réel ou batch : la réponse ne dépend ni de la technique ni de la mode, mais d'une seule question posée au métier : quelle décision est prise à partir de cette donnée, et que se passe-t-il si elle a deux heures de retard ? Dans la majorité des synchronisations entre deux logiciels de PME, la réponse honnête est "rien de grave", ce qui signifie qu'un batch bien placé dans la journée fait le travail, pour une fraction du coût d'exploitation d'un flux temps réel.

Le réflexe du métier est presque toujours de demander le temps réel, par habitude ou par prudence. C'est rarement le bon calibrage. Le temps réel n'est pas plus fiable qu'un batch : il est simplement plus rapide, et cette rapidité se paie en surveillance, en gestion des pannes et en propagation instantanée de la moindre erreur.

Cet article détaille la méthode pour trancher ce rythme : la bonne question à poser avant tout choix technique, les quatre rythmes de synchronisation possibles, ce que le temps réel coûte réellement une fois en production, et pourquoi le mode hybride reste la réponse la plus fréquente en PME.

La bonne question à poser avant de choisir un rythme de synchronisation

Avant de parler de webhook, de cron ou d'API, une seule question doit être posée au métier concerné, pour chaque donnée synchronisée : quelle décision est prise à partir de cette information, et que se passe-t-il concrètement si elle a deux heures de retard ?

Cette question est presque toujours esquivée. On demande plutôt "voulez-vous que ce soit synchronisé en temps réel", et la réponse est mécaniquement oui : personne ne va spontanément demander un délai. C'est une mauvaise façon de cadrer le besoin, parce qu'elle confond confort perçu et nécessité réelle.

Reformulée correctement, la question donne des réponses très différentes selon la donnée :

• Le stock affiché sur une fiche produit e-commerce. Un retard de deux heures peut faire vendre un produit déjà épuisé. Le coût du retard est direct et visible du client final.
• Le statut d'un dossier client dans un outil de reporting interne. Un retard de deux heures ne change rien à la décision que prendra le manager qui consulte ce tableau une fois par jour.
• Une adresse de livraison mise à jour dans le CRM. Un retard de deux heures est sans conséquence tant que la commande n'a pas encore été préparée.

Tant que cette réponse n'est pas obtenue par écrit, aucun schéma de synchronisation ne devrait être choisi. C'est ce même principe de clarification préalable qui structure le choix de la source de vérité entre deux logiciels : une décision d'organisation avant une décision technique.

Les quatre rythmes de synchronisation entre deux logiciels

Une fois le besoin réel connu, quatre rythmes distincts existent pour faire circuler une donnée d'un logiciel vers un autre. Ils ne s'excluent pas : la plupart des synchronisations sérieuses en combinent au moins deux, comme on le voit plus loin dans cet article.

Le rythme événementiel demande que le logiciel source propose un webhook, ce qui n'est pas toujours le cas. Quand ce n'est pas possible, l'interrogation fréquente devient le seul substitut réaliste au temps réel, et quand aucune des deux voies n'existe, il faut passer par d'autres solutions détaillées dans notre article sur l'automatisation d'un logiciel métier sans API.

Ce que le temps réel coûte vraiment, au-delà du développement

Le développement d'un flux temps réel n'est souvent pas le poste le plus coûteux du projet. Ce qui coûte, c'est de le faire vivre en production, mois après mois, sans que personne ne s'en aperçoive quand quelque chose se dérègle discrètement.

Cinq coûts reviennent systématiquement une fois qu'un flux événementiel tourne en production :

• La surveillance permanente. Un flux qui doit réagir en quelques secondes doit aussi être surveillé en continu : une panne silencieuse de trente minutes sur un flux temps réel passe souvent inaperçue plus longtemps qu'une panne sur un batch nocturne, précisément parce que personne ne la constate au réveil.
• La gestion des pannes de l'autre côté. Le logiciel qui reçoit les événements peut être indisponible quelques minutes. Sans file d'attente et mécanisme de rejeu, les événements arrivés pendant cette fenêtre sont perdus purement et simplement.
• L'ordre de traitement des événements. Deux modifications successives sur la même fiche, envoyées à quelques secondes d'écart, doivent être traitées dans l'ordre exact où elles se sont produites, faute de quoi la version la plus récente peut être écrasée par la plus ancienne.
• L'idempotence. Un même événement peut être envoyé plusieurs fois (nouvelle tentative après une coupure réseau, par exemple), et le traiter deux fois ne doit jamais créer deux fois la même commande ou décrémenter deux fois le même stock.
• La propagation instantanée d'une erreur. Un batch laisse une fenêtre de contrôle avant l'écriture : une anomalie détectée à 8h peut être corrigée avant le passage de 14h. Un flux temps réel écrit immédiatement, sans cette marge de sécurité, ce qui veut dire qu'une erreur de mapping se propage dans l'autre logiciel avant que quiconque ne l'ait vue.

Ce dernier point mérite d'être pris au sérieux : la vitesse d'un flux temps réel joue autant contre vous que pour vous en cas d'anomalie. Les mécanismes de garde-fou qui limitent ce risque sont détaillés dans notre article sur ce qui se passe quand une automatisation se trompe. Côté synchronisation entre logiciels spécifiquement, notre article sur les conflits et erreurs de synchronisation couvre les mêmes mécanismes.

Quand le temps réel est justifié, et quand le batch est le bon choix

Le temps réel n'est ni supérieur ni inférieur au batch dans l'absolu : il est adapté à certains cas précis, et disproportionné dans la plupart des autres.

Le temps réel a du sens quand le délai crée un risque direct

Quatre situations justifient réellement un flux événementiel, parce que le coût du retard y est concret et immédiat, pas seulement inconfortable :

• Le stock d'un e-commerce sur des références en tension. Vendre un article déjà épuisé génère une annulation, un remboursement et souvent un client mécontent.
• Une disponibilité affichée à un client final. Un créneau de rendez-vous, une chambre d'hôtel, une place limitée : afficher une disponibilité périmée crée une déception immédiate au moment de la réservation.
• Le blocage d'une commande. Un compte client suspendu pour impayé doit empêcher toute nouvelle commande sans délai, pas quelques heures plus tard.
• Un engagement contractuel sur un délai de mise à jour. Certains contrats fournisseurs ou clients imposent explicitement un délai de synchronisation maximal, ce qui rend le choix du rythme non négociable.

Le batch est meilleur, pas seulement moins cher

À l'inverse, trois situations rendent le batch objectivement préférable, indépendamment de son coût plus faible :

• Un contrôle humain doit avoir lieu avant l'écriture. Validation d'une note de frais, vérification d'un rapprochement comptable, relecture d'un document avant envoi : ces étapes exigent une fenêtre, que seul un batch peut offrir sans complexité ajoutée.
• La donnée source est elle-même consolidée en fin de journée. Un système de caisse ou un outil de production qui ne finalise ses chiffres qu'à la clôture n'a rien à transmettre en temps réel, puisque la donnée définitive n'existe pas avant ce moment.
• Le volume rendrait un flux temps réel instable. Des milliers de lignes générées en quelques minutes (import de masse, migration, période de forte activité) saturent un flux événementiel pensé pour des événements unitaires, alors qu'un batch les absorbe sans effort par construction.

Le mode hybride : la réponse la plus fréquente en PME

Dans la pratique, la synchronisation qui revient le plus souvent chez nos clients PME n'est ni entièrement temps réel ni entièrement batch. C'est un mélange assumé : un ou deux champs vraiment critiques passent en flux événementiel léger, et tout le reste suit un batch planifié classique.

Un exemple concret sur une boutique en ligne connectée à un ERP illustre bien ce partage, le même que celui détaillé dans notre article sur comment relier une boutique en ligne à l'ERP pour les stocks et les commandes :

• Le niveau de stock des références à faible disponibilité redescend de l'ERP vers le site en quasi temps réel, parce que c'est la seule donnée dont le retard crée un risque de survente.
• Les nouvelles commandes remontent du site vers l'ERP toutes les quinze minutes, un rythme largement suffisant pour la préparation logistique du jour.
• Les coordonnées clients, l'historique et les statuts secondaires se synchronisent une fois par nuit, sans que cela ne change rien à l'expérience d'achat.

Ce partage évite l'écueil le plus fréquent : traiter tous les champs d'une même intégration sur le même rythme, par simplicité de conception, plutôt que d'aligner chaque champ sur son propre niveau de risque. C'est aussi ce qui distingue une synchronisation pensée d'une synchronisation copiée d'un projet précédent sans être réévaluée.

L'impact du rythme sur la reprise après incident

Le rythme choisi ne change pas seulement la fraîcheur de la donnée au quotidien : il change radicalement ce qui se passe quand la synchronisation tombe en panne, ce qui finit toujours par arriver un jour ou l'autre.

Sur un batch planifié, une panne de trois heures a un effet simple à comprendre et à corriger : les changements survenus pendant cette fenêtre s'accumulent sans être perdus, et le prochain passage planifié les traite tous d'un coup dès que l'incident est résolu. Il suffit de vérifier que le volume rattrapé ne dépasse pas la capacité du traitement suivant, et le système revient à l'état normal sans intervention complexe.

Sur un flux événementiel, une panne de trois heures pose une question plus difficile : le logiciel source a-t-il conservé les événements non délivrés dans une file d'attente rejouable, ou les a-t-il simplement laissés partir ? Sans mécanisme de rejeu prévu à l'avance, ces événements peuvent être définitivement perdus, et la seule solution devient une reprise manuelle en comparant les deux bases ligne par ligne, un travail long et sujet à erreur.

C'est un critère de décision à part entière, souvent oublié au moment du cadrage : un rythme se choisit aussi en fonction de ce qu'il coûte à réparer, pas seulement de ce qu'il apporte quand tout fonctionne. Notre article sur ce qui casse dans une automatisation au bout de deux ans détaille comment ce type de fragilité s'installe progressivement, souvent bien avant le premier incident visible.

C'est précisément ce cadrage que nous menons dans nos projets de connecteur sur mesure entre logiciels : identifier, champ par champ, le rythme réellement nécessaire avant d'écrire la moindre ligne d'intégration, pour ne construire de la complexité temps réel que là où elle a une vraie raison d'être.

Sur le plan technique, la fiabilité d'un flux événementiel s'appuie sur des principes bien documentés par les éditeurs qui les manipulent au quotidien : Stripe, par exemple, détaille dans sa documentation sur les clés d'idempotence pourquoi un même événement de paiement ne doit jamais être traité deux fois, un principe qui s'applique à l'identique à toute synchronisation événementielle entre deux logiciels métier.

Questions fréquentes sur la synchronisation temps réel ou batch

Pour aller plus loin

• Supprimer la double saisie entre deux logiciels métier : comment trancher la source de vérité avant de choisir un schéma de synchronisation.
• Automatiser un logiciel métier qui n'a pas d'API : les solutions quand ni webhook ni interrogation directe ne sont possibles.
• Que se passe-t-il quand une automatisation se trompe ? : les garde-fous à poser pour limiter la propagation d'une erreur, en temps réel comme en batch.
• Ce qui casse dans une automatisation au bout de deux ans : comment la fragilité d'un flux mal calibré s'installe progressivement.
• Connecteur standard ou développement sur mesure : la décision à prendre avant de fixer le rythme de synchronisation.
• Automatiser votre PME avec n8n et l'IA : le guide pilier avec l'ensemble de nos ressources sur l'automatisation.