Six règles pour une synchronisation qui tourne quand personne ne regarde

Le 8 octobre 2026, Lance Martin et CJ Avilla ont publié la présentation d’un agent qui lit Slack et GitHub chaque matin et publie un résumé dans Slack. Personne ne le regarde tourner. Leur paragraphe le plus utile porte sur un échec qui ressemble à un succès. Quand le serveur d’une source est en panne ou que son token a expiré, « l’agent ne voit rien de cette source et signale “rien de nouveau” ».

Une synchronisation de contacts de Shopify vers Brevo connaît le même échec. Comme toute synchronisation planifiée entre deux outils SaaS. Une lecture qui échoue en silence ressemble exactement à une boutique où personne ne s’est inscrit aujourd’hui.

Leur article se termine par six règles pour un agent qui tourne sans surveillance. Lisez-les en tant que personne qui fait tourner des synchronisations, et chacune devient une règle de reverse ETL. Le worker est mort. La synchronisation, non. suit un contact à travers une panne. Cette page est la liste de contrôle au-dessus : six règles pour une synchronisation de données automatisée, ce que le runner de Tajo fait aujourd’hui pour chacune, et là où il ne suffit pas. Le côté du runner est décrit dans Rétablir une synchronisation bloquée ou en échec.

1. Lire à partir d’un marque-page, et ne le déplacer qu’une fois le lot arrivé

Leur première règle : « Lisez chaque source à partir d’un marque-page, pas d’une fenêtre de temps fixe. » Une fenêtre des « dernières 24 heures » laisse un trou quand une exécution démarre en retard et répète des enregistrements quand elle démarre en avance.

Une synchronisation Tajo lit sa source par lots à partir d’un curseur enregistré. Le curseur avance à la fin d’un lot, et seulement quand chaque enregistrement de ce lot est arrivé. Une exécution qui échoue garde la dernière position propre, si bien que l’exécution suivante relit le lot interrompu au lieu de le sauter.

Les commandes ont leur propre marque-page. Une synchronisation planifiée des commandes Shopify commence à sa première exécution planifiée et envoie ce qui a changé depuis la précédente. Les commandes passées ne partent que lorsqu’une personne lance la synchronisation. Les exécutions planifiées et celles lancées par une personne ont des curseurs séparés, si bien qu’un rattrapage de l’historique ou un lot de test ne peut pas faire reculer le curseur planifié.

Le prix, c’est qu’un lot interrompu est lu deux fois. La règle 2 rend cela sans danger.

2. Donner à chaque écriture une clé qui survit à la panne

Leur quatrième règle ne compte un message comme envoyé « que lorsque Slack le confirme », et ne met à jour qu’à ce moment le marque-page et le registre. Une lettre recommandée fonctionne ainsi. Elle est livrée quand l’accusé de réception signé revient, pas quand elle quitte le guichet.

Avant que Tajo n’écrive un enregistrement, celui-ci reçoit une clé de livraison. La clé est un hachage de la synchronisation, de la source, du curseur de page, de la position sur la page et de l’enregistrement lui-même, elle ne contient donc aucune donnée personnelle. Elle est réservée avant l’appel à la destination et marquée comme terminée quand l’écriture réussit. Les clés terminées sont conservées sept jours. Une nouvelle tentative, ou une exécution planifiée ultérieure, recalcule la même clé pour le même enregistrement, la trouve terminée et n’appelle pas la destination une seconde fois.

Cela a deux prix. Au bout de sept jours, le registre oublie, et une relecture depuis un curseur plus ancien peut écrire de nouveau. Et une écriture qui expire laisse un doute légitime : l’autre système l’a peut-être enregistrée sans répondre. Tajo retente cette écriture lors d’une tentative ultérieure plutôt que de l’inscrire comme échouée pour sept jours. Un connecteur qui transmet à la destination sa propre clé d’idempotence lève ce doute. Celui qui ne le peut pas garde le risque d’un doublon.

3. Une seule exécution possède la synchronisation, et le prouve avant chaque écriture

