Il est loin le temps où le web était la dernière roue du carrosse du SI. A cette époque, un des enjeux était de relier les différentes applications majoritairement non web d’une société, pour ce faire, on utilisait un « MiddleWare ». Aujourd’hui, le « digital » (euh le web 😉) a pris le pouvoir, le nombre d’interconnexions entre applications a explosé, en plus des connexions entre solutions du SI, il faut ajouter la couche micro au sein même d’une solution (front-end & back-end), ainsi que la couche macro entre solutions du SI et applications externes. La gestion de ces interconnexions est devenue de plus en plus stratégique pour les entreprises qui mettent souvent en place un moteur d’API pour traiter efficacement les échanges et faciliter l’évolutivité du SI.

1/ C’est quoi une API ? Que partage-t-elle avec un MiddleWare ?

API, pour Application Programming Interface, est un protocole d’échange d’informations avec une application par le web (via des requêtes http). Une API impose généralement de suivre un formalisme décrit dans la documentation de l’API (comment je récupère/transmets des informations en fonction de mon ID). La mise à disposition d’une API permet d’accéder à une application externe (sous réserve d’avoir un identifiant ayant les droits de connexion) de manière autonome sans avoir besoin de solliciter l’équipe technique de l’application à connecter. Pour schématiser, une API c’est un peu comme une télécommande 🕹, ça permet de demander ou envoyer des informations précises à une application tierce afin d’utiliser un service sans être responsable de celui-ci (par exemple l’édition d’un contrat, le paiement en ligne, l’utilisation d’une carte géographique etc.).

En cas d’absence d’API, on peut aussi connecter d’autres applications en développant des web services mais cela signifie que l’équipe technique de l’application cible doit développer un accès spécifique, ce qui rend cette approche un peu plus complexe car elle est dédiée et elle nécessite de synchroniser les travaux.

Un « MiddleWare » correspond à une application qui gère l’échange d’informations entre plusieurs applications d’un SI, son rôle est de relier les applications disparates d’un SI tant en termes de technologies que de services.

Un moteur d’API a exactement le même rôle que le « MiddleWare », celui de relier les applications, mais il dispose d’un avantage qui est la standardisation de son système grâce à l’API, surtout vis à vis de vos propres solutions. Par exemple, si vous utilisez un CRM maison qui se connecte au moteur d’API, en cas de refonte, vous n’aurez qu’à lire la documentation de l’API pour reconnecter le nouveau CRM au moteur sans avoir besoin de « redévelopper » les connexions du coté du moteur (ni de solliciter l’équipe qui maintient le moteur). De plus, vous n’êtes pas contraints par une technologie ce qui vous permet de choisir celle qui est le plus efficace pour votre service (ici votre CRM). Ainsi, vous renforcez l’évolutivité de votre SI grâce à l’interopérabilité du moteur d’API permise par le fonctionnement agnostique des requêtes « http » pour solliciter une API.

S’il te plait dessine-moi un moteur d’API ? Bien sûr mon grand ! Regarde comme il est beau :

Ah non, ce n’est pas un chapeau… Bon voyons voir ce qu’il y a à l’intérieur (parce que je le vois bien 😜) :

En ayant une place centrale dans les échanges d’information, le moteur d’API permet de contrôler la data sensible de votre SI.

2/ Pourquoi utiliser un moteur d’API ?

Quand vous devez construire un SI efficace (!?, enfin c’est à vous de voir…), la première question que vous devez vous poser est : pourquoi développer ce que vous pouvez utiliser chez le voisin ? En informatique, rien n’est pire que de réinventer la roue ☸, même si le geste est beau, ça coûte du temps donc de l’argent 💰 (le vôtre évidemment). Aujourd’hui, personne ne vous proposerait de développer un système de cartographie comme Google Maps 🗺 parce que ça vous ruinerait pour un résultat qui serait surement inférieur au service gratuit de Google 😉. De la même manière vous n’allez peut-être pas coder un système de gestion de vos utilisateurs sur vos applications mais utiliser un framework (ou une librairie) qui gère cette fonction. Concrètement, un bon développeur va naturellement chercher les solutions externes qui lui éviteront de maintenir une solution compliquée (vous savez les projets qui ne s’arrêtent jamais parce que vous avez toujours quelque chose à « refactorer »…). Pour réussir à faire communiquer toutes les applications (internes, micro & macro) dont vous avez besoin, la meilleure solution est d’utiliser un moteur d’API qui va par définition faciliter l’interopérabilité entre les applications et créer l’harmonie dans votre SI (rien que ça !).

Le moteur d’API va concentrer toutes les problématiques de connexions entre les applications ce qui vous permet notamment :

• d’industrialiser les connexions entre applications hétérogènes par l’utilisation d’une API ;
• de gérer les problématiques de temps réel au sein du moteur (par exemple pour une application boursière) ;
• d’améliorer les temps de traitements entre les applications, chaque application étant responsable d’optimiser les traitements pour un service (ce qui est plus facile que pour un ensemble de services) ;
• de modulariser le SI en segmentant les grandes applications et donc de faciliter l’évolutivité ou la refonte des applications stratégiques (en évitant une refonte « monolitique » de votre SI) ;
• d’optimiser les traitements des données prenant la place d’un ETL (Extract-transform-load).

