Démarche de déploiement d’une stratégie API : Reconnaître le besoin
Depuis de nombreuses années, les développeurs recherchent, consomment et créent des APIs pour faciliter et accélérer leurs travaux. Loin d’être des produits “techno-centrés”, ces APIs portent une très forte valeur business pour les entreprises qui les maîtrisent. Exposer le métier de l’entreprise par l’intermédiaire d’APIs, c’est faciliter les échanges, et donc la collaboration et l’innovation.
Cet article est le premier d’une série, dont le contenu s’appuie sur nos expériences et nos missions chez Neoxia ces dernières années. Dans celui-ci nous identifierons les signes qui doivent amener la DSI à mettre en place une telle démarche. Dans les articles à venir, nous parlerons des avantages et des risques inhérents à cette démarche et des actions que la DSI doit mettre en place pour mener à bien cette transformation. Nous aborderons également les thèmes de la sécurité, du design de ces APIs, de l’outillage et notamment de la CI/CD en nous appuyant sur des cas concrets.
All teams will henceforth expose their data and functionality through service interfaces.
Teams must communicate with each other through these interfaces.
There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
It doesn’t matter what technology they use.
All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
Jeff Bezos Mandate about Amazon services, 2002
Des signes clairs mais indirects
Le besoin de transformation du système d’information est le plus souvent émis par les équipes métier. Celles-ci ne l’expriment ni directement ni explicitement : il faut donc être attentif aux signes. Ceux-ci peuvent être discrets et seront majoritairement indirects.
Souvent, le SI est devenu un frein à l’innovation dans l’entreprise. Alors que son objectif principal est de faciliter les échanges pour permettre à l’entreprise de proposer des offres adaptées à son marché, il est devenu quasiment contre-productif. Cette inadaptation peut avoir 2 causes. La première est technique : le système ne permet plus de proposer des solutions adaptées aux besoins actuels. La seconde est liée aux méthodes : la DSI n’est plus proactive. Dans les deux cas, la DSI n’est plus en position de proposer aux métiers des solutions avec une forte valeur ajoutée.
Il existe déjà de nombreux indicateurs pour se rendre compte qu’un SI n’est plus techniquement adapté. Le premier d’entre eux est la dette technique, pour laquelle on trouve plusieurs méthodes d’estimation. Un autre est l’impossibilité d’interfacer le SI à des outils ou acteurs externes. Or, les acteurs (fournisseurs, partenaires, clients) sont de plus en plus étroitement liés et ce besoin revient donc souvent. Et si le métier ne se sent pas entendu, il n’hésitera pas à court-circuiter la DSI en allant chercher lui même les outils dont il a besoin, même si ceux-ci existent déjà dans le SI de l’entreprise.
Le SI peut être vu comme une contrainte par les entités métier qu’il sert, alors qu’il est sensé être un accélérateur. Les métiers de nos entreprises vivent des changements toujours plus rapides. Certes, cette évolution continue a toujours été présente, mais les changements sont si rapides aujourd’hui qu’il est nécessaire de les anticiper. Or, comme dit plus haut, si le SI ne permet pas de suivre ce rythme, il devient un frein pour l’entreprise. Tout comme les méthodes agiles permettent de répondre à un changement de priorités au cours d’un projet, la structure du SI doit être transformée afin de lui permettre de s’adapter plus rapidement et plus facilement aux nouveaux besoins.
Imaginons, sur le marché apparaît une API qui aurait pu être proposée par l’entreprise. Faute d’être prête, l’entreprise perd donc la place de lead sur ce marché et devient, de facto, le challenger. Elle perd ainsi du temps et de l’énergie : il lui faudra aller vite pour rattrapper ce retard. Le souci est le même à l’intérieur de l’entreprise. Disposer de services internes clairs et fins permet aux outils de l’entreprise de proposer des fonctionnalités avec une valeur ajoutée importante pour l’utilisateur. Et tout ça, sans embarquer des applications entières, souvent complexes et lourdes, dans le processus. Ainsi, tout le monde — les développeurs et les utilisateurs — gagne du temps (et du confort).
La bonne nouvelle, c’est que des APIs existent déjà probablement au sein du SI sans forcément le savoir. Elles sont certainement restées au stade d’initiatives isolées : soit elles sont nées d’un besoin de capitalisation technique, soit elles ont été créées à la suite d’une demande précise du métier pour se connecter à un acteur externe. Ce qui est sûr, c’est qu’elles manquent d’une vision stratégique globale.
La DSI lance l’impulsion
C’est à la DSI de reconnaître ces signes et de proposer les changements permettant d’y répondre.
Le SI doit devenir une plateforme de services qui expose le métier de l’entreprise. En s’ouvrant à travers le SI, les échanges entre les domaines de l’entreprise seront facilités. Chacun doit pouvoir appeler un service voisin, avec le minimum de contrainte.
La DSI doit avoir un rôle de conseil auprès des métiers. Les produits se dématérialisent, les exigences de qualité sont de plus en plus sévères et le contexte technique évolue de plus en plus rapidement. Rien n’est mieux placé que la DSI pour guider le métier dans ce nouvel état.
Entrer dans une démarche d’API-sation du SI implique d’y inclure toute l’organisation. Ce n’est pas une transformation qui ne concerne que la DSI mais elle doit en être le moteur. Avant de parler plus précisément des actions de la DSI pour mener cette démarche, le prochain article listera les avantages et les risques qui découlent de cette transformation.
Dossier API Management par Neoxia
Retrouvez ici tous nos articles concernant les APIs.
