Décidez quel système possède chaque information, intégrez par événements plutôt que de tout synchroniser avec tout, et journalisez chaque échange. La plupart des intégrations qui tombent en panne silencieusement le font parce que la propriété de la donnée n’a jamais été tranchée et que personne ne surveillait.
Dans presque toute entreprise de taille moyenne, quelqu’un passe en réalité sa journée à recopier des données d’un système vers un autre. La commande arrive par message, une personne la saisit dans l’ERP, une autre la répète dans le CRM, une troisième la note dans l’agenda. Quatre saisies de la même information et quatre occasions de se tromper.
D’abord, qui possède chaque information
Avant tout code, réglez la question politique. Pour chaque donnée importante, un système est la source de vérité et les autres en détiennent des copies.
La fiche client : vit-elle dans le CRM ou dans l’ERP ? Si la réponse est « dans les deux », vous n’avez pas une intégration, vous avez un conflit programmé. Le jour où le même client sera modifié aux deux endroits, une version sera écartée, et ce sera la mauvaise.
Une répartition qui fonctionne bien : le CRM possède la relation (contacts, historique, opportunités), l’ERP possède ce qui a une portée fiscale (produits, prix, commandes, factures) et l’agenda possède le temps (qui est occupé et quand).
Une fois cela réglé, la règle devient simple. L’écriture n’a lieu que chez le propriétaire. Les autres reçoivent et affichent.
Des événements, pas une synchronisation générale
La tentation est de créer une routine qui tourne toutes les heures en comparant tout avec tout. Cela fonctionne un temps, puis devient le processus le plus fragile de l’entreprise : lent, difficile à diagnostiquer et parfaitement capable d’écraser une modification récente par une donnée périmée.
Ce qui tient dans la durée, c’est le modèle par événements. « Commande validée », « client créé », « rendez-vous annulé ». Chaque événement déclenche des actions précises dans les autres systèmes. Si l’un d’eux est indisponible, l’événement patiente dans la file et sera traité plus tard, sans rien perdre et sans tout répéter.
En pratique, il faut trois pièces : un récepteur de notifications (le webhook que l’autre système appelle), une file d’attente, et un processeur capable de rejouer une opération sans dupliquer son effet.
L’idempotence, le mot barbare qui sauve l’exploitation
Toute intégration traitera deux fois le même message à un moment donné. L’autre système renvoie parce qu’il n’a pas reçu l’accusé de réception à temps, quelqu’un rejoue la file, le réseau hoquette.
Si votre processeur n’y est pas préparé, le client est débité deux fois ou le stock est décrémenté deux fois. La protection est simple : chaque événement porte un identifiant unique et, avant d’agir, vous vérifiez si cet identifiant a déjà été traité. C’est une demi-heure de travail qui évite le genre d’erreur que personne ne sait expliquer ensuite.
Journalisez tout, y compris le contenu
Quand une intégration échoue, et cela arrivera, la question est toujours la même : qu’a-t-on envoyé exactement et qu’a-t-on reçu exactement. Sans journal complet, il ne reste que la spéculation et les accusations croisées avec le prestataire d’en face.
Conservez, pour chaque échange : horodatage, adresse appelée, contenu envoyé, réponse reçue, code de statut et temps de réponse. Trente jours d’historique suffisent. Cela transforme « l’intégration déraille » en « à 14h32 l’ERP a renvoyé une erreur 500 sur cet appel », ce qui est une tout autre conversation.
La couche intermédiaire qui évite la dépendance
Brancher le système A directement sur le système B paraît économique et crée un problème pour plus tard. Le jour où l’un des deux est remplacé, toute l’intégration part avec lui.
Une couche au milieu, qu’il s’agisse d’un petit service maison ou d’un outil d’automatisation visuelle comme n8n, reçoit d’un côté et livre de l’autre en traduisant les formats. Changer de CRM revient alors à réécrire un connecteur, pas l’intégration entière. Et ceux qui exploitent le processus peuvent voir le flux sans ouvrir de code.
Commencez là où ça fait le plus mal, et mesurez avant
N’essayez pas de tout intégrer. Demandez à l’équipe quelle ressaisie consomme le plus de temps et commencez par celle-là. Avant d’automatiser, chronométrez : combien de minutes par jour, combien de personnes, avec quel taux d’erreur.
Un client a découvert que trois personnes passaient quarante minutes par jour à ressaisir des commandes entre l’outil de vente et l’ERP. Cela fait deux heures par jour, dix heures par semaine. L’intégration s’est remboursée en cinq semaines, et ce chiffre n’existait que parce qu’il avait été mesuré avant, et non estimé après.
Besoin de résoudre cela dans votre entreprise ?
Un échange de vingt minutes suffit en général pour savoir si cela a du sens, et vous parlez directement à l'ingénieur qui construit.