Choisir API INSEE ou stocks ouverts: cadence et périmètre
L’API Sirene V3 expose les unités légales et les établissements et permet des recherches ciblées par SIREN, SIRET ou périmètre filtré. Vérifiez les modalités d’authentification et de requêtage dans la documentation avant de l’automatiser dans votre CRM (source: INSEE, API Sirene V3 (consulté 2026-06)).
Les fichiers de stock regroupent les unités légales et les établissements. Ils conviennent au chargement initial, car ils fournissent une photographie complète du référentiel à une date donnée (source: INSEE, Base Sirene — données ouvertes (consulté 2026-06)).
| Option | Usage CRM recommandé | Point de vigilance |
|---|---|---|
| API Sirene V3 | Recherche ciblée, contrôle d’un SIREN ou enrichissement ponctuel | Prévoir les règles d’accès, les filtres et les erreurs de réponse |
| Stocks ouverts | Initialisation complète des comptes et sites | Charger unités légales et établissements de façon cohérente |
| Deltas ou mises à jour | Synchronisation récurrente | Appliquer les changements dans l’ordre de publication |
Pour une initialisation volumineuse, partez des stocks ouverts, puis utilisez l’API ou les fichiers de mise à jour pour le run récurrent. Cette séquence évite de reconstruire tout le référentiel à chaque synchronisation.
Modéliser vos objets CRM: Unités légales vs Établissements
Le SIREN identifie l’unité légale; le SIRET identifie un établissement rattaché à cette unité légale (source: INSEE, Base Sirene — données ouvertes (consulté 2026-06)). Cette distinction doit guider vos clés CRM: l’entité juridique n’est pas toujours le lieu d’exploitation.
Modèle recommandé: un objet Compte porte la clé SIREN. Les établissements deviennent des sous-objets liés, chacun avec sa clé SIRET. Une société avec un siège et plusieurs points de vente garde ainsi un seul Compte, mais plusieurs fiches établissement.
Mapping prêt à copier:
| Objet CRM | Clé | Champs issus de Sirene à mapper |
|---|---|---|
| Compte | SIREN | Dénomination ou raison sociale, forme juridique, code NAF, libellé NAF si disponible dans votre référentiel, date de création, état administratif |
| Établissement | SIRET | Adresse normalisée, complément d’adresse, code postal, commune, état administratif de l’établissement |
Conservez le code NAF et son libellé dans des champs distincts. Le code sert aux filtres stables; le libellé rend les listes commerciales et les tableaux de bord lisibles.
Normalisez l’adresse avant tout matching: casse, accents, type de voie, numéro, code postal et commune. « AV DE LA REPUBLIQUE » et « avenue de la République » doivent produire la même clé d’adresse, sinon l’upsert peut créer des doublons.
Pipeline d’intégration pas à pas: ETL robuste et idempotent
- Extraire avec une source traçable. L’extraction part soit d’un stock Sirene, soit d’un appel API. Chaque lot conserve son horodatage source, l’identifiant de fichier ou de réponse API, et le périmètre extrait.
- Transformer sans perdre l’origine. La transformation normalise les adresses, les accents, la casse et les abréviations comme SARL et S.A.R.L. Le mapping CRM garde l’origine par champ: Sirene, saisie commerciale ou enrichissement interne.
- Matcher avec des clés déterministes. La clé prioritaire reste le SIRET exact, car elle cible un établissement. En absence de SIRET fiable, utilisez SIREN + adresse normalisée + raison sociale avec tolérance typographique. Si le SIREN manque, calculez un hash stable sur adresse normalisée + raison sociale.
- Dédoublonner avant le chargement. Avant import, regroupez les doublons potentiels dans une table de revue. Désignez un enregistrement maître, listez les champs absorbés, puis journalisez chaque fusion avec l’ancien identifiant CRM et le nouvel identifiant maître.
- Charger par upsert idempotent. Le chargement utilise un upsert: créer si la clé n’existe pas, mettre à jour si elle existe. Les champs vides ne doivent jamais écraser une valeur CRM renseignée sans règle explicite. Chaque écriture doit pouvoir être rejouée sans créer de doublon.
Conservez un journal de revert avec clé de matching, valeurs avant écriture, valeurs après écriture et origine du changement. Cet historique permet d’annuler un lot sans supprimer les corrections manuelles postérieures.
Mises à jour et cas limites: cessations, transferts, fusions
Chargez les changements via les champs de dernière mise à jour des unités légales et établissements, ou via les fichiers de mise à jour Sirene disponibles dans votre dispositif d’alimentation. Votre ETL compare ces dates au dernier lot validé et ne traite que les enregistrements modifiés (source: INSEE, API Sirene V3 (consulté 2026-06); source: INSEE, Base Sirene — données ouvertes (consulté 2026-06)).
Cessation d’activité
Lorsqu’un établissement ou une unité légale cesse son activité, passez son statut CRM à inactif et renseignez la date de fin disponible. Ne supprimez pas la fiche: les opportunités, factures, consentements et échanges passés doivent rester rattachés à l’identifiant d’origine.
Transfert d’établissement
Dans le CRM, modélisez un transfert comme la fermeture opérationnelle de l’ancienne fiche établissement et l’ouverture ou le rattachement d’une nouvelle fiche quand un nouveau SIRET apparaît. Rattachez le nouveau SIRET au même SIREN lorsque cette relation est confirmée, puis conservez l’adresse précédente dans un historique d’adresses pour préserver les visites, secteurs commerciaux et contrats liés au site fermé.
Fusion ou absorption
Si votre référentiel identifie un SIREN repreneur, réaffectez les contacts, comptes enfants et contrats vers ce compte maître. Gardez le SIREN absorbé dans un champ d’historique et consignez l’événement juridique dans le journal CRM, avec la date et le type d’opération.
Conformité RGPD et CNIL pour l’enrichissement B2B
Les données Sirene sont publiques, mais un entrepreneur individuel identifiable par son nom, son adresse professionnelle ou son SIRET reste une personne physique identifiable: le RGPD s’applique (source: Règlement (UE) 2016/679 (RGPD)).
Base légale et opposition
L’intérêt légitime est souvent retenu pour la prospection B2B si le message vise l’activité professionnelle du contact et si l’opposition reste simple, gratuite et effective (source: CNIL, Prospection commerciale (consulté 2026-06)).
Une fiche CRM enrichie doit afficher l’origine des données, la finalité de prospection, le canal utilisé et un moyen d’opposition exploitable par les équipes commerciales (source: CNIL, Prospection commerciale (consulté 2026-06)).
Collecte indirecte et registre
Quand Sirene alimente le CRM sans collecte directe auprès de la personne, l’information prévue à l’article 14 doit être organisée et tracée (source: Règlement (UE) 2016/679 (RGPD)).
Le registre des traitements doit préciser la source Sirene, les catégories de données importées, les destinataires internes, la base légale et les durées de conservation retenues (source: Règlement (UE) 2016/679 (RGPD)).
Minimisation et preuve
N’importez que les champs utiles à la finalité CRM: identifiant SIREN/SIRET, dénomination, état administratif, adresse normalisée et segment métier si exploité par vos règles.
Conservez dans chaque enregistrement deux métadonnées de preuve: source Sirene et date_import. Elles facilitent les demandes d’accès, de rectification, d’opposition ou de suppression (source: Règlement (UE) 2016/679 (RGPD)).
Avant l’upsert CRM, listez la finalité, les champs Sirene retenus, la base légale, la durée de conservation et le droit d’opposition.