Se connecterEssayer gratuitement

[ Le cadre légal ]

Réutiliser des données publiques d'entreprises : ce qui est permis

La donnée d'entreprise française est ouverte, et sa réutilisation commerciale est prévue par les textes qui organisent sa diffusion. Cela règle la question du droit de réutilisation, et ne règle rien de la protection des personnes qui figurent dedans. Ici encore, les principes sont exposés ; un cas particulier se vérifie auprès d'un juriste.

Un droit de réutilisation, y compris commerciale

Les données du registre national des entreprises et celles du BODACC sont diffusées en données ouvertes. La diffusion s'accompagne d'une licence de réutilisation qui autorise l'exploitation, la transformation et la rediffusion, y compris à des fins commerciales. C'est ce qui rend possible l'existence même des services qui revendent de la donnée d'entreprise, Basile compris.

La licence emporte généralement des contreparties légères, de l'ordre de la mention de la source et de la date de la dernière mise à jour. Elles ne sont pas décoratives : elles évitent qu'un fichier vieux de deux ans soit présenté comme l'état actuel du registre. Vérifiez la licence attachée à chaque jeu de données que vous utilisez, car elles ne sont pas toutes identiques et elles évoluent.

Ce que la licence ne fait pas, c'est vous exonérer du reste du droit. Elle porte sur le droit de réutiliser le jeu de données. Elle ne dit rien du droit des personnes qui y figurent, ni des règles applicables à la prospection.

Ouvert ne veut pas dire hors RGPD

C'est le contresens le plus fréquent, et il mérite d'être formulé sans détour : le fait qu'une donnée personnelle soit publiée ne la fait pas sortir du champ du RGPD. Le nom d'un dirigeant publié au registre reste une donnée personnelle. Son mandat, sa date d'entrée en fonction, la commune où il exerce sont des données personnelles. Elles sont publiques, ce qui signifie que leur consultation est libre, pas qu'elles seraient devenues des données neutres dont on peut faire n'importe quoi.

La confusion vient de ce que la publicité du registre poursuit un but précis : permettre à quiconque de savoir avec qui il traite, de vérifier qu'une société existe, de connaître son représentant légal, de repérer une procédure en cours. Réutiliser ces données pour construire un fichier commercial est un usage différent de celui pour lequel elles sont publiées. Cet usage-là a besoin de sa propre base légale, et il déclenche ses propres obligations.

Le raisonnement inverse, celui qui consiste à dire « c'est public donc c'est libre », se retourne vite. Il suffit qu'un dirigeant demande d'où vient son adresse pour qu'il faille répondre, et répondre « du registre » n'est une réponse acceptable que si elle est vraie et vérifiable.

Ce qui n'est pas diffusé, et pourquoi

L'ouverture des registres n'est pas totale. Trois catégories font l'objet d'une diffusion restreinte, et il est utile de les connaître avant de promettre quoi que ce soit à un client :

DonnéeDiffusionCe qu'il faut savoir
Identité de la société, forme, capital, activitéOuverteRéutilisable, y compris à des fins commerciales
Nom et fonction des dirigeantsOuverteDonnée personnelle : le RGPD continue de s'appliquer
Coordonnées personnelles des entrepreneurs individuelsRestreinteL'adresse est très souvent celle du domicile
Registre des bénéficiaires effectifsRestreinteAccès réservé, sur justification d'un motif
Comptes annuels déclarés confidentielsNon diffuséeL'entreprise a exercé une option que la loi lui ouvre

Le cas des entrepreneurs individuels est celui qui pose le plus de difficultés en pratique, parce qu'ils sont très nombreux et que leur adresse d'établissement est souvent leur adresse d'habitation. Une donnée d'apparence professionnelle peut ainsi être, en fait, une donnée de vie privée. Sur les comptes annuels et ce qu'on peut réellement en tirer, voir la page consacrée aux bilans.

La question du scraping

Consulter une page publique et extraire massivement le contenu d'un site ne sont pas la même opération, même si la première ressemble à une version lente de la seconde. Trois ordres de considérations se superposent, et les confondre conduit soit à s'interdire l'évident, soit à s'autoriser n'importe quoi.

  • Le droit du producteur de bases de données protège l'investissement consenti pour constituer une base, indépendamment du droit d'auteur sur son contenu. L'extraction d'une partie substantielle d'une base protégée est le cas typiquement visé. Ce droit existe même quand chaque donnée prise isolément n'appartient à personne.
  • Les conditions d'utilisation du site visité, qui interdisent fréquemment l'extraction automatisée. Leur portée dépend du contexte, notamment de la façon dont elles ont été acceptées, mais elles ne sont pas sans effet.
  • Le RGPD, dès lors que les pages contiennent des données personnelles, ce qui est le cas d'à peu près tout annuaire de professionnels.

