Un interfaçage qui fonctionne n’est pas forcément un interfaçage réussi
Dans les articles précédents de cette série, nous avons d’abord identifié les conséquences des silos de données en entreprise, puis expliqué le rôle de l’interfaçage applicatif avant de comparer les différentes approches possibles : connecteur natif, iPaaS ou intégration applicative sur mesure.
Une fois l’approche choisie, le plus difficile commence parfois.
Car connecter techniquement deux applications n’est pas forcément le principal enjeu. Une API peut répondre. Les données peuvent circuler. Le premier test peut être concluant. Pourtant, quelques semaines après la mise en production, des doublons apparaissent, certaines informations ne sont plus synchronisées ou personne ne sait réellement quelle application détient la donnée de référence.
Le projet fonctionne techniquement. Mais il ne fonctionne pas réellement pour l’entreprise.
C’est précisément ce que découvre SERVIPRO, notre entreprise fil rouge. Après avoir décidé de mieux connecter son CRM, son ERP, son application métier et son portail client, elle doit désormais répondre à des questions beaucoup plus concrètes : quelles informations doivent circuler ? Dans quel sens ? Quelle application doit faire foi ? Que se passe-t-il lorsqu’une donnée est incohérente ou qu’un système devient temporairement indisponible ?
Autrement dit, un projet d’intégration applicative ne se résume pas à créer des connexions.
Il consiste à organiser durablement la circulation de l’information.
La tentation est grande de commencer par dresser la liste des logiciels à connecter : CRM, ERP, application métier, portail client.
Mais cette approche ne suffit pas. Deux applications peuvent avoir besoin d’échanger dix informations différentes, à des moments différents, avec des règles différentes.
Un cadrage efficace commence donc par les flux.
Chez SERVIPRO, la création d’un nouveau client dans le CRM peut par exemple entraîner plusieurs conséquences : création de sa fiche dans l’ERP, transmission de certaines informations à l’application métier, ouverture de droits dans le portail client ou encore alimentation d’un outil de reporting.
Il ne s’agit donc pas uniquement de dire « le CRM doit communiquer avec l’ERP ». Il faut comprendre précisément quelles données circulent, pourquoi elles circulent, dans quel sens et à quel moment du processus.
Cette cartographie permet également d’identifier les flux réellement critiques. Toutes les synchronisations ne nécessitent pas le même niveau d’attention. Une information destinée à alimenter un reporting hebdomadaire n’a pas les mêmes exigences qu’une donnée qui conditionne la facturation ou la planification d’une intervention.
Cette étape peut sembler évidente. Elle est pourtant souvent celle qui conditionne la qualité de tout ce qui suit.
Avant de connecter des outils, il faut comprendre ce qui doit réellement circuler entre eux.
Dès qu’une même information existe dans plusieurs systèmes, une question devient incontournable : quelle application est considérée comme la source de référence ?
Prenons une adresse client.
Le commercial peut la modifier dans le CRM. L’équipe administrative peut la mettre à jour dans l’ERP. Le client peut lui-même la corriger depuis son portail. Si aucune règle n’a été définie, quelle version doit être conservée ?
Ce type de situation paraît anodin jusqu’au moment où deux systèmes renvoient des informations différentes. Sans gouvernance claire, l’interfaçage peut alors accentuer le problème au lieu de le résoudre : une donnée erronée est simplement diffusée plus rapidement dans tout le système d’information.
C’est ici qu’intervient la notion de référentiel maître. Pour chaque type de donnée importante, l’entreprise doit déterminer quelle application en est responsable.
Le CRM peut être la source de référence pour les contacts commerciaux. L’ERP peut rester maître des données de facturation. L’application métier peut détenir le statut opérationnel d’une intervention.
L’objectif n’est pas forcément de centraliser toutes les données dans un seul outil. Il est de savoir clairement où se trouve la version de référence.
Pour SERVIPRO, cette décision évite notamment qu’une modification effectuée dans un logiciel soit écrasée quelques minutes plus tard par une information plus ancienne provenant d’un autre système.
Le sujet paraît technique.
Il est en réalité profondément organisationnel.
Une fois les flux identifiés et les référentiels définis, il reste à déterminer comment les données doivent circuler.
Certaines informations doivent être synchronisées immédiatement. D’autres peuvent l’être toutes les heures ou chaque nuit. Certains échanges fonctionnent dans un seul sens. D’autres doivent être bidirectionnels.
Chez SERVIPRO, le statut d’une intervention peut devoir remonter rapidement dans le portail client, tandis qu’un reporting financier peut très bien être consolidé une fois par jour.
Mais les règles nominales ne représentent qu’une partie du travail.
Les difficultés apparaissent surtout dans les exceptions.
Que se passe-t-il lorsqu’un client existe déjà dans l’ERP sous une autre orthographe ? Lorsque le CRM envoie une fiche incomplète ? Lorsque deux collaborateurs modifient la même information presque simultanément ? Ou lorsqu’une application est temporairement indisponible ?
Un projet d’intégration bien conçu prévoit ces situations avant qu’elles ne se produisent.
C’est souvent là que se joue la différence entre un interfaçage qui fonctionne lors d’une démonstration et un système capable de supporter plusieurs milliers d’échanges dans la durée.
Lorsqu’un interfaçage est développé, le premier réflexe consiste généralement à vérifier que la donnée part bien d’une application et arrive correctement dans l’autre.
C’est indispensable. Mais insuffisant.
Un test technique peut confirmer qu’un client créé dans le CRM est bien transmis à l’ERP. Il ne dit pas forcément ce qui se passera si le client existe déjà, si son adresse est incomplète, si un champ obligatoire manque ou si l’ERP est indisponible pendant quelques minutes.
Les tests doivent donc être construits à partir des situations réelles rencontrées par les utilisateurs.
Chez SERVIPRO, cela signifie tester le parcours classique d’un nouveau client, mais aussi un changement d’adresse, une fusion de doublons, une modification contractuelle ou encore l’échec temporaire d’un échange.
Cette approche permet de confronter l’intégration à la réalité du métier avant la mise en production.
Les utilisateurs ont ici un rôle essentiel. Ils connaissent les exceptions, les contournements et les cas particuliers que les spécifications techniques ne font pas toujours apparaître.
Tester un interfaçage, ce n’est donc pas seulement vérifier qu’une donnée circule. C’est vérifier que le processus reste cohérent quand tout ne se passe pas comme prévu.
Un autre piège fréquent consiste à considérer qu’un flux automatisé devient invisible dès lors qu’il fonctionne.
Au contraire.
Plus un processus est automatisé, plus il devient important de savoir ce qui s’y passe.
Lorsqu’un collaborateur ressaisit une donnée manuellement, il constate immédiatement qu’une information manque ou qu’un logiciel ne répond pas. Avec un échange automatisé, une erreur peut rester silencieuse pendant plusieurs heures, voire plusieurs jours.
Un projet d’intégration applicative doit donc prévoir dès le départ des mécanismes de supervision : journalisation des échanges, gestion des erreurs, alertes, possibilité de rejouer certains flux ou identification rapide des données rejetées.
L’objectif n’est pas de surveiller chaque échange manuellement. Il est au contraire de permettre aux équipes d’intervenir uniquement lorsqu’une situation l’exige.
Chez SERVIPRO, si la création d’un client dans l’ERP échoue, l’équipe concernée doit pouvoir le savoir rapidement, comprendre pourquoi et relancer le traitement sans reconstruire manuellement tout le processus.
La supervision n’est donc pas une fonctionnalité secondaire ajoutée à la fin du projet.
Elle fait partie de la fiabilité de l’intégration.
Un système d’information n’est jamais figé.
Un ERP évolue. Un CRM change de version. Une nouvelle application métier apparaît. Un processus commercial est modifié. Un éditeur fait évoluer son API.
Une intégration parfaitement adaptée aujourd’hui peut donc devenir progressivement moins pertinente si personne ne suit son évolution.
C’est pourquoi la gouvernance ne s’arrête pas au passage en production.
Les interfaces doivent être documentées, leurs responsabilités clairement définies et leurs évolutions anticipées. L’entreprise doit notamment savoir qui pilote le flux, qui intervient en cas d’incident et comment une modification apportée à l’une des applications peut impacter les autres.
Cette logique rejoint plus largement les enjeux de Tierce Maintenance Applicative. Une interface n’est pas un objet technique isolé : elle fait partie du système d’information et doit être maintenue et adaptée à mesure que son environnement évolue.
Pour SERVIPRO, cette gouvernance devient particulièrement importante à mesure que de nouveaux outils viennent rejoindre l’écosystème existant. Une intégration correctement conçue doit permettre d’accueillir ces évolutions sans remettre systématiquement en cause l’ensemble des flux.
Réussir un projet d’intégration applicative ne consiste donc pas uniquement à permettre à plusieurs logiciels de communiquer.
Il faut comprendre les processus métier, cartographier les flux, identifier les référentiels, anticiper les exceptions, tester des scénarios réels et prévoir la manière dont les échanges seront supervisés et maintenus.
La technologie reste évidemment essentielle. Mais elle intervient au service d’une organisation plus large.
C’est précisément l’objectif d’une démarche d’interfaçage d’applications pensée autour des usages métier : connecter les outils existants sans créer de nouvelles dépendances ou de nouveaux silos.
La phase de cadrage prend alors une importance particulière. Avant même de développer, elle permet de mettre à plat les flux, les responsabilités, les contraintes et les situations d’exception. Cette logique vaut d’ailleurs plus largement pour les projets de développement sur mesure : quelques décisions prises en amont peuvent éviter de nombreux contournements une fois la solution en production.
Une intégration réussie ne se juge donc pas uniquement le jour où les premiers flux passent correctement.
Elle se juge quelques mois plus tard, lorsque les volumes augmentent, que les applications évoluent et que les équipes continuent à travailler sans se demander ce qui se passe entre leurs outils.
Et une fois la méthode posée, reste à voir comment cette logique se traduit concrètement dans des projets réels.
Ce sera l’objet du dernier article de cette série : ERP, CRM, application métier… comment connecter des outils existants sans reconstruire tout le système d’information.
Vos questions fréquentes
Un projet d’intégration applicative commence généralement par le cadrage des besoins et la cartographie des flux. Il faut ensuite définir les référentiels de données, formaliser les règles de synchronisation, prévoir les cas d’erreur, tester les scénarios métier puis organiser la supervision et la maintenance des interfaces.
La première étape consiste à définir quelles données doivent circuler entre les deux outils et quelle application fait foi pour chaque information. Il faut ensuite préciser le sens des échanges, leur fréquence, les règles de gestion à appliquer et la manière de traiter les doublons ou les erreurs de synchronisation.
Lorsque plusieurs applications stockent une même information, il est essentiel de déterminer laquelle constitue la source de référence. Sans cette règle, les synchronisations peuvent diffuser des données incohérentes ou écraser une information récente par une version plus ancienne.
Les tests doivent couvrir les scénarios normaux, mais également les situations d’exception : données manquantes, doublons, modification simultanée, indisponibilité d’une application ou rejet d’une information. L’objectif n’est pas uniquement de vérifier que la connexion fonctionne, mais que le processus métier reste cohérent dans toutes les situations.
Une intégration fiable doit prévoir la journalisation des échanges, la remontée des erreurs, des alertes en cas d’échec et, lorsque cela est possible, la possibilité de rejouer certains flux. Cette supervision permet d’identifier rapidement les incidents sans contrôler manuellement chaque synchronisation.
