Les conditions d’une véritable stratégie API en entreprise

Le jour où l’API devient un sujet de direction

Situation illustrative : lundi matin, le directeur commercial demande d’ouvrir en trois mois les stocks et les tarifs à un nouveau partenaire. L’ERP sait répondre, mais seulement par des échanges de fichiers nocturnes. Une équipe propose une API rapide, une autre exige une plateforme complète, le RSSI refuse toute exposition sans authentification centralisée, et l’éditeur réclame une option contractuelle supplémentaire. Le DSI n’a pas un problème de développement. Il doit décider ce que l’entreprise accepte d’exposer, à qui, avec quel niveau de service, sous quelle responsabilité et à quel coût durable.

Une véritable stratégie API commence ici : non par le choix d’une passerelle technique, mais par des règles d’arbitrage sur les capacités numériques de l’entreprise. Sans ces règles, chaque API devient une exception locale. L’organisation gagne quelques interfaces et accumule une dette de dépendances, de sécurité et d’exploitation.

Partir des capacités métier, pas du catalogue technique

L’erreur classique consiste à lancer un inventaire de services disponibles, puis à chercher lesquels « APIser ». La bonne question est inverse : quelles capacités doivent être mobilisables par plusieurs canaux, partenaires ou applications ? Un prix, une identité client, une disponibilité produit ou un statut de commande ne sont pas de simples données. Ce sont des objets métier régis par des règles, une fraîcheur attendue et une autorité désignée.

Le DSI doit donc demander, pour chaque capacité prioritaire : qui en est propriétaire, quelle source fait foi, quels usages sont autorisés, quelle indisponibilité est acceptable et quelles conséquences aurait une réponse erronée ? Cette clarification évite qu’une API moderne masque un référentiel incohérent. Elle oblige aussi les métiers à assumer leurs décisions : ouvrir un service n’est pas seulement connecter deux systèmes, c’est formaliser une promesse opérationnelle.

Choisir ce qui doit être partagé, protégé ou refusé

Toutes les capacités ne méritent pas une API, et toutes les API ne doivent pas être ouvertes de la même manière. Une interface interne entre applications maîtrisées, une API destinée à des partenaires et un service public n’impliquent ni les mêmes contrôles ni les mêmes engagements. Le RSSI doit intervenir avant la conception détaillée pour classer les données, définir les identités admises, limiter les droits et prévoir la révocation. Ajouter la sécurité après l’ouverture conduit souvent à casser les usages ou à tolérer des dérogations durables.

L’arbitrage porte aussi sur le refus. Une donnée mal maîtrisée, un processus instable ou une application en fin de vie ne deviennent pas stratégiques parce qu’on les entoure d’une interface. Le dirigeant IT peut décider de différer l’exposition, d’imposer une remise en qualité ou de cantonner l’usage à un périmètre temporaire.

Installer un modèle de produit et de responsabilité

Une API sans propriétaire finit orpheline : personne n’assume sa documentation, ses évolutions, ses incidents ou la relation avec ses consommateurs. Chaque API critique doit avoir un responsable métier de la capacité, un responsable technique du service, des consommateurs identifiés et une politique de cycle de vie.

Cette politique précise les règles de versionnement, les délais de dépréciation, la compatibilité attendue et la procédure d’arrêt. Elle distingue aussi financement initial et exploitation récurrente. Le projet demandeur ne peut pas transférer silencieusement au DSI une charge permanente. Avant l’autorisation, le comité compétent doit savoir qui paiera la supervision, le support, les tests de non-régression et les adaptations futures.

Construire le socle minimal avant la plateforme idéale

Le DSI doit résister à deux excès : fabriquer chaque interface artisanalement ou acheter immédiatement une plateforme surdimensionnée. Le socle minimal comprend un registre fiable, des règles de nommage, une authentification cohérente, une gestion des secrets, des journaux exploitables, des limites de consommation et une chaîne de déploiement contrôlée. Il doit également permettre de retrouver rapidement qui consomme quoi.

On sélectionne quelques capacités réellement réutilisables, on définit les contrats de service, on sécurise leur exposition, puis on mesure l’usage avant d’étendre l’outillage. Les choix techniques doivent rester réversibles : formats documentés, contrats testables, données récupérables et dépendance fournisseur visible. Cette lecture rejoint l’approche de gouvernance défendue dans Révolution Numérique ! : relier les choix technologiques aux coûts, aux risques et aux dépendances plutôt que confondre modernité de l’outil et maîtrise du système d’information.

Mesurer la valeur sans compter seulement les API

Le nombre d’API publiées est un indicateur d’activité, pas de réussite. Le pilotage doit observer la réutilisation effective, le délai nécessaire pour raccorder un nouveau consommateur, la part des interfaces ayant un propriétaire actif, la conformité aux règles de sécurité, la stabilité en production et le volume d’anciennes interfaces réellement retirées. Un catalogue qui grossit sans consommateurs ni suppressions révèle souvent une usine à dette.

Les indicateurs doivent éclairer une décision. Une hausse des erreurs peut justifier un travail sur la qualité de la source plutôt qu’une nouvelle couche technique. Un temps d’intégration trop long peut révéler une documentation médiocre, des habilitations manuelles ou des environnements de test insuffisants. Une dépendance concentrée sur une plateforme peut imposer un scénario de sortie. Le tableau de bord utile relie ainsi usage, risque, coût d’exploitation et capacité de changement.

Trancher entre accélération et maîtrise

Les échecs les plus fréquents sont prévisibles : acheter avant de gouverner, exposer avant de fiabiliser, laisser les projets créer leurs propres standards, promettre une disponibilité que l’application source ne peut tenir, ou conserver indéfiniment toutes les versions. Chacun procure un gain immédiat et reporte la facture sur l’exploitation.

L’arbitrage final du DSI n’oppose donc pas innovation et contrôle. Il consiste à autoriser l’ouverture quand cinq conditions sont réunies : valeur métier explicite, source faisant autorité, propriétaire engagé, sécurité intégrée et coût de cycle de vie assumé. Si l’une manque, il faut la traiter ou réduire le périmètre. Une stratégie API crédible ne cherche pas à tout connecter. Elle rend les bonnes capacités accessibles, sous contrôle, et permet encore à l’entreprise de changer d’architecture, de partenaire ou de priorité sans reconstruire chaque relation.

Pour approfondir

Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon

Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon

Consulter la référence

Consulter la référence

#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique