Cas d’usage
Vos outils fonctionnent. Ils ne se parlent simplement pas assez.
Chaque système fait correctement son travail de son côté. Le problème apparaît entre eux : la même donnée est saisie deux fois, un export CSV fait office d'interface, et quand deux outils affichent des chiffres différents, personne ne sait lequel a raison.
Vous vous reconnaissez peut-être
Ces symptômes portent rarement sur un seul outil. Ils apparaissent aux jointures.
- La même donnée client ou produit est saisie dans plusieurs applications.
- Des exports et imports CSV servent de mécanisme d’échange régulier.
- Une personne lance une synchronisation manuelle à intervalle fixe, et s'en souvient.
- Certains outils n'ont pas d'API, ou en ont une qui ne couvre pas ce dont vous avez besoin.
- Deux systèmes affichent des informations différentes et la discussion porte sur qui a raison.
- Une modification dans un système casse un traitement dans un autre, découvert après coup.
- Des connecteurs ont été mis en place il y a des années et plus personne ne sait précisément ce qu'ils transportent.
Ce qui se passe si on ne fait rien
Le coût des échanges manuels est réparti sur beaucoup de personnes, ce qui le rend difficile à voir.
- Les décisions se prennent sur des chiffres discutés
- Quand deux systèmes divergent, la réunion commence par un débat sur la source avant de parler du fond. C'est un coût récurrent, rarement attribué au bon endroit.
- Les échanges manuels échouent silencieusement
- Un import qui n'a pas tourné ne prévient personne. L'écart se découvre plus tard, souvent par un client ou par une clôture comptable.
- Chaque nouvel outil aggrave le problème
- Sans règles d'échange, ajouter une application multiplie les liaisons point à point. La complexité croît plus vite que le nombre d'outils.
- Le système devient rigide
- Quand tout est couplé à tout, remplacer ou mettre à jour une application demande de toucher à plusieurs autres. Le changement finit par être reporté pour cette seule raison.
Connecter ne veut pas dire tout coupler
Une bonne intégration réduit les dépendances au lieu de les multiplier. Plusieurs modes d'échange existent, et ils ne se valent pas selon le besoin.
| Connecter ne veut pas dire tout coupler | Quand c’est adapté | Ce qu’il faut accepter |
|---|---|---|
| Appel direct à une API | Le besoin est ponctuel et synchrone : on demande une information au moment où on en a besoin, et on attend la réponse. | Le système appelé doit être disponible. Si ce n'est pas le cas, l'appelant doit savoir quoi faire — réessayer, dégrader, ou refuser proprement. |
| Événements | Plusieurs systèmes doivent réagir à un même fait métier — une commande validée, un client créé — sans que l'émetteur ait à les connaître. | Accepter un décalage de quelques instants, et concevoir les traitements pour supporter de recevoir deux fois le même événement. |
| Middleware ou bus d’échange | Le nombre de liaisons devient ingérable en point à point, ou les formats doivent être traduits entre plusieurs systèmes. | Une brique de plus à exploiter et à surveiller. Elle se justifie par le nombre de flux, pas par principe d'architecture. |
| Synchronisation par lots | Le volume est important et la fraîcheur n'est pas critique : un rapprochement quotidien ou horaire suffit. | Prévoir le rattrapage après un échec, et savoir dire à tout moment quand le dernier lot a réellement abouti. |
| Import et export cadrés | L'outil distant ne propose rien d'autre, ou l'échange concerne un partenaire externe qui impose son format. | Le fichier devient une interface comme une autre : format documenté, validation à l'entrée, accusé de traitement, gestion des rejets. |
| Adaptation d’un système ancien | Le logiciel n'expose rien d'exploitable et ne peut pas être modifié à court terme. | Construire une façade devant lui plutôt que de laisser chaque outil accéder directement à sa base. C'est aussi ce qui rendra son remplacement possible plus tard. |
Une donnée, une source de vérité
L'important n'est pas le nombre de liaisons, c'est de savoir quel système fait autorité sur quelle donnée — et par quel canal les autres en prennent connaissance.
Système de référence
Le système qui détient la version faisant foi pour un domaine donné : le client, le produit, la commande. Il n'y en a qu'un par domaine, et ce n'est pas nécessairement le même pour tous.
- CRMÉvénements
- ERPAPI
- Portail clientAPI
- Application mobileAPI
- Partenaire externeFichiers cadrés
- Reporting & BILots
Un même outil peut faire référence sur un domaine et être simple consommateur sur un autre. C'est la donnée qui a un propriétaire, pas l'application.
Comment nous abordons le problème
On commence par établir ce qui circule réellement aujourd'hui, ce qui est presque toujours plus que ce qui est documenté.
- 01
Cartographier les échanges actuels
Quels flux existent, entre quels systèmes, à quelle fréquence, portés par qui. Y compris les échanges manuels et les scripts que quelqu'un lance le matin.
- 02
Identifier les sources de vérité
Pour chaque donnée importante, quel système fait autorité. C'est une décision d'organisation autant que de technique, et elle se tranche explicitement.
- 03
Définir les contrats et les responsabilités
Ce qui est échangé, dans quel format, à quelle fréquence, et qui est responsable en cas d'écart. Un contrat écrit est ce qui permet de faire évoluer un système sans casser les autres.
- 04
Traiter les erreurs, les reprises et la surveillance
Que se passe-t-il quand un système ne répond pas, quand un message arrive deux fois, quand un lot échoue. Ces cas se conçoivent avant la mise en service, pas après le premier incident.
- 05
Migrer progressivement
Un flux à la fois, avec l'ancien mécanisme maintenu en parallèle le temps de comparer les résultats. Les écarts constatés pendant cette période sont souvent instructifs.
- 06
Observer les flux en exploitation
Volumes, délais, rejets, files en attente. Une intégration qui n'est pas observée redevient une boîte noire en quelques mois.
Quelle application fait foi ?
C'est la question qui débloque la plupart des projets d'intégration, et ce n'est pas une question technique.
Un propriétaire par donnée, pas par application
Le CRM peut faire autorité sur les coordonnées d'un client pendant que l'ERP fait autorité sur son encours. Découper par donnée plutôt que par outil évite les débats de territoire.
Les autres systèmes en détiennent une copie
Une copie locale est légitime : elle rend un système autonome et rapide. Ce qui ne l'est pas, c'est de la modifier là où elle n'est pas censée faire foi.
L'écart doit être visible, pas absorbé
Quand deux systèmes divergent, le bon comportement est de le signaler, pas de choisir silencieusement. Un écart détecté est un incident ; un écart masqué est une perte de confiance.
La décision se documente
Une liste courte — quelle donnée, quel système fait foi, qui arbitre en cas de conflit — vaut plus que n'importe quel schéma d'architecture pour la suite du projet.
Ce que cela peut donner
Selon les outils en place et leurs possibilités, une intégration prend des formes variées.
- Une API stable devant un système qui n’en exposait pas
- Le remplacement d’un export CSV quotidien par une synchronisation vérifiable
- Un mécanisme d’événements pour que plusieurs outils réagissent sans se connaître
- Une liste écrite des sources de vérité, arbitrée avec les responsables métier
- Une surveillance des flux avec alerte quand un traitement n’a pas abouti
- Un remplacement progressif d’un connecteur historique, l’ancien et le nouveau tournant en parallèle
Ces exemples décrivent des formes de solution possibles, pas des projets réalisés présentés comme références.
Cette trajectoire peut mobiliser
Le cadrage des échanges relève de l'analyse ; la construction et l'exploitation des flux relèvent des deux autres.
Questions fréquentes
Que faire si un logiciel n’a pas d’API ?
Plusieurs options existent selon le logiciel : une base de données accessible en lecture, des exports programmés, parfois un accès applicatif automatisable. Dans tous les cas, nous construisons une façade devant lui plutôt que de laisser chaque outil s'y connecter directement — c'est ce qui rendra son remplacement possible plus tard sans tout casser.
Faut-il passer par un middleware ?
Pas systématiquement. Un middleware se justifie quand le nombre de liaisons devient ingérable en point à point, ou quand les formats doivent être traduits entre plusieurs systèmes. Avec trois ou quatre applications et des échanges simples, il ajoute surtout une brique de plus à exploiter.
Comment éviter les doublons de données ?
En désignant une source de vérité par donnée, et en faisant en sorte que les autres systèmes n'y écrivent pas. Les doublons apparaissent presque toujours parce que deux outils se croient propriétaires de la même information. La détection automatique aide, mais elle traite le symptôme.
Que se passe-t-il lorsqu’un système est indisponible ?
C'est un cas à concevoir, pas un incident à subir. Selon le mode d'échange retenu : mise en file d'attente et reprise automatique, fonctionnement dégradé avec des données locales, ou refus explicite avec un message clair. Ce qu'il faut éviter, c'est qu'une indisponibilité passe inaperçue et laisse deux systèmes divergents.
Peut-on remplacer une intégration existante progressivement ?
Oui, et c'est généralement la bonne méthode. L'ancien mécanisme continue de tourner pendant que le nouveau est mis en service, et on compare les résultats pendant une période. Les écarts constatés révèlent souvent des règles métier que personne n'avait documentées.
Parlons de vos échanges
Dites-nous quels outils doivent se parler et ce qui coince aujourd'hui. Une cartographie rapide suffit souvent à voir où est le vrai nœud.