Faire communiquer deux logiciels en PME : les pièges d'une intégration mal préparée

Pourquoi l'intégration « simple » cache toujours quelque chose

« On a juste besoin que le CRM parle à l'ERP. » Cette phrase précède une proportion significative des projets qui glissent de deux à quatre semaines sans que personne ne comprenne vraiment pourquoi. L'intégration n'est pas difficile techniquement. Ce qui est difficile, c'est ce qu'elle révèle.

Quand vous connectez deux logiciels, vous découvrez qu'ils ne parlent pas le même vocabulaire. Un « client » dans le CRM est un prospect qui a répondu à une campagne. Un « client » dans l'ERP est une entité qui a passé au moins une commande facturée. Ces deux définitions ne se recouvrent pas exactement. Décider de la correspondance est une décision métier, pas une décision technique. Et tant que cette décision n'est pas prise, le développeur ne peut pas avancer.

Le même phénomène se produit pour les statuts, les dates, les unités de mesure, les identifiants. Chaque champ qui voyage d'un système à l'autre traverse potentiellement une différence de définition. Cartographier ces différences avant de commencer à coder est exactement ce qui distingue une intégration qui livre dans les temps d'une intégration qui s'étire.

Les vraies causes de dépassement dans une intégration

Les scénarios non nominaux, découverts en cours de route

Toute intégration a un scénario nominal : la donnée part du système A, arrive dans le système B, les deux sont synchronisés. Ce scénario fonctionne en général dès les premiers tests. Ce qui prend du temps, c'est l'ensemble des cas qui s'en écartent.

Que se passe-t-il quand la connexion au système source échoue à mi-transfert ? Que se passe-t-il quand un champ obligatoire dans le système cible est vide dans le système source ? Que se passe-t-il quand un enregistrement a été modifié dans les deux systèmes simultanément ? Ces questions n'ont pas de réponse technique universelle. Elles ont des réponses métier que l'équipe doit définir, et ces réponses doivent être définies avant le développement, pas pendant.

« Derrière le scénario nominal, du fait d'un métier très technique, il y avait un certain nombre de scénarios qui arrivaient de manière plus aléatoire. Et ça, ça a amené pas mal d'allers-retours. »

Sur un projet de modernisation pour un fournisseur d'énergie ETI, les scénarios non nominaux propres au secteur (soutirage, injection, règles Enedis, TURPE) avaient généré plusieurs semaines de va-et-vient entre l'équipe métier et l'équipe technique, alors que ces scénarios auraient pu être cartographiés en atelier avant la première ligne de code. Pour aller plus loin sur ce point précis, l'article sur les scénarios qui tuent un projet SI après la mise en prod détaille la méthode de cartographie.

L'absence de propriétaire de la donnée de référence

Quand deux systèmes contiennent la même donnée avec des valeurs différentes, qui a raison ? Si personne ne l'a décidé en amont, le développeur doit soit choisir arbitrairement, soit bloquer en attendant une décision. L'intégration force à nommer un propriétaire pour chaque type de donnée partagée.Le CRM est la référence pour les coordonnées clients, l'ERP est la référence pour les données de facturation. Cette décision prend dix minutes en atelier et évite trois semaines d'incertitude en développement.

Les questions à poser avant de commencer à coder une intégration

Quatre questions permettent de qualifier une intégration avant de la chiffrer.

Première question : quels sont exactement les champs qui doivent voyager d'un système à l'autre, et dans quelle direction ? Une intégration bidirectionnelle est plus complexe qu'une intégration unidirectionnelle. Identifier le sens du flux et la liste exacte des champs concernés est la première étape.

Deuxième question : à quelle fréquence la synchronisation doit-elle se produire ?Temps réel, toutes les heures, une fois par jour ? Plus la fréquence est élevée, plus l'architecture est complexe et coûteuse. Dans beaucoup de cas, une synchronisation nocturne suffit et simplifie considérablement le développement.

Troisième question : que se passe-t-il en cas d'erreur de transfert ?Qui est notifié ? Le transfert est-il rejoué automatiquement ou manuel ? Les enregistrements en erreur sont-ils mis en quarantaine ou ignorés ? Cette question est presque toujours omise dans les briefs initiaux.

Quatrième question : qui maintient l'intégration quand l'un des deux logiciels est mis à jour ? Les API évoluent. Un logiciel SaaS qui sort une mise à jour majeure peut casser une intégration existante. Identifier qui est responsable de la maintenance et comment les mises à jour sont gérées est une question de propriété, pas de technique.

Pour comprendre comment le coût caché de l'absence d'interopérabilité s'accumule dans le temps, l'article sur le coût caché de l'interopérabilité manquante en PME donne des éléments de calcul concrets.

Ce qui change quand l'intégration est préparée comme un chantier à part entière

Traiter l'intégration entre deux logiciels comme un sujet mineur est une erreur de dimensionnement fréquente. Une intégration bien préparée prend deux à trois semaines de cadrage pour trois à cinq semaines de développement.Une intégration mal préparée prend trois à cinq semaines de développement, puis deux à quatre semaines de corrections et d'allers-retours.

La différence de coût total est souvent nulle. La différence de prévisibilité est majeure : dans le premier cas, le projet livre dans les temps ; dans le second, il glisse sans qu'on sache exactement pourquoi. Si vous êtes en train de chiffrer un projet qui inclut une intégration entre deux systèmes, assurez-vous que le cadrage de cette intégration est listé comme une phase distincte dans le planning, avec ses propres ateliers et livrables.