SOAP, API REST, GraphQL, CMS Headless et j’en passe. On pourrait se mettre à croire que les tech inventent des acronymes compliqués juste pour nous embrouiller l’esprit. Entretenir ce mystère autour des mots ou des acronymes. Tout cela afin de nous faire croire qu’il s’y cachent une quelconque difficulté monstrueuse.
Loin de moi l’idée de réduire la complexité associée aux sujets techniques. J’ai moi-même été du coté tech en tant que développeur durant de nombreuses années avant de m’orienter coté produit en tant que PO/PM, et maintenant sur du coaching produit. En revanche, bien comprendre ce qui ce cache derrière tout cela, peut réellement vous aider à comprendre que la complexité n’est pas toujours la où on le pense. Même si l’on travaille de concert avec une équipe de développement et/ou un ou plusieurs tech lead, avoir une bonne compréhension technique du produit sur lequel on intervient en tant que PO ou PM est importante afin de pouvoir prendre les bonnes décisions.
Cet acronyme “API” fait actuellement partie des mots les plus couramment utilisés dans le développement de produits digitaux. Il est souvent associé à tord à cette équipe back-end dont on ne sait pas trop ce qu’elle fait et qui est chargée de réaliser des choses très techniques. Mais il est essentiel de comprendre pourquoi cet acronyme “API” est si présent aujourd’hui. Notamment si l’on souhaite comprendre les enjeux qui s’y dégagent. Et pour cela, rien de mieux qu’un peu d’histoire, alors remontons dans le temps pour un rapide résumé.
Un peu d’histoire : Le monde d’avant
Il faut savoir que jusque dans les années 2000, il n’existait pas de norme commune pour créer une API (Application Programming Interface). Une API est une interface logicielle qui permet d’échanger de la donnée suivant un ensemble de définitions et de protocoles.
RPC (Remote Procedure Call) ou encore SOAP (Simple Object Access Protocol) sont alors les protocoles les plus utilisés à l’époque. Un protocole informatique, c’est un ensemble de règles qui permettent de définir la manière de formaliser et d’échanger des données. Les premières versions du protocole RPC sont apparues dès les années 60 de manière théorique. Elles ont ensuite été implémentées au début des années 80. D’abords présenté sous le nom de XML-RPC, SOAP est lui arrivé bien plus tard en 1998.
On pourrait donc se poser la question suivante. Pourquoi ces protocoles, permettant de faire des API aujourd’hui, n’ont-ils pas fait autant parlé d’eux avant les années 2000 ?
En fait, elles ont fait couler pas mal d’encre à l’époque. Mais avec une portée toutefois limitée à un public de connaisseurs. Ces protocoles, bien que ultra-sécuritaire étaient plutôt complexes à mettre en place et à maintenir. De plus, l’informatique n’était pas aussi bien distribué et ouvert qu’aujourd’hui. Les cas d’usages étaient aussi différents à cette époque. C’est entre autre pour tout cela, que ces protocoles n’ont pas permis de favoriser une émergence notable et à grande échelle des API auprès du grand public.
Les API aujourd’hui: HTTP le leader
Actuellement, lorsque l’on parle d’API, on pense surtout Web Services. Pour cela, on peut grandement remercier REST (Representational State Tranfer). Présenté au début des années 2000, il s’agit d’une norme et non d’un nouveau protocole. Celui-ci permet de définir un ensemble de principes et de contraintes. Il s’appuie cette fois-ci sur un autre protocole bien connu de tous : le HTTP (Hypertext Transfer Protocol).
Le protocole HTTP est considéré comme étant plus souple et moins contraignant que les protocoles SOAP et RPC. En l’additionnant à la norme REST, ils vont marquer une révolution et un tournant majeur pour le monde des API. Facile à prendre en main, cette norme sera rapidement adoptée. Elle fera du HTTP, le protocole le plus utilisé encore aujourd’hui afin de créer des API.
Mais concrètement, que permet de faire REST vous me direz ? La réponse réside un peu dans son acronyme. Une API REST, ou REST comme on aime le dire, permet d’échanger simplement toutes sortes de données. Ce sont d’ailleurs ses multiples possibilités d’implémentations et d’applications dans le monde actuel qui en font sa force.
Les types d’API
On peux distinguer 4 principaux type d’API aujourd’hui:
- Les API internes ou privées. Elles sont principalement destinées à un usage interne à l’organisation afin de faciliter la collaboration et la productivité. Les organisations peuvent formater la manière de partager leurs données notamment dans le but d’interconnecter leurs applications.
- Les API publiques ou ouvertes. Ces API sont les plus connues du grand public. Et pour cause, elles sont accessibles à tous, utilisateurs lambda, développeurs ou organisations externes. Elles présentent certaines restriction légères notamment au niveau de l’authentification et des conditions d’utilisations. Elles facilitent l’accès à des données ou services d’une organisation.
- Les API partenaires sont destinées à des développeurs et organisations externes. Entre autre, elles facilitent grandement la mise en place et l’interconnection entre les organisations. Elles sont souvent très restrictives et contraintes par des droits d’utilisation, des licences et des mécanismes d’authentification fort. Elles sont particulièrement présentes dans les marchés B2B.
- Les API composites servent à traiter des informations complexes en consommant et regroupant deux ou plusieurs interfaces. Elles sont considérées comme étant rapides et performantes. Elles sont souvent utilisées dans des architectures micro-services afin de regrouper plusieurs points de terminaison.
MICROSOFT, SALEFORCES, EBAY ET AMAZON: LES PRÉCURSEURS
Les entreprises qui ont ouverts cette voie à l’émergence des API sont encore considérées pour certaines comme des précurseurs dans toutes sortes de domaines et d’applications du numérique. En s’appuyant et développant des modèles d’affaire autour des API, elles ont connu une forte croissance et font d’ailleurs aujourd’hui parties des géants du numérique.
Contrairement aux idées reçues, les API ne se limitent pas seulement au domaine du Web. L’émergence des API au yeux du grand public est arrivée avec le Web et les Web Services, cependant, on retrouve des API dans tous les domaines du numérique comme le logiciel ou encore le réseau.
Le monde du logiciel: Microsoft
Dès le début des années 85, Microsoft a su tirer son épingle du jeu en fournissant une API pour son système d’exploitation aux développeurs du monde entier. WinAPI offrait un ensemble de fonctions et bibliothèques logicielles de façon simple et natif. Permettant ainsi à Microsoft de se constituer, et ce dès les premières versions de Windows, un catalogue d’applications considérable. C’est le nombre croissant d’applications disponibles qui va notamment augmenter la désidérabilité de Windows aux yeux du grand public. Son système d’exploitation est encore aujourd’hui le plus utilisé au monde sur PC.
Le monde du Web : Saleforces et Ebay
Saleforces puis Ebay sont encore d’autres succès de l’emmergence des API au début des années 2000. En créant la toute première solution SAAS (Software as a service), Saleforces ouvre alors l’accès à une solution complètement décorélée de la machine de l’utilisateur en leur permettant grâce à ses API de partager et synchroniser des données à travers plusieurs applications. Ebay lui, mise alors sur la mise en place d’API selon des domaines fonctionnels. La sortie de ses API, dont l’eBay Shopping API marque d’ailleurs la croissance d’eBay dans le monde, et ce grâce aux intégrations de son API d’achat et de vente sur de nombreux sites externes.
Le monde de l’Infrastructure et du réseau: Amazon
Des success story comme celles-ci, il en existe beaucoup. Alors je vais terminer sur un grand nom de l’infrastructure et du réseau qui n’en était pas un à ses débuts, à savoir Amazon. À l’origine, une librairie, il est l’instigateur de l’IAAS pour Infrastructure as a service. C’est en Mars 2006 que la société propose un service hébergé de stockage de données avec son API, Amazon S3. Suivi en Aout 2006 d’un nouveau service de serveurs virtuels hébergés, Amazon EC2. Amazon est aujourd’hui l’un des acteurs incontournables du monde des Web Services commandés par API.
API, les enjeux d’aujourd’hui: Le monde du Produit
L’intensification et l’utilisation massive des terminaux mobiles ont totalement redistribués les cartes. Il en est d’ailleurs de même concernant l’interconnexion des organisations dû à l’accroissement des marchés B2B. Développer des programmes informatique n’est plus l’affaire d’un groupe restreint, d’une niche d’experts et d’initiés. On retrouve de nombreux développeurs de tous âges et de toutes origines à travers le monde. Et cela continuera d’accroître avec le temps car le monde de demain continuera de s’appuyer de plus en plus sur le numérique, son développement et ses nombreuses applications.
Contrairement à ce qu’on pense, l’enjeu n’est plus de savoir comment créer une API, ou comment développer un modèle d’affaire autour des API. Dans ce nouveau monde ultra connecté, les organisations qui souhaitent s’en sortir ont déjà pris conscience de l’importance des API pour évoluer et gagner de nouveaux marchés.
Il faut travailler les API comme étant un produit à part entière.
En revanche, il reste encore un gap à combler sur la partie product management. Les organisations ont encore du mal à considérer et développer leurs API comme un produit, et non un pan fonctionnel et/ou service additionnel. C’est le nouvel enjeu majeur d’aujourd’hui, il faut travailler les API comme étant un produit à part entière.
Le produit API
Faire de son API un produit passe notamment par la mise en place d’une vision produit forte, visible et soutenu par toute l’organisation. Ou encore la mise à disposition d’une équipe produit auto-gérée et cross-fonctionnelle entièrement dédié à ce produit API.
A l’heure de l’utilisation du numérique cross-plateforme, apporter de la cohérence en unifiant les services proposé aux travers des API est indispensable. La facturation à l’usage et celui du partage des revenus sont les modèles économiques souvent appliqués aux API. Avoir une équipe produit centrée utilisateurs permet d’engager les organisations dans un processus produit et de créations de valeurs afin d’obtenir un produit API utile et consommé. C’est en définitive ce qui permettra aux organisations de gagner une stabilité et une croissance économique certaine au travers de ces API.
Lorsque l’on parle produit, il y a toujours beaucoup à faire, mais il faut surtout et toujours penser à la satisfaction des utilisateurs finaux. Mais dans le monde des API, il y a un utilisateur auquel on ne pense que peu, et travailler son API comme un produit, pourrait grandement vous aider à combler ses besoins au travers de la DX (Developer eXperience).
La Développeur Expérience (DX)
Hormis quelques organisations qui capitalisent réellement leurs modèles d’affaires à travers les API, peu comprennent qu’une bonne gestion d’un produit API passe à la fois par la satisfaction des utilisateurs et par une bonne gestion de la qualité des API qu’ils fournissent.
Les développeurs sont souvent les grands oubliés dans cette course aux API. Pourtant ce sont eux les premiers utilisateurs qui vont consommer et se charger d’implémenter vos API. Sachez-le, une API consommée et partagée, est une API qui outre de répondre aux besoins, séduit avant tout les développeurs qui devront la consommer.
Plus une API offrira une bonne DX et plus celle-ci aura de chance d’être consommée et partagée.
Pour cela, on parle de DX (Developer eXperience), équivalent de l’UX (User eXperience), mais dont le persona principal est un développeur. La DX est tout aussi importante que l’UX, voir plus lorsque l’on travaille sur des API. Plus une API offrira une bonne DX et plus celle-ci aura de chance d’être consommée et partagée.
J’imagine que vous vous demandez sûrement comment se traduit une bonne DX ? Il y a plusieurs aspects à prendre en compte et cela pourrait faire l’objet d’un prochain article. Je vous invite d’ailleurs, à vous informer sur le sujet. Ce que je peux vous dire en revanche, c’est de vous attarder a minima à réaliser et fournir une bonne documentation avec vos API. Vous aurez alors de fortes chances de réussir à améliorer votre Developer eXperience.
API, les enjeux de demain: Etre ECO-durable
Une fois les enjeux d’aujourd’hui comblés, il reste encore à s’attarder sur les enjeux de demain. Et ils sont plutôt nombreux car tout reste à faire et/ou même à imaginer. En revanche, certaines lignes se dessinent déjà comme l’éco-conception, l’IOT (Internet of Things) avec l’avènement de la 5G et la maturité du protocole WebSocket.
L’IOT représente tous les objets pouvant se connecter à internet comme des capteurs et autres technologies qui transmettent et reçoivent des données. On la retrouve particulièrement dans le monde de la domotique et de l’automatisation.
L’arrivée de la 5G est entrain de redéfinir les usages du numérique d’aujourd’hui. Cela passe notamment par une intensification des usages de l’IOT et l’utilisation du protocole WebSocket. Apparu en 2011, c’est un protocole qui contrairement au HTTP, facilite des échanges de petites données de façon bi-directionnelle.
En s’appuyant sur la 5G, l’IOT permet d’offrir et de créer encore plus de services aux utilisateurs. Il a un vecteur fort en matière d’échange et de création de données. Et c’est en ce sens qu’il représente un des nombreux enjeux pour les API de demain.
Mais il n’est pas le seul. A l’heure où l’on parle de changement climatique, il ne faut pas oublier que l’informatique a aussi une grande part de responsabilité. Les principes d’éco-conception font parti des enjeux de demain afin de pouvoir offrir des services numérique écologique et durables. Pour cela, il faut mettre en place dès aujourd’hui une vrai démarche d’éco-conception au sein des produits API.
Conclusion
Afin de pouvoir combler les enjeux d’aujourd’hui et de demain, il est impératif de faire entrer le développement des API dans une démarche produit. Avoir une bonne DX est tout aussi importante, voir plus lorsque l’on développe des API qu’une bonne UX.
Avec la prise de conscience des changements climatiques et de l’impact du domaine informatique, l’Union Européenne ainsi que plusieurs gouvernements commencent progressivement à mettre en place des mesures en ce sens. Infuser dès le début les principes d’éco-conception au sein des API n’est plus seulement un challenge mais un objectif pour être durable.
D’autres articles suivront si vous souhaitez approfondir le sujet du management produit des API. J’y aborderai une thématique pour vous aider à voir votre API comme un produit, ou encore quelles sont les mesures de succès d’une API et même ce qu’est selon moi une bonne API. N’hésitez pas à me faire vos retours sur cet article, notamment sur ce que vous comprenez vous des API et de leurs nombreux enjeux.
Agilement vôtre,
Transparence, Inspection, Adaptation,
Jonathan
