Article
Données
27.9.2017
Perturbation continuum temporel
5 minutes
Temps d'un café
4 questions à poser à son futur concepteur d’API
4 questions à poser à son futur concepteur d’API
Antoine Michel
Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

Parlez-moi de l’expérience développeur

Dans le cadre d’une API, la DSI s’apprête à exposer l’ensemble des services métiers de son entreprise à destination de développeurs tiers. Ce sont des clients que l’entreprise ne connaît pas, ou fort peu. Elle ne sait qu’une chose : ils sont très différents de ses clients habituels.

Alors, comment séduire des clients dont je ne sais rien ? Rien des technologies qu’ils utilisent, rien de la façon dont ils les utilisent ?

Il n’y a qu’une seule façon de faire les choses. Il faut fournir une API simple à utiliser, qui ne soit source d’aucune frustration. On n’engagera une communauté de développeurs à exploiter ces services seulement s’ils sont faciles d’accès et si l’on prend du plaisir à les utiliser.

S’il faut le rappeler, allons-y : les développeurs, tiers à l’entreprise, fondent leur propre économie sur de nombreuses API. Ils auront donc toujours tendance à privilégier celles qui leur facilitera la vie et dont le coût de développement n’est pas trop élevé.

On ne bénéficie d’une exposition de ses services à de nouveaux publics que lorsque l’API est appréciée. C’est un vecteur extrêmement efficace, capable de vous propulser parmi les happy few membres d’une future application destinée à faire un carton… ou pas, si la qualité n’est pas au rendez-vous.

Je souhaite garder le contrôle. Quelles sont mes garanties ?

Voilà un thème cher à toute entreprise. La réponse à cette question est d’une rare évidence : pour garder le contrôle, concevez des API. En vérité, il existera toujours des solutions pour des développeurs très motivés d’obtenir les informations dont ils ont besoin pour leur propre travail. C’est une autre forme de shadow IT, contre laquelle la meilleure défense reste une proposition de valeur de qualité.

Mais qu’en est-il de l’usage que des développeurs tiers pourraient faire des APIs existantes ?

En effet, si l’on n’y prend pas garde, des utilisations tout à fait inattendues peuvent émerger. Les comparateurs de prix ont certainement fait grincer des dents plus d’un directeur marketing.

La conception d’une API est une question de délicat équilibre et d’un arbitrage poussé. Il faut d’un côté donner beaucoup de flexibilité pour favoriser l’apparition de nouveaux usages et d’un autre, limiter au maximum les abus.

La sécurité fonctionnelle est au cœur du travail du concepteur d’API. Une API en ce sens doit être suffisamment coercitive pour que les usages obtenus ne sortent pas (trop) du périmètre qu’on a voulu leur donner. Et cela dépendra des technologies et des modes à la fois d’exposition, de pricing et de sécurité (technique et fonctionnelle) de l’API. En d’autres termes, c’est une stratégie, à laquelle l’entreprise doit réfléchir suffisamment tôt avant de se lancer dans la phase de conception à proprement parler.

Réflexions autour du mode de distribution, de la façon d’intégrer de nouveaux développeurs, une DSI doit se doter d’un ensemble de dispositifs capables de distribuer ses interfaces, que ce soit en mode onboarding direct ou selon une stratégie partenaire. Un portail développeurs doublé d’outils de monitoring relève sans équivoque d’un indispensable pré-requis.

Comment puis-je inclure les métiers dans cette conception ?

Les métiers sont la pierre angulaire d’une API puisque ce sont les services auxquels ils contribuent qui sont exposés via l’interface de programmation. Autant dire que sans les métiers, il n’y a pas d’interface qui tienne. Il ne faut donc pas se demander comment les associer mais quand. Dès le départ, en résumé.

Un directeur de produit, une direction marketing sont très au fait des enjeux du digital et des nouveaux usages issus des évolutions technologiques en cours. Tous savent ce qu’ils souhaitent pour leurs produits et leur entreprise, et ce qu’ils ne veulent pas. Pour reprendre un exemple courant dans le secteur de la banque, chacun est sûrement prêt à distribuer des services en marque blanche pour favoriser de nouvelles expériences bancaires mais peu d’entre eux se réjouissent des comparaisons de services.

Forts de leur expertise, c’est aux métiers qu’il appartient d’exprimer le service et son processus. Le jeu (parce qu’à cette étape de conception, c’est un jeu à part entière !) consiste à aider les métiers à se projeter de façon abstraite, sans visuel, sur le fonctionnement d’un protocole technique. Voilà qui semble irréaliste ? Au contraire, cela fonctionne très bien dès lors que l’on s’extraie complètement de la technique.

Puisque l’objectif est de parvenir à traduire les échanges humains en échanges machines, tout en s’assurant que les métiers s’approprient le phénomène, à l’instar d’un jeu de rôle, chaque élément du processus est considéré comme un acteur vivant. Le contact par téléphone, le compte bancaire, l’opération de virement prennent vie et meurent. Les besoins de chaque acteur sont pris en compte, de quelle façon il communique, ce qu’il a besoin de savoir, la teneur du dialogue qu’il engage…

C’est à l’occasion de ces ateliers qu’une squad pourra avec précision déterminer le périmètre attendu pour ensuite réduire drastiquement les risques d’exploitation abusive ou rendre très compliquée une opération de reverse engineering, tant redoutée.

Quelle sera l’évolution de mon API ?

C’est peut-être la meilleure question à poser car d’une part, elle sous-tend l’ensemble des aspects développés plus haut et d’autre part, elle est le parent pauvre de la conception d’API et c’est une grave erreur.

Distribuer une API à des tiers, c’est conclure un contrat qui engage l’entreprise distributrice. Si l’expérience développeur a bien été prise en compte, il y a de fortes chances de voir son API exploitée. C’est bien pourquoi le travail d’idéation en atelier de conception avec les métiers est fondamental.

Parce qu’une API dispose d’une très longue durée de vie, il faut donc garder à l’esprit que les choix que l’on fait sont pris pour longtemps. L’idéal évidemment est de construire un système viable sur plusieurs décennies, sur le modèle de l’architecture du web. Une decades-long architecture garantit aux systèmes des propriétés d’évolutivité et d’extensibilité sur des dizaines d’années. Au demeurant, son impact sur les plannings et les budgets conduit assez inévitablement à des choix plus pragmatiques et à des arbitrages.

No items found.
Pour aller plus loin :