Relier deux logiciels : ce qu’il faut vérifier avant de promettre une intégration

« Est-ce que les deux systèmes se parlent ? » est une question à laquelle on ne peut pas répondre. Ils se parlent pour faire quoi : quelle donnée, dans quel sens, à quelle fréquence, et qui a raison quand les deux disent des choses différentes. Ce guide sert à répondre avant de prendre un engagement, parce qu’une intégration promise et non vérifiée transforme un projet en une maintenance sans fin.

Presque toutes les intégrations ratées ont la même histoire : ça fonctionnait à l’essai, puis un cas non prévu est arrivé — une commande annulée, un client avec deux fiches, un article supprimé — et personne ne s’est aperçu que depuis trois jours plus rien ne passait.

Une ligne pour chaque donnée

Le document de départ est une liste : une ligne par donnée, quatre colonnes. Si l’on n’arrive pas à la remplir, ce n’est pas encore le moment de regarder les spécifications techniques.

La dernière colonne est celle qui évite les discussions. Si le prix d’un article est différent dans les deux systèmes, lequel l’emporte ? Si la réponse est « ça dépend », l’intégration produira des données incohérentes quelle que soit la technologie utilisée.

Les données qui changent de propriétaire en cours de route

Certaines données changent de propriétaire, et c’est le cas le plus délicat. Une commande appartient au site tant qu’elle n’est pas prise en charge ; à partir de ce moment, la vérité se trouve dans le système de gestion et le site n’en montre plus qu’une copie. Si les deux peuvent la modifier, tôt ou tard deux modifications se croiseront et c’est la dernière arrivée qui l’emportera, ce qui n’est pas forcément la bonne.

La règle pratique est unique : pour chaque donnée, à tout moment, un seul système peut l’écrire. Les autres se contentent de la lire.

Ce que les interfaces ne disent pas sur la première page

• Les permissions. Les identifiants qu’on vous donne peuvent ne pas couvrir tous les champs dont vous avez besoin, et l’autorisation peut expirer ou nécessiter un renouvellement périodique que quelqu’un doit penser à faire.
• Les limites. Combien d’appels par minute ou par jour, combien d’enregistrements par requête. Un grand catalogue peut ne pas tenir dans les limites à la fréquence dont vous avez besoin, et cela change le projet, pas seulement le code.
• Les champs réellement disponibles. La documentation liste les objets, mais ne dit pas toujours si vos champs personnalisés sont exposés : il faut vérifier sur vos données, pas sur l’exemple.
• L’environnement de test. S’il n’existe pas, chaque vérification se fait sur les données réelles, avec ce que cela implique. C’est une contrainte à prendre en compte avant, pas à découvrir après.
• Les conditions du fournisseur. Ce qui est permis de faire, avec quelle formule, et si l’accès à l’échange de données est inclus ou constitue un coût à part.

Fiche d’intégration : la commande qui arrive deux fois

Le cas à concevoir n’est pas le cas normal, c’est le cas sale. Une commande est envoyée au système de gestion, la réponse n’arrive pas à cause d’un problème réseau, le système réessaie, et la commande est enregistrée deux fois. C’est la panne la plus fréquente de toutes.

1. Chaque message porte un identifiant stable, décidé par celui qui l’envoie : le numéro de commande du site, pas un numéro séquentiel généré au moment de l’envoi.
2. Celui qui reçoit vérifie si cet identifiant a déjà été traité. Si oui, il ne refait rien et répond que c’est déjà en ordre. C’est cette propriété qui rend les nouvelles tentatives sûres.
3. Les tentatives se répètent à intervalles croissants et pour un nombre défini de fois ; ensuite, le message finit dans une file d’erreurs qu’une personne consulte. Réessayer indéfiniment cache le problème au lieu de le résoudre.
4. À intervalles réguliers, on compare les deux systèmes sur la période : combien de commandes d’un côté, combien de l’autre, lesquelles manquent. C’est la réconciliation, et c’est la seule chose qui dit vraiment si l’intégration fonctionne.
5. La récupération est une procédure écrite : qui supprime le doublon et dans quel système, ce qui arrive au document éventuellement déjà émis, qui prévient le client s’il a reçu deux confirmations.

La même fiche doit être remplie pour la fiche client, où la panne typique est différente : deux fiches pour la même entreprise, créées avec le numéro de TVA écrit de deux façons différentes. Il faut une règle de reconnaissance décidée à l’avance, et un endroit où atterrissent les cas douteux en attendant qu’une personne les examine.

Qui s’en aperçoit quand ça s’arrête

Une intégration s’arrête toujours, tôt ou tard : le fournisseur met à jour, un mot de passe expire, un certificat n’est pas renouvelé, un champ change de format. La question n’est pas de savoir si cela arrivera, mais combien de temps passera avant que quelqu’un ne le remarque.

• Un contrôle qui vérifie le passage récent de données et alerte quand le flux s’interrompt, au lieu d’attendre l’appel d’un client.
• Un destinataire nommément identifié pour cette alerte, et un second nom pour quand le premier est absent.
• Un registre des échanges consultable sans appeler un développeur : quand une commande n’arrive pas, la première question est toujours « est-elle partie ? ».
• Une responsabilité déclarée pour la maintenance, avec les dates d’expiration des identifiants et des certificats notées quelque part où quelqu’un les consulte.

Ce que ce guide ne couvre pas

Ici, on conçoit l’échange entre deux systèmes destinés à coexister. Importer des données historiques — depuis un ancien système de gestion ou des feuilles de calcul — est un travail différent, avec des problèmes de nettoyage et de contrôle du résultat, et a son guide dédié. Le cas particulier de la liaison entre boutique en ligne et stock est également traité à part.