Leur troisième règle : « Revérifiez chaque élément juste avant de publier. » Pour une synchronisation, ce qui a le plus de chances d’avoir changé entre la lecture et l’écriture, c’est qui a le droit d’écrire.

Chaque synchronisation Tajo a un bail, avec son propre token et une durée de vie de 15 minutes renouvelée toutes les cinq minutes. Une exécution vérifie qu’elle détient toujours le bail avant d’appeler la destination, puis de nouveau avant de déplacer le curseur. Une exécution qui l’a perdu s’arrête, et sa page indique « L’exécution a perdu son créneau en cours de route et s’est arrêtée pour ne pas écrire deux fois. » Une seconde exécution qui entre en collision avec une exécution en cours se termine au lieu d’attendre derrière elle.

Les enregistrements sont vérifiés eux aussi. Entre la lecture et l’écriture, les enregistrements passent par le filtre de consentement. Un contact écrit dans une audience marketing sans consentement prouvable est refusé plutôt que deviné. Selon les mots de la page d’aide, le mode d’échec est « trop prudent », jamais « trop envoyé ».

4. Relancer ce qui passe, arrêter ce qui dure

Leurs six règles ne disent rien de la fréquence des nouvelles tentatives. Une synchronisation a besoin de cette règle, car ses échecs les plus courants sont une limite de débit et une mauvaise minute chez un fournisseur.

Une exécution Tajo en file d’attente qui échoue a droit à cinq tentatives. Les attentes entre elles sont de 60, 120, 240 et 480 secondes, environ quinze minutes au total. Certains échecs ne sont jamais relancés, parce qu’une nouvelle tentative ne peut pas les corriger. Une exécution entrée en collision avec une exécution déjà en cours n’est pas relancée, pas plus qu’une exécution dont la version publiée ou les connexions ne sont plus valides.

Une série n’est pas un accroc. Si les cinq dernières exécutions terminées depuis la dernière modification de la synchronisation ont toutes échoué, Tajo met la synchronisation en pause et affiche la dernière erreur sur sa page. Un seul succès remet le compteur à zéro. Rien ne relance d’elle-même une synchronisation en pause ; une personne corrige la cause et la publie de nouveau. L’article sur le worker mort raconte l’incident qui a produit cette règle.

5. Traiter le silence comme un constat

« Signalez une lecture échouée comme illisible, jamais comme une journée calme. » C’est la plus difficile des six, et celle que nous ne respectons qu’en partie.

Là où elle tient : une lecture en erreur fait échouer l’exécution. Un token refusé ou un serveur qui ne répond pas n’envoie rien à la destination, laisse le curseur là où il était et compte pour la pause après cinq exécutions échouées. Et toutes les heures, à la 13e minute, Tajo vérifie chaque espace de travail qui a une synchronisation active. Il alerte sa propre équipe quand il n’y a eu aucune exécution réussie au cours des dernières 24 heures, y compris pour un espace de travail où aucune exécution n’a été enregistrée. C’est la vérification horaire.

Là où elle ne tient pas : la lecture silencieuse que décrivent les auteurs est une lecture qui répond « OK » sans aucun enregistrement. Notre runner compte cela comme un succès. Pour des sources comme les clients Shopify, une vérification séparée prévient l’équipe de Tajo après dix exécutions réussies d’affilée avec zéro enregistrement, si la synchronisation avait produit des enregistrements auparavant. Les commandes Shopify sont lues par date de mise à jour, une exécution vide y est donc normale et cette vérification ne s’exécute pas. Une source qui renvoie quelques enregistrements, mais moins qu’elle ne devrait, n’est pas détectée du tout.

L’objection est la suivante : « Dix exécutions vides, cela fait deux heures et demie avec un rythme de 15 minutes. Pourquoi ne pas alerter dès la première ? » Les synchronisations de contacts tournent bien toutes les 15 minutes par défaut. Et une boutique sans nouveau client pendant un quart d’heure, c’est ordinaire. Une alerte à la première exécution vide se déclencherait chaque nuit, et une alerte qui se déclenche toujours, personne ne la lit. Ce seuil échange la vitesse contre la crédibilité. Il reste une supposition sur le silence, pas la règle des auteurs.

