Une communauté de 120 000 membres, 36 événements sur 11 pays… en quelques années, API Days a réussi à fédérer les professionnels de l’IT autour des API et de l’interopérabilité des services. Le succès de la conférence API Days s’explique par le large spectre couvert par l’événement : des sujets techniques, des workshops, mais aussi de nombreux sujets sur le rôle des API (et des développeurs) dans l’évolution de notre société. 

La technologie et la politique sont connectées, comme nous allons le voir ci-dessous.

Slow Web

Le constat posé par Tariq Krim est plutôt sombre : le monde dans lequel nous vivons est un désastre, et la technologie en est la principale cause. Pourtant l’IT a le pouvoir de redéfinir l’architecture du monde, la politique et la culture, alors qu’attendons-nous pour reprendre le contrôle de nos vies numériques ? Second constat, un brin désabusé, l’Europe a inventé Linux et le Web (Tim Berners-Lee en 1989 au CERN), et pourtant aujourd’hui nous sommes dominés par ces technologies. A qui la faute? Certainement aux politiques qui dans les années 90 ont préféré investir dans le diesel propre plutôt que dans l’Internet. La technologie et la politique sont connectées.

Selon Tariq, nous subissons aujourd’hui la vision de la technologie imposée par les géants du Web, et il prend pour exemple la transparence (son absence), la manipulation (de nos humeurs ou opinions), ou de la vie privée. Il n’y a aucune transparence de nos actions sur nos réseaux sociaux : derrière un “like”, il y a de nombreux mécanismes qui s’enclenchent et des adaptations des algorithmes dont nous n’avons aucune idée. L’actualité récente (Cambridge Analytica) a montré comment la donnée pouvait être exploitée pour manipuler les opinions. Concernant la vie privée, pour Tarid Krim il faudrait changer complètement le paradigme. Sur les grandes plateformes, l’utilisateur n’a pas la possibilité de “couper les caméras”, de demander un moment privé qui ne sera pas analysé.

Que nous soyons des professionnels de l’IT ou des praticiens des API, nous avons le pouvoir de changer cela. Ne laissons pas les suprémacistes du digital faire en sorte que la technologie domine le monde : comme le souligne Tariq Krim, la technologie est politique et chaque technologie a un impact sur le monde, donc c’est aux professionnels de l’IT d’agir. Tariq Krim conclut ainsi la keynote : “Nous avons fait quelque chose d’incroyable en connectant les trois quarts de la planète, maintenant il faut s’assurer que les gens puissent bien vivre dans ce monde connecté”. Parmi les réponses possibles, le projet de Tariq Krim, Dissident.ai est une plateforme neutre d’accès aux contenus, qui vise à rendre les utilisateurs plus actifs de leurs expériences, à ralentir le rythme, et se libérer d’un monde dominé par l’IA et les algorithmes.

La culture  des API

Les API ne sont pas seulement un sujet technique : le succès de votre entreprise dépend de la culture de l’API que vous aurez réussi à mettre en place. Comme l’explique Laure Jouffre, API Program Director chez Orange, il faut expliquer les API, les promouvoir, et les améliorer. Pour diffuser cette culture, il faut aussi travailler avec les early adopters et partager les bonnes pratiques.

Ce sujet est également abordé par Pauline Pham, VP Growth & Strategy chez Five by Five. Son sujet “When talking about API, think culture first” vise à considérer les API comme des produits. Une API est à la fois un middleware, un outil qui permet aux logiciels de travailler ensemble, un outil créé par les géants du Web pour construire des écosystèmes autour de leurs services, et le hub de notre économie digitale. Mais si les API sont utilisées par les géants du Web, elles servent également à de nombreux autres acteurs.

Pourquoi l’API est-elle un produit ? L’API répond à une demande, où le client est le dévelopeur de l’application, elle a un prix et elle est marketée comme un produit. Elle permet de répondre à des challenges différents selon que l’on soit une startup, une entreprise SaaS ou une entreprise plus traditionnelle. Créer des API est encore un challenge, parce que même si les bonnes pratiques progressent, il n’y a pas vraiment de standard. Comme Laure Jouffre, Pauline Pham insiste sur la nécessité d’expliquer le fonctionnement de l’API pour embarquer tout le monde. Et pour réussir dans cette culture de l’API, Pauline Pham conseille plusieurs règles : réfléchir avant d’agir (voir la citation d’Albert Einstein : If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions), penser à la plateforme, à la monétisation du savoir-faire, et à la modularité des API, construites comme des briques de Lego.

Ensuite, on appliquera une méthodologie de design produit à l’API : benchmark, cas d’usages, personas, interviews utilisateurs, définition de la proposition de valeur et du business model… Pour devenir un produit, l’API doit être pensée pour être utilisée, et il est essentiel de faciliter la compréhension de son fonctionnement. Ceux qui vont l’utiliser ne connaissent peut-être pas votre vocabulaire, votre business, votre culture, et donc l’API doit être marketée, en interne comme en externe : si personne ne sait qu’elle existe, personne ne va l’utiliser. Enfin, Pauline Pham conseille de se réorganiser autour de cette nouvelle culture : définir l’équipe produit, définir le produit (nom de l’API, proposition de valeur, utilisateurs de l’API et marché, roadmap de l’API, fonctions clés), définir les métriques de mesure du succès (notoriété de la marque, extension du market reach, engagement consommateur, automatisation, baisse des coûts…), et enfin la documentation et les aspects légaux de l’API (exemples de code, CGU…).

