Démarche de déploiement d’une stratégie API : Actions à mener

Cet article est le dernier d’une série qui s’intéresse à la démarche de déploiement d’une stratégie API au sein d’une entreprise. Le premier article portait sur les signes permettant d’identifier ce besoin de transformation ; le second sur les avantages et les risques liés à cette transformation. Ce dernier va s’intéresser aux actions à mettre en place pour mener à bien cette transformation.

Gouvernance

Comme introduit dans l’article précédent, la DSI doit définir la gouvernance des API de l’entreprise. Chez Neoxia, nous sommes intimement persuadés que le succès d’un programme API passe par l’adoption d’une vision “API FIRST”, c’est à dire une démarche résolument et immédiatement tournée vers les clients (les développeurs, internes ou externes) et les APIs (les produits). La clé du succès est, en premier lieu, de concevoir une API en se mettant à la place de ses clients, puis, de l’implémenter. Par opposition, une bonne API n’est jamais le fruit d’un compromis entre un système existant et un budget.

Le métier a le rôle d’API Product Owner : il développe la vision “business” des API. Comme son homologue dans des projets classiques, “l’API PO” détient les responsabilités de définition de son produit, de la roadmap et du budget du projet. Évidemment, ce PO doit être entouré et soutenu dans ses responsabilités.

La DSI apporte tout l’éventail des compétences techniques, en sa qualité de maître d’œuvre sur les projets : développement, architecture, sécurité, … Elle doit également soutenir le PO dans sa mission en lui apportant un cadre technique, organisationnel et méthodologique. Elle endosse alors ici le rôle de coach agile.

En plus de ces rôles classiques, elle devra aussi :

• Conseiller : pour mener à bien la transformation et communiquer les bonnes pratiques, elle doit évangéliser et coacher les équipes de l’entreprise, communiquer largement sur l’objectif et la vision de l’entreprise et diffuser la méthode et les outils pour y parvenir.
• Auditer : en étant à l’écoute de tous les acteurs, elle sera capable d’identifier des améliorations (concernant les méthodes, outils, media, process, …) et de se rendre compte si de mauvaises pratiques apparaissent.
• Redresser : avec le temps, elle va également devoir endosser un rôle de garde fou, afin d’éviter que de mauvaises pratiques se répandent.

Gardons à l’esprit que ces responsabilités vont s’appliquer pendant et après la transformation de l’entreprise et que l’objectif est de mettre en place un cycle vertueux entre ces 3 rôles.

Dès le début de la transformation de l’organisation, l’entreprise doit définir les domaines fonctionnels ainsi que les responsabilités de chaque entité : chaque domaine fonctionnel doit être couvert et son responsable identifié. Les parties prenantes de ce projet seront toutes les entités de l’entreprise et c’est à la DSI de le piloter. Au terme de cette mission, l’entreprise doit avoir traité les points suivants :

1. tous les domaines fonctionnels de l’entreprise doivent être couverts : les domaines liés au cœur de métier de l’entreprise ainsi que les domaines support ;
2. à un domaine fonctionnel est associé un (idéalement, unique) responsable ;
3. définir comment piloter les projets qui impliquent plusieurs domaines ;
4. les exceptions à ces règles pouvant exister, un dispositif permettant de les identifier et d’échanger à leur sujet est défini.

Enfin, la DSI est le gardien de l’inventaire exhaustif et à jour des APIs exposées par l’entreprise : ce document liste toutes les APIs que le système d’information de l’entreprise expose. Cet inventaire est la clé d’une réutilisation efficiente du code et donc d’une meilleure gestion du système d’information. C’est également ce qui permet d’enrichir et d’améliorer continuellement les services proposés par l’entreprise — y compris en utilisant des APIs externes. C’est aussi l’un des outil nécessaire pour aider l’entreprise dans le découpage des responsabilités fonctionnelles évoquées plus haut.

Cadre technologique

