Open data et signaux web : bâtir une base de prospection vérifiable

Assembler Sirene, BODACC, RNE et quelques pages web peut sembler être une opération de jointure. Le vrai travail est ailleurs : savoir quelle entité existait à quelle date, distinguer une formalité d’un besoin commercial, expirer les indices faibles et pouvoir reconstruire chaque décision après une correction.

Une base temporelle, pas un annuaire

Un annuaire répond à « qui existe ? ». Une base de signaux doit répondre à « qu’avons-nous observé, quand, où et avec quel niveau de preuve ? ». Cette différence impose de ne pas écraser l’historique par la dernière valeur connue.

Une entreprise peut changer de siège le 1er mars, l’information être publiée le 5 mars et votre système l’ingérer le 7 mars. Ces trois dates ont un sens différent. Si la base ne conserve que le 7 mars, elle ne peut plus expliquer pourquoi une règle s’est déclenchée ni mesurer son délai de détection.

Le système doit également accepter qu’une information soit corrigée. Une annonce rectificative ne rend pas la première observation imaginaire ; elle modifie ce que l’on considère exact à partir d’une nouvelle preuve. Conserver cette chronologie rend les scores, segments et actions recalculables.

Trois couches et deux dates

Couche 1 : l’identité

Elle regroupe les unités légales et établissements avec leurs identifiants stables, dénominations, états, activités déclarées et statuts de diffusion. Son rôle est de résoudre « de quelle organisation parlons-nous ? », pas de déterminer son intention d’achat.

Couche 2 : les événements

Elle enregistre les créations, modifications, radiations, dépôts, ouvertures d’établissement ou autres faits datés. Chaque événement est immuable : une correction crée une nouvelle version ou relation, elle n’efface pas silencieusement le passé.

Couche 3 : les signaux

Elle contient des interprétations bornées : « une offre d’emploi liée aux données a été observée », « une nouvelle page produit est apparue », « un changement de technologie est détecté ». Le signal cite sa preuve et possède une date d’expiration. Il ne devient pas « besoin confirmé » sans une validation distincte.

Pour chaque valeur temporelle, conservez au minimum deux dates :

• date d’effet : quand le fait est censé être vrai dans le monde, si la source la fournit ;
• date d’observation : quand votre système a obtenu l’information.

Ajoutez la date de publication lorsqu’elle diffère et la date d’expiration pour les signaux. Cette modélisation évite de présenter comme actuel un indice vieux de six mois simplement parce qu’il a été réimporté hier.

Choisir les sources par fonction

La Base Sirene, produite par l’Insee, constitue un socle d’identité pour les unités légales et leurs établissements. La fiche data.gouv.fr indique une diffusion sous Licence Ouverte 2.0 et attire l’attention sur le statut de diffusion le plus récent, notamment pour certaines personnes physiques. Elle annonce aussi le passage à la nomenclature NAF 2025 au 1er janvier 2027, diffusée par anticipation : un pipeline construit en 2026 doit donc prévoir la coexistence de versions de nomenclature.

Le BODACC, fourni par la DILA, rend accessibles des annonces concernant notamment immatriculations, créations d’établissements, modifications, radiations, procédures collectives et dépôts de comptes. Ces annonces sont des événements à interpréter dans leur contexte, pas des étiquettes commerciales prêtes à l’emploi.

Le RNE de l’INPI est alimenté par le Guichet unique des formalités et diffuse gratuitement ses données publiques. L’INPI propose aussi des accès API et des données de créations, modifications et cessations. Les actes ou comptes déclarés confidentiels ne doivent évidemment pas être reconstitués par d’autres moyens.

L’Annuaire des Entreprises illustre la composition de plusieurs jeux publics : Sirene, Base Adresse Nationale, RNE/RCS, BODACC et autres référentiels. Cette composition est utile comme exemple d’architecture, mais chaque réutilisateur reste responsable de ses propres finalités, règles et preuves.

Les pages web viennent en dernier. Elles peuvent documenter un changement opérationnel plus vite qu’un registre, mais elles sont moins stables et plus ambiguës. Le registre dit ce qui a été déclaré ; le web montre ce qui est publié ; ni l’un ni l’autre ne prouve seul une intention d’achat.

Le modèle d’une fiche reconstruisible

Une fiche lisible par le commercial peut être matérialisée, mais elle doit pouvoir être reconstruite depuis des objets plus simples :

Objet	Champs essentiels	Propriété
Organisation	Identifiant, type, statut, dénomination	Versionnée selon la source de référence
Établissement	SIRET, lien à l’unité légale, adresse, état	Distinct du siège et de l’unité légale
Événement	Type, date d’effet, publication, source	Immuable et corrigeable par relation
Observation web	URL, extrait minimal, empreinte, date	Périssable et soumise à politique de source
Signal	Type, force, règle, expiration	Interprétation dérivée, jamais vérité primaire
Décision	Règle, version, motifs, action proposée	Recalculable et contestable
Restriction	Type, portée, origine, date	Prioritaire sur les vues d’activation

La fiche commerciale est alors une vue : identité actuelle, trois événements récents, signaux non expirés, conflits et prochaine action autorisée. Elle ne copie pas toutes les données brutes dans le CRM.

Cette distinction permet de centraliser les données dans une interface sans transformer l’interface en nouveau silo. L’utilisateur voit une synthèse, tandis que le système garde les liens vers les preuves.

Le pipeline d’ingestion et de résolution

