API — Application Programming Interface

Un bref historique

Les APIs ne sont pas vraiment un concept nouveau en informatique. Déjà dans les années 60 des développeurs ont créé des bibliothèques de routines standardisées. J'ai moi-même acheté des librairies C ou Assembleur pour accélérer mon propre développement dans nombre de cas, bibliothèques de routines et fonctions que je garde bien précieusement comme autant de pièces de musée.

Avec la généralisation des ordinateurs connectés — en 1989, au sein de la société FastWrite, aucun ordinateur n'était connecté : les cartes réseaux étaient chères et les standards réseaux pas encore ce qu'ils sont aujourd'hui — on a vu l'émergence de règles qui permettaient d'appeler du code qui se trouvait sur d'autres machines grâce, par exemple, aux appels RPC (Remote Procedure Call)

Quelles que furent les solutions qui avaient au moins le mérite de leur inventivité, cela restait quand même complexe et surtout … les deux parties, celui qui appelle le service et celui qui y répond, continuaient à devoir utiliser le même langage. Ce qui était vrai avec les librairies, dynamiques ou non — des DLLs (Dynamic Link Library) par exemple — continuait à l'être pour des composants COM (Component Object Model) et DCOM (Distributed Component Object Model).

Puis, dans les années 90, on en est arrivé à découpler le tout. D'un côté l'appelant, de l'autre, l'appelé. Dans le langage technique, le «client» et le «serveur». Le client pouvait alors fonctionner dans un langage et le serveur dans un autre.. Deux choses importaient :  (1) standardiser l'appel (essentiellement le passage des paramètres) et (2) standardiser la réponse (le résultat renvoyé).

Ce découplage a donné naissance à l'informatique moderne comme on la connait aujourd'hui avec des APIs en pagaille, une pléthore de services dans laquelle se sont jetés tous les grands que nous connaissons: Google, Amazon, Microsoft, Spotify, Deezer, Apple, ... Désormais ce sont des millions de services qui sont disponibles partout sur Internet puisque tout est découplé et qu'il suffit de s'entendre sur le passage des paramètres et la réception de la réponse, une simple affaire de format en somme.

C'est précisément cette évolution de l'informatique moderne qui a permis d'envisager des paradigmes qui nous semblent évidents aujourd'hui. Prenons ces paradigmes qui sont les pierres angulaires du mouvement DevOps comme «Continuous Integration» et «Continuous Delivery» et vérifions ce que nous en dit le ngram viewer :

Poussons la réflexion plus loin et voyons quel fut le démarrage du terme "OpenAPI" … :

On remarque que les courbes se juxtaposent assez bien et que leur changement d'inflexion se situe grosso-modo au même moment, soit 2012–2013.

