API ouverte vs API fermée : au-delà du manichéisme
Dans la première partie et la seconde partie de cette série sur les APIs, nous avons vu : ce qu’était une API, les différents types d’APIs et leur histoire.
De l’essor des APIs web est née la polarisation entre API ouverte et API fermée. Les APIs ouvertes sont souvent représentées comme le saint Graal de toute start-up se respectant. Les APIs fermées, comme l’expression d’un capitalisme de bon aloi, ennemi de l’innovation.
Et si toutes deux n’étaient pas destinées à se regarder indéfiniment en chien de faïence ? Levons le voile !
Nous l’avons dit, le terme même d’API est aujourd’hui synonyme — par un abus de langage — d’ouverture à un écosystème. Les APIs fermées sont aujourd’hui considérées comme suspicieuses. Le champ lexical entourant les restrictions d’accès aux APIs sont révélateurs :
“Quelques fournisseurs ont cependant récemment durci les conditions d’accès à leurs API, réduisant ainsi l’accès aux services et aux données d’une application ou d’un service. Netflix a ainsi bloqué son API publique en novembre, préférant réserver les informations sur ses utilisateurs à un petit nombre de partenaires.” Source
Mais concrètement, quelles sont leurs possibilités respectives pour les entreprises et les ponts entre ces deux approches.
APIs fermées : quels usages ?
Les APIs fermées permettent le partage de données et/ou de fonctionnalités internes à une entreprise ou des développeurs (internes ou prestataires). Les applications développées par ces développeurs sont alors à usage interne et n’exposent l’ensemble de la base de données ni aux usagers, ni au grand public.
Les APIs fermées permettent à des entreprises et des collectivités de centraliser et interopérabiliser les données nécessaires à leur bon fonctionnement. Une étude McKinsey de 2012 montre que l’échange facilité d’informations au sein d’une organisation peut augmenter sa productivité de plus de 25%. Une API fermée permet à une organisation de conserver la main sur ses données et ses informations partagées.
Une API fermée permet aux équipes de développeurs d’une entreprise de réduire le temps de développement et les ressources IT pour s’interfacer avec une SI (système d’information) interne. Il devient alors possible de se concentrer plus rapidement sur le développement d’un design de service basé sur les ressources exposées en interne par l’API.
Par exemple, le service de réservation de billets de train Captain Train centralise les données d’une douzaine de transporteurs (filiales comprises) qu’il agrège en plusieurs APIs internes. Ce qui apparaît aux yeux de l’utilisateur final (dans ce cas, différent du consommateur de l’API qui sera l’algorithme de recherche) est le design de service : une interface graphique, une expérience utilisateur et une sélection de résultats.
Une API fermée peut également être un excellent bac-à-sable dans lequel déployer ses premiers essais. Les données échangées via une API peuvent être de nature sensible : données personnelles, données protégées par le secret industriel, données bancaires… Une API développée dans un environnement clos permet d’identifier et traiter en amont les problèmes potentiels de sécurité. Dans ce cas, l’ouverture de l’API devient une itération prévue dès l’amorçage du projet.
APIs ouvertes : vers la fin de la pression sociale
La volonté ou la nécessité d’ouvrir une API au grand public trouve ses fondements dans de multiples causes. Brossons-en les grandes lignes.
👉 Une entreprise peut décider d’ouvrir ses APIs pour pénétrer et capter un marché d’utilisateurs.
En favorisant l’interfaçage à son service, une entreprise comme Slack (le logiciel de messagerie) a dans un même mouvement :
- Encouragé l’intégration de services tiers par des développeurs attirés par la large base d’utilisateurs,
- Capté plus d’utilisateurs attirés par l’intégration de nombreux services tiers.
Lorsque Facebook développe le Facebook Connect reposant sur sa Graph API, l’entreprise permet à des millions d’utilisateurs de se connecter à des applications tierces en deux clics. Le Facebook Connect réduit la friction pour les utilisateurs, favorisant l’expérience de création de compte et de connexion. Dans un même temps, Facebook s’impose rapidement comme une brique technologique essentielle pour l’écosystème technique, dépassant les strictes limites attendues d’une plate-forme d’interaction sociale.
Nous voici bien loin de l’idéalisme de l’Open Innovation.
👉 Le cadre législatif français est également le vecteur de profond changement dans le partage des données publiques.
De la loi CADA (liberté d’accès aux documents administratifs publics) à la loi NOTRe, les collectivités et administrations publiques sont encouragées à ouvrir leurs données. Certaines partagent déjà des données financières, de transport, de ressources humaines… Citons les exemples de la ville de Paris, d’Issy-les-Moulineaux ou encore de Toulouse. Notons que les entreprises publiques font également preuve de volontarisme dans la démarche Open Data.
Autre acteur majeur de l’Open Data en France, le groupe SNCF souhaite :
“Faire de l’ouverture des données un accélérateur d’innovation au service de la mobilité de tous”
Grâce au transport quotidien de 10 millions de voyageurs, le groupe SNCF collecte et partage de nombreuses données : horaires planifiés et temps réel, équipements et services en gare, régularité des trains, accessibilité des gares, etc.
L’Open Data et les API proposés sur data.sncf.com constituent un vecteur d’innovation sur les nouveaux challenges de la mobilité : cheminement, optimisation et valorisation du temps de voyage, gestion de l’affluence dans les trains, adaptation aux besoins de chaque voyageur.
Une API ouverte peut également naître d’un changement de paradigme « données = valeur pécuniaire » vers le paradigme « service bâti sur les données = valeur pécuniaire ».
Parallèlement aux fins proclamées de l’Open Innovation et de l’innovation washing, nous observons l’émergence d’une tendance remettant en cause la valeur pécuniaire des seules données. Si les entreprises ont longuement jalousé l’exploitation de leurs données, certaines start-ups privilégient la qualité du service.
levels.io, créateur de Nomadlist résume parfaitement cette pensée sur Twitter :
Vers le développement API-first
Cette première introduction aux APIs ne saurait se conclure sans une mention du développement API-first.
Des nombreux exemples que nous avons pu aborder dans notre historique des APIs, nombreux sont ceux à avoir proposé une ou des APIs a posteriori. Comme le souligne Mark Headd — Developer Evangelist pour Accela :
“Websites often retrofit an API (application program interface) after deployment. The API may or may not be in response to scraping by those seeking data from the website.” Source
La démarche API-first tend à inverser ce positionnement stratégique. Les entreprises API-first se libèrent d’un développement device agnostic en focalisant leurs efforts sur l’accessibilité d’un point d’entrée aux données et/ou aux fonctionnalités d’un service.
Design et expérience utilisateur ne sont dès lors plus le principal levier d’adoption d’un service. Sa consommation et son interfaçage avec d’autres services le deviennent.
“I end up delivering solutions to my clients that are far less complex to implement, are much easier to maintain, cost exponentially less to serve, work on multiple browsers and devices, […] and — of course — are accessible to everyone … everyone … using the Web today. And try to argue with the business value of that.” Source
Voilà, vous savez (presque) tout. Une API ouverte n’est pas nécessairement une bonne API. Une API fermée n’est pas forcément une mauvaise API.
La prochaine fois que vous lirez un article gourmant une entreprise pour son API fermée, vous saurez poser les bonnes questions :
- comment cette API structure-t-elle le service de cette entreprise ?
- quelles sont les problématiques de sécurité liées aux données partagées via cette API ?
- quels bénéfices stratégiques pourraient apporter l’ouverture d’une API ?
C’est en sortant de l’idéalisme que nous pourrons vraiment comprendre comment les APIs structurent l’offre des start-ups.
Cet article vous a été utile ? Aidez les autres à comprendre les APIs en cliquant le ❤.
Cette série d’articles est une adaptation de mon mémoire de Master 2 Management et Entrepreneuriat de Projets Numériques (oui, tout ça). Vous voulez en recevoir le texte intégral ? Envoyez-moi votre email via LinkedIn.
Des feedbacks, une coquille repérée, des erreurs à corriger ? Pinguez-moi sur Twitter.
