Une point to point integration, ou intégration point à point en français, relie directement deux logiciels, sans hub, bus ni plateforme au milieu. Chaque application lit ou écrit dans l’autre, et la transformation des données se fait dans la liaison elle-même. Ce montage convient tant qu’il reste deux ou trois applications, mais le nombre de liaisons grimpe vite avec chaque outil ajouté, et c’est ce seuil qui décide du moment de l’abandonner.
Point to point integration : le principe d’une liaison directe
Une liaison directe passe le plus souvent par un script maison, par l’API d’un éditeur ou par un webhook. Un CRM qui ajoute chaque nouveau contact à une liste d’emailing en est l’exemple type : un seul flux, deux applications, aucun intermédiaire.
Une API n’est pas en soi une intégration point à point. Elle le devient quand deux applications s’appellent directement, chacune dépendant de l’autre. La nuance est détaillée dans notre article sur la différence entre API et intégration d’API.
Les cas où la liaison directe reste le bon choix
Pour un flux unique entre deux applications, avec un responsable clair, la liaison directe est la solution la plus simple. Il n’y a aucune plateforme à acheter ni à maintenir, et la mise en place est rapide.
Elle sert aussi de pont temporaire, par exemple quand un ancien logiciel doit alimenter un nouvel outil le temps d’une migration. Raccorder une base de données de PME à un nouvel outil de gestion relève de ce cas. Avec deux ou trois systèmes stables, peu modifiés, ce montage tient sans difficulté.
Le calcul qui fait exploser la maintenance
Pour relier entièrement n applications, il faut au plus n(n-1)/2 liaisons. Trois applications en demandent 3, cinq en demandent 10, dix en demandent 45 et vingt en demandent 190. La croissance suit le carré du nombre d’applications, pas une courbe exponentielle, et la plupart des parcs ne relient pas toutes les paires : ce chiffre est un maximum.
Chaque liaison a son propre planning, ses identifiants, sa gestion d’erreurs et ses journaux. Le couplage est fort : un changement de version d’API ou de format d’un côté casse la liaison de l’autre. Faute de documentation, la connaissance du montage repose souvent sur une seule personne.
Aucune vue d’ensemble ne montre l’état des flux, ce qui donne l’effet spaghetti. La sécurité se règle liaison par liaison, ce qui multiplie les points à contrôler.
Hub and spoke, ESB, iPaaS : ce que changent les alternatives
Dans un modèle hub and spoke, chaque application ne se connecte qu’une fois au centre. Pour dix applications, cela fait 10 connexions au lieu de 45, et la transformation comme la supervision des flux se font au même endroit.
Le bus de services d’entreprise (ESB) relie les applications par un hub central de communication, en général installé sur site, avec un investissement d’infrastructure notable. Une plateforme d’intégration en ligne (iPaaS) joue le même rôle depuis le cloud, avec des connecteurs préconstruits et des outils visuels, et peut aussi être déployée sur site ou en mode hybride.
La contrepartie est double : le hub devient un point unique de défaillance, et la plateforme a un coût de mise en place et d’exploitation.
Les signes qu’il est temps de changer d’architecture
Le passage à une plateforme se justifie quand plusieurs de ces signaux apparaissent en même temps :
- plus de quatre systèmes sont interconnectés, et chaque ajout oblige à créer plusieurs liaisons ;
- des rapports se contredisent sans qu’aucun responsable ne puisse dire quelle liaison a échoué ;
- une mise à jour d’API chez un éditeur casse un flux, et la correction se fait dans l’urgence, liaison par liaison.
Quand la maintenance de ces flux dépasse les compétences ou le temps de l’équipe, la confier à un prestataire est une option, comme le décrit l’infogérance du système d’information.
Passer d’une liaison directe à une plateforme sans tout casser
Le premier travail est l’inventaire : lister chaque liaison existante, les deux applications qu’elle relie, le format échangé et la personne qui la connaît. Cette documentation manque presque toujours, et elle sert quelle que soit la suite.
On migre ensuite vers la plateforme les flux les plus fragiles, ceux qui échouent le plus souvent. Les liaisons simples qui fonctionnent peuvent rester telles quelles, puisqu’une liaison directe entre deux systèmes stables n’a rien d’une erreur. Pour choisir les outils qui se connecteront à cette plateforme, les critères de choix de solutions connectées aident à trier.
Une migration réussie se reconnaît à un résultat simple : chaque flux a un propriétaire, une documentation et une alerte en cas d’échec, que l’architecture reste en liaisons directes ou passe par un hub.
