Intégration de systèmes

• Les pannes

  L’autre côté disparaît, et vos promesses tiennent quand même.

• Les doublons

  Rejouer doit être sans risque, parce que cela finit par arriver.

• Les désaccords

  Deux systèmes, une vérité, et une règle pour trancher.

• La traçabilité

  Six heures plus tard, quelqu’un doit voir ce qui s’est passé.

L’autre côté disparaît

Tout système externe dont vous dépendez sera indisponible à un moment, généralement sans prévenir et généralement pendant votre heure la plus chargée. La question est de savoir si cela devient votre panne. C’est le cas si votre tunnel de commande appelle leur API de façon synchrone et attend. Ce ne l’est pas si l’appel est mis en file, rejoué avec un délai croissant, et que le client voit une commande confirmée pendant que le système rattrape derrière lui.

Cette décision se prend le premier jour et coûte cher à changer ensuite, parce qu’entre-temps toute l’application suppose que l’appel est instantané.

La même chose arrive deux fois

Les réseaux expirent après que l’autre côté a déjà fait le travail. Un rejeu crée alors une deuxième commande, un deuxième débit ou une deuxième expédition. L’idempotence est ce qui empêche cela : chaque opération porte une clé, le côté récepteur note ce qu’il a déjà traité, et une répétition est reconnue plutôt que réexécutée.

Cela doit être conçu dès le départ. L’ajouter pendant un incident, alors que des factures en double partent déjà, est le pire moment pour y réfléchir pour la première fois.

Deux systèmes ne sont pas d’accord sur ce qui est vrai

Votre ERP dit qu’il en reste quatre, la boutique dit six, et les deux ont techniquement raison parce qu’ils se sont parlé il y a quarante minutes. Quelqu’un doit décider quel système détient ce nombre, si l’autre a le droit de décider à partir d’une copie périmée, et ce qui se passe quand ils divergent.

Nous rendons cette propriété explicite pour chaque champ qui compte. C’est généralement l’heure la plus utile d’un projet d’intégration, et presque toujours celle que personne n’avait prévue.

Personne ne sait ce qui s’est passé

Six heures après un incident, quelqu’un doit expliquer pourquoi un client a été débité deux fois. Si l’intégration n’a rien journalisé au-delà d’« erreur », cette explication n’existe pas. Nous journalisons la charge utile, la décision et le résultat pour tout ce qui touche à l’argent ou au stock, avec assez de détail pour reconstituer la séquence et pas assez pour que vous stockiez des numéros de carte.

Nous avons beaucoup travaillé sur WhatsApp Business API, y compris pour notre propre produit wagate.app, donc les réalités opérationnelles ici sont celles avec lesquelles nous vivons plutôt que celles dont nous avons lu la documentation.

L’API elle-même est simple. Ce qui surprend, c’est la validation des modèles de message et le temps qu’elle prend, la fenêtre de service client de vingt-quatre heures et ce qu’on a le droit d’envoyer en dehors, la gestion des numéros et de la note de qualité, et des webhooks livrés au moins une fois plutôt qu’exactement une fois. Une intégration qui ignore ce dernier point finira par envoyer deux fois le même message à un client.

Nous commençons par cartographier ce qui existe réellement, pas ce que la documentation dit qui existe. Cela veut généralement dire lire le code ou observer le trafic, parce que l’écart entre les deux est l’endroit où vivent les surprises.

Ensuite nous fixons le contrat : quelles données circulent, dans quel sens, qui détient chaque champ, ce que fait le système quand l’autre côté est indisponible, et ce qu’il faut dire à un humain quand la reprise automatique a épuisé ses options. Ce document est le livrable du cadrage, et il est rédigé pour pouvoir être confié à un autre prestataire.

Nous construisons derrière une file par défaut, avec une file d’échecs qu’une personne peut réellement traiter, parce qu’une intégration qui perd des échecs en silence est pire qu’une qui casse visiblement.

Une intégration unique bien documentée, par exemple une boutique vers un ERP pour les commandes et les stocks, prend généralement trois à six semaines. Un programme multi-systèmes, où quatre ou cinq briques doivent s’accorder, court sur trois à neuf mois et se fait au mieux une connexion à la fois, chacune en production avant que la suivante ne démarre.

Ce qui fait bouger le chiffre, c’est la qualité de l’API d’en face, pas le nombre de champs souhaités. Une excellente API avec cinquante champs va plus vite qu’une mauvaise avec cinq.

L’intégration accompagne généralement une plateforme sur mesure, et chez les clients du commerce elle relie le plus souvent l’infrastructure e-commerce aux systèmes derrière. Quand l’intégration alimente un assistant ou une automatisation, voir le développement IA.

Dites-nous ce qu’il faut connecter