Interconnecter deux logiciels : les questions à poser avant

« Les deux outils ont une API, ça devrait aller vite. » L’API n’est pas le sujet difficile. Le sujet difficile est que les deux systèmes ne parlent pas de la même chose sous le même nom.

Le sens, décidé pour chaque champ

Une synchronisation bidirectionnelle sur un même champ garantit des conflits. Pour chaque donnée, un seul système fait autorité, et l’autre lit.

L’exercice consiste à parcourir la liste des champs et à désigner le propriétaire de chacun. Il est fastidieux, se fait en une réunion, et supprime la majorité des incidents ultérieurs.

Quand une donnée doit réellement être modifiable des deux côtés, la règle de résolution doit être écrite avant le développement, pas découverte en production.

Le référentiel, source des vraies difficultés

Le premier système identifie un client par un code interne, le second par un numéro attribué ailleurs. La correspondance entre les deux n’existe nulle part.

C’est là que se passe l’essentiel du travail : établir et maintenir une table de correspondance, décider ce qui se produit quand un enregistrement existe d’un côté et pas de l’autre, et traiter les doublons — le même client saisi deux fois avec une orthographe différente.

Cette phase représente régulièrement plus de la moitié du projet, et n’apparaît dans aucun devis qui n’a pas regardé les données.

Les erreurs, prévues dès le début

Une interconnexion qui échoue en silence est pire que pas d’interconnexion : les deux systèmes divergent sans que personne ne le sache, et la découverte se fait sur une facture.

Trois éléments indispensables :

• une file de reprise : ce qui échoue est conservé, pas perdu, et rejouable ;
• une alerte au-delà d’un seuil d’échecs, adressée à quelqu’un de nommé ;
• un écran de suivi montrant ce qui est passé, ce qui attend, ce qui a échoué et pourquoi.

Le troisième est celui qui permet à une personne du métier de diagnostiquer sans appeler un développeur.

Rejouer sans dupliquer

Un message envoyé deux fois ne doit pas créer deux commandes. Cela suppose que chaque opération porte un identifiant unique et que le récepteur ignore ce qu’il a déjà traité.

Sans cette propriété, aucune reprise après incident n’est possible sans vérification manuelle.

La volumétrie change la conception

Synchroniser trente enregistrements à la demande et trois cent mille chaque nuit ne relèvent pas de la même architecture. Le second cas impose un traitement par lots, une reprise sur incident au milieu du lot, et une fenêtre horaire compatible avec l’exploitation.

Poser la question du volume à cinq ans, et non du volume actuel, évite de reconstruire l’ensemble au premier gros client.