1. Inventorier les sources. Producteur, URL stable, licence, schéma, fréquence, restrictions, responsable et date de prochaine revue.
2. Ingérer sans écraser. Conserver le millésime, l’empreinte, le statut de l’exécution et les lignes rejetées.
3. Valider le contrat. Une colonne absente, un nouveau code ou une baisse brutale de volume met le lot en quarantaine.
4. Résoudre les identités. Joindre d’abord sur identifiant officiel ; les correspondances par nom, domaine ou adresse exigent un niveau de confiance et une revue en cas d’ambiguïté.
5. Créer les événements. Transformer les changements en objets datés, sans déduire encore une opportunité.
6. Calculer les signaux. Appliquer des règles versionnées avec une date d’expiration et une explication.
7. Publier une vue de revue. L’équipe confirme, rejette ou demande une preuve supplémentaire.
8. Mesurer et reprendre. Les erreurs vont dans une file dédiée ; une reprise ne duplique pas les événements.

Avant de développer, formalisez les états et responsabilités. Le canevas de documentation d’un workflow permet de spécifier le déclencheur, les règles, les exceptions et les preuves attendues.

Un identifiant de lot doit relier chaque fiche à son ingestion. Si un fichier est retiré ou corrigé par le producteur, l’équipe peut identifier les décisions concernées et les recalculer. Sans lignage, toute correction devient une enquête manuelle.

Traiter les signaux web comme des indices périssables

Un signal web doit répondre à cinq questions :

1. quelle page précise a été observée ?
2. qu’indique-t-elle factuellement, sans interprétation commerciale ?
3. à quelle organisation a-t-elle été rattachée et par quelles preuves ?
4. combien de temps cette observation reste-t-elle utile ?
5. quelle restriction de collecte ou de réutilisation a été examinée ?

La CNIL rappelle dans ses recommandations générales de 2024 que le caractère publiquement accessible ne supprime pas les règles applicables aux données personnelles. Elle demande d’examiner les attentes raisonnables, la nature du site, les licences, les conditions générales et les restrictions exprimées. Pour un dispositif de prospection, Forge Labs en déduit une règle opérationnelle prudente : exclure les espaces privés, ne pas contourner les mécanismes de blocage et limiter les extraits au nécessaire.

Chaque type de signal possède sa demi-vie. Une page de recrutement retirée peut perdre son intérêt après quelques semaines ; une création d’établissement reste un événement historique mais son utilité commerciale décroît. L’expiration doit être automatique. « Non revu » ne signifie pas « toujours vrai ».

La corroboration améliore la décision : un événement officiel et un signal web indépendant peuvent justifier une recherche. Deux copies du même communiqué sur des sites différents ne sont pas deux preuves indépendantes. Conservez les relations de dépendance entre sources lorsque c’est identifiable.

Séparer connaissance et activation

L’open data n’est pas une autorisation de démarchage. Une licence organise la réutilisation du jeu ; elle ne remplace pas l’analyse des règles relatives aux données personnelles, au canal de prospection, à l’information ou à l’opposition.

La vue d’activation doit donc être un produit séparé de la base de connaissance. Elle ne reçoit qu’un petit nombre de dossiers et vérifie :

• l’organisation, le signal et la preuve sont encore valides ;
• la finalité et le canal ont été documentés ;
• les éventuelles données de personne sont nécessaires et correctement sourcées ;
• l’information requise peut être fournie, notamment sur l’origine ;
• les oppositions et restrictions sont appliquées avant l’export ;
• une personne reste responsable de la pertinence du message.

Obligation : les traitements de données personnelles doivent respecter les principes et droits prévus par le RGPD. Interprétation : la base juridique et les modalités d’information dépendent du dispositif concret. Recommandation : valider la chaîne avec le DPO ou un conseil compétent et documenter séparément collecte, qualification et contact.

Un plan de construction sur quatre semaines

Semaine 1 — Prouver l’identité

Choisissez un périmètre étroit et une source officielle. Chargez uniquement les identifiants et champs nécessaires. Testez changements de schéma, statut de diffusion, établissement fermé et identifiants invalides. Le livrable est un référentiel reconstructible, pas un segment commercial.

Semaine 2 — Prouver l’événement

Ajoutez une seule famille d’événements, par exemple les créations d’établissement. Conservez date d’effet, date de publication, date d’observation et source. Vérifiez manuellement un échantillon et classez les divergences.

Semaine 3 — Prouver le signal

Ajoutez un type de signal web dont la collecte est permise et proportionnée. Définissez l’expiration, la règle de rattachement et les cas de quarantaine. Aucune coordonnée personnelle n’est nécessaire pour démontrer la valeur de cette couche.

Semaine 4 — Prouver la décision

Construisez une vue de revue avec raisons, preuves et exclusions. Comparez-la à une sélection simple. Mesurez la précision, la fraîcheur, les ambiguïtés et le temps de revue. Testez également la suppression, la correction d’une source et la reprise après échec.

Les indicateurs finaux sont modestes mais exigeants : part des fiches avec identité certaine, événements datés, signaux non expirés, provenance complète, conflits ouverts et décisions reconstructibles. Les méthodes de mesure de la fiabilité aident à ne pas confondre exécution technique et résultat utile.

Une telle base devient un actif parce qu’elle peut être maintenue, auditée et corrigée. Elle ne dépend pas d’un export mystérieux reçu chaque trimestre. Forge Labs étudie ponctuellement des collaborations stratégiques pour concevoir ces systèmes de sourcing et de décision lorsque la traçabilité et l’exploitation comptent autant que la collecte.

Sources

• data.gouv.fr / Insee — Base Sirene des entreprises et de leurs établissements, fiche mise à jour en septembre 2026 et consultée le 27 septembre 2026.
• DILA — API BODACC.
• INPI — Accès à l’API formalités / RNE.
• data.gouv.fr — Cas d’usage Annuaire des Entreprises et sources mobilisées.
• CNIL — Recommandations pour les réutilisateurs de données publiées sur Internet.
• CNIL — RGPD, chapitre III, notamment information en cas de collecte indirecte.