API Sirene INSEE : quotas, limites, pannes (et comment s’en affranchir)

Ce que l’API Sirene de l’INSEE offre vraiment

L’API Sirene est le service par lequel l’INSEE expose, entreprise par entreprise, le contenu du répertoire Sirene : unités légales (SIREN), établissements (SIRET), adresses, codes NAF, tranches d’effectif, dates de création et de fermeture. D’après la documentation publiée par l’INSEE sur son portail API, la version en service est la 3.11. L’accès s’obtient en créant un compte puis une « application », ce qui génère une clé d’API à transmettre dans l’en-tête de chaque requête. Les données sont mises à jour quotidiennement et l’offre de base ne coûte rien.

Gratuit ne veut pas dire sans contrepartie. L’offre publique s’accompagne de trois limites structurantes : un quota d’appels par minute, l’absence de tout engagement de disponibilité, et une mise en œuvre qui suppose un développeur pour gérer l’authentification, la pagination et l’historique des données. Le reste de cet article détaille chacune de ces limites, puis les deux façons concrètes de s’en affranchir.

Le quota réel : 30 requêtes par minute

Le chiffre à retenir est simple : 30 requêtes par minute pour l’offre gratuite de l’API Sirene, selon les conditions d’utilisation affichées sur le portail API de l’INSEE. Au-delà, le serveur répond par un code HTTP 429 (Too Many Requests) et ignore la requête, qu’il faut alors rejouer après une pause. Ramené à des volumes de fichiers, ce plafond change tout.

• 1 000 SIRET à vérifier : environ 34 minutes, à condition d’enchaîner les appels sans interruption.
• 10 000 SIRET : plus de 5 heures et demie.
• 50 000 SIRET : près de 28 heures, soit plus d’une journée complète de traitement, sans compter les erreurs réseau à rejouer.

Le quota se compte par clé, pas par utilisateur : une application partagée entre plusieurs services de l’entreprise consomme le même plafond. La recherche multicritère (par nom, par commune, par code NAF) obéit aux mêmes règles, avec une contrainte supplémentaire : chaque réponse est limitée à 1 000 résultats par page, et au-delà de 10 000 résultats il faut basculer sur une pagination par curseur, plus délicate à programmer.

Tableau récapitulatif : les limites des sources Sirene gratuites

Indisponibilités : ce que l’INSEE ne garantit pas

L’offre gratuite ne prévoit aucun engagement de disponibilité. Concrètement, trois types d’interruptions reviennent régulièrement :

• Les maintenances programmées, annoncées sur le portail et souvent placées la nuit ou le week-end, mais qui bloquent tout traitement lancé au mauvais moment.
• Les incidents non planifiés : ralentissements, erreurs 500 ou 503, réponses tronquées pendant les mises à jour quotidiennes de la base.
• Les migrations de plateforme. En 2024, l’INSEE a remplacé son ancien portail, fondé sur des jetons OAuth2 à renouveler tous les sept jours, par un nouveau portail où l’authentification repose sur une clé d’API. Chaque intégration existante a dû être réécrite sous peine de cesser de fonctionner.

Pour un usage ponctuel, ces coupures se contournent en réessayant plus tard. Pour un traitement automatisé qui alimente un ERP ou un CRM, elles imposent de programmer des reprises sur erreur, une file d’attente et une supervision. Sans cela, une panne d’une heure laisse des centaines de lignes non vérifiées sans que personne ne s’en aperçoive.

La complexité cachée : authentification, pagination, historisation

Le quota n’est que la partie visible. Une intégration robuste de l’API Sirene demande de traiter au moins neuf points, dont plusieurs tiennent à la manière dont l’INSEE structure ses données.

1. Authentification : créer l’application, stocker la clé en sécurité, la transmettre dans l’en-tête X-INSEE-Api-Key-Integration et prévoir sa rotation.
2. Respect du quota : espacer les appels d’au moins deux secondes, détecter les codes 429 et rejouer avec un délai croissant.
3. Pagination : gérer le paramètre de taille de page, puis le curseur pour les recherches qui dépassent 10 000 résultats.
4. Historisation : chaque établissement porte une liste de périodes avec date de début et date de fin. Le statut actif ou fermé, l’enseigne ou le code NAF ont pu changer plusieurs fois ; il faut lire la bonne période, ou interroger l’API à une date précise.
5. Diffusion partielle : certaines personnes physiques ont demandé la non-diffusion de leurs données, comme le permet le code de commerce publié sur Légifrance. Leur nom et leur adresse reviennent masqués, ce qu’un programme doit interpréter sans conclure à une erreur.
6. Codes d’erreur : distinguer un 404 (SIRET inconnu) d’un 400 (format invalide) et d’un 503 (service indisponible), car la conséquence métier diffère.
7. Nettoyage en amont : retirer les espaces et restaurer les zéros de tête perdus dans Excel avant l’appel, sinon la requête échoue sur un identifiant pourtant correct.
8. Enrichissement croisé : le numéro de TVA intracommunautaire ne figure pas dans Sirene ; il se calcule à partir du SIREN puis se contrôle auprès d’une autre source.
9. Maintenance dans le temps : suivre les changements de version (la 3.11 a succédé à la 3.0) et les migrations de portail.

