« Avoir son application ne suffit plus, il faut pouvoir entrer dans celles des autres »

Jean-Charles Quantin : Une API est une interface de programmation d’application. Elle permet à des entités de communiquer entre elles par un moyen technique commun, clair et standardisé. Des fournisseurs peuvent donc ainsi exposer des services, qui seront consommés par des tiers. Elles existent depuis longtemps en informatique, mais désormais, c’est le web qui devient l’interface. La récupération des données horaires des trains est typique de ce que l’on peut faire à travers une API SNCF. C’est un cas de consultation pur, mais on peut imaginer d’autres services où l’interaction est plus forte.

J-C.Q : Ce qui a énormément changé depuis trois ou quatre ans, c’est le management de ces APIs. On voit émerger des solutions services logicielles ou cloud, qui permettent de mieux comprendre les consommations des uns et des autres et donc de mieux gérer les interfaces. Mieux gérer, c’est par exemple savoir qui a accès à quoi, en quelle quantité, ou encore s’assurer qu’un utilisateur ne dépasse pas sa souscription. L’API est un objet technique d’informaticien, qui sort désormais de cette sphère pour entrer dans le domaine de la com’ et du marketing, afin d’adresser finalement de nouveaux business. C’est devenu un produit digital commercialisable. Chez SNCF de nombreuses APIs sont déjà prêtes. Elles ne sont pas encore mises sur le marché pour des raisons règlementaires, mais on sait que demain, il y aura du business autour d’elles, véritables portes d’accès aux services SNCF. C’est ce qu’a déjà fait Uber avec TripAdvisor par exemple. Lorsque vous vous connectez à l’application touristique, une petite puce de la startup de VTC apparaît et vous permet de commander directement un véhicule pour vous rendre à votre restaurant préféré ou en repartir. Si Uber a pu faire cela, c’est par ce qu’ils ont eu la possibilité d’exposer des APIs à TripAdvisor. C’est la finalité désormais. Les entreprises capitalisaient sur le « mobile first ». Elles passent désormais à « l’API first ». Avoir son application ne suffit plus, il faut pouvoir « entrer » dans celles des autres et ce sont les APIs qui permettent de le faire. Elles effacent beaucoup d’alternatives technologiques, tout simplement parce qu’elles sont universelles.

J-C.Q : Deux démarches ont vu le jour en parallèle chez SNCF. La première suit celle de la stratégie open data, qui a amené à de l’open API. On a depuis quelques années une API SNCF ouverte à l’externe et utilisée par de nombreux partenaires pour innover ou créer de nouveaux services. Un franc succès piloté par Romain Lalanne, directeur de la Fab open innovation. La seconde démarche vient des SI, et de cette idée que technologiquement, l’interopérabilité du SI envers lui-même, entre une application A et une autre B, avait grandement à gagner en se tournant vers la solution API. Une « APIsation » des applicatifs a donc débuté afin de faciliter les interactions. Aujourd’hui, on décline cette stratégie et on fournit une plateforme d’API management, pour exposer les différents outils et en faire la gestion.

J-C.Q : L’un des objectifs majeurs est la transformation numérique du groupe, qui ne peut atteindre un palier supplémentaire sans socle API. L’urgence est donc « d’APIfier » le SI, et d’exposer ces outils et services afin de se digitaliser. Une fois cette révolution menée à bien, un deuxième enjeu se dessine : notre ouverture à l’externe et la création de nouveaux produits digitaux qui viendront compléter l’offre d’open API déjà existante. Il faudra que l’on soit à même de fournir plus de matière à l’équipe de Romain Lalanne dont je parlais un peu plus tôt, mais aussi de leur clarifier l’origine des sources des données officielles. Un exemple concret d’avant/après : quand une application avait besoin d’une source de datas, le travail pour remonter l’information était énorme. Une fois les données en sa possession, il fallait adresser beaucoup de sujets techniques différents pour les traiter, les analyser et pouvoir en faire l’usage souhaité. Désormais, en cartographiant toutes les données SI dans un référentiel ouvert en interne, on officialise une pratique essentielle à l’innovation et à l’agilité qu’est le « self-service ». L’entité qui fournit de la data ou des services propose une API dont les clients peuvent disposer de manière autonome.

J-C.Q : Cette démarche nous force déjà à nous concentrer sur notre gouvernance de données. On ne peut pas faire n’importe quoi. Il y a des droits et des devoirs, comme la protection des données personnelles. Il y a donc des contraintes règlementaires, de sécurité et de protection, mais aussi d’ouverture et de transparence, notamment sur les données qui doivent être complètement publiques. Des obligations propres à l’open data, mais qui s’appliquent également à l’open API.

J-C.Q : Une bonne API doit être « affordante ». Un terme qui nous vient du design et qui définit la capacité d’un objet à s’autodécrire sans devoir utiliser des kilomètres de documentation. Ce qui est le cas d’une poignée de porte par exemple. Elle doit être intuitive. Les GAFA, champions des APIs, ont fait du délai entre la découverte de l’outil par un développeur et les premiers tests qu’il va mener, leur cheval de bataille. Et ce laps de temps est aujourd’hui réduit à quelques minutes seulement ! C’est notre objectif. Cela induit donc une description courte, claire, nette et précise du service. Il est également fondamental de respecter une certaine philosophie qui se cache derrière les APIs, afin de retrouver en chacune une homogénéité et une cohérence.