Le problème n'a jamais été de connecter les systèmes entre eux
Interrogez quiconque a mené un projet d'intégration, et vous obtiendrez la même frustration. En apparence, c'est technique. En réalité, rarement.
« Ce n'était jamais la technologie », explique Caspar, PDG d'Alumio. « C'était toujours les personnes au sein de l'organisation. Le responsable informatique qui ne voulait pas ouvrir les accès, ou qui n'avait aucune vision globale de la manière dont tout cela s'articulait. »
La tuyauterie elle-même était souvent banale. Les systèmes hérités étaient souvent présentés comme difficiles à connecter, mais la réalité était plus simple. « On nous vendait les anciens logiciels comme étant extrêmement complexes à intégrer », raconte Caspar. « Mais cela revenait presque toujours au même : un fichier sur un serveur ou une connexion SOAP. Je me disais souvent que quelqu'un avait rendu la chose bien plus compliquée qu'elle ne devait l'être. »
Si le travail technique était gérable, la difficulté résidait ailleurs : dans l'organisation et dans ce qui se passait une fois l'intégration mise en service.
À quoi ressemble réellement la dépendance à l'intégration
Lorsqu'une entreprise construit une intégration sur mesure, elle n'obtient pas seulement une solution fonctionnelle. Elle hérite d'un ensemble de dépendances qu'elle prend rarement en compte au départ.
La première est la dépendance vis-à-vis du concepteur. La logique réside dans la tête d'un seul développeur ou dans un code que lui seul comprend. Lorsqu'il part, le savoir disparaît avec lui. C'est ce qu'on appelle le risque lié à l'homme-clé : le danger qu'une connaissance critique soit détenue par une seule personne. Caspar l'a constaté à maintes reprises chez des fabricants de taille moyenne : « Tout avait été construit par une seule personne, et cette personne est partie. » Les systèmes continuaient de tourner, mais plus personne dans l'entreprise ne les comprenait.
La seconde est la dépendance entre les systèmes eux-mêmes. Les connexions point à point s'enchevêtrent avec le temps, au point qu'il devient impossible de remplacer un système sans casser les autres. Remplacer un ERP n'est plus un simple projet, mais un risque que personne ne veut prendre.
La troisième est la dépendance au passé. Comme le changement est perçu comme dangereux, les entreprises continuent d'exploiter une architecture qu'elles ont déjà dépassée. « Les entreprises ne cherchaient pas à poser des fondations sur lesquelles bâtir année après année », note Caspar. « Elles préféraient tout reconstruire, puis tout reconstruire à nouveau quelques années plus tard. »
La facture arrive plus tard, et elle n'est pas seulement financière
Le coût de la dépendance à l'intégration est facile à ignorer car il n'apparaît pas comme une ligne budgétaire distincte. Il émerge lentement, de manière difficile à retracer jusqu'à sa source.
Caspar décrit des connexions de gestion d'entrepôt qui tombent en panne toutes les quelques semaines et restent inactives pendant une heure ou plus. Des équipes entières sont alors à l'arrêt. Ce qui frappe, ce n'est pas la panne en soi, mais le fait que l'entreprise finisse par la considérer comme normale. L'hébergement se noie dans une vague facture cloud. L'indisponibilité se traduit par des heures perdues. Ni l'un ni l'autre ne sont étiquetés « dépendance », mais les deux sont bien réels.
C'est pourquoi le débat dépasse désormais le cadre de l'informatique. Les investisseurs et les acquéreurs posent des questions différentes : qui peut maintenir cela si l'équipe actuelle part ? Qu'est-ce qui est réellement documenté ? Combien coûterait la reprise de cet existant à un acheteur ? L'architecture d'intégration fait désormais partie de la due diligence, et les développements sur mesure non documentés sont systématiquement signalés. En pratique, professionnaliser la couche d'intégration n'est plus seulement une amélioration technique. C'est un impératif pour rendre une entreprise cessible, ce qui implique le propriétaire et le directeur financier dans une discussion autrefois réservée à l'informatique. Les mêmes questions surgissent de l'autre côté de la table lors de l'intégration post-fusion.
Mais le coût le plus lourd est celui du temps. « Il n'y a vraiment qu'un seul ennemi pour toute entreprise, et c'est le temps », explique Caspar. « Si l'argent n'est pas la contrainte, cela devient en réalité plus dangereux, car les gens acceptent que les choses prennent inutilement du temps. » Une entreprise qui ne peut pas évoluer à la vitesse de son marché a un sérieux problème, et c'est la dépendance qui la ralentit.
Supprimer les dépendances créées par les intégrations sur mesure
La solution n'est pas de construire de meilleures intégrations sur mesure. Il s'agit d'éviter, dès le départ, les dépendances qu'elles engendrent. Cela signifie changer l'endroit où réside la logique d'intégration, et non la qualité de son code.
C'est là qu'une plateforme d'intégration en tant que service (iPaaS) change la donne. L'iPaaS Alumio est une solution native cloud, axée sur la configuration qui connecte les systèmes métier via une couche centrale, plutôt que par des liens personnalisés uniques entre chaque paire de systèmes. Chaque connexion est établie grâce à des paramètres structurés plutôt que codée de toutes pièces. Cela fonctionne avec un connecteur pré-construit lorsqu'il en existe un, et avec l'API propre au système dans le cas contraire. Alumio propose également un transformateur de code pour les développeurs qui préfèrent résoudre un cas particulier par le code. L'intérêt n'est pas que la plateforme connecte les choses plus élégamment. L'intérêt est ce qu'elle élimine.
Mettez en place cette couche d'intégration centrale, et la logique de chaque connexion réside dans un endroit visible et gouverné, plutôt que dans la tête d'un seul développeur. Lorsqu'une commande est passée sur la boutique en ligne, elle est transmise à l'ERP, met à jour les stocks et déclenche l'exécution. L'entreprise peut visualiser et modifier ce flux sans dépendre de la personne qui l'a initialement écrit. Un système peut être remplacé sans que les autres ne s'effondrent. Le savoir reste au sein de l'organisation.
Il existe un compromis qu'il convient d'énoncer clairement. Adopter une plateforme signifie standardiser, et standardiser signifie renoncer à une partie de la liberté sur mesure qu'offrent les développements spécifiques. Pour les entreprises convaincues que leurs processus sont totalement uniques, cela peut ressembler à une contrainte. En pratique, c'est tout le contraire. C'est ce qui leur permet de changer un système sans avoir à renégocier toute leur architecture.
Pourquoi la dépendance est désormais une question stratégique
Rien de tout cela n'est statique. Le même schéma qui a commencé par extraire la logique du code continue de se déployer. Caspar a vu le terrain bouger sous ce problème depuis la fondation d'Alumio, et son analyse est que la tendance se poursuit dans la même direction.
« Nous avons lancé Alumio pour sortir la technologie du code », déclare Caspar. « Aujourd'hui, la technologie n'est plus dans le code ; elle est dans une couche visuelle. L'étape suivante est que cette couche visuelle compte de moins en moins. Cela devient une question métier. » La tuyauterie s'efface progressivement à l'arrière-plan, et la décision stratégique passe au premier plan.
L'IA est le domaine où cela devient concret. La promesse est que les modèles et les agents agiront sur les données métier : répondre à une question sur les stocks, déclencher une réapprovisionnement, rapprocher une facture, préparer un rapport. Cela ne fonctionne que si les données sous-jacentes sont complètes, à jour et autorisées, et s'il existe un historique de ce qui a été déplacé, où et pourquoi.
Une organisation dont la logique d'intégration réside dans la tête d'un seul développeur ne peut pas donner à un système d'IA un accès fiable à ses propres opérations. Elle ne peut pas non plus auditer a posteriori ce que ce système a réellement fait. L'IA ne supprime pas la dépendance liée à l'intégration. Elle en augmente le prix. Les entreprises qui tireront une réelle valeur de l'IA sont celles qui ont rendu leurs flux de données visibles et gouvernés avant d'en avoir besoin. Une couche d'intégration gouvernée est désormais une fondation plutôt qu'une commodité.
Les entreprises qui anticipent cela gagnent en agilité. Elles peuvent adopter de nouveaux systèmes, répondre au marché et exploiter leurs données sans avoir à reconstruire les fondations à chaque fois. Celles qui continuent de reconstruire des intégrations sur mesure héritent de la même dépendance que leurs prédécesseurs, et la paient dans la seule monnaie qu'aucune entreprise ne peut récupérer. S'en défaire plus tard passe par une migration de système existant.
Où réside votre logique d'intégration aujourd'hui
L'évolution de la manière dont les entreprises connectent leurs systèmes tient à un changement fondamental dans leurs objectifs d'achat. Pendant des années, l'objectif était d'obtenir une connexion fonctionnelle. Aujourd'hui, il s'agit de s'offrir la liberté de changer sans avoir à demander la permission au passé. Ce n'est pas la même chose. La différence réside dans la dépendance elle-même. Elle pèse sur le développeur qui détient le savoir, sur des systèmes trop étroitement imbriqués pour être séparés, et sur des décisions prises il y a des années que personne n'ose remettre en question.
Aucune de ces dépendances ne se manifeste ouvertement. Elles résident silencieusement au sein d'un environnement qui fonctionne encore. Puis, une personne clé s'en va, un investisseur pose une question difficile, ou une évolution du marché exige un changement que l'architecture ne peut absorber. À ce stade, le coût n'est plus théorique. La différence devient alors flagrante. Une entreprise qui a rendu sa logique d'intégration visible et gouvernée peut évoluer. Celle qui ne l'a pas fait ne peut que subir.
Le point de départ pratique est plus simple qu'il n'y paraît. Cartographiez où réside réellement votre logique d'intégration et demandez-vous qui pourrait la modifier demain si la personne qui l'a conçue n'était plus là. Cette simple question met en lumière la dépendance que la plupart des entreprises ont cessé de remarquer, transformant un risque invisible en un problème sur lequel vous pouvez agir. Il n'est pas nécessaire de tout remplacer d'un coup. Il suffit de décider, délibérément, que la prochaine connexion que vous créerez ne sera pas une énième chose que seule une personne comprend.
L'intégration n'a jamais été la partie la plus difficile. C'est ce qu'il en reste après qui l'est. Les entreprises qui agissent en conséquence dès maintenant sont celles qui seront encore capables de bouger quand cela comptera vraiment.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
