Modules

Trouver le site web

Retrouve le site officiel d'une entreprise à partir de son nom et de sa ville, puis prouve la correspondance en lisant le site lui-même. Aucune IA : chaque décision repose sur un fait observable, et un candidat non prouvé n'est jamais écrit.

À quoi il sert

emails, socials, legal_mentions, techstack et pricing exigent tous une colonne site_web. Une liste qui n'a que des noms ne peut atteindre aucun d'eux. Ce module est le pont.

Il travaille en deux temps :

Recherche. Une recherche web sur le nom de l'entreprise et sa ville. Les annuaires, réseaux sociaux, places de marché, fiches de greffe et sites d'emploi sont écartés : la cible est le site de l'entreprise, pas sa fiche chez un tiers. Si la raison sociale ne donne rien d'exploitable, une seconde recherche part du mot le plus distinctif du nom suivi de la ville, qui est la façon dont les entreprises sont réellement citées en ligne (personne n'écrit « SAS LABLAUDE Diégo » ; « Lablaude » plus la commune, oui). Le qualificatif d'établissement que les registres collent derrière la raison sociale est retiré avant la recherche : « NALDEO - SITE DE TARNOS » devient « NALDEO », sans quoi la requête porte sur un libellé que personne n'écrit nulle part.
Preuve. Les candidats retenus sont ouverts et lus. Le site n'est accepté que si ses pages contiennent le code postal ou la commune de l'entreprise, ou, pour un nom de domaine strictement identique au nom, le nom lui-même. Sans preuve, la case reste vide.

Entre deux domaines qui prouvent la même entreprise, le domaine racine l'emporte sur un sous-domaine, et une adresse d'hébergeur de déploiement (.vercel.app et assimilés) ne passe qu'en dernier recours.

Tout le trafic passe par le pool de proxies VPN, une sortie par worker.

Entrées

Champ	Requis	Notes
`nom`	oui	Nom de l'entreprise. Alias acceptés (`name`, `raison sociale`, `entreprise`…).
`ville` / `commune`	non	Fortement recommandé : c'est à la fois un terme de recherche et la preuve principale.
`code_postal`	non	Sert de preuve à la lecture du site candidat.
`adresse`	non	Utilisée en secours : le code postal et la commune y sont lus quand les colonnes dédiées manquent.

Comme opendata, ce module accepte des lignes sans aucun point de contact : en créer un est précisément son rôle. Les lignes sans nom exploitable sont conservées telles quelles dans le fichier de sortie.

Sorties

Colonne	Type	Description
`site_web`	url	Le site trouvé. Une valeur déjà présente n'est jamais écrasée.
`site_finder_match`	texte	Sur quoi la décision a été prise : `nom + adresse vérifiés sur le site`, `nom vérifié sur le site`, `nom exact (site injoignable)`, `site déjà présent`, ou la raison pour laquelle rien n'a été écrit.

Toutes les colonnes d'entrée ressortent intactes (contrat de passthrough des colonnes).

Cycle de vie

POST /api/jobs/site-finder → pending → running → completed.

Les lignes qui ont déjà un site sont écrites directement en sortie et jamais recherchées : enchaîner ce module après un module moins cher ne coûte rien sur les lignes déjà remplies.

L'annulation est prise en compte entre deux entreprises. Une ligne qui échoue deux fois est écrite avec site_finder_match = recherche indisponible plutôt que perdue.

Chaînage


entrée	`pois_any`
sortie	`pois`
exige	`nom`
produit	`site_web`, `site_finder_match`

Ordre recommandé : sirene → opendata → site_finder → emails. Les deux premiers sont gratuits et instantanés ; celui-ci coûte du temps réseau, il ne doit voir que ce qu'ils n'ont pas pu remplir.

Erreurs

Cas	Comportement
Aucun nom exploitable dans la liste	`400` avec la liste des colonnes lues
Moteur de recherche indisponible	La ligne est réessayée sur une autre sortie VPN, puis écrite vide avec une raison explicite
Site candidat injoignable	Accepté seulement si le domaine reprend exactement le nom, sinon ignoré
Homonyme dans une autre ville	Rejeté : la preuve par code postal / commune échoue, rien n'est écrit

Et après

La sortie alimente tous les modules qui exigent un site web. emails est la suite habituelle.