API Sirene devient critique dès qu'un CRM, un ERP, une plateforme B2B, un portail fournisseur, un module KYC ou un back-office commercial utilise SIREN, SIRET, unité légale, établissement, adresse, état administratif ou activité principale pour accepter, enrichir, segmenter ou bloquer une relation entreprise.
Les sources officielles confirment un périmètre riche: l'API Sirene donne accès au répertoire Sirene géré par l'INSEE, avec recherche par SIREN, recherche par SIRET, requêtes multicritères, recherche phonétique, service informations, liens de succession et données enregistrées depuis 1973, y compris des unités fermées.
Le risque n'est donc pas de savoir appeler un endpoint REST. Le vrai risque consiste à confondre unité légale et établissement, siège et établissement secondaire, identifiant valide et identifiant actif, résultat courant et période historique, ou encore donnée publique et donnée à rediffuser avec prudence.
Le bon arbitrage consiste à comprendre quoi décider, quoi bloquer et quoi corriger avant production: clé `X-INSEE-Api-Key-Integration`, quota open data, endpoint 3.11, paramètre `date`, requête `q`, paramètre `champs`, pagination, date de dernière mise à disposition, statut de diffusion, liens de succession, codes 301, 404, 429 et reprise différentielle, avec une décision métier pour chaque famille de réponse.
Pour poser ce cadre sans bricolage, notre accompagnement en intégration API aide à écrire les contrats, mappings, seuils, retries, dashboards, preuves et runbooks nécessaires. Le sujet rejoint la landing API services publics et Open Data et la page intégrateur INSEE Sirene, parce que la valeur vient d'un référentiel B2B gouverné, pas seulement d'une fiche établissement retournée en JSON.
Pour qui API Sirene devient critique
API Sirene devient prioritaire pour les équipes qui créent ou contrôlent des comptes entreprises: sales operations, finance, achats, conformité, marketplace B2B, portail fournisseur, base partenaires, logistique professionnelle et data warehouse orienté clients ou fournisseurs.
Le signal faible apparaît quand plusieurs systèmes affichent la même société avec des noms, adresses, sièges, établissements ou statuts différents. L'équipe croit traiter une anomalie de saisie, alors qu'elle gère souvent une divergence entre référentiel public, modèle interne et usage métier.
Le coût complet vient des doublons de comptes, des factures rattachées au mauvais établissement, des contrôles KYC relancés, des campagnes envoyées à une entité fermée, des contrats signés sur un siège obsolète ou des dashboards qui agrègent mal une famille de SIRET.
Le déclencheur de priorité est simple: si une erreur SIREN/SIRET peut changer une commande, une facture, un risque crédit, une attribution commerciale, une livraison ou un reporting de direction, alors API Sirene doit être exploitée comme un référentiel de production avec owner, seuils, trace, purge et rollback.
1. SIREN, SIRET et objets Sirene
Séparer unité légale et établissement
Le premier cadrage consiste à distinguer l'unité légale, identifiée par un SIREN de 9 chiffres, et l'établissement, identifié par un SIRET de 14 chiffres. Cette séparation doit exister dans le modèle interne avant tout enrichissement.
Une entreprise peut porter plusieurs établissements, et chaque établissement peut avoir sa propre adresse, son propre état administratif et une relation différente avec les équipes commerciales, financières ou logistiques. Un seul champ "société" finit vite par perdre cette granularité.
Le connecteur doit donc relier SIREN, SIRET, siège, établissement actif, établissement fermé, raison sociale, enseigne, adresse, activité principale, période historique et source interne. Sinon, un contrôle valide techniquement peut produire une décision métier fausse.
Traiter l'historique sans écraser le courant
API Sirene expose des informations courantes et certaines variables historisées. Le connecteur doit savoir si le besoin porte sur la situation actuelle, sur une situation à une date donnée, ou sur un historique utile pour expliquer une décision passée.
Le paramètre `date` des appels unitaires permet de demander la période comprenant cette date. Cette capacité est précieuse quand un litige porte sur une facture ancienne, un contrat signé avant un transfert ou une décision prise avec l'état connu à l'époque.
Si un traitement remplace systématiquement l'ancien état par l'état courant, alors la preuve devient fragile. L'équipe doit conserver le contexte de décision, la date d'appel, la période utilisée et la règle qui a consommé la réponse Sirene.
Respecter diffusion partielle et rediffusion
Les fiches data.gouv rappellent que les personnes inscrites au répertoire ayant demandé le statut de diffusion partielle ne doivent pas voir leurs informations personnelles rediffusées entièrement ni utilisées à des fins de prospection.
Cette règle change le mapping. Le connecteur doit distinguer donnée technique reçue, donnée affichable, donnée conservable, donnée exclue du marketing et donnée supprimée des exports, surtout pour les personnes physiques entrepreneuriales.
Si un flux marketing ignore le statut de diffusion pendant 7 jours, alors le risque de conformité dépasse le simple bug d'enrichissement. La priorité est de bloquer l'usage aval, purger les exports concernés et corriger la règle d'exposition.
2. Accès catalogue, clé et quota public
Créer une application et souscrire
L'accès actuel passe par le catalogue des API de l'INSEE. La procédure publique demande de créer une application, de souscrire à API Sirene, de choisir le plan Public disponible et de récupérer une clé API rattachée à cette souscription.
Cette clé doit être traitée comme un secret d'intégration: coffre, rotation possible, révocation, séparation des environnements, propriétaire identifié et audit d'usage. Un copier-coller dans un job ponctuel rend la reprise beaucoup plus difficile.
Le header actuel indiqué par la documentation de connexion publique est `X-INSEE-Api-Key-Integration`. Le connecteur doit centraliser son injection, journaliser l'application appelante et éviter que plusieurs traitements critiques partagent une clé sans traçabilité.
Dimensionner le quota open data
La fiche data.gouv annonce une limite de 30 requêtes par minute pour les usages open data, avec une disponibilité indiquée à 99,5 %. Ces deux chiffres doivent devenir des paramètres de run, pas une note oubliée dans un ticket.
Le connecteur doit séparer les appels interactifs, les enrichissements de masse, les reprises nocturnes et les contrôles de cohérence. Mélanger ces usages dans la même cadence rend les 429 plus probables et moins explicables.
Si plus de 3 pics de quota en 24 heures bloquent des validations client, alors le seuil de priorité support est dépassé. L'équipe doit corriger cadence, queue, cache et priorisation avant d'ajouter un nouveau cas d'usage.
Gérer JSON, gzip et Accept
La documentation des appels unitaires indique un service REST en HTTPS, une réponse JSON avec `Accept: application/json` et la possibilité de demander une compression gzip via `Accept-Encoding`. Ces détails doivent être configurés de manière explicite.
La compression peut aider les traitements volumineux, mais elle ne doit pas masquer l'observabilité. Le monitoring doit garder statut HTTP, taille utile, latence, endpoint, paramètres, nombre de résultats et trace de corrélation.
Une erreur 406 liée à un header `Accept` incorrect ne doit pas arriver en production. Elle doit être couverte en recette, parce qu'elle signale un contrat technique mal stabilisé plutôt qu'un problème du référentiel Sirene.
3. Recherche unitaire, date et historique
Appeler une unité légale par SIREN
L'appel unitaire par SIREN utilise l'URL 3.11 dédiée à `/siren/{siren}`. Le paramètre obligatoire est un SIREN de 9 chiffres; le paramètre facultatif `date`, au format AAAA-MM-JJ, renvoie la période comprenant cette date.
Le connecteur doit valider longueur, chiffres, présence, checksum si la règle interne l'impose, source de saisie et usage métier. Appeler l'API avec un identifiant manifestement invalide consomme du quota sans améliorer la qualité.
La réponse doit alimenter un statut interne: unité légale trouvée, doublon purgé, non trouvée, accès interdit, erreur de format, quota atteint ou service indisponible. L'agent ne doit jamais lire uniquement le code HTTP brut.
Appeler un établissement par SIRET
L'appel unitaire par SIRET utilise l'URL 3.11 dédiée à `/siret/{siret}`. Le paramètre obligatoire est un SIRET de 14 chiffres, avec le même paramètre `date` quand le besoin porte sur une période historique précise.
Le modèle doit relier établissement, unité légale, siège, adresse et état administratif. C'est souvent la différence entre un compte B2B propre et une base qui mélange siège juridique, lieu de livraison et établissement facturé.
Si un SIRET fermé reste utilisé pour créer des commandes pendant 7 jours, alors le seuil de qualité commerciale est dépassé. Le flux doit bloquer la création, proposer un établissement actif ou envoyer le dossier vers revue humaine.
Choisir le bon moment de vérité
Une donnée Sirene peut servir à valider un compte aujourd'hui, mais aussi à expliquer une facture, une aide, une livraison ou une relation commerciale passée. Le connecteur doit donc conserver la date de consultation et la période retournée.
Le bon design distingue vérité courante, vérité au jour du contrat, vérité au jour de facturation et vérité affichée dans un écran support. Sans cette nuance, une correction Sirene peut rendre incompréhensible une décision pourtant correcte au moment où elle a été prise.
Le seuil de recette est concret: 10 cas avec `date`, 10 cas sans `date`, zéro écrasement silencieux d'une période passée et une phrase support expliquant pourquoi la valeur affichée correspond au bon moment de vérité.
4. Multicritère, phonétique et champs
Encadrer le paramètre q
Les recherches multicritères utilisent le paramètre `q`, avec une syntaxe fondée sur les variables Sirene. Les mots clés AND et OR sont autorisés, et les variables historisées demandent une attention particulière avec la fonction de période documentée pour rechercher dans les blocs historiques.
Cette puissance doit être gouvernée. Une recherche trop large peut consommer du quota, produire trop de candidats ou créer des rapprochements douteux entre sociétés portant des noms proches mais des identités administratives différentes.
Si plus de 5 % des rapprochements multicritères sont corrigés manuellement sur 30 jours, alors le seuil de précision est dépassé. Le scoring, les filtres, les libellés et la revue humaine doivent être revus avant automatisation complète.
Utiliser la recherche phonétique avec prudence
La documentation Sirene décrit une recherche phonétique sur plusieurs variables, comme la dénomination, le nom, le prénom, l'enseigne, la commune ou la voie selon le niveau unité légale ou établissement. Elle aide quand l'utilisateur saisit mal un nom.
La recherche phonétique ne doit pas devenir une validation automatique. Elle doit produire des candidats, des scores ou des motifs de rapprochement, puis laisser la décision finale à une règle explicite ou à un agent si le risque est élevé.
Le signal faible apparaît quand les équipes fusionnent deux comptes "qui se ressemblent" sans preuve SIREN/SIRET stable. Cette pratique réduit temporairement les doublons, mais elle peut casser facturation, droits d'accès et reporting.
Limiter les champs retournés
Le paramètre `champs` permet de restreindre les variables retournées. La documentation précise qu'un libellé inconnu renvoie une erreur 400, et que certaines variables englobantes apparaissent seulement si les variables concernées sont demandées.
Cette capacité sert la minimisation et la performance. Le connecteur doit demander les variables utiles au cas métier: SIREN, SIRET, dénomination, état administratif, adresse, activité principale, siège, date de création ou période utile.
Si un traitement conserve toutes les variables par défaut sans usage identifié, alors la dette de donnée est à corriger. Le mapping doit indiquer champ reçu, champ exposé, champ conservé, champ purgé et owner de chaque décision.
5. Mises à jour et service informations
Lire les dates de rafraîchissement
Le service informations de l'API Sirene distingue les états des collections et les dates de rafraîchissement. Il expose notamment `dateDerniereMiseADisposition`, `dateDernierTraitementMaximum` et `dateDernierTraitementDeMasse`, que le run doit relier aux fenêtres de synchronisation, aux alertes de fraîcheur et aux reprises différentielles.
Ces dates doivent piloter les traitements différentiels. Une synchronisation qui ignore la date de mise à disposition peut lire une page juste avant un basculement quotidien puis la page suivante juste après, avec un risque de doublon ou d'écart.
Le dashboard doit afficher collection disponible, dernière mise à disposition, dernier traitement maximum, traitement de masse, lag interne, volume à reprendre, erreurs et temps de rattrapage. Sans cela, la fraîcheur reste une impression.
Construire la mise à jour différentielle
La documentation recommande d'utiliser `dateDernierTraitementUniteLegale` et `dateDernierTraitementEtablissement` pour déterminer les unités modifiées depuis une date de référence et mettre à jour une copie interne du référentiel.
Les volumes indiqués sont opérationnels: environ 20 000 unités mises à jour quotidiennement pour chacune des collections, et depuis le 7 avril 2025 une volumétrie supplémentaire d'environ 25 000 établissements le lundi liée à un traitement interne.
Si le backlog différentiel dépasse 2 jours ouvrés, alors le seuil de fraîcheur B2B est dépassé et la cadence est à corriger. L'équipe doit ajuster pagination, priorité, stockage temporaire et reprise avant de dépendre de cette copie interne.
Prévoir les traitements de masse
Le service informations signale aussi les traitements de masse, qui peuvent intervenir entre 1 et 3 fois dans l'année. La documentation indique qu'ils peuvent concerner plus de 200 000 unités légales et leurs établissements.
Un connecteur mature doit distinguer mise à jour quotidienne et mise à jour exceptionnelle. Le même worker, la même alerte et la même fenêtre de traitement ne conviennent pas forcément quand le volume explose.
Si un traitement de masse s'ouvre sans fenêtre dédiée, alors le risque est de saturer les appels interactifs. La priorité doit aller aux validations utilisateur, puis aux reprises essentielles, puis aux enrichissements non bloquants.
6. Liens de succession et continuité
Comprendre les liens prédécesseur successeur
Le service liens de succession permet de connaître, pour un établissement donné, les SIRET prédécesseurs et successeurs présents dans le répertoire Sirene. La documentation précise que tous les liens ne sont pas forcément connus de l'INSEE.
Les liens peuvent être créés quand deux établissements d'unités légales différentes se succèdent à une même adresse, ou quand deux établissements d'une même unité légale se succèdent à des adresses différentes. Le transfert de siège peut aussi être indiqué.
Cette information doit être exploitée comme une piste de continuité, pas comme une fusion automatique. Elle aide le support à comprendre pourquoi un établissement disparaît, se déplace ou laisse place à un successeur administratif.
Traduire succession en décision métier
Un SIRET successeur ne signifie pas toujours que les contrats, tarifs, droits ou responsabilités doivent être transférés. Le connecteur doit produire une décision: proposer le successeur, demander validation, bloquer la migration ou conserver l'ancien rattachement.
La réponse peut inclure le SIRET prédécesseur, le SIRET successeur, la date du lien, l'indicateur de transfert de siège et des informations de continuité économique selon la recherche. Ces champs doivent rejoindre une table de transition.
Si plus de 3 migrations d'établissement sur 30 jours demandent une correction commerciale, alors le seuil de qualité est dépassé et la règle de succession est à corriger avant d'automatiser un nouveau portefeuille.
Éviter les fusions trop agressives
Le risque classique consiste à fusionner deux fiches sur une adresse ou une ressemblance de nom, puis à découvrir que la relation commerciale, la dette, la facture ou l'autorisation ne devait pas suivre le même chemin.
Le bon workflow présente la preuve: ancien SIRET, nouveau SIRET, type de lien, date, transfert de siège, données internes concernées, impacts attendus et décision autorisée. La fusion devient un acte gouverné, pas un nettoyage discret.
Une succession doit toujours rester réversible pendant la période de stabilisation. Le rollback doit pouvoir restaurer le rattachement précédent, isoler une facture, retirer un alias ou remettre le compte en revue humaine.
7. Codes retour, 301, 404 et 429
Traiter 301 comme une correction de doublon
Les codes retour Sirene indiquent notamment 301 quand le SIREN correspond à une unité légale purgée pour cause de doublon, avec une information de localisation vers l'unité doublonnée ou l'établissement siège selon le cas documenté.
Le connecteur ne doit pas ignorer cette redirection. Elle peut corriger une fiche interne, mais elle doit laisser une trace: identifiant initial, identifiant cible, date, écran impacté, décision support et éventuelle validation métier.
Si plus de 5 redirections 301 sont appliquées sans journal en 30 jours, alors le seuil d'audit est dépassé. L'équipe doit bloquer la correction silencieuse et rendre la substitution visible dans les dossiers concernés.
Distinguer 400, 401, 403 et 406
Un 400 signale des paramètres incorrects, une variable mal orthographiée, inexistante ou mal utilisée. Un 401 signale une clé manquante ou invalide, un 403 un droit insuffisant, et un 406 un header `Accept` non prévu.
Ces erreurs ne doivent pas arriver au support sous forme de message unique. Le back-office doit indiquer si l'action relève d'une correction de requête, d'une clé à régénérer, d'une souscription à vérifier ou d'un contrat HTTP à corriger.
Le seuil de recette est simple: 4 familles d'erreur simulées, 4 messages distincts, zéro donnée métier modifiée et une escalade claire vers l'équipe responsable. Sinon, le go-live reste prématuré.
Interpréter 404, 414, 429, 500 et 503
Un 404 peut signifier une entreprise non trouvée dans Sirene, ou une date antérieure à la création quand le paramètre date est utilisé. Un 414 indique une requête trop longue, un 429 un quota dépassé, 500 une erreur interne et 503 une indisponibilité.
Le connecteur doit traduire chaque statut en action: corriger la requête, réduire les critères, attendre le quota, relancer plus tard, afficher une attente ou passer en revue manuelle. Aucun de ces codes ne doit devenir automatiquement un refus client définitif.
Si plus de 3 réponses 429 en 24 heures déclenchent des relances immédiates, alors le seuil de risque run est dépassé et le worker est à corriger. Une file idempotente doit respecter l'attente et préserver la décision précédente.
8. Plan d'action API Sirene
Cartographier les usages SIREN/SIRET
Commencez par lister les décisions qui consomment Sirene: création compte, enrichissement prospect, validation fournisseur, contrôle facturation, rattachement établissement, vérification siège, segmentation commerciale, scoring risque et export data warehouse.
La cartographie doit relier chaque usage à son niveau: unité légale, établissement, siège, période historique, recherche multicritère, recherche phonétique, lien de succession ou mise à jour différentielle. Cette granularité évite les raccourcis dangereux.
Le livrable attendu tient dans une matrice: endpoint, paramètre, clé interne, champ demandé, champ conservé, champ purgé, statut métier, owner, quota, cache, retry, rollback, preuve, message support et impact business. Cette matrice montre immédiatement les usages trop flous.
- À valider d'abord: SIREN, SIRET, unité légale, établissement, siège, état administratif, adresse et statut de diffusion.
- À bloquer avant ouverture: toute fusion ou redirection 301 sans trace, owner, décision support et rollback possible.
- À corriger avant extension: tout 404, 400 ou 429 traduit en refus alors qu'une correction ou attente est nécessaire.
- À différer volontairement: les recherches phonétiques qui créent trop de candidats sans preuve SIREN/SIRET stable.
Écrire les contrats de réponse
Le deuxième jalon consiste à écrire les contrats: SIREN trouvé, SIRET trouvé, période à date, établissement fermé, unité légale cessée, diffusion partielle, lien de succession, 301, 400, 401, 403, 404, 406, 414, 429, 500 et 503.
Chaque contrat doit préciser input, output, responsabilités, seuils, journalisation, idempotence, retry, queue, endpoint, payload conservé, mapping, message agent, message client, décision autorisée, action interdite et rollback.
Le contrat doit contenir un cas nominal et un cas dégradé par famille: identifiant invalide, quota atteint, donnée absente, établissement remplacé, recherche trop large, variable inconnue, clé révoquée, service indisponible et traitement de masse.
Il doit aussi préciser qui tranche quand la réponse est ambiguë: sales operations, finance, conformité, support technique, data steward ou responsable référentiel. Cette responsabilité évite que la décision reste cachée dans une règle de mapping.
Construire monitoring et preuves
Le troisième jalon porte sur l'exploitation: volume par endpoint, taux 200, redirections 301, erreurs 400, 404, 429, latence, taille des réponses, backlog différentiel, âge de fraîcheur, résultats phonétiques et corrections manuelles.
Les alertes doivent dire quoi faire. Si 429, alors attente et priorité. Si 301, alors trace et validation. Si 404, alors contrôle du numéro ou de la date. Si traitement de masse, alors fenêtre dédiée et limitation des appels interactifs.
La preuve doit être lisible hors logs bruts: identifiant reçu, identifiant retenu, source interne, endpoint appelé, date de consultation, date Sirene utilisée, statut retourné, décision métier, éventuelle purge et personne responsable.
Limiter la première ouverture
La première mise en production doit prouver un périmètre court: validation SIRET, enrichissement unité légale, statut établissement, un cas 301, un cas 404, un cas 429, une recherche multicritère contrôlée et une mise à jour différentielle.
Le go-live doit être conditionné par des critères vérifiables: clé isolée, quota respecté, champs minimisés, erreurs traduites, diffusion partielle protégée, dashboard prêt, support formé et rollback testé sur une fiche réelle.
Le risque est de croire qu'un référentiel public suffit. Une intégration API Sirene mature sait aussi refuser la fusion, temporiser une reprise, purger une donnée inutile et expliquer pourquoi un établissement ne doit pas être traité comme une simple société.
9. Exemple API Sirene en production
Enrichir un onboarding fournisseur
Prenons un portail fournisseur qui demande un SIRET à l'inscription. Le back-office interroge API Sirene, retrouve l'unité légale, vérifie l'établissement, affiche l'adresse et rattache le fournisseur à une fiche interne.
Le scénario nominal est simple, mais les variantes coûtent cher: SIRET fermé, SIREN valide mais mauvais établissement, diffusion partielle, recherche phonétique trop large, 301 de doublon, 404 avec date historique ou 429 pendant un pic.
Le bon résultat n'est pas seulement une fiche préremplie. Le dossier doit montrer SIREN, SIRET, niveau utilisé, endpoint, période éventuelle, statut administratif, champs conservés, décision fournisseur, preuve et action support autorisée.
Décider ce qui bloque le go-live
Cas concret: l'API retourne 301 sur un SIREN purgé pour doublon. Le flux ne doit pas remplacer l'identifiant sans trace; il doit enregistrer l'identifiant initial, la cible, la date et l'impact sur les contrats internes.
Le seuil de lancement doit être lisible: zéro clé partagée sans owner, aucun 301 silencieux, aucun 404 converti en rejet définitif sans contrôle, aucun 429 sans file d'attente et aucune donnée de diffusion partielle poussée en prospection.
Cette discipline protège la base autant que les équipes. Elle réduit les doublons sans automatiser une confusion entre siège, établissement, unité légale, ancien identifiant et relation commerciale réellement active.
Afficher la preuve dans la fiche
La fiche fournisseur doit présenter une chronologie simple: SIRET saisi, validation de format, appel Sirene, réponse reçue, statut, éventuelle redirection, champs utilisés, décision métier et mise à jour interne.
Les statuts visibles doivent rester peu nombreux: vérifié, établissement fermé, unité légale cessée, identité à confirmer, diffusion partielle, quota atteint, service indisponible, recherche ambiguë, succession détectée et action interdite.
Si un agent ne peut pas expliquer la décision en moins de 15 minutes, alors le connecteur n'est pas prêt. La preuve doit suivre la fiche fournisseur, pas rester enfermée dans un log technique ou un export temporaire.
10. Recette, seuils et rollback
Tester les familles coûteuses
La recette doit couvrir les familles qui coûtent en production: SIREN invalide, SIRET invalide, établissement fermé, unité cessée, période historique, diffusion partielle, 301, 400, 401, 403, 404, 406, 414, 429, 500 et 503.
Chaque test doit produire une preuve complète: endpoint, version 3.11, paramètre, statut HTTP, champ demandé, champ conservé, clé d'application, quota, retry, owner, décision, message agent, message client et rollback possible.
Le seuil d'acceptation peut être simple: si une même famille revient sur 7 jours sans cause documentée, alors le flux est à corriger avant toute extension. Cette règle protège finance, conformité, vente et expérience fournisseur.
Séparer recette métier et recette data
La recette métier vérifie création compte, validation fournisseur, blocage, fusion, message support, redirection et revue humaine. La recette data vérifie schéma, champs, historique, pagination, différentiel, fraîcheur, rediffusion et purge.
Une réponse technique peut être correcte mais dangereuse si le statut interne fusionne deux établissements. Inversement, un écran rassurant peut masquer une rediffusion interdite ou un rattrapage différentiel incomplet.
Cette revue doit produire une décision écrite. Le ticket de recette doit dire quelle action est autorisée, quelle action reste interdite et quel indicateur prouvera que Sirene, SI interne et support racontent la même histoire.
Préparer rollback et mode dégradé
Le rollback peut prendre plusieurs formes: restaurer un ancien SIRET, retirer une redirection 301, annuler une fusion, purger un champ, rétablir une adresse, remettre un compte en revue ou suspendre une mise à jour différentielle.
Le mode dégradé doit rester utile. Une indisponibilité Sirene peut demander attente ou validation manuelle, mais elle ne doit pas créer un fournisseur approximatif si la décision dépend vraiment du statut administratif.
Si, après 30 jours, l'équipe retrouve encore 301 silencieux, 404 mal interprétés, quotas atteints, doublons B2B ou exports non purgés, alors le seuil de priorité est dépassé et le run est à corriger avant d'élargir le périmètre.
Auditer les décisions réelles
L'audit des premières semaines doit partir de décisions réelles: fournisseur accepté, compte fusionné, établissement bloqué, adresse corrigée, prospect enrichi, fiche purgée ou mise à jour différentielle rattrapée.
Chaque cas doit être résolu avec les écrans disponibles, sans intervention de la personne qui a développé le connecteur. Si l'équipe doit ouvrir les logs bruts pour comprendre le SIRET retenu, l'observabilité est trop faible.
Le seuil de sortie peut être concret: 8 dossiers relus en moins de 15 minutes, 8 décisions support cohérentes et zéro correction hors procédure. Si une réponse dépend d'un souvenir projet, la documentation est à corriger avant volume.
11. Erreurs fréquentes API Sirene
Confondre entreprise et établissement
La première erreur consiste à utiliser le SIREN comme s'il identifiait toujours le lieu opérationnel. Pour la facturation, la livraison, la relation commerciale ou un portail fournisseur, le SIRET peut être la clé réellement pertinente.
Le bon réflexe consiste à écrire la décision attendue avant l'appel: valider une unité légale, rattacher un établissement, retrouver un siège, détecter une fermeture, proposer une succession ou enrichir un compte.
Si un agent peut modifier un SIRET sans trace et sans recalcul des impacts, alors l'architecture est trop ouverte. La clé administrative doit rester reliée aux décisions qu'elle influence.
Faire confiance à la recherche floue
La deuxième erreur consiste à laisser une recherche phonétique ou multicritère décider seule. Une dénomination proche, une enseigne similaire ou une adresse partagée ne suffisent pas à prouver l'identité administrative.
Le support doit savoir dire "candidat probable", "identifiant confirmé", "revue humaine", "fusion interdite" ou "nouvelle fiche à créer". Ces statuts ne peuvent pas rester mélangés dans une même liste de résultats.
Si plus de 3 comptes sur 30 jours sont fusionnés puis rouverts, alors le seuil de qualité support est dépassé et la règle de rapprochement est à corriger avant extension.
Stocker trop de variables Sirene
La troisième erreur consiste à conserver la réponse complète "au cas où". Une validation B2B demande souvent peu de champs: identifiant, statut, adresse utile, activité principale, siège, période et preuve de consultation.
Le connecteur doit distinguer preuve durable, donnée temporaire, donnée affichée, donnée rejetée et donnée purgée. Cette séparation protège conformité, performance, audit et maintenabilité du référentiel.
Si plus de 20 champs restent stockés sans usage opérationnel, alors le mapping doit être repris. API Sirene doit fiabiliser la base, pas transformer chaque fiche interne en copie exhaustive du répertoire.
Questions fréquentes API Sirene
Que faut-il cadrer avant une intégration API Sirene ? Il faut cadrer SIREN, SIRET, unité légale, établissement, clé `X-INSEE-Api-Key-Integration`, quota 30/minute, endpoints 3.11, `date`, `q`, `champs`, pagination, statuts HTTP, diffusion partielle et mise à jour différentielle.
API Sirene remplace-t-elle une base entreprise interne ? Non. Elle sert de référentiel public pour vérifier et enrichir, mais le SI doit garder ses règles métier, ses décisions, ses historiques, ses owners, ses purges et ses preuves de consommation.
Pourquoi 301 et liens de succession doivent-ils être visibles ? Parce qu'une correction de doublon ou une succession d'établissement peut changer les rattachements internes. Le support doit voir l'identifiant initial, la cible, la date, l'impact et le rollback possible.
Dawap peut-il industrialiser API Sirene dans un référentiel B2B ? Oui. Dawap peut cadrer accès, mapping, différentiel, recherche, succession, diffusion partielle, supervision, retries, tableaux de bord et passation support pour rendre l'API exploitable sans dette de run.
Guides complémentaires API Sirene
Pour comparer avec les attestations administratives et les données protégées par habilitation, relisez l'intégration API Entreprise. API Sirene porte le socle entreprise, tandis qu'API Entreprise ajoute des pièces et statuts utiles aux démarches autorisées.
Pour les univers proches, consultez aussi l'intégration API INPI Entreprises, l'intégration API data.gouv.fr et l'intégration API Base Adresse Nationale. Ces lectures aident à distinguer identité entreprise, registre, catalogue public et adresse normalisée.
La landing API services publics et Open Data permet ensuite de rattacher API Sirene aux autres briques publiques, tandis que la page intégrateur INSEE Sirene précise l'accompagnement possible sur SIREN, SIRET, recherche, mise à jour différentielle, succession et gouvernance B2B.
La priorisation doit rester très concrète: commencer par le flux où le mauvais établissement coûte le plus, où la dette de doublons ralentit le support, où la conformité limite la rediffusion et où la preuve peut être relue simplement par finance, commerce, achats, data, assistance, audit, formation et pilotage.
Conclusion: intégrer API Sirene sans dette de run
Une intégration API Sirene fiable ne se juge pas au nombre de fiches préremplies. Elle se juge quand chaque SIREN, SIRET, statut, période, redirection, succession, champ conservé et décision peut être expliqué par les équipes qui utilisent la base au quotidien.
Le bon ordre reste clair: créer l'application, protéger la clé, choisir les endpoints, limiter les champs, traduire les erreurs, surveiller le quota, piloter la mise à jour différentielle et documenter la règle entre unité légale et établissement.
La valeur vient aussi du refus des raccourcis. Il faut laisser en revue les recherches floues, les redirections silencieuses, les fusions incertaines et les usages de diffusion partielle qui ne portent pas de règle explicite.
Dawap peut vous aider à transformer API Sirene en référentiel B2B robuste, observable et utile au métier avec notre accompagnement en intégration API, depuis l'accès au catalogue INSEE et les endpoints 3.11 jusqu'aux mappings, à la mise à jour différentielle, aux erreurs, aux dashboards et aux runbooks de production.
