Guide · 8 min
Connecter plusieurs logiciels par API.
Le choix technique est la partie facile. Ce qui fait échouer une intégration, ce sont trois questions d’organisation qu’on découvre trop tard.
Le problème n’est pas de transporter la donnée
Faire passer une information d’un logiciel à un autre est un exercice résolu depuis longtemps. Ce qui coince arrive après : deux systèmes détiennent désormais la même information, et rien ne dit lequel a raison quand ils divergent.
Une intégration qui échoue ne tombe presque jamais en panne. Elle produit silencieusement deux vérités — un client dont l’adresse est à jour d’un côté et périmée de l’autre, une facture qui existe deux fois — et personne ne s’en aperçoit avant qu’un client le signale.
Question 1 — Qui détient la donnée de référence ?
Pour chaque information partagée, un seul système doit faire autorité. Le client est-il créé dans le CRM ou dans la comptabilité ? Le tarif vient-il du catalogue ou de l’ERP ? Si la réponse est « les deux », l’intégration fabriquera des conflits.
Cette décision n’est pas technique : elle dit qui, dans l’entreprise, a le droit de modifier quoi. Elle se tranche avec les personnes concernées, avant d’écrire une ligne. Une fois posée, la règle est simple : ailleurs, la donnée est en lecture seule — et l’interface doit le montrer, sinon quelqu’un la modifiera là où ça ne compte pas.
Question 2 — Dans quel sens, et quand ?
Une synchronisation à sens unique est infiniment plus simple à tenir qu’une synchronisation bidirectionnelle. Chaque fois que c’est possible, choisissez le sens unique : la bidirectionnalité impose de résoudre les conflits, et il n’existe pas de bonne façon générique de le faire.
Sur le rythme, trois approches, par ordre de robustesse décroissante.
À la demande
On interroge l’autre système au moment où on a besoin de l’information. Rien n’est dupliqué, donc rien ne diverge. À privilégier quand le volume le permet et que l’autre système répond vite.
Sur évènement
L’émetteur prévient quand quelque chose change. Réactif et économe — mais un évènement manqué se rattrape rarement tout seul : il faut prévoir un rattrapage périodique, sinon un incident de quelques minutes laisse un écart permanent.
Par lot
Un passage régulier qui rattrape tout. Moins réactif, beaucoup plus simple à rejouer — et c’est cette capacité à rejouer qui sauve la mise le jour d’un incident.
Question 3 — Que se passe-t-il quand l’autre ne répond pas ?
Il ne répondra pas. Une maintenance, une coupure, une limite d’appels atteinte : c’est certain, la seule inconnue est la date. Une intégration qui n’a pas prévu ce cas transforme une indisponibilité de dix minutes chez un fournisseur en incident chez vous.
Ce qu’il faut décider à l’avance : est-ce que l’opération est mise en file d’attente et réessayée plus tard, ou est-ce qu’elle échoue franchement devant l’utilisateur ? Les deux sont défendables — mettre en file une facture est raisonnable, mettre en file une vérification de solvabilité ne l’est pas. Ce qui n’est pas défendable, c’est de laisser croire que ça a marché.
Deux mécanismes valent d’être exigés dans toute intégration : la reprise avec délai croissant — on réessaie, en espaçant, sans marteler un système déjà en difficulté — et l’idempotence : envoyer deux fois la même opération ne doit pas créer deux factures.
Ce qu’il faut voir depuis l’application
Une intégration invisible est une intégration dont on découvre les pannes par un client mécontent. Il faut pouvoir répondre, sans ouvrir un journal technique : à quand remonte la dernière synchronisation réussie, qu’est-ce qui attend, qu’est-ce qui a échoué, et peut-on le rejouer.
C’est le point le plus souvent oublié dans un devis d’intégration, et celui qui fait la différence entre un système qu’on surveille et un système qu’on subit.
Quand l’autre logiciel n’a pas d’API
Cela arrive, notamment avec des outils anciens. Les solutions de contournement — export de fichiers déposés à intervalle régulier, accès direct à la base, automatisation de l’interface — fonctionnent, mais elles sont fragiles : elles dépendent d’un format ou d’un écran que l’éditeur peut changer sans prévenir.
Si vous devez en passer par là, traitez-le comme provisoire, isolez ce mécanisme derrière une interface propre, et surveillez-le davantage que le reste.
Pour aller plus loin
Notre façon de concevoir et d’exploiter ces connexions sur APIs & intégrations. Sur la question de garder un progiciel et de développer le métier à côté, voyez ERP ou sur mesure.
Écrit par
Yoann Burel, développeur
Les guides de ce site sont écrits par la personne qui développe les applications qu’ils décrivent, chez ErmineSoft.