Le premier appel d’API réussi donne le sentiment que l’intégration est faite. C’est le moment où la plupart des projets se chiffrent — et où l’essentiel n’a pas encore commencé.
Ce qui décide du sort d’une intégration, ce n’est pas l’appel qui fonctionne : ce sont les cas où il ne fonctionne pas.
Trois décisions à prendre avant d’écrire du code
Qui fait autorité sur quoi
Pour chaque donnée partagée, un seul système doit décider. Le stock vient de l’ERP. La fiche client vient du CRM. Le contenu marketing vient du site.
Sans cette règle écrite, deux systèmes finissent par modifier la même donnée et la dernière écriture gagne — au hasard des horaires de synchronisation. C’est la cause la plus fréquente des divergences que l’on découvre six mois plus tard.
Le sens de circulation
Une intégration unidirectionnelle est dix fois plus simple qu’une bidirectionnelle. Avant d’accepter la seconde, il faut vérifier qu’elle est réellement demandée : dans beaucoup de cas, le besoin réel est « le site lit », pas « le site écrit ».
Ce qui se passe en cas de panne
L’autre système sera indisponible. Pas peut-être : certainement, et souvent au pire moment. La question n’est pas de l’éviter mais de décider du comportement — file d’attente avec nouvelles tentatives espacées, mise en attente visible par l’utilisateur, ou refus explicite.
Une commande perdue parce que l’ERP ne répondait pas est un incident commercial, pas un incident technique.
Ce qui rend une intégration solide
Des appels rejouables sans effet de bord. Si le réseau coupe après l’envoi mais avant la réponse, la nouvelle tentative ne doit pas créer une seconde commande. Une clé d’idempotence transmise à chaque appel règle ce problème, et son absence produit des doublons impossibles à démêler.
Le traitement en arrière-plan. Aucun appel à un système tiers ne doit se faire pendant que l’utilisateur attend. Le site enregistre l’intention, répond immédiatement, et une file d’attente se charge du reste. C’est aussi ce qui permet de rejouer un traitement après correction.
Une journalisation qui sert à quelque chose. Ce qui a été envoyé, ce qui a été reçu, quand, et pour quel enregistrement. Sans ce journal, diagnostiquer une divergence revient à comparer deux bases à la main.
Un environnement de test qui existe vraiment. Beaucoup d’éditeurs facturent l’accès à un environnement de recette, ou n’en proposent pas. Le découvrir après la signature transforme la mise en production en essai en conditions réelles.
Le cas de l’ERP sans API
Il est plus courant qu’on ne le croit, surtout sur les logiciels métier installés il y a quinze ans. Trois solutions existent, par ordre de préférence : un export programmé déposé sur un serveur de fichiers, un accès en lecture seule à la base, ou une automatisation qui pilote l’interface du logiciel.
Cette dernière fonctionne, et elle casse à chaque mise à jour. Nous la proposons uniquement comme solution transitoire, avec une date de fin écrite. C’est souvent l’occasion de reposer la question d’un outil métier taillé pour l’activité plutôt que d’un logiciel qu’on contourne.
Ce que nous chiffrons
Une intégration se chiffre après lecture de la documentation de l’autre système et test d’un appel réel. Un ERP dont la documentation est à jour et l’API cohérente demande quelques jours ; le même périmètre sur un système sans documentation, avec des champs libres et des règles implicites, peut en demander quatre fois plus.
C’est pourquoi nous refusons de chiffrer une intégration sur la seule base du nom du logiciel.
