Une commande arrive correctement, l’ERP l’accepte, le site la confirme et l’entrepôt la voit. Tout semble fonctionner. Puis un jour, une mise à jour de catalogue modifie un champ, une commande se bloque, et personne ne sait si elle est en attente, annulée ou dupliquée.
Intégrer des systèmes, ce n’est pas les faire parler ; c’est décider qui tranche lorsqu’ils ne sont pas d’accord.
C’est ce que beaucoup d’entreprises découvrent trop tard. L’intégration API est souvent vendue comme un projet technique, alors qu’en réalité c’est une décision opérationnelle : quel système fait référence, quelles erreurs sont acceptables, ce qui est relancé automatiquement, et ce qui doit être traité par une personne.
L’échec classique : intégrer sans contrat opérationnel
L’erreur la plus fréquente consiste à penser en endpoints plutôt qu’en règles. Le flux de données est dessiné, mais les questions de base ne sont jamais tranchées :
- Quel système possède le stock, les prix, les commandes et les clients ?
- Que faire si l’ERP répond lentement ou renvoie une erreur partielle ?
- Quelles validations doivent exister avant création d’un enregistrement ?
- Comment détecter les doublons, les changements de format ou les champs vides ?
- Qui est alerté, et sous quel délai doit-il agir ?
Sans réponses, l’intégration devient une suite de rustines. Les ventes voient un statut, les opérations un autre, et le support finit par faire de la réconciliation manuelle.
La thèse est simple : une intégration utile n’est pas celle qui transporte le plus d’événements par minute, mais celle qui réduit les exceptions opérationnelles et rend la panne visible avant que le client ne la subisse.
Ce qu’il faut décider avant de développer
Trois décisions méritent d’être fermées avant d’écrire une ligne de code :
- Source de vérité par objet : dire “l’ERP est maître” ne suffit pas. Il faut préciser s’il l’est pour le stock, les tarifs, les adresses, la fiscalité, la disponibilité ou le statut de commande.
- Politique d’erreur : une erreur de validation ne se traite pas comme un timeout. Certains incidents doivent aller en file d’attente ; d’autres doivent échouer immédiatement ; d’autres nécessitent une revue humaine.
- Observabilité minimale : chaque intégration doit être traçable par identifiant de commande ou de transaction, statut du message, horodatage, cause racine et responsable de résolution.
Si cela n’est pas documenté, le projet dépend trop du développeur qui l’a construit. C’est fragile.
Un test simple : si l’entreprise ne peut pas expliquer ce qui arrive à une commande en échec sans ouvrir le code, l’intégration n’est pas encore mature.
Mini cas : quand “ça marchait” mais n’était pas exploitable
Une entreprise de distribution de taille intermédiaire vendait via ecommerce et gérait ses commandes dans un ERP. L’intégration fonctionnait au sens strict : les commandes arrivaient. Mais lorsqu’une adresse de livraison posait problème, le système ne distinguait pas un incident récupérable d’un incident définitif.
Résultat : certaines commandes restaient dans un état ambigu pendant des heures. L’équipe opérations traitait manuellement des dizaines de cas par jour. L’équipe commerciale annonçait des délais que l’entrepôt ne pouvait pas tenir. Et chaque petite panne déclenchait une longue chaîne de mails.
La solution n’a pas été de “rendre l’intégration plus robuste” en général. Il a fallu introduire des règles concrètes :
- rejet automatique des adresses incomplètes,
- file d’attente pour les incidents temporaires de l’ERP,
- alertes uniquement pour les erreurs non relançables,
- tableau de statut par type d’erreur,
- et un responsable opérationnel pour chaque exception.
Le volume a peu changé. La différence, c’est que les exceptions ont cessé d’être mystérieuses.
La décision inconfortable : parfois, moins d’automatisation est mieux
Voici la partie impopulaire : tout ne doit pas être automatisé de bout en bout.
Dans les intégrations critiques, automatiser 95 % et laisser les 5 % délicats à une revue humaine peut être préférable à une automatisation totale. C’est particulièrement vrai pour :
- les commandes à forte valeur,
- les changements d’adresse après paiement,
- les clients avec conditions commerciales spéciales,
- les stocks à fort risque de rupture,
- et les flux qui touchent à la fiscalité ou à la facturation.
La décision inconfortable consiste à reconnaître qu’une efficacité apparente peut masquer un risque opérationnel. La vraie question n’est pas “peut-on automatiser ?”, mais “quel est le coût d’une erreur ici ?”.
Les signes qu’une intégration est réellement mature
Il n’est pas nécessaire d’avoir une plateforme géante pour savoir si une intégration est saine. Ces signaux sont parlants :
- les erreurs sont catégorisées et attribuées,
- les relances sont limitées et traçables,
- les données critiques sont validées avant d’entrer dans l’ERP,
- les incidents sont traités avec un SLA interne,
- et les opérations voient l’état sans dépendre de l’équipe technique.
Il existe aussi un signal négatif très clair : si chaque incident se termine par “redémarre le connecteur” ou “relance le job”, le système est conçu pour survivre, pas pour opérer.
La meilleure intégration API n’est pas la plus élégante techniquement ; c’est celle qui réduit le travail invisible de réconciliation, de suivi et de correction manuelle.
Dans ce type de projet, Codefuente commence souvent par le contrat opérationnel avant l’implémentation, parce que c’est là que se joue la différence entre un vrai soutien au business et une couche de complexité supplémentaire.