L’API Menace L’Industrie Du Middleware Et C’est Tant Mieux !

Les entreprises sont invitées à se tourner vers les API pour se transformer. Une confusion est faite volontairement sur le rôle des API. Présentées comme le nouveau salut des systèmes d’information encombrés et vieillissants, les API sont réduites au statut d’intégrateur technique intelligent. Elles sont beaucoup plus que ça. Elles symbolisent – à elles seules – la transformation numérique et avec elle, le pivot culturel à opérer pour s’affranchir de ses vieux démons.

L’entreprise dans la tempête

Transformation numérique, voilà, l’expression est jetée une énième fois. Les entreprises en recherche de transformation numérique sont engluées dans leur propre complexité informatique. Un système aujourd’hui paralysé, ayant atteint ses ultimes limites, sans retour en arrière possible et sans opportunité, voilà ce qui compose le cœur de trop nombreuses entreprises conventionnelles.  

Face au raz-de-marée technologique, l’entreprise se tourne alors vers ce que le logiciel fait de mieux. Elle virtualise pour échapper à la quantité astronomique de machines physiques à gérer.  Avec le cloud, elle veut satisfaire son ogre énergétique. Elle veut comprendre ses données muettes avec une analytique sur étagère, elle ambitionne d’industrialiser ses processus… bref, à en croire le trust ICE, regroupant les intégrateurs, constructeurs et éditeurs de middleware, la transformation informatique est possible, même avec le legacy. N’ayez crainte et faites nous confiance.

Le train de la mise en production sifflera trois fois

Le legacy ? Cette vieille pelote de fils de laine entremêlés ? J’entends d’ici les cris d’orfraie : “Vieux peut-être mais c’est aussi ce qui fait tourner l’entreprise. Ce sont ces systèmes qui détiennent la connaissance de l’entreprise, qui en assurent l’activité quotidienne. Et si pour les maintenir et les faire évoluer, il faut en passer par de longues nuits d’insomnie et d’importantes sueurs froides, et bien c’est chose entendue.”

C’est certain, personne ne lorgne avec envie sur les milliers de mises en production quotidiennes que réalise Amazon. Personne ne soupire après la légèreté et la flexibilité des systèmes informatiques des start-up et dont le business model s’inspire directement. Et bien, si, au contraire, parce que les exemples de réussite de transformation existent et les entreprises qui ont compris par quel bout prendre leur changement sont là pour en témoigner.

Le salut de l’intégration, une illusion

Des dizaines de logiciels métiers ont été achetés au fil des années et au gré des fusions acquisitions entre éditeurs. Des logiciels qui n’ont jamais su inter-opérer fonctionnellement entre eux. Pour établir une route de communication, on a progressivement fait de la place au middleware, censé réconcilier techniquement ces maudites applications. Ainsi, on a tenté de faire communiquer un logiciel de traitement de commande et un logiciel de livraison. Un logiciel de comptabilité avec un logiciel de CRM. Mais ils ne se comprenaient toujours pas.

Les années passant, l’entreprise perdait la connaissance de ses applicatifs métiers et leurs éditeurs se montraient incapables de les faire évoluer. “Un mal pour un bien”, s’écria l’édition logicielle ! “Vendons de l’intégration intelligente !”. On a alors donné de nouvelles compétences aux ESB, EAI, ETL et consorts, fonctionnelles cette fois-ci, pour que le dialogue s’instaure enfin.

Résultat ? Le contenu fonctionnel des systèmes d’interopérabilité était devenu supérieur aux contenus fonctionnels des deux applicatifs à manipuler.

Concentrant l’intelligence métier, ces logiciels d’intégration sont devenus des foyers d’infection métier (FIM). S’il fallait les comparer à nos habitudes de consommation, ça serait des perturbateurs endocriniens. Les conséquences ont été désastreuses et seront encore pires demain.

Le désastre Dumb Endpoints & Smart pipes

D’une part, l’entreprise s’est aperçue qu’il ne lui était plus possible de réaliser la moindre étude d’impact fiable pour un projet d’évolution. Ni l’intégration ni les applications indéfiniment imbriquées ne supportaient une quelconque modification. Dès lors, toute évolution portait en elle un risque systémique industriel.

D’autre part, cela a contribué à faire exploser les budgets en maintenance « gériatrique » d’applications vieillissantes et en experts d’incidents graves pour intervenir en mode pompier sur l’extraordinaire complexité des systèmes d’intégration. Au point qu’on a fini par donner un nom à cette situation : dumb endpoints & smart pipes, que je traduirais volontiers par point limites et tuyaux intelligents.

Le monde de l’édition fait preuve d’une résilience à toute épreuve et c’est sur ce terrain sablonneux qu’il invite les entreprises à se transformer. Et les professionnels de la profession ont une solution toute trouvée. Les API.

Objectif : Maintenir la confusion

Les API seraient la nouvelle panacée du micmac technologique dans lequel les entreprises sont enfermées. Passer au cloud ? Les API. Casser les silos ? Les API. Ouvrir son système d’information à son écosystème ? Les API. Ça ne vous rappelle rien ? Sous cet angle, les API ne sont qu’un énième protocole technique pour forcer ces pauvres applications malmenées à inter-opérer, et avec le cloud cette fois.

Or, s’il ne doit y avoir qu’une information à retenir, c’est celle-ci : une API n’est pas un protocole d’intégration. Les API portent en elles une nouvelle manière de concevoir des programmes interopérables by design.

Toute la philosophie et le concept de l’API sont à contre-courant total de la façon dont on développe les applications. Alors que les applicatifs ont une durée de vie définie, les API sont durables et infiniment extensibles. Alors que les applications reposent sur des solutions de protection périmétrique pour que leur sécurité soit relativement garantie, une API est fondée sur le principe de sécurité by design.  
Une API, contrairement à ce que l’on veut nous faire croire, n’est pas le nouveau pompier du SI, ni le soignant bienveillant d’applications grabataires

Intégration, application, obsolescence : leur fin annoncée

L’API désigne un véritable dialogue métier. C’est un point d’entrée unique, qui permet par dévoilement progressif d’obtenir toutes les fonctions attendues. A ce titre, toute API nouvellement créée est destinée à discuter et à négocier avec une autre, comme le feraient les être humains. Imaginons alors le nombre exponentiel de nouvelles valeurs que cette interopérabilité illimitée va engendrer.

Le mécanisme de dévoilement progressif de ses fonctions rend difficiles et coûteuses les intrusions fonctionnelles frauduleuses. L’API guide mais ne se laisse pas dicter son comportement, comme le ferait un logiciel classiquement conçu selon le triptyque écran utilisateur – traitement métier – bases de données, qui le rendait si fragile.

En exécutant sa propre sécurité et son interopérabilité, l’API a toute latitude pour contribuer à des systèmes durables, affranchis du risque d’obsolescence. Tant que, évidemment, le web ne devient pas caduc à son tour.

Une entreprise soucieuse de son avenir ne peut décemment pas croire que les API sauveront des eaux son legacy. Ce serait inutilement reproduire le schéma des années passées, renforcer d’autant la complexité et passer à côté du vrai sens à donner à sa transformation numérique.

Les API invitent au pivot culturel. Elles invitent à concevoir son métier autrement, à penser customers journey, expérience utilisateur. Elles nous invitent également à leur asservir l’architecture technique et les choix technologiques, et non l’inverse. Avec les API, nous ferons demain notre métier autrement dans une entreprise à l’informatique durable et évolutive.

Tribune rédigée par Habib Guergachi, CTO de Fabernovel