En fait le Web a atteint un tel degré de maturité (et de professionnalisation 🤓 surtout chez Agilap 😉) qu’il permet la prise en charge des applications de gestion stratégiques ainsi qu’un nouvel « intergiciel », le moteur d’API, reprenant les fonctions du MiddleWare, de l’EAI (Enterprise Application Integration) et de l’ETL avec une capacité à prendre en charge certains nouveaux services tout en ayant une attitude ouverte grâce à l’API permettant aux autres applications de « consommer » les services de l’API de manière indépendante.

Donc la grande question est être ou ne pas être ! Et aussi, pourquoi créer sa propre API et même son moteur d’API ? Tout d’abord, parce que grâce aux avantages évoqués précédemment, l’intégration des données à l’aide d’une API est presque devenue incontournable. A moins d’avoir vécu dans une grotte ces dix dernières années, vous avez forcément remarqué l’explosion des solutions s’appuyant sur une API permettant notamment le développement des solutions SaaS (Software as a Service) et la mise en place d’architecture « Microservices » au sein même de votre SI. L’API a ouvert la voie à une consommation de services entre applications et l’utilisation d’un moteur API permet de rationnaliser ces échanges.

3/ Comment un moteur d’API se connecte à d’autres applications ?

Quand on regarde sous le capot, il existe aujourd’hui deux grandes méthodes d’échange de données pour les API, le protocole SOAP (Simple Object Access Protocol) et le protocole REST (REpresentational State Transfer). Dans les deux cas, ces protocoles utilisent des web services pour gérer l’échange des données.

Si vous êtes un pionnier de l’API, vous avez certainement utilisé le protocole SOAP couplé au méta-langage XML (Extensible Markup Language) permettant de transporter les données dans un fichier plat. Ce protocole a eu le mérite d’ouvrir la voie en jetant les bases du fonctionnement d’une API moderne. Il a permis de basculer d’une interconnexion rigide entre bases de données à une logique de consommation de services. Schématiquement, avec une API, je ne récupère plus les champs de la colonne B mais, par exemple, les champs correspondants à la données « prénom » peu importe où ils sont situés en base de données. L’inconvénient est que le protocole SOAP XML a bien vieilli… les requêtes sont complexes à développer et les retours de l’API sont lourds avec une gestion des erreurs importante due au fichier plat XML. Avec ce protocole, on traite beaucoup de code pour peu d’information…

La tendance est aujourd’hui d’utiliser le protocole REST couplé au format de données JSON (JavaScript Object Notation). L’avantage du protocole REST JSON est que le code des requêtes est plus léger avec une structure des données plus simple ce qui limite les erreurs et offre un retraitement moins lourd des retours. Cette approche conserve la notion d’objet qui permet d’être plus précis dans les données à récupérer. Ainsi en ne récupérant que l’essentiel, on améliore les performances et on facilite la maintenance de ce type d’API.

Et s’il n’existe pas d’API (!), peut-on tout de même se connecter une autre solution ? Oui si la solution cible le permet, par exemple, il peut être possible de récupérer des fichiers plats sur des serveurs comme le .csv ou le .xml ou même de se connecter directement en base de données. A noter qu’avec des fichiers plats, il est très probable que vous ayez à gérer les erreurs liées à des séparateurs présents au sein de vos données ce qui peut être très chronophage (donc très cher…). Enfin, il convient de faire attention avec ce type d’approche en dehors des API car elle fige les échanges entre applications et engendre généralement des bugs lorsque les évolutions modifient la structure des données ✋.

Et pour le moteur d’API ? Il s’agit d’une application à part entière et il va être important de choisir une technologie qui puisse gérer le traitement des requêtes en parallèle pour favoriser les performances 🚀 du moteur et la gestion « temps réel » dans l’échange des données. Chez Agilap, nous utilisons deux technologies qui répondent à ces critères :

• Le langage Java qui gère particulièrement bien le « multi-thread » mais qui est relativement complexe (donc relativement onéreux). Nous préconisons cette technologie lorsque le moteur d’API va traiter un très grand nombre de requêtes avec un volume de données très importants car Java est très performant. Il est donc pertinent pour les entreprises qui gèrent une base de données avec des millions de clients (par exemple les banques ou les assurances).
• Le framework Node.JS qui permet de faire des développements back-end sous le langage JavaScript avec une gestion « multi-thread » en étant plus simple d’utilisation que Java et très performant. C’est d’ailleurs pour cette raison que ce langage a explosé récemment et que vous en avez certainement déjà entendu parler car il a permis en quelque sorte de démocratiser le moteur d’API pour les SI de PME et d’ETI qui ne gèrent pas (encore) des millions d’utilisateurs.

Un MiddleWare est un logiciel tiers qui crée un réseau d’échange d’informations entre différentes applications. Un moteur API est aussi un MiddleWare mais il ne se limite pas au rôle de « passe-plats », il facilite l’évolutivité de votre SI en standardisant les connexions entre solutions qui deviennent modulaires, il peut aussi embarquer des logiques métiers grâce à son aspect modulaire et il optimise les performances de votre SI en gérant le « temps réel ».

Bons projets et à bientôt, l’équipe d’Agilap 🌈