smart solutions for smarter enterprises

L’API à l’échelle

Par Mathieu Dutertre, architecte solution chez Sentelis. Avec la collaboration de Laurent Baumard, Yasser Rougi et Jérôme Besson

De l’API à la VPI(Value Proposition Interface)

Les APIs ont été d’abord considérées comme un outil technique pour motoriser l’intégration des systèmes informatiques. Avec la démocratisation des « Apps » et l’avènement de l’API économie, il est admis que les APIs doivent aussi être vues comme des sources potentielles de revenus indirects ou directs. Elles permettent en effet à l’entreprise de faire levier sur son écosystème en attirant et connectant de nouveaux partenaires qui prolongent et étendent sa proposition de valeur et d’en tirer un bénéfice pécuniaire via leur monétisation.

Dans ce contexte d’ « Api-as-a-product », d’évolution du business model de l’entreprise vers un business model de plateforme, de foisonnement des xTech, de plateformisation de l’économie numérique ainsi que du système d’information de l’entreprise et de son hybridation, le nombre d’APIs dans les entreprises explose, les contraignant à s’industrialiser et à se tourner vers les solutions dites d’ « API management ». Ces dernières permettent, pour les plus sophistiquées, d’outiller la gestion du cycle de vie des APIs depuis leur production jusqu’à leur consommation, d’en rendre possible la découverte, le marketing et le merchandising via la mise en place de portails API internes et externes, voire d’API Marketplace – véritable canal de distribution de l’offre de l’entreprise – tout en sécurisant et monitorant leurs utilisations tant du côté des acteurs de l’entreprise (métiers et IT) que des tiers.

Choisir une solution d’API Management qui convient à la stratégie métier de l’entreprise en matière d’API et au contexte de son système d’information est nécessaire mais de fait insuffisant. Il faut pouvoir assurer à l’échelle de l’entreprise une cohérence durable d’ensemble des APIs, d’autant plus lorsque l’entreprise se tourne vers un écosystème. Cette exigence passe par la mise en place d’une gouvernance globale de ces dernières dans une logique de régulation au service de l’innovation.

Gouverner sans scléroser la dynamique API

Certaines formes de gouvernance liées aux données existent déjà au sein de l’entreprise, que ce soit la création et la maintenance d’un dictionnaire de données ou une gouvernance de type SOA. Elles sont de nature assez rigide (vocabulaire unique et multi-tout, objet pivot strict, protocole technique figé, découverte des services à partir des processus, etc.) et reposent sur un respect de principes et de règles de granularité très fins, et de fait très contraignants, coûteux, peu véloces et sclérosants en termes d’innovation.
L’évolution des organisations vers plus d’agilité et la nature même des APIs qui nécessitent des itérations pour en trouver le juste design selon leur finalité (applicative, intégration de partenaires, extension vers des tiers) rendent ces formes de gouvernance obsolètes. Les équipes projets sont de plus en plus petites et fortement autonomes sur leur périmètre voire cross-fonctionnelles. Le déploiement continu a été adopté par la plupart des entreprises et le cloud est en cours d’adoption généralisée, ce qui accélère la fréquence des livraisons en production et minimise d’autant le temps pour les sécuriser en terme de conformité au cadre défini par l’entreprise.

Toutes ces évolutions amènent à une réflexion forte sur certains aspects de la gouvernance, le risque étant qu’une gouvernance envahissante et trop stricte soit finalement destructrice de valeur. Ces risques peuvent ainsi mener à l’échec de la mise en place de la gouvernance (non pertinence, décisions tardives) voire à son abandon pur et simple.
La gouvernance des APIs est néanmoins indispensable. Sans elle, il sera très difficile de garantir une homogénéité de design partagée par tous les domaines fonctionnels de l’entreprise.

Un des aspects de cette gouvernance passe par la création d’une instance transverse et centrale type « API Governance Office ». Cette instance a en charge la supervision et la régulation des usages. Il est important qu’elle soit indépendante car elle va devoir assurer le pivot entre les métiers et l’IT.

L’API Governance Office (API G.O.) est proactif sur :
l’identification des pratiques opérationnelles implicites et explicites, leur analyse critique (points forts/faibles) et la détection de celles qui peuvent être étendues à l’entreprise

  • la proposition et promotion de pratiques, normes et standards et méthodes transverses pragmatiques, pour maximiser leur chance d’adoption par les projets agiles et stratégiques pour assurer la cohérence d’ensemble
  • la mise à disposition d’outils pour encourager et simplifier leur application et mesurer leur taux d’emploi en termes de
    design des APIs
  • développement des APIs
  • la socialisation autour des APIs par l’animation d’une communauté API
  • le respect des jalons de sa feuille de route pour garder la confiance des producteurs et des consommateurs d’APIs

Pour ce faire, voici 6 recommandations pratiques.