Des produits comme Maeven et Jenkins datent de 2004. Comparez ces naissances au pic de la courbe ngram de «Web Services» (et vous pourrez aussi, à titre d'exercice personnel, comparer ce pic avec celui du mot «interopérabilité») : d'abord une vue très étalée dans le temps (ce qui fait ressortir le pic de 2005), et puis une courbe plus ramassée sur les années (ce qui nous permet de mieux mettre en évidence la période de «gloire»)…

N'est-ce pas frappant ?

En 2011, chez BNP Paribas, alors que nous développions la plateforme Internet & Mobile Banking, diverses équipes travaillaient à la réalisation d'APIs. Cela n'a pas discontinué jusqu'en 2014.

Lorsque je suis retourné chez BNP Paribas en 2016, les équipes parlaient désormais de «API First» comme peu de temps avant «Mobile First» !

Voyons la courbe «Docker»:

Il n'y a pas de doute : quelque chose s'est bien produit en 2012 — 2013 , quelque chose qui a été rendu possible par l'apparition de plus en plus généralisée des APIs et des Web Services en 2004 — 2005.

Achevons la démonstration avec le terme «DevOps»:

Rebelote ! Même le Cloud suit la même tendance. D'ailleurs comment envisager son utilisation sans une kyrielle de services agencés en paquets fonctionnels.

La conclusion s'impose d'elle-même : à peu de choses près la mise au point d'APIs et le mouvement DevOps vont main dans la main ! Le premier a permis le second. On comprend dès lors à quel point le développement et l'utilisation d'APIs imprime la direction dans laquelle va l'informatique du jour.

Et malgré cette direction très marquée de très nombreuses organisations n'ont pas encore complètement embrassé le modèle. Il faut dire que si l'utilisation de services est entrée dans les habitudes des équipes de développement, la mise au point et la création d'ensembles de services ordonnés est affaire plus compliquée. Souvent plus compliquée que ce qu'on imagine. Une affaire dans laquelle s'imbriquent d'autres notions comme — exemples choisis — SOA (Service Oriented Architecture) et ESB (Enterprise Service Bus). Cette imbrication est à ce point forte que les notions ne vont plus l'une sans l'autre : ESB, une notion qui s'apparente à la mise en place d'une véritable colonne vertébrale digitale.

Les trois phases

La mise au point d'APIs, qui peuvent d'ailleurs faire appel à des services d'APIs externes, nécessite une réflexion en profondeur du métier de l'organisation, une sorte de dépeçage intellectuel. Vous ne faites plus appel à des "analystes" ! Vous faites appel à des "anatomistes" et "chirurgiens", des collaborateurs qui vont étudier en profondeur les détails de votre organisation. Tout comme en médecine vous avez des spécialistes du cœur, d'autres des poumons, du foie, etc. vous allez voir l'émergence de spécialités distinctes et, dès lors, d'APIs distincts également.

C'est furieusement intéressant de voir cela se produire au sein d'une organisation et, pour tout dire, cette marche en avant est un marqueur de maturité. Voyons cela avec un peu de hauteur.

Tout d'abord se fait sentir le besoin de mettre un API au point. Cela se fait dans l'enthousiasme et avec fougue. Quelques passionnés se lancent dans l'aventure. Ils sont remuants et ont besoin d'abattre des murs pour en construire d'autres. C'est un peu le temps des héros, une période que j'appelle celle des vaisseaux par référence au système sanguin : on découvre les interconnexions d'un vaste entremêlement.

Puis vient le temps où la création débridée doit être encadrée. C'est une période qui marque un autre degré de maturité et dont la difficulté essentielle n'est pas l'encadrement technique mais plutôt l'encadrement humain. C'est l'époque où les bouillonnants de la première heure peuvent se sentir dépossédés de leur création or … ils sont la force motrice du mouvement. La meilleure chose qui puisse se passer c'est que ce soient ces sémillants programmeurs qui érigent eux-mêmes les règles de l'encadrement nécessaire. J'appelle cette période celle du cÅ“ur par référence à la découpe en organes essentiels et à l'émergence de spécialités.

Enfin, vient la période de l'organisme. Elle fait donc suite aux periodes des vaisseaux et du cœur. Tout communique, aucun des organes n'est isolé. Chaque spécialité fait partie d'un grand tout et si chacune a son propre écosystème, l'organisme (entendez l'organisation) est elle-même un écosystème. C'est une nouvelle étape dans la maturité, une étape où on se rend compte que l'amélioration d'un écosystème isolé ne se traduit pas nécessairement par un progrès, par un avantage pour l'organisme dans sa globalité. C'est une autre de ces étapes essentielles qui est fortement liée à l'amplification naturelle de la complexité des systèmes. Toute complexité croissante est assortie d'un pendant économique. C'est le moment où les processus et les règles pour tout indispensables qu'ils soient représentent néanmoins un poids supplémentaire. La maîtrise bicéphale, tant donc économique que technique, caractérise cette période.

Tout ceci vous ne le verrez à l'œuvre que si l'organisation s'est lancée dans la création de son propre API ou ensemble d'APIs.

Besoins internes et besoins externes

Imaginons que vous ayez décidé de vous lancer dans la création et le maintien d'un API, voire même d'un ensemble d'APIs. Prenons ceci comme un fait acquis. Après être passé par les différentes phases décrites ci-avant, voire même pendant l'une des phases citées plus haut, il se pourrait que la question de servir des besoins externes se fasse sentir. Dans ce cas, vous ne vous contentez plus de servir une communauté de programmeurs internes à votre organisation mais vous décidez de satisfaire une communauté externe à votre organisation. Tout à coup vous entrez en confrontation avec des considérations totalement nouvelles, a ce point nouvelles d'ailleurs que ce qui était considéré comme acquis est chamboulé dans ses plus infimes détails : l'infrastructure physique, la sécurité, la publication de la documentation, les conditions de testing, etc.

Les besoins des développeurs externes ne sont pas nécessairement ceux des développeurs internes. Le besoin de rétrocompatibilité stricte de l'API mais également la nécessité d'adapter l'API pour les nouvelles fonctionnalités souhaitées par désormais les «clients» ont un coût non négligeable et peuvent impacter très sensiblement la vitesse du projet.

Tout à coup vous entrez en confrontation avec des considérations totalement nouvelles.