Il existe en face une différence de nature entre extraire un site tiers et télécharger un jeu de données que l'administration met elle-même à disposition, avec une licence explicite et souvent une interface de programmation prévue pour ça. Quand la voie officielle existe, elle est à la fois plus sûre, plus stable et généralement plus complète que la voie détournée. C'est le choix que fait Basile pour la partie registre.

Cette page ne se prononce pas sur la licéité d'une collecte particulière : cela dépend de la source, du volume, de la finalité et des conditions applicables. C'est exactement le type de question qui se pose à un juriste avant d'être tranchée par un développeur.

Documenter l'origine de chaque champ

La bonne pratique tient en une phrase : savoir dire d'où vient chaque ligne, et même chaque champ. Une fiche d'entreprise dans un outil sérieux est un assemblage. La dénomination et la forme juridique viennent du registre, l'effectif d'une déclaration, la catégorie d'activité peut venir d'une fiche Google, le nom d'un contact d'un réseau professionnel. Ces provenances n'ont ni la même fraîcheur, ni le même régime.

Tracer cette origine sert trois choses concrètes. Elle permet de répondre à une demande d'exercice de droits sans improviser. Elle permet de purger proprement une source si son statut change. Et elle permet de savoir quoi croire quand deux sources se contredisent sur la même entreprise, ce qui arrive plus souvent qu'on ne l'imagine.

Cette exigence n'est pas un raffinement de juriste. C'est ce qui sépare un fichier qu'on peut défendre d'un fichier qu'on subit, et accessoirement ce qui permet de comprendre pourquoi une segmentation rend un résultat étrange. Voir segmenter son marché pour la suite pratique.

Lire l'origine de chaque champ dans un export

Vous avez un fichier sous les yeux et quelqu'un vous demande d'où vient telle colonne. La réponse est déjà écrite dans le fichier : le préfixe du nom de colonne désigne la source, et les drapeaux de fin de ligne disent, ligne par ligne, quelles sources ont effectivement matché. C'est le test de la section précédente, appliqué à votre propre export.

Dans la plateforme, pas à pas

  1. Lancez votre recherche entreprises (ou personnes) comme d'habitude. Chaque ligne de résultat porte ses pastilles de source, trois au maximum : Legal pour le registre, LinkedIn, Google. Il n'y en a pas de quatrième. Ce qui a été relevé sur le site de l'entreprise (emails, téléphones, technologies) ne donne pas de pastille, il se lit dans les colonnes de l'export.
  2. Retenez ce que la pastille dit exactement : elle signale que cette source détient de la donnée sur cette société, pas que la ligne est sortie de cet index. Une société connue des trois sources porte les trois pastilles, quelle que soit la source qui a produit la ligne.
  3. Cliquez sur la ligne pour ouvrir le panneau latéral. Les sections y sont rangées par provenance : l'identité légale pour le registre, la fiche Google, la page LinkedIn, et les technologies détectées sur le site.
  4. Sous chaque source, dépliez la liste complète des champs. Vous lisez alors l'enregistrement brut de cette source, tel qu'il est stocké, avant tout croisement. C'est le seul endroit de l'interface où la donnée n'est pas assemblée. Pour Google, le panneau liste en plus tous les établissements du domaine, une fiche par point de vente.
  5. Exportez en CSV. Le fichier entreprises compte 57 colonnes, le fichier personnes 79. Le nom de la colonne porte sa source : legal_ pour le registre (legal_siren, legal_naf, legal_naf_label, legal_forme_juridique, legal_date_creation, legal_capital, legal_tranche_effectif, legal_siege_ville), gmb_ pour la fiche Google (gmb_name, gmb_phone, gmb_website, gmb_rating, gmb_reviews, gmb_category, gmb_address, gmb_hours_monday, gmb_hours_sunday), le suffixe _lki et company_linkedin_handle pour LinkedIn (company_name_lki, company_industry, company_headcount_lki, company_hq_city_lki), crawled_emails et crawled_phones pour ce qui a été relevé sur le site de l'entreprise, tech_stack pour les technologies détectées sur ce même site. Seules company_name_raw et company_domain_raw n'ont pas de préfixe : ce sont les deux colonnes d'identification de la ligne.
  6. Lisez ensuite les drapeaux, en fin de ligne : has_lki_company_enrichment, has_legal_match, has_domain, has_gmb_match, has_crawled_email, has_crawled_phone. Une colonne gmb_ vide sur une ligne où has_gmb_match est faux n'est pas un trou de données : cette société n'a pas de fiche Google, et c'est une réponse en soi.
  7. Dans l'export personnes, deux colonnes ne viennent d'aucune source publique : person_email et person_phone. Elles ne se remplissent que pour les contacts dont vous avez vous-même fait chercher les coordonnées (email finder, recherche de téléphone), et restent vides partout ailleurs. Elles n'existent pas du tout dans l'export entreprises. Ne les présentez jamais comme de la donnée de registre.

