Quand on a un marteau, tous les problèmes ressemblent à des clous
Les APIs sont les chevilles ouvrières du Web. Afin de ne pas transformer ce dernier en un épouvantable bazar, mais au contraire de construire ensemble une magnifique cathédrale, il convient d’exceller dans l’art de leur développement. C’est à ce propos qu’Arnaud Lauret, l’auteur du livre The Design of Web APIs, a bien voulu répondre à nos questions.
Bonjour Arnaud Lauret, pourquoi avoir écrit ce livre… maintenant ?
Arnaud Lauret : Les APIs Web, ou plus simplement APIs, sont ces interfaces de programmation qui permettent à des briques logicielles de communiquer entre elles. A la base, j’ai très prosaïquement commencé à écrire The Design of Web APIs pour permettre aux autres de designer de bonnes API en évitant tous les écueils et en connaissant tout de suite les principes et les astuces que l’on découvre et maîtrise au fur et à mesure d’années de pratique. Mais le sujet API a une portée bien plus grande.
Les APIs sont partout. Sans elles, notre monde qui dépend de l’informatique et d’internet, ne fonctionnerait tout simplement pas. Après avoir été pendant longtemps de petits rouages cachés dans les tréfonds de la cale du vaisseau IT, elles sont devenues des pièces maîtresses de la stratégie IT mais aussi business.
Les experts en API, et moi le premier, promettent monts et merveilles. Pour l’IT, les APIs rendent les systèmes simples, flexibles et réutilisables à l’infini pour répondre aux besoins en des temps records. Pour le business, les APIs permettent d’enrichir rapidement son offre avec des APIs fournies par des tiers et/ou ouvrir de nouveaux canaux de distribution ou d’acquisition voir d’accéder à de tout nouveaux marchés en fournissant ses services ou de tout nouveaux services sous forme d’API.
Mais toutes ces promesses ne se réaliseront que si, et seulement si, le design des dites APIs est effectivement bon. A petite échelle, une bonne API permettra de revoir son funnel de souscription web pour obtenir un meilleur taux de conversion ou de s’intégrer facilement avec un ou douze partenaires, le tout à moindre coût et avec un time to market réduit. A grande échelle, une vision API poussée à l’extrême a donné de grandes réussites comme Amazon, Stripe ou Twilio. A l’opposé, je connais quelques entreprises qui se sont mordus les doigts à cause de coûts d’intégration pharaonique ou encore d’avoir perdu des appels d’offres tout simplement car leurs APIs n’étaient pas au niveau.
Le design d’API a donc un impact majeur sur l’IT et le business. Donc, après coup, je pourrai dire que j’ai écrit ce livre pour permettre aux entreprises de pouvoir capitaliser sur des bases solides afin de construire une vraie stratégie API IT et/ou business et éviter de sombrer dans la dernière ligne droite à cause d’un design hasardeux qui aurait pu être évité (c’est plus vendeur!).
Une page de votre livre, ou un passage, qui vous représente le mieux ?
A.L. : Les designers d’API ont beaucoup à apprendre de la conception des interfaces utilisateur des objets de tous les jours. Qu’il s’agisse d’interfaces physiques (portes, appareils électro-ménagers ou télécommandes de télévision) ou d’interfaces virtuelles (sites Web ou applications mobiles), toutes partagent des principes de conception communs qui doivent également être appliqués design d’API. Le choix du bon point de vue, de la bonne perspective, est l’un des aspects les plus cruciaux de la conception pour toutes ces interfaces et pour les API.
Concentrez-vous sur ce qui se passe sous le capot et cela se terminera par un désastre total. Concentrez-vous sur ce que les utilisateurs peuvent faire et tout se passera bien.
Lors de la conception d’API, séparer ces deux perspectives et les comprendre n’est pas toujours facile au début. Mais transposé dans le monde réel, tout cela devient évident, et la façon dont ces deux perspectives peuvent affecter la conception des API devient plus facile à saisir.
Les tendances qui émergent à peine et auxquelles vous croyez le plus ?
A.L. : L’UX en interne et à tous les étages. Je suis toujours stupéfait par la capacité que nous avons, collectivement en entreprise, pour choisir/designer/créer/mettre en œuvre les solutions proposant l’expérience utilisateur la plus désastreuse possible quand les utilisateurs sont internes. Quel employé n’a jamais pesté contre l’ergonomie de l’outil de suivi de congés ou de gestion des demandes? Quel ops, n’a pas pesté contre une architecture se composant de 267 microservices utilisant 67 technologies différentes, certaines encore au stade alpha incompatible avec un run en production. Quel dev n’a pas râlé en essayant de lancer une application sur son poste avant sa modification car le repository de code ne contient aucune explication, aucune aide pour aider à démarrer.
Tant d’économies en numéraire mais aussi en temps ou tout simplement en stress pourraient être faites si on portait autant d’attention à l’expérience des employés, de nos collègues qu’à celle des sacro-saint clients. De mon point de vue IT, travailler sur les APIs et la fameuse DX (l’expérience développeur), m’a permis de prendre conscience de cela et de toujours faire attention à ce que je construis: tout doit être facilement compréhensible, utilisable, déployable et maintenable dans le durée; et que l’on parle d’un simple outil pour analyse un design d’API en ligne de commande, une implémentation d’API ou une architecture plus complète. Mettre un petit peu d’empathie dans ce qu’on fait a de gros effets.
Si vous deviez donner un seul conseil à un lecteur de cet article, quel serait-il ?
A.L. : Un conseil d’architecte IT mais qui vaut pour tout. La réponse à toutes les questions de l’univers n’est pas 42, mais “ça dépend”. Il faut toujours bien revenir sur le besoin, le contexte et les contraintes avant de choisir une solution et d’évaluer ses conséquences en toute objectivité.
Et dans la tech, où beaucoup pense “ce que je fait est mieux”, “ce que font les autres (ou notre ancien moi d’il y a 2 ans) est de la m****” ou “si <la startup du moment> fait ça, on doit le faire”, ce n’est pas toujours évident d’être objectif. Il faut se méfier des habitudes, pour paraphraser Maslow, quand on a un marteau, tous les problèmes ressemblent à des clous. Il faut se méfier de la hype, le nouveau framework/outil/paradigme n’est pas forcément la silver bullet, la solution magique à tous vos problèmes.
En un mot, quels sont les prochains sujets qui vous passionneront ?
A.L. : J’en ai deux. Le premier c’est l’architecture événementielle, pas directement sous l’angle purement technique (qui a dit Kafka), mais plutôt sous l’angle design. J’espère pouvoir capitaliser sur les principes de design d’API mais je vais certainement découvrir des problématiques particulières à ce mode de communication entre système et peut-être un jour écrire The Design of Events.
Le second, c’est la formation. Être un expert du design d’API dans son entreprise c’est bien, mais le but du jeu, c’est surtout que les autres le deviennent aussi. Je vais travailler sur comment former efficacement toutes les autres personnes qui doivent designer des APIs en mixant formation présentielle (enfin via visio en ce moment) et formation en self-service.
Merci Arnaud
Merci Bertrand
Le livre : The Design of Web APIs, Arnaud Lauret, Manning Publication, 2020.