Un backfill peut compléter des données manquantes dans un système connecté, mais il peut aussi répéter des actions qui ne se limitent pas à l’enregistrement de données. Avant de le lancer, définissez ce qui sera retraité, quel système fait référence et quels effets secondaires risquent de se produire. L’objectif n’est pas simplement d’envoyer des données anciennes : il s’agit de corriger un écart vérifiable sans perturber les opérations en cours.
Backfill, migration et nouvelle tentative : trois opérations différentes
Un backfill consiste à retraiter un ensemble délimité de données historiques pour compléter ou corriger des informations dans un système connecté. Il peut, par exemple, envoyer des enregistrements antérieurs à la date d’activation d’une intégration ou renseigner un champ qui n’était pas transmis auparavant.
Une migration, en revanche, transfère des données d’un système vers un autre, ou en modifie la structure, le modèle ou la destination. Elle peut inclure un backfill, mais implique généralement d’autres décisions concernant les transformations, la correspondance des champs et la coexistence des systèmes. Une nouvelle tentative de traitement d’événements en échec relance des opérations précises qui n’ont pas abouti, généralement repérées par une erreur ou une file d’attente en attente. Cela ne revient pas à parcourir tout l’historique.
Cette distinction aide à choisir la bonne solution. Si des enregistrements manquent parce qu’ils n’ont jamais été envoyés, un backfill peut être nécessaire. Si le système destinataire possède les données et que seule leur structure doit changer, il s’agit d’une migration. Si certains événements présentent des erreurs connues, il est préférable de les corriger puis de les relancer plutôt que de renvoyer tous les enregistrements historiques.
Déterminer si le retraitement est la bonne option
Avant de concevoir le processus, décrivez le problème sous la forme d’un écart observable : quelle donnée manque, où devrait-elle se trouver et depuis quand ? Si la source contient la valeur correcte, mais pas la destination, un backfill peut convenir. Si la valeur est erronée à la source, l’envoyer telle quelle ne fera que reproduire le problème ; il faut d’abord la corriger à cet endroit ou définir une transformation explicite.
Une synchronisation de l’état actuel peut également suffire. Si la destination doit uniquement connaître l’état en vigueur et n’a pas besoin de conserver chaque changement historique, l’envoi de tous les états intermédiaires ajoute de la complexité sans apporter nécessairement de valeur. En revanche, s’il faut disposer d’événements à des fins d’audit, de traçabilité ou de calcul, il peut être important de conserver l’ordre et le détail de l’historique.
- Un backfill est indiqué lorsque des enregistrements éligibles et vérifiables ne sont pas arrivés à destination, ou lorsqu’une règle d’intégration a laissé des champs incomplets.
- Une correction de la source est indiquée lorsque la donnée de référence est incorrecte ou incomplète avant son transfert.
- Une nouvelle tentative est indiquée lorsque le problème concerne des opérations en échec identifiables et que le mécanisme permet de les reprendre.
- Une synchronisation de l’état actuel est indiquée lorsque la destination n’a pas besoin de reproduire l’historique des changements.
Évaluez également les conséquences opérationnelles. Un enregistrement peut déclencher une notification, une mise à jour visible par un utilisateur, l’attribution d’une tâche ou une opération financière. Si vous ne pouvez pas déterminer quelles actions seront déclenchées, ne commencez pas par traiter l’historique complet.
Délimiter les enregistrements et définir la référence
Définissez le jeu de données à l’aide de règles qu’une autre personne peut appliquer à nouveau. Précisez les dates et le fuseau horaire, les états inclus, les types d’enregistrements, les exclusions et les critères d’éligibilité. Indiquez si la limite temporelle repose sur la date de création, de mise à jour ou de survenue de l’événement : ces dates ne sont pas forcément équivalentes.
Identifiez également la clé qui relie chaque enregistrement entre les systèmes. Une clé stable permet de savoir si la destination contient déjà l’objet et de décider s’il faut le créer, le mettre à jour, l’ignorer ou l’examiner. Ne supposez pas que deux enregistrements sont identiques simplement parce qu’ils partagent un nom ou une adresse ; utilisez les identifiants définis par l’intégration et vérifiez le traitement des valeurs absentes ou répétées.
Désignez un système de référence pour chaque champ. La source peut faire autorité pour l’adresse e-mail, tandis que la destination contrôle un autre attribut. Sans cette décision, un backfill risque d’écraser des modifications légitimes effectuées dans le système récepteur. Documentez les champs qui seront écrits, ceux qui seront préservés et la marche à suivre en cas de conflit.
Choisir le mécanisme et protéger les effets secondaires
Un chargement par lots peut convenir lorsqu’il s’agit de transférer un ensemble connu et que le système récepteur accepte les importations contrôlées. Une API permet de traiter les enregistrements avec des validations et des réponses pour chaque élément, mais exige de gérer les limites, les échecs et la reprise. La relecture d’événements est utile si l’historique des changements compte et s’il existe un moyen sûr de repérer les événements déjà traités. Aucune option n’est automatiquement préférable : le choix dépend des garanties offertes en matière d’ordre, de doublons, d’erreurs et de visibilité sur le processus.
Avant l’envoi, vérifiez si l’opération est idempotente : la répétition d’une même requête avec la même clé devrait empêcher la création d’un second effet indésirable. Dans le cas contraire, définissez comment détecter les doublons et reprendre après une interruption sans repartir de zéro. Utilisez des identifiants d’opération ou des marqueurs de progression lorsque le système le permet, et conservez une trace des tentatives et des réponses obtenues.
Dans la mesure du possible, séparez l’écriture des données des effets qui lui sont associés. Par exemple, un mode d’importation sans notifications ou une règle temporaire de suppression peut réduire les risques, à condition que cette option soit disponible et approuvée. En présence de paiements, de communications ou de changements d’état irréversibles, mettez en place des contrôles explicites avant le traitement. Ne partez pas du principe qu’une mise à jour historique sera considérée comme une mise à jour ordinaire.
L’ordre peut également modifier le résultat. Si des enregistrements sont liés ou font l’objet de changements successifs, déterminez s’il faut traiter d’abord les éléments principaux, puis leurs dépendances, ou respecter l’ordre chronologique de chaque changement. Si seul l’état final importe, consignez cette règle et évitez de rejouer des transitions susceptibles de déclencher des actions.
Tester, procéder par étapes et savoir s’arrêter
Effectuez un essai sur un échantillon représentatif comprenant différents états, différentes dates, des cas incomplets et des situations susceptibles de comporter des doublons. Comparez le résultat attendu au comportement réel de la destination, y compris les effets secondaires. Un échantillon composé uniquement d’enregistrements simples peut masquer les cas les plus risqués.
Convenez des indicateurs à suivre avant de commencer : nombre d’enregistrements sélectionnés, traités, créés, mis à jour, ignorés et en échec. Définissez aussi la manière de mesurer l’écart entre la source et la destination. Les chiffres doivent concerner le même ensemble et appliquer les mêmes critères d’éligibilité ; comparer les totaux généraux peut faire confondre les enregistrements exclus avec des pertes.
Procédez par étapes : commencez par un petit échantillon, poursuivez avec une tranche limitée et ne traitez le reste que si les résultats sont acceptables. Désignez une personne chargée de surveiller le processus et établissez des critères d’arrêt, tels qu’un taux d’erreur supérieur au seuil convenu, des doublons inattendus, une hausse des effets secondaires ou des écarts qui s’accentuent. L’arrêt doit être une décision prévue, et non une improvisation.
Pour reprendre le traitement, conservez le point de progression et distinguez les échecs pouvant être récupérés de ceux qui nécessitent une intervention. Corrigez la cause avant de relancer le traitement ; sinon, la même erreur se reproduira. Un retour en arrière n’est pas toujours possible, en particulier si des communications ont été envoyées ou des actions externes exécutées. Déterminez donc à l’avance si le plan consiste à restaurer les données, à compenser les effets ou à suspendre les nouvelles écritures pendant l’enquête.
Rapprocher les données et clôturer l’opération
À la fin du traitement, comparez les enregistrements attendus aux résultats de destination à l’aide des clés convenues. Classez les écarts : enregistrements non éligibles, erreurs techniques, conflits de données et cas nécessitant une vérification manuelle. Ne concluez pas à la réussite simplement parce que le processus s’est terminé sans interruption ; un rapprochement doit expliquer les écarts.
Consignez le périmètre traité, les exclusions, les erreurs encore en attente, les décisions prises sur les conflits et les effets secondaires observés. Conservez suffisamment d’informations pour permettre aux équipes d’assistance et d’exploitation de répondre aux questions ultérieures. Si l’écart provient de données qui continuent d’évoluer, définissez comment capturer les modifications survenues pendant le backfill afin d’éviter la création d’un nouvel écart.
Liste de contrôle avant la mise en production
- La différence à corriger est-elle clairement définie, et sait-on pourquoi une nouvelle tentative ou une synchronisation de l’état actuel ne suffit pas ?
- Les dates, états, exclusions, identifiants et systèmes de référence pour chaque champ sont-ils définis ?
- Le comportement en cas de doublons, de répétition des requêtes et d’échecs partiels a-t-il été vérifié ?
- Les notifications, paiements, changements d’état et autres actions déclenchées sont-ils connus et contrôlés ?
- L’échantillon de test couvre-t-il des cas représentatifs, et le résultat a-t-il été vérifié à destination ?
- Dispose-t-on d’indicateurs, d’un responsable opérationnel, de critères d’arrêt et d’un plan de reprise ?
- Existe-t-il une méthode de rapprochement et une liste des écarts pouvant nécessiter une vérification ?
Si une réponse essentielle est inconnue, limitez le périmètre et levez cette incertitude avant d’étendre l’opération. La sécurité d’un backfill dépend moins de la rapidité du traitement que de la capacité à expliquer ce qui a été envoyé, ce qui a changé, ce qui reste en attente et comment éviter la répétition d’effets indésirables.