La conception collaborative des API

Le spécialiste de la gestion des dépenses professionnelles Spendesk a officiellement déployé ses API, accompagnées de leur portail destiné aux développeurs. En 2024, l'annonce serait insignifiante s'il n'était fait mention de la méthode collaborative employée pour leur conception, fort inspirante pour des situations couramment rencontrées.

Comme tellement d'entreprises, entre autres dans le secteur financier, Spendesk pouvait aisément imaginer les besoins prioritaires de ses clients et partenaires avant de se lancer. En visant d'abord les intégrations les plus évidentes – avec les logiciels de comptabilité, les plates-formes de ressources humaines, les outils de gestion de projet… –, il ne lui était guère difficile d'esquisser les grandes lignes de solutions susceptibles de les intéresser et de les aider à optimiser les processus d'entreprise.

Pourtant, quand il s'agit d'affiner la proposition et de mettre au point les services, rien ne vaut l'expérience concrète des utilisateurs cibles : seuls ceux qui sont de l'autre côté de la barrière connaissent vraiment les informations qui leur sont nécessaires ou comment elles doivent être présentées. C'est la raison pour laquelle Spendesk a commencé par publier une version beta de ses API, accessible à tous, en demandant à son écosystème de les évaluer et de transmettre ses commentaires et autres exigences.

Les moutures définitives, validées après plusieurs itérations, sont ainsi assurées de satisfaire les développeurs qui vont devoir la prendre en main, tout en répondant au mieux aux besoins de leurs organisations. Toutes les conditions sont donc réunies pour viser le succès, même sur des fonctions incertaines, voire expérimentales, lorsque vient l'heure d'explorer des opportunités moins flagrantes pour les APIs.

La démarche mérite l'attention des entreprises – institutions financières en tête – qui hésitent encore et toujours à déployer massivement des APIs en raison de leurs incertitudes sur leur usage potentiel et, par conséquent, sur leur modèle économique. Le meilleur moyen d'avancer consisterait alors à développer des prototypes, puis à les soumettre à une audience qualifiée afin d'en confirmer la pertinence et, le cas échéant, ajuster leur configuration en fonction des réactions qu'elles suscitent.

Naturellement, une telle approche n'est acceptable que si l'effort requis pour réaliser un produit minimum viable est minime (de manière à être en mesure d'absorber les échecs) et n'est efficace que si les cycles de mise à jour sont suffisamment rapides pour que les participants à cette phase de tâtonnements soient convaincus de l'engagement à progresser et aboutir à un résultat optimal dans un délai raisonnable. Dans cette perspective, il faudrait non seulement instaurer une culture agile – pas superficielle, comme on le voit trop souvent, mais réelle – mais également, et ce sera le plus complexe, préparer le système d'information à une exposition en services universelle.