La dernière colonne, fill_score, résume le taux de remplissage de la ligne (elle existe dans les deux exports). Elle sert à trier un fichier, pas à qualifier une source. Rappel des réserves déjà signalées : les notes et les avis n'existent que sur les fiches Google, tech_stack seulement pour les entreprises dont le site a été analysé, et le chiffre d'affaires manque pour la majorité du parc, les comptes étant massivement déclarés confidentiels.

Par l'API : POST /companies/export

{
  "filters": {
    "naf_code": { "include": ["62.01Z"] },
    "headquarters_city": { "include": ["Nantes"] },
    "company_ceased": false
  },
  "mode": "companies"
}

Un flux CSV (Content-Type text/csv; charset=utf-8), une ligne par entreprise, 57 colonnes dans un ordre fixe : company_name_raw et company_domain_raw, puis les colonnes LinkedIn (company_id_lki, company_name_lki, company_industry, company_headcount_lki, company_hq_*_lki, company_linkedin_handle, company_description_lki, company_specialties_lki, company_type_lki), les colonnes legal_, les colonnes gmb_, crawled_phones et crawled_emails, tech_stack, enfin les drapeaux has_lki_company_enrichment, has_legal_match, has_domain, has_gmb_match, has_crawled_email, has_crawled_phone et fill_score. Deux en-têtes de réponse complètent le tableau : X-Export-Max-Rows donne le plafond de lignes de cet export (plafond par export de votre plan, moins ce que vous avez déjà consommé ce mois-ci), X-Export-Capped vaut true quand des résultats restaient au-delà. Avec mode à locations, une ligne par établissement Google et les colonnes gmb_ passent en tête.

Attention à l'effet de bord du corps ci-dessus : naf_code est un filtre que seul le registre porte. Posé avec des filtres multi-sources comme la ville, il restreint la recherche au registre, donc toutes les lignes du fichier sont ancrées sur Legal. Les colonnes gmb_ et LinkedIn se remplissent quand même, l'enrichissement d'export croisant les sources après coup. Pour une fiche précise et la donnée AVANT croisement, GET /companies/{id}/full renvoie { success, sources } : un tableau, une entrée par source réellement présente, dans l'ordre LKI, Legal, GMB, chacune avec son enregistrement brut (row) et la liste de ses colonnes peuplées (columns). L'entrée Google porte en plus establishments, tous les établissements du domaine (200 au maximum) et leur nombre total. Côté personnes, GET /people/{id}/full renvoie { row, columns }, la ligne à 79 colonnes de l'export pour un seul contact. Ces deux appels coûtent 1 crédit chacun, à chaque appel, même si la fiche a déjà été payée dans la recherche. POST /people/export prend le même corps que ci-dessus, sans le champ mode.

Le détail des champs, des filtres et des codes de réponse est dans la documentation de l'API.

Avec Claude, en langage courant

Prends une agence de développement web à Nantes dans Basile, ouvre sa fiche complète et dis-moi, champ par champ, ce qui vient du registre, ce qui vient de sa fiche Google et ce qui vient de LinkedIn.

Claude enchaîne basile_activity_suggest, basile_search_companies, basile_get_entity puis basile_export.

