Quand on relie deux outils, un ERP et un site marchand, un CMS et un site, ou un logiciel de paie et une administration, la question finit toujours par arriver en réunion : API temps réel vs batch, on fait quoi ? Souvent, quelqu'un répond « temps réel » parce que ça sonne moderne, et la discussion s'arrête là.
Je pose la question autrement, parce que j'ai vu ce choix coûter cher dans les deux sens. Sur ce site, j'utilise les deux, chacun pour une donnée précise. Voici la grille que j'applique, donnée par donnée, et ce que j'écris dans la spécification d'intégration pour que le choix tienne quand quelque chose casse.
01Ce que veulent dire temps réel et batch dans une intégration
Un flux batch regroupe des données et les traite d'un coup, à une heure fixe ou à la main. Le temps réel, dans une intégration, veut presque toujours dire « déclenché par un événement » : une commande est passée, un document est publié, et un message part aussitôt vers l'autre outil.
Andreas Kretz donne un repère simple dans une vidéo sur le traitement par flux et par lots. Un horaire fixe ou un lancement manuel, c'est du batch. Un déclencheur sur un événement, c'est du flux. Il ajoute un point que je trouve utile en réunion : la présence d'une file de messages ne rend pas un traitement temps réel. Si vous la videz toutes les dix minutes, vous faites du batch avec un outil de plus.
Les deux formes existent dans les outils que vous avez déjà. Odoo propose des actions planifiées qui tournent à intervalle fixe, en minutes, heures, jours, semaines ou mois. Sanity envoie des webhooks quand un document est créé, modifié ou supprimé. C'est donc le besoin métier qui tranche, et l'outil suit.
02La première question : quand la donnée doit-elle être juste ?
Je ne demande pas « faut-il du temps réel ? ». Je demande : à quel moment cette donnée doit-elle être juste dans l'autre outil, et que se passe-t-il si elle ne l'est pas ?
Un stock affiché sur un site marchand doit être juste au moment où le client clique sur « acheter ». S'il a une heure de retard, vous vendez ce que vous n'avez plus. Une fiche produit enrichie peut attendre la nuit sans que personne ne s'en aperçoive. Un chiffre d'affaires consolidé pour la direction n'a besoin d'être juste qu'au moment de la réunion.
Parfois, c'est la règle extérieure qui fixe le rythme. Moonworkers, mon entreprise, est une API de paie pour les petites entreprises britanniques. Côté HMRC, l'employeur envoie sa Full Payment Submission le jour de paie ou avant, et la même page met en garde contre un envoi trop précoce : si l'information change, il faut renvoyer une déclaration corrigée. Elle précise aussi que l'envoi peut être découpé en lots. Le rythme est donc fixé par une échéance, avec un risque si l'on envoie trop tard comme trop tôt.
03Ce que coûte chaque option quand quelque chose casse
Sur le papier, les deux marchent. La différence apparaît le jour où l'outil cible est en panne, où une donnée arrive mal formée, ou où le volume double.
Le temps réel : vite, mais il faut savoir encaisser
La documentation de Sanity est honnête sur ce que demande un webhook. La livraison se fait « au moins une fois » : un même message peut arriver deux fois, et chaque requête porte une clé qui permet au destinataire d'ignorer les doublons. En cas d'échec, Sanity réessaie deux fois, à 30 secondes d'intervalle, avec une seule requête à la fois. Si votre traitement est plus lent que le rythme des modifications, la file ne se vide jamais.
Concrètement, le temps réel vous oblige à prévoir trois choses : un récepteur qui répond vite, un moyen d'ignorer un message déjà traité, et une façon de rattraper ce qui a été perdu pendant une panne plus longue que les tentatives.
Le batch : simple, mais une nuit ratée se voit tard
Une tâche planifiée est plus facile à relancer. Si le fichier de la nuit a échoué, on corrige et on le relance le matin. Regrouper a aussi un intérêt de coût : Google explique que chaque connexion HTTP a un coût, et son API Gmail accepte des requêtes par lot pour en ouvrir moins.
Le risque est inverse : un échec silencieux. Si personne n'est prévenu, la donnée est fausse jusqu'au passage suivant, ou pendant des jours. Andreas Kretz signale un autre piège dans sa vidéo : vider une file d'un seul coup toutes les heures crée des pics de charge, là où un flux régulier laisse de la marge.
04Choisir donnée par donnée, en cinq questions
Je ne choisis pas pour toute l'intégration. Je fais une ligne par donnée échangée (stock, catalogue, commande, client, facture, contenu) et je réponds à cinq questions.
- À quel moment la donnée doit-elle être juste dans l'outil cible ? Au clic du client, avant une échéance, avant une réunion ?
- Que coûte un retard d'une heure ? D'une journée ? Si la réponse est « rien de visible », le batch suffit presque toujours.
- Qui est prévenu quand ça échoue, et par quel canal ? Une intégration sans alerte est une intégration qu'on découvre cassée.
- Comment reprend-on après une panne ? Il faut savoir où le traitement s'était arrêté, et pouvoir le relancer sans créer de doublons.
- Quelle est la donnée de référence ? Quand deux outils ne sont pas d'accord, lequel a raison, et dans quelle unité ?
La dernière question vient d'une leçon de projet. Sur un projet, un mélange de centimètres et de millimètres entre deux outils a déformé tout un rendu. Ni le temps réel ni le batch n'y auraient rien changé. Ce qui manquait, c'était une phrase dans la spécification qui disait quelle donnée faisait foi, et dans quelle unité.
Ce que j'écris dans la spécification
Pour chaque ligne, j'ajoute au document d'intégration : le sens du flux, le déclencheur (événement ou horaire, avec le fuseau), le délai acceptable, la règle de reprise, la personne alertée et la source de vérité. Sur une intégration entre un ERP et un site marchand, la spécification a bougé presque à chaque réunion. Je l'ai fait évoluer version après version, pour que tout le monde parle du même document. J'en détaille la méthode dans l'article sur la spécification d'intégration ERP et site marchand, et un cas pratique dans la connexion entre Odoo et PrestaShop.
05Ce que je fais sur ce site, et ce que j'en retiens
Ce blog tourne sur Next.js et Sanity, et je l'ai construit moi-même (j'en parle dans l'article sur le CMS headless Sanity). Il utilise les deux modes, pour deux besoins différents.
Quand ma machine de contenu publie un article dans Sanity, elle appelle aussitôt une route de revalidation du site, protégée par un secret, puis charge la page une fois. C'est un déclenchement par événement : un article publié doit être visible tout de suite, sinon je relis une version périmée.
À l'inverse, un rapport mensuel qui part seul à date fixe n'a aucune raison d'être en temps réel. C'est un traitement planifié, du même type que les tâches cron de Vercel, qui déclenchent une adresse du site par une requête HTTP à l'heure prévue, toujours en UTC. J'en décris un exemple dans l'article sur le reporting SEO automatique.
Ce que j'en retiens tient en une leçon apprise ailleurs : un site peut sembler normal à l'équipe connectée et être cassé pour les visiteurs, à cause du cache. Une synchronisation des données « en temps réel » qui écrit bien dans la base mais ne rafraîchit pas ce que voit le visiteur n'est pas en temps réel pour lui. Je vérifie donc toujours comme un visiteur, sans session.
06Les limites de cette grille
Cette grille aide à décider, elle ne remplace pas un architecte quand les volumes sont très élevés ou quand plusieurs systèmes écrivent la même donnée. Dans ces cas, la question n'est plus temps réel ou batch, mais qui a le droit d'écrire quoi, et je préfère le dire tôt.
Elle ne règle pas non plus le choix d'outil. Entre un connecteur sans code et un développement sur mesure, les critères sont autres (j'en parle dans l'article Zapier ou Make). Et je ne fais pas de refonte d'ERP : quand le problème vient de l'ERP lui-même, ce n'est pas une intégration qui le corrigera.
Enfin, mélanger les deux modes a un coût. Andreas Kretz montre que les architectures combinent souvent flux et batch, avec un stockage intermédiaire entre les deux. C'est souvent la bonne réponse, mais c'est un composant de plus à surveiller.
07Par où commencer lundi
Prenez votre intégration, ou celle qui est en projet, et faites le tableau : une ligne par donnée échangée, les cinq questions en colonnes. Vous verrez vite que deux ou trois données seulement ont vraiment besoin d'un déclenchement immédiat, et que le reste peut passer par un flux batch surveillé.
Ensuite, écrivez pour chaque ligne qui est prévenu en cas d'échec. Si la case reste vide, c'est par là qu'il faut commencer, avant de discuter de technologie.
Si vous voulez un regard extérieur sur ce tableau, c'est le genre de diagnostic court que je fais dans mes missions de direction technique, et vous pouvez voir des exemples de projets dans le portfolio. On peut en parler.