Les éléments techniques restent dans le giron de la DSI. Elle doit apporter les réponses aux problématiques techniques de l’API-sation de l’entreprise : architecture du système d’information, outillage des projets et des plateformes numériques, gestion des environnements, …

Elle va également définir et diffuser toutes les bonnes pratiques liées à cette activité. En premier lieu, des règles précises de design des APIs doivent être rapidement définies et communiquées afin de proposer des produits uniformes. D’autres pratiques techniques (classiques) doivent également être définies et diffusées au sein de l’entreprise : règles de développement, cycles de vie des plateformes, outils utilisés, …

Enfin, elle est seule et unique responsable de l’infrastructure et des outils utilisés pour exposer les APIs : la ou les gateway(s), les serveurs hébergeant le code métier et le réseau. Ce qui est évident dans le cadre d’un projet classique de développement peut être ici un sujet délicat, notamment dans les grandes organisations. Le développement des APIs se fait au plus près du métier, parfois par des équipes de développeurs intégrés à une entité métier. Dans le cadre de développements d’APIs, ils peuvent également concerner la gateway ; on touche alors à la responsabilité de la DSI. Un équilibre entre permissions (la DSI autorise d’autres entités à implémenter la gateway…) et responsabilités (… mais pas à n’importe quel prix) doit être trouvé ; il sera basé sur les règles et les bonnes pratiques partagées en amont.

Piloter la transition

Une fois la cible définie, il devient nécessaire de piloter la transition vers cette nouvelle “organisation API”. Ici encore, c’est le rôle de la DSI.

Ayez conscience que cette transition va demander du temps. Entre la phase de cadrage et la pleine mise en marche de cette organisation, il faut compter plusieurs mois :

• La phase de cadrage, qui implique de nombreux acteurs, va nécessiter à elle seule entre 3 et 6 mois.
• La mise à l’échelle complète de cette organisation va dépendre de très nombreux facteurs, qu’il n’est pas possible de lister exhaustivement. Parmi eux, on peut citer la culture de l’entreprise, sa taille, sa maturité technologique et organisationnelle et sa capacité à évoluer.

Selon nos expériences, on estime que l’ensemble de la transition prend entre un an et demi et trois ans. Cependant, il existe des exceptions. Ainsi, dans certaines organisations très importantes et/ou peu agiles, la durée de transformation peut durer jusqu’à dix ans. Quoi qu’il en soit, de nombreuses APIs auront déjà vu le jour avant même de compléter cette transformation.

Conclusion

Ces articles sont basés sur nos expériences dans des projets de transformation avec les clients de Neoxia. Sur tous ces projets, nous avons joué le rôle d’API Engineers, c’est à dire de responsables opérationnels de la transformation du système d’information. Nous en avons retenu, notamment, plusieurs points :

1. Plusieurs initiatives éparses, hétérogènes et isolées de développement et d’exposition d’APIs naissent avant que l’organisation n’en prenne conscience. Ne les sous-estimez pas - ni en quantité, ni en qualité - et utilisez les pleinement pour soutenir la transformation.
2. Dans un second temps, l’organisation lance sa transformation et définit une gouvernance claire. Cependant, les APIs continuent de naître durant cette phase. Gardez votre inventaire à jour et appliquez les bonnes pratiques de manière rétroactive.
3. Un “API Committee” composé de la DSI, des responsables métiers et de la direction permet de définir et diffuser efficacement la vision de l’entreprise. Ce comité doit être mis sur pied rapidement et aura besoin d’avoir l’engagement de la direction pour avancer.

Vous trouverez des informations utiles pour la phase de cadrage et de construction des API dans nos autres articles, notamment comment concevoir et sécuriser vos APIs, quelle(s) architecture(s) mettre en place, comment sécuriser votre plateforme API grâce à l’intégration et au déploiement continus, etc.

Dossier API Management par Neoxia

Retrouvez ici tous nos articles concernant les APIs.