Votre intégration tourne chaque heure et prie

Quelque part dans votre infrastructure, un cron job tourne toutes les 60 minutes. Son travail est de connecter le Système A au Système B. Il extrait les données de l'un, les transforme et les pousse vers l'autre. Il a été écrit par un développeur parti il y a deux ans. Il tourne sur un serveur que personne n'a redémarré depuis. Il fonctionne. La plupart du temps.

À la minute 0, la synchro tourne. Elle copie votre inventaire du système d'entrepôt vers l'outil commercial. À la minute 12, un appareil est vendu. Le système d'entrepôt le marque comme vendu. L'outil commercial ne le sait pas encore — il ne le saura qu'à la minute 60. À la minute 35, un acheteur voit l'appareil dans l'outil commercial, pense qu'il est disponible et lance une négociation. À la minute 47, il fait une offre sur un appareil vendu depuis 35 minutes.

À la minute 60, la synchro tourne à nouveau. L'appareil disparaît de l'outil commercial. L'offre de l'acheteur référence maintenant un fantôme. Quelqu'un doit téléphoner. L'appel commence par "je suis désolé, cet appareil n'est plus disponible" et se termine avec un acheteur qui se demande pourquoi votre inventaire est toujours faux.

Le trou de 59 minutes

Toute intégration basée sur la synchro a un trou : le temps entre le moment où quelque chose change dans un système et le moment où l'autre système le sait. Pour une synchro horaire, ce trou peut durer 59 minutes. Pour une synchro quotidienne, 23 heures et 59 minutes. Pour l'intégration qui "tourne généralement la nuit mais échoue parfois et personne ne vérifie jusqu'à ce que quelqu'un se plaigne", le trou est existentiel.

Le trou n'est pas un bug. C'est l'architecture. Les jobs de synchro copient un snapshot. Entre les snapshots, le monde change. Des appareils se vendent. Des grades changent. Des commandes partent. Des prix s'ajustent. La synchro ne sait rien de tout cela jusqu'à son prochain passage, quand elle regarde la source et copie l'état actuel. Tout ce qui s'est passé entre la dernière synchro et celle-ci est compressé dans une seule mise à jour. La granularité du changement est perdue. La séquence des événements est perdue. Il ne reste que l'état final.

Un job de synchro n'intègre pas deux systèmes. Il leur donne une mémoire partagée qui se met à jour une fois par heure et espère que l'heure a été calme.

L'erreur que vous ne voyez pas

Quand un job de synchro réussit, personne ne le remarque. Quand il échoue, parfois personne ne le remarque non plus. Le job tourne, rencontre un timeout, logge une erreur dans un fichier que personne ne surveille, et les deux systèmes divergent silencieusement. L'inventaire du Système A dit 47 appareils. Celui du Système B dit 52. La différence : cinq appareils traités pendant l'échec de synchro. Quand quelqu'un s'en aperçoit — généralement parce qu'un acheteur demande un appareil qui existe dans un système mais pas dans l'autre — les données ont assez divergé pour que la réconciliation demande du travail manuel.

La réconciliation manuelle de systèmes divergents fait partie de ces tâches que tout le monde juge horribles et dont personne ne mesure le coût. Elle prend une heure. Ou trois. Ou une journée entière, selon la durée de la panne et le nombre de changements accumulés. Elle est toujours urgente parce que quelqu'un attend les données. Elle est toujours frustrante parce que ce n'est pas du "vrai" travail — c'est du travail créé par une infrastructure qui n'a pas fonctionné.

L'alternative

L'alternative à l'intégration par synchro est l'intégration par événements : quand quelque chose change, le changement est communiqué immédiatement. Un appareil se vend — tous les systèmes connectés le savent en quelques secondes. Un grade change — le listing le reflète instantanément. Une commande est expédiée — le portail client affiche le tracking number avant que l'opérateur d'entrepôt ait reposé le scanner.

Ce n'est pas aspirationnel. C'est ce qui se produit quand vos systèmes partagent une base de données au lieu de copier des données entre bases. Quand l'entrepôt, l'outil commercial, le portail client et le moteur de settlement lisent et écrivent tous dans la même source of truth, il n'y a pas de trou de synchro parce qu'il n'y a rien à synchroniser. Les données sont déjà là. Elles sont toujours à jour. Personne n'a besoin de prier.

Votre intégration tourne toutes les heures. Pendant cette heure, votre entrepôt change. Votre inventaire change. Votre pipeline commercial change. Et votre intégration, fidèlement, ignore tout jusqu'à ce que l'horloge dise qu'il est temps de regarder. Le cron job n'est pas une solution. C'est un mécanisme de compensation pour des systèmes qui auraient dû n'en faire qu'un depuis le début.