basile_get_entity avec full activé (c'est le défaut) appelle GET /companies/{id}/full : Claude reçoit un enregistrement brut par source et répond donc sans rien reconstituer. Surveillez les crédits, ils se cumulent : la recherche en débite un par fiche renvoyée, la fiche complète un par appel même si la fiche a déjà été payée dans la recherche. Pour plusieurs sociétés d'un coup, basile_export coûte le même prix et renvoie tout le tableau, préfixes et drapeaux compris.

Restreindre une extraction à une seule source

Certains usages n'acceptent que le registre : une réutilisation que vous voulez pouvoir adosser à la licence open data, un client qui refuse toute donnée issue d'un réseau social, un périmètre que vous devrez décrire par écrit. Restreindre la recherche à une source rend ce périmètre défendable, à condition de savoir ce que la restriction fait, et surtout ce qu'elle ne fait pas.

Dans la plateforme, pas à pas

  1. Ouvrez la recherche entreprises. L'interface n'expose pas de sélecteur de source : c'est le choix des filtres qui décide des index interrogés, et le panneau de gauche le montre en rangeant les filtres par famille.
  2. Pour rester sur le registre, ne posez que des filtres que seul le registre porte : code NAF, forme juridique, catégorie juridique, SIREN, département, région, code postal, année de création (ou la fenêtre « créée récemment »), capital. Aucun de ces champs n'existe sur une fiche Google ni sur une page LinkedIn. Il n'y a pas de filtre de numéro de TVA.
  3. Quand tous les filtres mono-source posés viennent du registre, la recherche est restreinte au registre et les deux autres index sont écartés. Un seul filtre mono-source pris ailleurs suffit à rouvrir la recherche à cette source : Domaine, Stack technique, Followers, Secteur LinkedIn et Type de société appartiennent à LinkedIn ; Note Google, Avis et Ouverture (ouvert le dimanche) appartiennent à la fiche Google.
  4. Les filtres portés par plusieurs sources, eux, ne cassent rien : Activité, Nom et Ville ne sont propres à aucun index et ne rouvrent ni LinkedIn ni Google. Vous pouvez donc combiner « Activité = restaurant » avec un capital minimum et rester sur le registre. L'effectif est dans le même cas, à une nuance près : il est incompatible avec les fiches Google, qui ne portent aucune donnée d'effectif, donc le poser écarte Google d'office.
  5. Ne comptez pas sur les bascules « Avec : Données légales » et « Avec : Page LinkedIn » pour restreindre. Ce sont des conditions supplémentaires appliquées à l'intérieur de chaque source (garder les sociétés qui ont AUSSI un enregistrement légal, ou AUSSI une page LinkedIn), pas des sélecteurs d'index. Une recherche restreinte au registre le reste que ces bascules soient posées ou non.
  6. Exportez en CSV, puis ne conservez que les colonnes legal_. La restriction porte sur la population extraite, pas sur la largeur du fichier : la jointure d'export continue de remplir les colonnes gmb_ et LinkedIn dès que la société est aussi connue ailleurs. Un fichier strictement registre demande donc les deux gestes, le filtre puis la coupe de colonnes.

Vérifiez le périmètre sur une fiche, pas sur les pastilles de la liste : une pastille LinkedIn ou Google signale que la société est aussi connue de cette source, pas que la ligne en provient. Le panneau latéral, section par section, montre ce qui est réellement présent.

Par l'API : POST /companies/find

{
  "filters": {
    "source": "Legal",
    "naf_code": { "include": ["62.01Z"] },
    "headquarters_postal_code": { "include": ["44000", "44100", "44200", "44300"] },
    "company_ceased": false
  },
  "limit": 100
}

{ success, total, establishmentsTotal, leads[], meta }. Chaque entrée de leads[] porte son _id, son tag de source et son enregistrement data. L'information décisive est dans meta.sources, qui liste les index ayant réellement contribué : avec le corps ci-dessus il ne contient que Legal, ce qui est une preuve vérifiable du périmètre, à conserver avec le fichier. Lisez aussi meta.noticeCode, qui prend trois valeurs : sources_conflict quand vos restrictions n'ont laissé aucune source éligible (le total est alors nul pour une raison explicite, et non par un vide silencieux), sources_split quand une source retenue n'est PAS contrainte par vos filtres mono-source et gonfle donc le total, gmb_filter_dropped quand un filtre propre à Google (note, avis, ouverture) a été posé alors que Google est écarté, auquel cas ce filtre ne retire rien du tout. Enfin meta.unknownFilters énumère les clés envoyées mais non reconnues, donc non appliquées.

Le filtre source accepte Legal, LKI et GMB côté entreprises, et seulement Legal ou LKI côté personnes : aucune personne ne provient des fiches Google. Il passe tel quel dans POST /companies/export et POST /people/export, et c'est là qu'il compte, puisque c'est le fichier qui sort. Attention au malentendu : source choisit l'index qui produit les lignes, il ne vide pas les colonnes des autres sources dans le CSV, l'enrichissement d'export croisant toujours ce qu'il trouve. À noter enfin que company_ceased à true (les sociétés cessées) écarte d'office LinkedIn et Google, ces deux sources n'ayant pas de notion de cessation d'activité, alors que le défaut « actives » (company_ceased à false) les laisse participer normalement.

Le détail des champs, des filtres et des codes de réponse est dans la documentation de l'API.

Avec Claude, en langage courant

Dans Basile, compte puis exporte les sociétés du code NAF 62.01Z autour de Nantes en restant uniquement sur le registre légal, sans rien prendre de LinkedIn ni de Google.

Claude enchaîne basile_count, basile_search_companies puis basile_export.

Le MCP transmet le filtre source tel quel : Legal pour le seul registre, LKI pour LinkedIn, GMB pour les fiches Google. Demandez le comptage d'abord, basile_count est gratuit et exact là où une recherche débite un crédit par fiche renvoyée et plafonne son total à 100 000. Et gardez en tête la même réserve que sur l'API : le CSV que renvoie basile_export garde les colonnes des trois sources, c'est la population qui est restreinte, pas la largeur du fichier.

À lire ensuite