Recommandation#1 : construire le corpus de règles par jurisprudence

Dans un premier temps, l’API G.O. doit s’attacher à rapidement faire émerger de façon collaborative avec ceux qui devront les appliquer un premier niveau de ‘guidelines’ et de ‘best practices’ pour poser les grands principes vers lesquels l’implémentation des APIs dans l’entreprise doit tendre. Ces principes s’affineront naturellement par jurisprudence, c’est-à-dire en situation d’usage à partir de leur interprétation par les projets accompagnés par l’API G.O. Il faut éviter l’approche tour d’ivoire par une autorité hors sol.

Ces ‘guidelines’ comprennent deux volets, un volet métier et un volet technique. Dans la partie métier sont décrits entre autres le processus de création des APIs, la manière de les documenter, la matrice des responsabilités ainsi que la gestion du cycle de vie des APIs. Dans la partie technique, on retrouve les grands classiques : standards de sécurité (oauth2), standards de protocole (http methods, errors & statuses) ainsi que les principes d’architecture.
Ces ‘guidelines’ sont continuellement enrichies par les retours des producteurs et consommateurs d’APIs pour devenir des standards de fait. Les principaux contributeurs sont mis en lumière et récompensés lors d’évènements internes type API Days.

Recommandation#2 : une chaine de valeur partagée

Partager la chaine de valeur des APIs est essentiel à la compréhension des activités relevant du métier et de celles relevant de l’IT. Ce partage est un outil de sensibilisation sur la nécessité d’optimiser chaque maillon de la chaine pour en réduire les coûts et en maximiser la valeur produite pour l’entreprise.

Dans cette chaine de valeur, le processus de création d’une API est logiquement celui le plus impactant en termes de création de valeur. Petite plongée en eaux profondes sur ce dernier.

Le processus de création d’une API doit être supervisé. Cette supervision est assurée par l’API G.O. lors de revues périodiques à chacune de ses étapes, afin de s’assurer que le processus se déroule conformément au cadre de gouvernance, aussi embryonnaire qu’il soit. Il est impératif que les décisions ne soient pas prises en silo projet mais en coordination avec l’API G.O. qui est en charge d’enrichir et d’ajuster progressivement les règles de la maison commune.

Le processus comprend classiquement 4 étapes :

  1. la modélisation de l’API,
  2. le design de l’API ,
  3. l’implémentation de l’API,
  4. et sa livraison.

La modélisation d’une API coté consommateur (on parle souvent d’API Usage) est une activité très orientée métier qui nécessite donc une forte implication de ses représentants. Elle a pour but d’identifier les acteurs qui interagiront avec l’API, leurs objectifs d’usages ainsi que la nature de ces interactions afin de concevoir l’API idéale. Cette identification permet, en décrivant les interactions au niveau de détail adéquat, de dégrossir la liste des ressources et des méthodes attendues dans l’API coté consommateur. La sémantique de l’interface est un facteur clé de succès de l’API et doit s’appuyer sur un ou plusieurs thésaurus partagés.
L’étape de modélisation est itérative et peut se servir des concepts clés de l’approche « Domain Driven Design » (value objects, entities, aggregates, bounded contexts, ubiquitous language…) pour rendre moins empirique sa conception, sans pour autant qu’il n’existe de méthodologie déterministe. Une API est bien désignée si elle est plébiscitée par ceux pour qui elle a été conçue. Il faut donc intégrer le fait que plusieurs essais seront nécessaires avant de trouver la bonne et qu’il est primordiale de pouvoir en mesurer le succès auprès des consommateurs.

La phase de design vise à identifier les ressources dans le SI ou hors de ce dernier, capables de motoriser l’API Usage. On désigne souvent ces ressources par API Ressources. Dans la plupart des cas il faut s’attendre à ce qu’il n’existe pas d’API ressources « matchant » 100% des besoins de l’API Usage visée. Si l’adaptation fonctionnelle est importante ou s’il n’existe pas de ressources adaptées, il faut identifier le système le plus adéquat pour la porter et la développer. Si l’adaptation est légère, cas classique où il existe déjà un service né de la SOA y répondant raisonnablement, elle peut être réalisée via un middleware d’intégration type ESB. Il conviendra cependant de construire une ontologie permettant de passer de la verbosité SOA (verbe + concept, e.g ListCustomer, EndContract, UpdateProduct…) à la frugalité API (PUT, GET, POST, UPDATE). Ainsi, une interaction de type liste deviendra un GET, une création deviendra un POST, etc. Le résultat du design est matérialisé par un fichier versionné de spécification API au standard OpenAPI (a.k.a Swagger).
Il faut ensuite surveiller que les principes énoncés dans les ‘guidelines’ sont bien respectés par les équipes projet lors des phases d’implémentation (en mettant l’accent sur la documentation) et de livraison (pour laquelle le versioning est important).