Un appel unitaire tient en une ligne, ce qui donne une impression trompeuse de simplicité. Le SIRET ci-dessous est un exemple fictif :

curl -H "X-INSEE-Api-Key-Integration: VOTRE_CLE" "https://api.insee.fr/api-sirene/3.11/siret/12345678900015"

Tout ce qui précède vient s’ajouter autour de cette ligne. Comptez plusieurs jours de développement pour une première version fiable, puis un entretien régulier. C’est un investissement raisonnable pour un éditeur de logiciel ; il devient disproportionné pour un service comptable qui doit contrôler un fichier fournisseurs une fois par trimestre.

Issue n°1 : construire votre propre intégration

Si la vérification de SIRET doit vivre au cœur de votre produit (un parcours d’inscription client, un module achats, un CRM maison), l’API reste le bon choix, à condition de traiter la liste ci-dessus comme un cahier des charges et non comme des détails. Deux alternatives publiques allègent la tâche. L’API Recherche d’entreprises, opérée par la DINUM, fonctionne sans authentification avec un plafond documenté de 400 requêtes par minute et par adresse IP, soit plus de dix fois celui de l’INSEE ; elle renvoie une fiche synthétique par entreprise, mais pas l’historique complet des périodes. Pour les traitements exhaustifs, les fichiers stock publiés chaque mois sur data.gouv.fr permettent de charger la base Sirene entière dans votre propre système, au prix de plusieurs gigaoctets à indexer et d’une fraîcheur seulement mensuelle.

Avant d’écrire la première ligne, notre guide pour intégrer la vérification d’entreprise dans vos propres logiciels compare ces API publiques et détaille les bonnes pratiques d’appel, de cache et de reprise sur erreur.

Issue n°2 : le no-code en masse, sans quota

Pour tous les autres cas, le fichier est la bonne unité de travail. Le besoin réel d’un comptable, d’un acheteur ou d’un responsable CRM n’est pas d’appeler une API : c’est de récupérer son tableau avec, pour chaque ligne, le statut de l’établissement, l’adresse à jour, le code NAF, la dénomination officielle et le numéro de TVA. Trouve-ton-siret.com répond exactement à ce besoin : vous importez un fichier de SIRET, de SIREN ou de numéros de TVA, l’outil interroge la base Sirene via l’API officielle recherche-entreprises.api.gouv.fr, gère lui-même le rythme des appels, et vous rend le fichier enrichi en quelques minutes, exportable en CSV ou en JSON. Le quota de 30 requêtes par minute disparaît de votre horizon, puisqu’il n’est plus votre problème.

La différence se mesure sur un cas simple. Un fichier de 5 000 fournisseurs exige près de trois heures d’appels ininterrompus sur l’API de l’INSEE, plus le développement préalable ; le même fichier passe en quelques minutes quand vous choisissez de confier votre liste complète à la recherche SIRET en masse, sans compte développeur ni script à maintenir. Nous détaillons ailleurs le fonctionnement de cet import de fichier quand le quota bloque, y compris les formats acceptés et les colonnes renvoyées.

Comment choisir entre les deux

• Vous êtes éditeur ou vous avez une équipe technique, et la vérification doit se déclencher à chaque saisie dans votre logiciel : construisez l’intégration, en privilégiant l’API Recherche d’entreprises pour le débit et l’API Sirene de l’INSEE pour l’historique.
• Vous traitez des fichiers, à l’occasion d’un audit fournisseurs, d’une migration de CRM ou d’une campagne de nettoyage avant la facturation électronique : l’import en masse vous rend le résultat le jour même, sans dépendre du quota ni des maintenances.
• Vous hésitez : commencez par l’import de fichier. Il ne coûte rien, ne demande aucun code, et vous saurez en quelques minutes si votre base mérite un contrôle plus profond.

L’API Sirene reste une ressource publique précieuse, et l’INSEE la maintient avec sérieux. Ses limites ne sont pas des défauts, mais des choix de dimensionnement pour un service gratuit ouvert à tous. Le tout est de ne pas les découvrir au milieu d’un traitement de 40 000 lignes, la veille d’une échéance.

Questions fréquentes