6. Décider une fois ce que la synchronisation peut écrire, et faire prouver chaque exécution

Leur cinquième règle tient les préférences de l’agent « dans un stockage que l’agent ne peut pas modifier ». Leur sixième donne à l’agent un accès en lecture seule partout où il ne fait que lire, et plafonne ce que chaque exécution peut dépenser. Les deux existent parce que l’agent lit du texte écrit par d’autres, et ce texte peut essayer de lui donner des ordres.

La version synchronisation du fichier de préférences, c’est la règle publiée. Publier une synchronisation Tajo la lie à une empreinte de la règle exacte qui a été prévisualisée. La modifier la renvoie en brouillon, et elle repasse par l’aperçu avant de tourner à nouveau. Chaque exécution vérifie, avant de changer quoi que ce soit, qu’elle exécute bien cette version publiée avec les connexions avec lesquelles elle a été publiée. Une exécution qui échoue à cette vérification n’est pas relancée. Le sens est fixé lui aussi : une règle de synchronisation écrit dans un seul sens et jamais en retour dans Shopify.

Le plafond de dépense n’a pas d’équivalent. Nos exécutions de synchronisation n’ont aucune limite de dépense par exécution. La limite de nouvelles tentatives et la pause bornent la durée d’un échec, pas le coût d’une exécution.

Ce qui est construit, et ce qui ne l’est pas

Construit, à l’heure où nous écrivons :

• Un curseur qui n’avance qu’après un lot dont chaque enregistrement est arrivé, et un curseur de commandes planifié que les exécutions lancées par une personne ne peuvent pas faire reculer.
• Une clé de livraison par enregistrement, vérifiée dans un registre des écritures terminées conservé sept jours.
• Un bail par synchronisation, vérifié avant l’écriture et avant que le curseur n’avance.
• Cinq tentatives par exécution, avec une attente de 60 secondes puis de 120, 240 et 480, sans nouvelle tentative pour une collision ou une publication invalide.
• Une pause après cinq échecs d’affilée, affichée sur la page de la synchronisation.
• Une alerte horaire quand aucune exécution n’a réussi au cours des dernières 24 heures.
• Un filtre de consentement à l’exécution pour les contacts écrits dans une audience marketing, et une vérification à chaque exécution qu’il s’agit de la version publiée.

Pas construit, et bon à savoir avant de vous y fier :

• Une lecture qui réussit avec zéro enregistrement n’est pas signalée comme illisible. L’avertissement après dix exécutions en couvre une partie. Il ne couvre ni les commandes Shopify ni une source qui renvoie trop peu d’enregistrements.
• L’alerte des 24 heures arrive chez Tajo, pas chez vous, tout comme l’avertissement après dix exécutions. La pause, elle, s’affiche sur la page de la synchronisation.
• La vérification horaire surveille l’espace de travail, pas chaque synchronisation. Une synchronisation en bonne santé en cache une silencieuse juste à côté.
• Aucun plafond de dépense par exécution.
• Rien ne relance une synchronisation en pause. Une personne le fait.
• La pause après cinq échecs et la vérification des 24 heures sont réglées pour tout le déploiement de Tajo, pas par synchronisation.

Quand l’un de ces points apparaît sur votre propre synchronisation, Rétablir une synchronisation bloquée ou en échec dit ce que vous voyez et ce qu’il faut faire.

Les auteurs ont écrit six règles pour un résumé qu’une personne lit chaque matin. Une synchronisation n’a aucun lecteur le matin, et c’est pour cela qu’elle en a encore plus besoin. Les règles un à quatre et la règle six sont du code dans notre runner aujourd’hui. La règle cinq est à moitié écrite : une synchronisation qui ne peut pas lire sa source devrait le dire.