L'accès programmatique aux données ouvertes : un levier sous-exploité
Les APIs sont aujourd'hui la porte d'entrée pour exploiter les jeux de données publics à grande échelle. Selon l'OCDE, plus de 70 % des portails open data gouvernementaux proposent un accès via API, contre moins de 30 % en 2015. Pourtant, la plupart des utilisateurs continuent de télécharger manuellement des fichiers CSV ou JSON, sans tirer parti des capacités d'automatisation que ces interfaces offrent.
Savoir interroger une API open data permet de maintenir des données fraîches en temps réel, d'automatiser des tâches répétitives et de construire des applications qui se mettent à jour sans intervention humaine. C'est ce que cette page explore, de façon concrète.
Ce qu'est concrètement une API open data
Définition technique simplifiée
Une API (Application Programming Interface) est un protocole de communication standardisé qui permet à deux systèmes de s'échanger des données. Dans le contexte open data, elle sert d'intermédiaire entre un serveur gouvernemental ou institutionnel et votre application, script ou tableau de bord analytique.
La majorité des APIs open data repose sur l'architecture REST (Representational State Transfer). Elles communiquent via HTTP et retournent des données structurées, principalement au format JSON ou XML. La requête se construit sous forme d'URL, ce qui la rend lisible et testable directement depuis un navigateur.
Les standards dominants dans l'écosystème public
Plusieurs standards s'imposent selon les types de données. OGC API Features (anciennement WFS) est privilégié pour les données géographiques. SPARQL gère les données liées (Linked Data), notamment sur data.gouv.fr ou le portail européen. OData apparaît fréquemment dans les portails institutionnels européens et américains.
Ces standards assurent une certaine interopérabilité entre plateformes. Un développeur familier avec OGC API peut interroger l'IGN français aussi bien que l'US Geological Survey sans réapprendre les bases.
Les principales plateformes open data accessibles par API
data.gouv.fr et l'API nationale française
Le portail national français expose une API REST documentée, accessible sans authentification pour la plupart des jeux de données. L'endpoint de base est https://www.data.gouv.fr/api/1/. Depuis ce point d'entrée, on peut lister les datasets, filtrer par organisation ou par tag, et récupérer les métadonnées associées à chaque ressource.
Un appel typique pour rechercher des jeux de données liés à la qualité de l'air ressemble à ceci :
GET https://www.data.gouv.fr/api/1/datasets/?q=qualite+air&page_size=20
La réponse retourne un objet JSON paginé avec les identifiants, descriptions et URLs de téléchargement direct.
Le portail européen data.europa.eu
Le portail européen agrège plus de 1,6 million de jeux de données provenant de 36 pays membres. Son API SPARQL permet des requêtes sémantiques complexes, tandis que l'API REST simplifie l'accès pour les cas d'usage courants. La documentation officielle propose des exemples en Python, R et curl, ce qui facilite la prise en main.
Wikidata Query Service et les données structurées mondiales
Wikidata est l'une des plus grandes bases de connaissances libres. Son endpoint SPARQL (https://query.wikidata.org/sparql) permet d'extraire des données structurées sur pratiquement tout sujet : géographie, personnalités, organisations, données scientifiques. Le service est gratuit mais impose un quota de 60 secondes de traitement par requête.
Comment structurer une requête API efficacement
Anatomie d'une requête REST open data
Une URL d'API REST se décompose en plusieurs éléments. L'endpoint de base est l'adresse du serveur hébergeant les données. La ressource désigne le type de données demandées (datasets, records, organizations). Les paramètres de requête couvrent les filtres, le tri, la pagination et le format de sortie. La clé API, enfin, est un jeton d'authentification lorsque requis.
Exemple structuré avec l'API OpenDataSoft, utilisée par de nombreuses collectivités françaises :
https://data.toulouse-metropole.fr/api/explore/v2.1/catalog/datasets/
?where=date_creation>2023-01-01
&order_by=modified DESC
&limit=50
&apikey=VOTRE_CLE
Gérer la pagination pour les grands volumes
Les APIs open data limitent généralement le nombre de résultats par appel, souvent entre 20 et 100 enregistrements. Pour récupérer un dataset complet, il faut mettre en place une boucle de pagination. Deux mécanismes coexistent : la pagination par offset (?page=2&page_size=100) et la pagination par curseur, plus performante sur les très grands volumes.
En Python, la bibliothèque requests couplée à une boucle while suffit pour automatiser ce processus. L'indicateur de fin de pagination se situe généralement dans un champ next ou has_more dans la réponse JSON.
Filtrer les données à la source plutôt qu'après extraction
Filtrer côté serveur via les paramètres de l'API réduit massivement la bande passante consommée et le temps de traitement local. La plupart des APIs open data supportent des opérateurs de comparaison (>, <, =), des recherches textuelles et des filtres géographiques par bounding box.
Sur l'API Hubeau (données sur l'eau en France), une requête géofiltrée pour les stations hydrométriques d'un département précis réduit la réponse de plusieurs milliers à quelques dizaines d'enregistrements pertinents.
Authentification et quotas : ce qu'il faut anticiper
Clés API et tokens OAuth
Beaucoup de plateformes open data proposent un accès public limité et un accès authentifié avec des quotas élargis. L'inscription est généralement gratuite. La clé API se transmet soit en paramètre d'URL (?apikey=xxx), soit dans les headers HTTP (Authorization: Bearer xxx), selon les standards de chaque plateforme.
Stocker ces clés en dur dans le code source est une mauvaise pratique. Les variables d'environnement ou les fichiers .env protègent contre les fuites accidentelles lors d'un commit Git.
Respecter les quotas pour éviter le blocage
Les portails imposent des limites : x requêtes par minute, y appels par jour. L'API de la Banque Mondiale autorise par exemple 10 000 appels par jour en accès libre. Dépasser ces seuils déclenche des erreurs HTTP 429 (Too Many Requests).
Deux pratiques s'imposent pour tout script de collecte en production : ajouter un délai entre les requêtes (time.sleep() en Python) et gérer les réponses d'erreur avec des mécanismes de retry exponentiels.
Outils et bibliothèques pour accélérer le développement
Python : l'environnement de référence
L'écosystème Python domine pour l'interrogation d'APIs open data. La bibliothèque requests gère les appels HTTP ; pandas transforme les réponses JSON en dataframes exploitables. Pour les données géographiques, geopandas et fiona permettent de manipuler les formats GeoJSON et GML retournés par les APIs OGC.
Des wrappers spécialisés existent pour les plateformes les plus populaires : eurostat pour le portail statistique européen, wbdata pour la Banque Mondiale, pynsee pour l'INSEE. Ces abstractions réduisent la quantité de code à écrire.
Outils no-code et low-code
Pour les analystes qui ne codent pas, des outils visuels permettent d'interroger des APIs sans écrire de code. Postman facilite l'exploration et le test des endpoints. Knime et Alteryx intègrent des connecteurs API graphiques. Power Query dans Excel ou Power BI peut également interroger directement des APIs REST via des connecteurs web.
Documentation et découverte des APIs
Avant d'interroger une API, il faut localiser sa documentation. Les portails OpenAPI/Swagger (/swagger-ui ou /docs) génèrent une interface interactive qui liste tous les endpoints disponibles avec leurs paramètres. Le catalogue APIs.guru recense plus de 2 400 APIs publiques documentées en OpenAPI Specification, dont une part significative concerne des données ouvertes.
Bonnes pratiques pour un pipeline open data fiable
Versionner et mettre en cache les réponses
Les données ouvertes évoluent : des jeux de données sont mis à jour, des endpoints disparaissent, des formats changent. Versionner les données extraites (avec une date dans le nom du fichier ou via un système comme DVC) permet de tracer l'historique et de détecter les ruptures.
Mettre en cache les réponses d'API évite de solliciter inutilement les serveurs publics et accélère les développements en local. La bibliothèque requests-cache en Python met en place ce mécanisme en deux lignes de configuration.
Documenter ses propres scripts d'extraction
Un script d'extraction non documenté devient rapidement inexploitable. Consigner l'URL de l'API source, la date de première utilisation, la fréquence de mise à jour des données et les transformations appliquées constitue un minimum de traçabilité, aussi bien pour le travail en équipe que pour la reproductibilité des analyses.