Recommandation#3 : une proximité opérationnelle

Les revues d’APIs sont animées par l’ « API G.O. » et interviennent de manière itérative tout au long du processus de création et de suivi des APIs. Elles requièrent la présence des différentes équipes de développement d’APIs (notamment leur Product Owner, leur Tech Lead et leur Business Analyst) et sont nécessaires pour assurer la cohérence globale du design.

Ces revues permettent d’aligner les équipes projet et de discuter des points d’achoppement subsistants. Elles doivent produire par API un document publié et versionné qui comprend toutes les observations de l’API G.O. liées au design, leurs justifications, l’importance de les prendre en compte. Il faut constamment être dans la pédagogie plus que dans l’autoritarisme, et montrer la valeur à suivre ces remarques et les risques à ne pas le faire. Il faut accompagner leur prise en compte et leur mise en œuvre effective en apportant un appui opérationnel dans le sprint courant, à défaut dans un sprint suivant.

Afin de préparer et de simplifier ce travail de revue, il est souhaitable que l’ API G.O. ait accès en lecture seule à la backlog des différents projets API voire soit représentée directement dans les réunions de travail des projets sur le design. Le travail de l’API G.O. est un travail de longue haleine, un marathon.

Recommandation#4 : une expérience développeur à soigner

Le catalogue des APIs d’entreprise est un des autres outils à mettre en place par l’API G.O. Il est la référence et le langage commun de toutes les APIs au sein de l’entreprise. Dans ce catalogue, sont listées toutes les APIs, privées et publiques, classées et regroupées par domaines fonctionnels et caractérisées par un ensemble de métadonnées (finalité, cible de consommateur, couverture fonctionnelle, restriction d’utilisation, règle d’usage, performance, tarification, lien vers la spécification…). Le catalogue d’API est classiquement exposé via un « API Portal » interne et un ou plusieurs « API Portal » externes, pour les partenaires B2B ou dans le cadre d’une initiative Open API pour des tiers.

Les différentes solutions d’API management du marché permettent de générer en partie ce catalogue en fonction des APIs exposées dans l’API Gateway. A défaut, la publication manuelle sur un réseau social d’entreprise des différentes APIs est possible grâce à des outils comme Swagger Editor.

La publication dans le catalogue d’une API doit être précisée dans le cycle de vie de gestion des APIs et automatisée (exemple : « en développement », « en production », « dépréciée »).

Recommandation#5 : par défaut, commencez par les APIs data

A défaut d’un premier projet métier et donc d’un besoin en « API Usage », il est possible d’anticiper la création des APIs Ressources qui serviront de lego de base. On peut ainsi commencer à exposer les fonctionnalités des systèmes existants dans une logique de micro-services pour être le plus versatile possible lorsque les premiers cas d’usage se présenteront. Les APIs entités, c’est-à-dire les APIs des données les plus utilisées dans l’entreprise, sont dans ce cas les premières APIs à développer et ce d’autant plus que l’on est dans une logique data-centric. Dans l’ordre, celles pour accéder aux données maitres (produits, structures, nomenclatures de référence) puis celles pour accéder aux données procédurales (clients, souscriptions, contrats, etc.) pour déjà libérer/décloisonner les données de leurs silos historiques.

Recommandation#6 : automatisez la mesure de la performance de votre gouvernance

Lorsqu’on parle de gouvernance, la mesure de sa pertinence, de ses progrès et de son succès sont essentiels au travers de la mise en place de métriques et d’indicateurs de performance. Il faut pouvoir avoir une idée de la maturité des différents projets API par rapport à leur adoption du cadre de gouvernance.

On pourra par exemple via l’utilisation d’outils comme les « linters » automatiser la vérification de la conformité des APIs développées face à un ensemble de règles technico-fonctionnelles où s’assurer que les nouvelles APIs utilisent bien les modèles des ressources tels que publiés dans le catalogue.

Conclusion : API@Scale = API Platform + API Social Governance

La mise en place d’une dynamique de gouvernance des APIs collaborative, au sens co-construite avec l’ensemble des acteurs, est essentielle pour garantir l’adoption par tous du cadre de gouvernance. La régulation, qui est nécessaire pour passer à l’échelle, doit être accompagnatrice et créatrice de valeur et éviter le syndrome d’une gouvernance type « tour d’ivoire ». Elle doit s’appuyer par une « core team 4×4» alliant vision stratégique et solutions pragmatique. Elle doit être capable de s’insérer dans les pizza teams et autres squads de façon constructive tout en maintenant un niveau d’exigence important en matière de standardisation, de réutilisation et de langage commun afin de réussir le déploiement durable des APIs dans l’entreprise ainsi que dans son écosystème. Elle doit être capable d’apporter des réponses opérationnelles rapides qui font jurisprudence

Laisser une réponse

*