Le bon, la brute et les bots

Il y a deux ans lors des API Days Paris, Mike Amundsen évoquait la place des robots dans notre société, les peurs qu’ils pouvaient susciter, et la réflexion que nous devions mener autour du sujet. Cette année, il aborde la question des robots sous l’angle des chatbots et du machine learning. En effet si les entreprises font déjà largement confiance aux chatbots (80% d’entre elles utilisent des chatbots ou vont le faire d’ici 2020), les utilisateurs ne sont pas encore convaincus et ils manifestent une certaine défiance à leur égard.

En 2013, Peter Noving, directeur de recherche Google, s’interrogeait la capacité d’amélioration de nos systèmes avec l’accès plus de données, et constatait que nous arrivions à un point où nous obtenions moins de bénéfices que par le passé. Pour pointer les limites de l’apprentissage et du machine learning, Mike Amundsen s’appuie sur plusieurs exemples, et notamment ELIZA en 1966, le premier chabot de l’histoire, conçu pour mimer le comportement d’un psychiatre, et PARRY en 1972, qui reproduisait le comportement d’un paranoïaque. En 1972, Eliza et Parry ont eu une discussion, qui commence ainsi :

• ELIZA: Good Evening. Tell me your problems. Please terminate input with a period or a question mark.

• PARRY: People get on my nerves sometimes.

• ELIZA: I am not sure I understand you fully.

• PARRY: You should pay more attention.

• ELIZA: Suppose you should pay more attention.

• PARRY: You’re entitled to your own opinion.

La suite de cette discussion est accessible ici. A travers cet exemple, Mike Amundsen veut souligner le danger de concevoir des bots qui réagissent aux stimuli négatifs. Plus récemment, Microsoft en a fait les frais avec Tay, une IA qui publié 96 000 tweets en 8 heures avant d’être mise hors ligne définitivement. Grâce au machine learning, Tay devait apprendre de ses interactions sur les réseaux sociaux, mais l’expérience a mal tourné. Pour Mike Amundsen, le problème avec les bots actuels et l’IA en général c’est que les algorithmes sont susceptibles de contenir des biais. Par exemple, des biais latents (corrélation d’idées avec le genre, la race, le revenu…), de sélection (sur-représentation d’une population, par exemple sur Google Images), ou des biais d’interaction (comme dans le cas de Tay, où les utilisateurs ont amené des biais par leurs interactions). 

Outre la question des algorithmes et leur gestion des biais, Mike Amundsen propose plusieurs recommandations pour les chatbots du futur : une identification claire (l’utilisateur devrait toujours savoir qu’il parle avec une IA, ce que Google n’a pas fait dans sa démo de prise de rendez-vous), les IA devraient opérer sous licence officielle d’une entreprise, et fournir des garanties de protection des données. Enfin, il recommande de créer des IA qui soient focus sur des micro-mondes (Taks Focused Microworlds), qui n’aient pas besoin d’apprendre, et qu’il sera plus facile de faire passer à l’échelle.

L’impact de la décentralisation sur les API

A l’instar de Tarq Krim, Ruben Verborgh tire la sonnette d’alarme. L’innovation sur le Web est menacée par des business models centrés sur la collecte de données. Il se fait ainsi l’avocat d’un nouvel écosystème, Solid, où les données sont séparées des applications. Cela aura un impact sur la façon dont sont construites les API et les clients, puisque dans ce système l’utilisateur est propriétaire de ses données, qu’il partage ensuite avec les gens et les applications de son choix.

Si le Web s’est construit sur la notion d’universalité, celle-ci a été régulièrement menacée : l’innovation technique a dépendu du choix du navigateur Web, la portée de l’innovation dépend d’un moteur de recherche, et des données contrôlées par une seule plateforme. Aujourd’hui la centralisation est massive, et elle porte préjudice à la diversité, à l’innovation et au choix. Par exemple, à défaut de ressources suffisantes pour développer l’intégration de plusieurs API, on se contentera de l’intégration de l’API Facebook. De fait les API et leurs développeurs sont dépendants des plateformes centralisées, à moins qu’ils ne développent leur propre plateforme. Quant aux utilisateurs, ils perdent la propriété et le contrôle de leurs données.

Ruben Verborgh préconise de repenser le rapport entre les applications et les données, et présente Solid, un écosystème décentralisé développé au MIT, dont l’objectif est de rendre la propriété des données aux utilisateurs et d’offrir une meilleure protection de la vie privée. Solid propose ainsi aux utilisateurs de choisir où stocker chacune de leurs données, et ensuite d’autoriser les applications à accéder à des parties spécifiques de ces données. Pour ce faire, Solid s’appuie sur les standards du Web (HTTP, URL…), cependant l’approche actuelle des API est assez peu adaptée à la décentralisation. Ruben Verborgh appelle donc à développer les API en mode bottom up plutôt que top down. Pour plus de détails, les slides de Ruben sont disponibles ici, ou vous pouvez consulter son article sur le Web décentralisé.

Planning des formations AWS 2019