Deux systèmes qui ne sont jamais tout à fait d’accord

Une intégration est déclarée finie le jour où les données passent d’un système à l’autre. C’est un jalon réel et ce n’est pas la fin : deux systèmes reliés se mettent à diverger, lentement, et personne ne s’en aperçoit avant que quelqu’un compare deux écrans.

La divergence n’est pas un bug au sens habituel. Rien ne tombe en panne, aucune erreur n’est enregistrée, les deux logiciels affichent des chiffres cohérents avec leur propre contenu. Simplement, ils ne racontent plus la même histoire, et le jour où la différence est découverte, personne ne sait depuis quand elle dure.

Cet article traite de la vie d’une intégration en marche : qui a raison quand deux systèmes se contredisent, à quelle fréquence rapprocher, ce qu’on fait d’un doublon, comment rejouer sans dupliquer, ce qui arrive quand un champ est renommé, et jusqu’où on peut remonter dans le passé. L’article qui l’accompagne traite de la faisabilité — l’inventaire avant le devis, ce qui sort d’un logiciel, la caisse qui n’expose rien — et rien de cela n’est repris ici.

Il ne contient aucun graphique, et la raison est plus intéressante que d’habitude : ce dont il parle n’a jamais été compté par personne, parce qu’aucun des deux systèmes ne l’enregistre comme une erreur.

La divergence commence toujours petit et par un cas particulier. Une commande annulée pendant que la synchronisation tournait. Un enregistrement modifié deux fois dans la même minute. Une panne de réseau de quarante secondes au milieu d’un envoi. Chacun de ces cas produit un écart d’une ligne, et une ligne ne se remarque pas.

Ce qui rend le phénomène dangereux est qu’il s’accumule sans se signaler. Au bout de trois semaines l’écart est de quelques dizaines de lignes, au bout d’un an il est structurel, et il est découvert par un inventaire physique ou par un client qui affirme avoir payé quelque chose que le système ne connaît pas.

À ce moment-là, la question posée est « depuis quand », et c’est la question à laquelle il est le plus coûteux de répondre après coup. Sans comptage régulier conservé, il n’existe aucun moyen de dater le début de la dérive, et la seule option est de reprendre la totalité de la période.

Nous ne pouvons pas dire à quelle fréquence cela arrive, et l’explication mérite d’être donnée plutôt que contournée. Il n’existe aucune statistique publiée sur les taux de divergence entre systèmes, non pas parce qu’elle est confidentielle, mais parce que personne n’a jamais pu la mesurer : pour les deux logiciels concernés, l’opération a réussi. L’envoi a réussi, l’écriture a réussi. L’événement n’est enregistré nulle part comme un échec, donc il n’existe aucune population d’erreurs à échantillonner. C’est le seul chiffre de cette page, et il n’a jamais été compté par personne.

Le système d’en face sera indisponible, et pas rarement : maintenance, coupure réseau, quota atteint, serveur saturé un jour de forte activité. La question n’est pas de l’éviter mais de savoir ce que fait votre côté pendant ce temps.

Il y a trois comportements possibles et un seul est acceptable. Perdre l’envoi, ce qui produit la divergence de la section 2 et ne se voit pas. Bloquer et attendre, ce qui transforme une panne chez eux en panne chez vous. Ou mettre de côté et réessayer, ce qui est la seule réponse qui préserve à la fois le service et l’exactitude.

La mise en attente doit avoir une limite et une voix. Une file qui grossit indéfiniment est une perte différée : au bout d’un moment quelqu’un la vide pour débloquer la situation, et personne ne saura jamais ce qu’il y avait dedans. Une file qui prévient quand elle dépasse un seuil transforme la panne en information.

Il faut aussi que les tentatives s’espacent. Réessayer toutes les secondes contre un système déjà en difficulté ajoute de la charge à la panne, et certains fournisseurs traitent cette insistance comme un abus et coupent l’accès. Espacer les tentatives est une politesse technique qui protège surtout celui qui l’applique.

Quand une intégration est mise en place, la demande qui suit immédiatement est de récupérer le passé : reprendre les deux dernières années de commandes, remplir le nouveau système avec l’historique de l’ancien. Elle est légitime et elle a une limite qu’il vaut mieux poser tout de suite.

Ce qui peut être repris est ce qui a été enregistré. Ce qui n’a jamais été saisi n’existe nulle part et aucune reprise ne le fera apparaître : si l’ancien système ne notait pas le canal d’acquisition, le nouveau ne l’aura pas pour les années passées, quelle que soit la qualité du travail de migration.

C’est une distinction que les demandes formulent rarement et qui change complètement l’estimation. « Reprendre l’historique » peut vouloir dire recopier des champs qui existent, ce qui est du travail mécanique et faisable, ou reconstituer une information qui n’a jamais été collectée, ce qui est de l’invention et doit être refusé.

La bonne pratique est de séparer les deux dans le devis, en toutes lettres : voici les champs repris, voici les champs qui resteront vides pour la période antérieure. Le client décide alors en connaissance de cause, et personne ne découvre six mois plus tard que la colonne qui devait servir à tout est vide sur trois quarts des lignes.

Ce que nous prenons en charge est délimité : écrire la source de vérité champ par champ avec les personnes qui utilisent les deux systèmes, construire l’intégration avec sa table de correspondance et sa référence stable, et installer le rapprochement qui se conserve — la partie la moins spectaculaire et celle qui rend tout le reste réparable.

Nous ne construisons pas d’intégration sans que la source de vérité soit écrite pour chaque champ qui circule, même quand le client trouve la question théorique. Elle ne l’est pas : sans cette page, le premier conflit est arbitré par l’ordre d’exécution des programmes, ce qui revient à laisser une décision de gestion à un hasard d’ordonnancement.

Nous ne reconstituons pas un historique qui n’a jamais été enregistré. Nous recopions ce qui existe et nous disons quelles colonnes resteront vides pour la période antérieure. Remplir ces colonnes par estimation produirait des données d’apparence complète sur lesquelles quelqu’un fondera une décision, ce qui est plus dommageable qu’une case vide.

Enfin, nous ne promettons pas un taux d’erreur. Cette page explique pourquoi il n’en existe pas de publié — l’événement n’est enregistré comme un échec par aucun des deux systèmes — et il serait incohérent d’en annoncer un après l’avoir écrit. Ce que nous pouvons promettre est que l’écart sera mesuré chez vous, chaque semaine, et conservé, de sorte que la question « depuis quand » ait toujours une réponse.