API publiques : ouvrir les données de l’administration

La plupart des administrations échangent déjà des données entre elles. Elles le font par des fichiers envoyés par courriel, des exports déposés chaque nuit sur un serveur, des accès directs à une base accordés il y a des années à un service voisin. Ces échanges fonctionnent, jusqu’au jour où la personne qui les connaissait change de poste. Une API, une interface de programmation documentée, remplace ces pratiques par un contrat explicite. Encore faut-il une gouvernance des API publiques qui survive au premier projet.

Pourquoi la question se pose maintenant

Deux mouvements se rejoignent. Le premier est l’ouverture des données publiques : la directive (UE) 2019/1024 en fixe le cadre européen, et son règlement d’exécution (UE) 2023/138 impose, depuis le 9 juin 2024, que les ensembles de données de forte valeur (données géospatiales, d’observation de la Terre et d’environnement, météorologiques, statistiques, sur les entreprises, sur la mobilité) soient disponibles gratuitement, dans un format lisible par machine et par API. Le second est la simplification des démarches : ne plus demander à l’usager une pièce qu’une autre administration détient déjà suppose que cette administration puisse la fournir, de manière sûre et automatique. En France, les API mises à disposition des administrations par l’État pour récupérer des données sur les entreprises ou les particuliers en sont un exemple.

Dans les deux cas, l’API n’est pas un projet technique isolé. C’est un engagement durable envers des utilisateurs que l’on ne connaît pas toujours.

Trois catégories d’API, trois régimes

La première décision consiste à classer chaque API. Ce classement détermine presque tout le reste : la sécurité, la documentation, les engagements de service et le budget.

Les étapes d’une gouvernance qui tient

1. Inventorier ce qui existe déjà. Recenser les échanges de données en place, y compris les plus informels : exports nocturnes, fichiers partagés, accès directs aux bases. L’inventaire révèle les dépendances cachées et les données qui circulent sans contrôle.
2. Désigner un responsable pour chaque API. Un responsable métier, dans le service qui détient la donnée et en répond juridiquement, et un responsable technique. Une API sans responsable nommé finit toujours sans maintenance.
3. Écrire le contrat d’interface avant le code. Décrire les ressources, les paramètres, les réponses et les erreurs dans un format standard comme la spécification OpenAPI, puis faire relire ce contrat par de futurs utilisateurs. Corriger un contrat sur le papier coûte peu ; le corriger après publication oblige tous les utilisateurs à suivre.
4. Adopter des conventions communes. Nommage, format des dates (ISO 8601), pagination, codes d’erreur, langue de la documentation : un référentiel unique pour toutes les API de l’organisation rend chacune plus facile à utiliser et à maintenir.
5. Organiser l’accès et la sécurité. Pour les API restreintes : authentification de chaque appel (par exemple avec OAuth 2.0), habilitations liées à une base légale, réponses limitées aux données nécessaires, journalisation exploitable. Le Top 10 de l’OWASP consacré à la sécurité des API donne une liste de contrôle utile.
6. Fixer une politique de versions. Toute évolution incompatible donne lieu à une nouvelle version ; l’ancienne reste disponible pendant une durée annoncée à l’avance. Cette règle, écrite et publique, est ce qui rend une API digne de confiance pour un réutilisateur.
7. Publier et accompagner. Un catalogue, une documentation à jour, un environnement de test, des conditions d’utilisation et une licence claire pour les données ouvertes (en France, la Licence Ouverte d’Etalab, par exemple). Un point de contact qui répond.
8. Mesurer et rendre compte. Disponibilité, temps de réponse, volume d’appels, nombre de réutilisateurs, incidents. Ces indicateurs justifient le budget d’exploitation et signalent les API à faire évoluer ou à arrêter.

Une API publique est une promesse faite à des inconnus : ils bâtiront dessus des services que vous ne verrez jamais.

Le budget oublié : l’exploitation

Les projets d’API sont souvent financés comme des investissements : un développement, une mise en ligne, une inauguration. Le coût principal vient ensuite : hébergement, supervision, support aux réutilisateurs, mises à jour de sécurité, évolutions du contrat quand la donnée change. Une API ouverte qui tombe en panne un vendredi soir pénalise des services tiers qui n’ont aucun moyen de la réparer.

La règle à adopter est simple : pas de publication sans budget d’exploitation identifié sur plusieurs années, et sans niveau de service annoncé, même modeste. Mieux vaut un engagement de disponibilité limité et tenu qu’une promesse implicite que personne ne peut honorer.

Qui décide : l’organisation de la gouvernance

La gouvernance des API ne demande pas une nouvelle direction. Elle demande trois fonctions clairement attribuées. Une fonction transverse, souvent rattachée à la direction du numérique, tient le référentiel commun, le catalogue et les règles de sécurité, et arbitre les cas difficiles. Les services détenteurs de données restent responsables de leurs API, de la qualité de la donnée et des habilitations. Une instance de décision, qui peut être un comité existant, tranche les priorités : quelles données ouvrir d’abord, quelles API arrêter, quels investissements consentir.

Les arbitrages de cette instance doivent être tracés : qui a autorisé l’ouverture de telle donnée, sur quelle base, à quelle date. C’est ce qui permet, des années plus tard, de répondre à un auditeur ou à un usager qui demande pourquoi ses données circulent.

Le premier pas

Commencer petit et visible : choisir une donnée très demandée, qu’un service détient avec une bonne qualité et dont l’ouverture ne pose pas de question juridique. La publier proprement, avec un contrat, une documentation et des indicateurs, et s’en servir comme modèle pour la suivante.

Pour accompagner cette mise en place au sein de vos équipes, jusqu’à ce qu’elles l’exploitent seules, notre façon de travailler en équipes déployées est conçue pour ce type de chantier. Pour tracer les décisions d’ouverture et d’habilitation, notre produit Gouvernance conserve qui a décidé quoi, quand et sur quelle base.

Questions fréquentes

Une administration doit-elle ouvrir ses données par API ?

Pour certaines, c'est une obligation : dans l'Union européenne, les ensembles de données de forte valeur définis par le règlement d'exécution (UE) 2023/138 doivent être disponibles gratuitement par API depuis juin 2024. Au-delà, l'API est souvent le moyen le plus fiable d'appliquer le principe « dites-le-nous une fois » entre administrations.

Faut-il une équipe dédiée aux API ?

Il faut au moins une fonction identifiée qui tient le référentiel commun (conventions, sécurité, catalogue) et arbitre les choix transverses. Chaque API garde ensuite un responsable métier et un responsable technique dans le service qui détient la donnée.

Comment protéger une API qui expose des données personnelles ?

En la réservant à des utilisateurs habilités sur une base légale précise, en authentifiant chaque appel, en ne renvoyant que les données nécessaires à la démarche, et en journalisant les accès pour pouvoir répondre de chacun. Le référentiel de l'OWASP sur la sécurité des API décrit les failles les plus fréquentes.

Que faire d'une API que plus personne ne maintient ?

La traiter comme un risque : identifier ses utilisateurs, décider de la reprendre ou de l'arrêter, et dans ce second cas annoncer une date de fin avec un préavis suffisant. Une API abandonnée mais toujours ouverte est une porte que personne ne surveille.