Les projets d’API Management sont fondamentalement simples. Il s’agit de faire échanger des données d’un système A vers un système B. Mais c’est sans compter sur le fait qu’un projet d’API Management fait intervenir un grand nombre d’acteurs, ce qui engendre de la complexité.
Les acteurs de la gestion des API
Pour commencer, nous pouvons énumérer les acteurs typiques impliqués :
Le CxO qui a décidé que les API faisaient partie de la stratégie de l’entreprise, mais qui ne vous donne pas un parrainage très fort ;
Les autres CxOs qui ont d’autres priorités que les APIs ;
L’équipe A qui veut accéder à des données, mais qui n’a pas le temps de s’occuper de vous ;
L’équipe B qui est responsable de données exposées, mais qui n’a pas de temps à vous consacrer ;
Les développeurs de la solution qui veulent accéder aux données ;
Les développeurs de la solution qui exposent les données ;
Les membres de l’équipe de gestion de l’API ;
Et au moins un architecte, bien évidemment !
On voit bien qu’il y a une multiplicité d’acteurs, qui vont tous pousser dans leur propre direction. Et on perd rapidement toute forme de coordination si :
L’équipe de gestion de l’API ne joue pas un rôle de coordination constructif ;
Il n’y a pas de parrainage des membres du CxO.
Le défi de la complexité
Il est donc nécessaire de maîtriser la complexité de l’entreprise et la complexité due à ses interactions et à ses acteurs. En effet, selon la théorie des systèmes complexes, la complexité du système « entreprise » réside dans le nombre élevé d’acteurs et le nombre élevé d’interactions entre eux !
Ce qui est complexe, ce n’est pas de faire une API avec un acteur, mais de faire une API avec, par et pour de multiples acteurs.
Il est donc fondamental de :
Chercher à aligner tous les acteurs dans la même direction par une très bonne communication, des explications sur les bonnes pratiques, etc. ;
Faire de l’équipe de gestion des API un point d’échange central pour toute conversation sur les API ;
Infuser les connaissances dans toutes les équipes autant que possible.
A partir de là, on peut déduire deux prérequis :
Une gouvernance claire, simple et efficace est essentielle ;
Un sponsorship solide doit garantir l’alignement de l’entreprise sur un projet d’API.
Le mode d’organisation le plus souvent utilisé est le mode de gouvernance que j’appelle open source. L’équipe API encadre, guide, aide, soutient, mais surtout permet à chacun de contribuer facilement et efficacement.
De ces activités et défis ainsi énumérés, nous pouvons ainsi déduire deux types d’activités.
Deux typologies d’activités de l’équipe API
On peut ainsi diviser les activités d’une équipe API en deux types d’activités : les activités régaliennes et les activités étendues. En effet, la gouvernance d’une équipe de gestion d’API doit fixer un cadre dans lequel tous les acteurs impliqués dans les API doivent s’inscrire, afin que tous les acteurs puissent pleinement travailler.
Les activités régaliennes
Nous pouvons appeler activités régaliennes les activités pour lesquelles l’équipe de gestion des API a toute l’autorité et ne peut être supprimée. Dans ces activités, nous pouvons mettre :
La mise en œuvre et l’administration technique de la plateforme API Management.
La définition des meilleures pratiques de gestion d’API.
Les formats des ateliers de définition des API – pour passer de réunions interminables et contre-productives à des réunions efficaces et productives. J’ai personnellement réduit par 4 le nombre d’ateliers, juste en repensant la façon dont nous les animons !
L’organisation des ateliers API – Pour être le moteur des sujets API, mais libre à l’équipe API Management de laisser les équipes concernées s’organiser elles-mêmes si elles sont suffisamment autonomes.
La gestion de la formation et de la communication – Pour assurer l’adhésion des équipes, et pour démontrer la valeur ajoutée des équipes d’API Management.
Les activités étendues
Certaines activités doivent cependant être menées non pas sur un mode purement régalien mais sur un modèle beaucoup plus collaboratif, car après tout, il s’agit d’organiser les échanges entre au moins deux systèmes :
Définir et gérer le cycle de vie des API avec les projets et les architectes fonctionnels – Même si l’équipe API a le dernier mot, elle reste au service des projets et du métier ! Ne l’oubliez jamais !
Travailler avec les architectes sur l’alignement des besoins en API dans une feuille de route claire – Les architectes sont censés avoir une vision à moyen et long terme des besoins futurs, les équipes API sont censées s’aligner sur eux !
Outiller pour les développeurs afin d’apporter les bons outils et cadres de travail – Dire à un projet « allez-y et faites l’API » n’est pas suffisant ! Dites-le à un projet Legacy ! C’est aux équipes API de travailler avec les projets pour moderniser la base technique, la distribuer et la partager avec d’autres équipes de développement.
Contribuer à l’idéation avec les métiers pour trouver de nouvelles idées d’API – Le but étant de tirer le maximum de valeur des actifs de l’entreprise.
2 typologies de gouvernance, ou plutôt 2 “curseurs” de gouvernance
Enumérer une liste de tâches n’est pas pour autant équivalent à définir une gouvernance API.
De ces deux typologies d’activités, on remarque que le pattern “décentralisée” revient forcément.
En effet, le mode de gouvernance qu’on pourrait appeler “décentralisée” revient très souvent. Dans ce mode de gouvernance, l’équipe d’API Management a comme but principal de permettre à tout à chacun de contribuer facilement et efficacement. Ainsi, charge à l’équipe API Management de cadrer, orienter, aider, d’apporter du support, mais pas nécessairement d’implémenter et définir les APIs. C’est une logique de gouvernance qui cherche avant tout à permettre aux autres équipes de travailler de manière autonome.
Dans une logique totalement inverse, l’autre mode de gouvernance que l’on rencontre régulièrement est une gouvernance centralisée. Le centre de compétence d’API regroupe alors toutes les compétences nécessaires, et travaille de manière auto-suffisante.
Pour autant, rares sont les entreprises qui mettent en place une gouvernance aussi “marquée” par une de ces deux logiques. Toute la question est de pouvoir s’adapter à l’organisation de l’entreprise et de son SI, mais aussi de s’adapter à la maturité et à l’autonomie des équipes en place. Il faut toutefois bien chercher à autonomiser les équipes, sans quoi il vous sera impossible de “scaler” votre organisation autour des APIs, sans compter les effets de bord d’une logique de tour d’ivoire…
Il y a encore aujourd’hui de nombreuses entreprises qui ne misent pas encore sur les API et qui se demandent encore comment faire. Elles se retrouvent souvent bloquées par le grand nombre de questions qui se posent à elles, ne sachant pas comment aborder ce genre de projets. Elles se retrouvent rapidement bloquées. C’est pourquoi je préconise une démarche MVP.
L’approche MVP pour un projet d’API Management
Parler d’approche MVP pour d’aussi gros projets peut surprendre. En effet, les points à soulever sont nombreux, que l’on parle de sécurité, des solutions techniques, de l’organisation, de la roadmap API ou encore de la définition de bonnes pratiques.
Mais les avantages d’une démarche MVP pour un projet d’API Management sont nombreux :
Démontrer la valeur :
En mettant en place la première API en mode MVP, il est possible de communiquer plus rapidement aux métiers ce que l’on peut désormais faire grâce aux API.
Démontrer la faisabilité :
Dans le cas de systèmes Legacy complexes, encore plus s’ils sont cloisonnés, les raisons sont nombreuses de penser qu’il sera long et compliqué de mettre en place des API. Grâce à l’existence de nombreux modèles d’architecture d’intégration (comme le CQRS), il est plus facile qu’on ne le pense de faire sauter les verrous !
Obtenir des retours d’expérience :
Plutôt que les audits SI et autres audits de maturité, qui sont longs et pas toujours pertinents, rien de tel que des REX réguliers pour faire avancer un projet d’API Management.
Prioriser les initiatives :
Grâce aux premiers retours d’expérience, il est possible de savoir quelle initiative prioriser. La gouvernance doit-elle être étudiée ? La stratégie d’intégration ? La communication interne ?
Réduire les risques :
La démarche MVP permet d’adopter une approche totalement intégrée, avec des décisions de type Go/NoGo à chaque étape. Vous courrez donc un risque réduit à sa portion la plus congrue.
Cette approche MVP peut rapidement aboutir à une première API en un mois, certes imparfaite, mais utilisable. Est-ce qu’il y aura encore des questionnements après un mois ? La réponse est évidente : c’est oui ! Et vous serez même en mesure de classer ces questionnements par ordre de priorité !
Approche MVP et grandes étapes
Une approche MVP étalée sur quatre semaines est clairement réalisable, pour peu qu’on suive les grandes étapes suivantes :
Définition du périmètre (première semaine) :
Choix d’une API candidate :
Vous allez d’abord choisir une première API en fonction de sa facilité à être instanciée et de la valeur qu’elle apportera. Visez le gain rapide !
Lister les attendus :
Plusieurs contraintes techniques, fonctionnelles et autres sont susceptibles d’être émises par les parties prenantes, qu’ils soient métier ou IT. Collectez-les !
Visioning (deuxième semaine) :
Définition de l’architecture :
Vous devez ensuite définir l’architecture cible de votre gestionnaire d’API. Une solution sur site ? dans le nuage ? L’important est de le faire rapidement. Ce n’est pas compliqué de changer le gestionnaire d’API, vous aurez le temps de le changer plus tard. Visez vite et pas cher ! Et n’oubliez pas les sujets d’authentification.
Définition de l’API :
Il vous faut ensuite définir l’API. Un travail à faire de concert avec les métiers, les développeurs et les architectes.
Validation :
Partagez enfin votre API et votre architecture avec tout le monde, pour la valider.
Construction (troisième semaine) :
Installation des composants :
Il est donc temps d’installer votre gestionnaire d’API ! N’oubliez pas, dans le cas de solution cloud, de vérifier s’il n’y a pas de contraintes de sécurité à gérer !
Développements :
Rien n’est plus simple que d’instancier une API, avec son interface. Et n’oubliez pas les sujets d’authentification (bis repetita).
L’intégration et les tests avec les systèmes consommateurs :
Bien sûr vous devez tester. Avec toutes les parties prenantes disponibles, idéalement en même temps…
Rétrospective (quatrième semaine) :
REX technique et métier :
Faites des démonstrations de votre API, avec présentation de la plateforme d’API Management. Ce faisant, vous obtiendrez des retours techniques et métiers.
Initiatives à venir à prioriser :
C’est le bon moment pour lister les prochaines initiatives. Comme les retours d’expérience viennent d’être faits, il n’est pas question de tout arrêter. Continuez !
En respectant ces étapes, vous serez en mesure de poursuivre votre programme API grâce au travail des initiatives priorisées, mais surtout, de pouvoir continuer sur votre lancée ! Et n’oubliez pas que les projets d’API Management nécessitent beaucoup de communication et d’évangélisation !
J’ai analysé Pro Santé Connect, un service fort intéressant avec plein de potentiels, réalisé dans les règles de l’art et qui suit les standards actuels du domaine de l’authentification. Mon retour : j’adore ! (oui bon laissez-moi mes kiffes hein…).
Pro Santé Connect, c’est quoi ?
Il s’agit d’un service d’authentification et d’identification des professionnels de santé.
Ce service est construit sur les bases des standards du marché actuel : OAUTH2 pour l’authentification et, cerise sur le gâteau, de l’OpenID Connect pour avoir le complément d’information d’identification qui va bien : que pouvons-nous demander de plus ?
À quoi sert Pro Santé Connect ?
Ce service permet qu’un organisme d’état certifie :
La personne qui est en train de s’authentifier est bien celle qu’elle dit être, avec des preuves à l’appui ;
La personne qui accède à mon site dispose bien de certaines caractéristiques qui ne viennent pas d’une auto-déclaration mais d’informations recensées et vérifiées au niveau des organismes d’État ;
Ces informations sont transmises de façon sécurisée et non corruptibles (jetons JWT signés).
Pour être clair, il fonctionne un peu comme France Connect, mais son caractère médical, associé aux caractéristiques spécifiques de la profession, sécurisé et complété par l’OiDC, ouvre la possibilité d’exploiter beaucoup plus d’informations : quel est son lieu de travail ? dans quel établissement ? quelle spécialisation médicale le professionnel pratique ? et d’autres encore…
Pour finir, ces informations peuvent être propagées à des applications tierces, avec un simple transfert de jeton sécurisé, ce qui permet d’éviter les surcoûts et les efforts d’authentification à plusieurs niveaux.
Et alors, on en pense quoi de ce service d’authentification ?
J’adore. Je n’aurais pas fait mieux, ni pire… Techniquement ça a l’air de tenir la route et même plus.
L’utilisation de standards reconnus et plébiscités par le marché, alors que personnellement j’en ai ch…, pardon bavé… Veuillez m’excuser, j’ai eu un peu de mal dans le passé avec des standards d’interconnexion mal documentés, incompréhensibles… Ils étaient pondus par des organismes publics qui, dans un souci de sécurisation, avaient rédigé des documents illisibles et impossibles à utiliser. Bref, je pense qu’ils n’ont jamais rencontré de problèmes de sécurité, vu que personne n’a dû réussir à les implémenter…
Dans le cas de Pro Santé Connect, ceux qui ont déjà implémenté de l’OAUTH2 ou de l’OiDC, se retrouvent dans un cadre familier, clair, bien documenté, enfin un vrai plaisir (bon au moins de mon point de vue hein… laissez moi ce plaisir…). Pour les autres, ces standards sont tellement bien documentés que, avec un peu d’effort de lecture, on peut vite en comprendre les concepts.
Des informations certifiées, complètes, simples à lire ? Il est où le pépin ?
C’est beau tout ça, magnifique, dans ce monde parfait nous n’avons plus rien à craindre ! Plus de questions à se poser ! Nah…
Bon ce n’est pas forcément le cas, une alerte reste d’actualité et se base sur un concept cher à pas mal de DSI : la qualité des données traitées et leur fraîcheur.
Si le service a une chance de marcher tel qu’il est présenté, la collecte des informations devra se faire :
Dans des délais très courts, à partir du changement de situation du professionnel de santé ;
Avec une qualité irréprochable.
Or, la fusion de plusieurs référentiels dans un seul (le RPPS), en cours, plus l’effort que l’ANS semble mettre dans cette initiative, laissent présager des bons résultats.
En conclusion
La voie est la bonne, techniquement pas de surprise, une implémentation reconnue et éprouvée, un service qui nous plaît !
Et maintenant nous attendons le même service pour les personnes physiques, en lien avec Mon Espace Santé et les domaines associés !
Le 23 juin 2022, l’équipe Architecture a animé un événement dédié aux fondations digitales et data. C’était l’occasion de partager avec les participants les témoignages exceptionnels de Catherine Gapaillard (Groupama) et de Yannick Brahy (STIME – DSI du Groupement Les Mousquetaires).
Retour sur notre petit déjeuner événement
Nos intervenants ont pris le temps de partager leur contexte, leur expérience, les spécificités de leurs directions , ainsi que les leviers : organisation, gouvernance et outils mis en place pour soutenir leurs systèmes d’information
3 Temps forts ont rythmé cette matinée:
Comment Groupama se met en route vers une Entreprise Data Driven avec les socles data référentiels et data hub qui supportent la construction de leur domaine data par Catherine Gapaillard, Responsable de la division Urbanisme et Architecture.
Le partage de la Stime – DSI du groupement Les Mousquetaires, de la mise en place d’une stratégie de Data Intégration grâce à son Hybrid Integration Platform (HIP) par Yannick Brahy, Directeur de l’Architecture et de l’Urbanisme.
Les architectures de référence, qui associées à des principes directeurs de constructions du SI permettent de structurer des fondations digitales / data et définir une vision cible du SI et les trajectoires de transformation associées, par Damien Blandin, Directeur Associé de Rhapsodies Conseil
Téléchargez notre livre blanc Architecture SI – Nos modèles de référence
Revivez l’évènement en photo :
A propos de Rhapsodies Conseil
Créé en 2006, Rhapsodies Conseil est un cabinet indépendant de conseil en management. Sa vocation : accompagner les programmes de transformation de ses clients, depuis le cadrage jusqu’à leur mise en œuvre opérationnelle, sur 4 grands domaines d’expertise : Architecture & Transformation Data/ Digitale, Sourcing & Performance de la DSI, Paiements & Cash Management et enfin Agilité, Projets & Produits. Fort d’une centaine de consultants et d’une longue expérience de la transformation des processus et du SI, Rhapsodies Conseil intervient auprès des Grands Comptes et ETI de secteurs d’activité variés (Banque, Assurance, Services, Industrie, Luxe, e-commerce,…). Expertise, Indépendance, Engagement, Agilité, Partage, Innovation et Responsabilité sont les valeurs fondatrices du cainet et guident l’action de ses consultants au quotidien.
1. Renforcer la collaboration et la coopération entre les départements Dev & Ops
Une organisation DevOps amène les équipes en place à adopter des changements positifs et à partager un objectif commun, à travers une communication fluide et transparente. La coopération, la confiance et le respect mutuel profitent aux équipes et permettent d’atteindre le niveau d’agilité exigé.
2. Améliorer la qualité des développements applicatifs et la stabilité de l’application
L’analyse qualitative du code source intégrée dans le processus de développement, voire implémentée dans la phase d’intégration continue, permet de réduire les coûts de remédiation et de prévenir les défaillances de l’application.
3. Accélérer le déploiement, réduire les risques opérationnels et renforcer le time to market
Un management agile reposant sur le DevOps permet de délivrer à une fréquence plus importante, pouvant aller à plusieurs déploiements chaque semaine suivant les Sprints, et réduisant ainsi le time to market.
4. Diminuer les coûts IT
Les équipes Devs et Ops adoptent un outillage commun et une plateforme unique: l’Usine Logiciel, pour gérer le cycle de vie des applications, dès la phase de développement jusqu’au déploiement en Production.
5. Limiter le temps d’interruption de service
L’ensemble des tests automatisés permettent à l’entreprise de détecter en amont et plus rapidement les problèmes, évitant ainsi de mettre hors service leurs systèmes pour des raisons inconnues.
6. Intégrer la sécurité by design : DevSecOps
Intégrés à l’usine logicielle, les outils dédiés à cet usage permettent de se conformer aux règles de sécurité de l’entreprise et de maîtriser les risques. L’analyse se fait de bout en bout et couvre tous les aspects de sécurité, depuis la revue du code source jusqu’aux tests de vulnérabilité et d’intrusion.
Pour conclure : avancer étape par étape
Les bénéfices du DevOps sont donc aujourd’hui reconnus ! Pour atteindre ces objectifs, il est nécessaire de passer par différentes phases de transformation, aussi bien sur le plan humain que sur les aspects techniques.
Etes-vous prêts à franchir le cap et passer au DevOps ?
L’entreprise data driven, la digitalisation de la relation client, l’amélioration de l’expérience client omnicanale, l’ouverture et la cloudification du SI sont autant de préoccupations actuelles pour les entreprises qui sont portées par les innovations technologiques du SI.
Le SI est désormais au cœur des décisions stratégiques de transformation des entreprises et conditionne leur capacité à accroître leur performance au travers d’une évolution permanente et continue.
L’Architecture SI se base sur des fondations digitales / data, des modèles de référence associés à des principes directeurs qui permettent de structurer et définir une vision cible du SI et les trajectoires de transformation associées.
Nos modèles de référence d’Architecture sont donc là pour vous aider à soutenir vos projets de transformation SI, à organiser et structurer la construction de vos fondations digitales / data pour établir une feuille de route cohérente de votre SI cible.
Au cœur de notre expertise, ces modèles de référence d’Architecture structurent notre approche méthodologique construite par R&D mais aussi éprouvée de manière très opérationnelle auprès de nos clients.
Dans ce Livre Blanc, vous trouverez une cartographie de toutes les fonctions attendues par modèle de référence afin d’éclairer vos choix de solution selon vos enjeux métier et vos contextes SI spécifiques.
D’autres modèles de référence d’Architecture viendront très prochainement enrichir et compléter cette première version.
