V1.23.25 Constitution d'une BDD mutualisée des entreprises et alimentation avec 56, 29

journal/ASPIC - Reflexions strategiques.md

@@ -441,3 +441,29 @@ Restait un point sans case évidente : la dimension relationnelle envers l'équi
 **Statut.** Modèle à quatre facettes adopté et codé le soir même (voir journal de développement, section 33) ; prompts sortis du code pour les quatre cas réels du projet ; dé-figement du prénom du patron traité comme un premier cas d'école, pas comme un chantier de "multi-tenant" en soi — aucune autre donnée de ce type recherchée systématiquement à ce stade.
 
 `<code>` avance également au cours de cette même session (détail au journal de développement, section 33) — nouvelle version **V1.23.24**. Point de méthode noté au passage (voir Index) : `<conception>` est un compteur libre, incrémenté à chaque évolution jugée majeure — **il ne correspond pas** au numéro que prend la section ci-dessus dans ce document (24), malgré une coïncidence numérique fréquente ces derniers jours.
+
+## 25. Prospection B2B — mutualisation de la ressource entreprises, architecture Phase1/2/3, et découverte de la prospection par géographie personnelle (11-12 septembre 2026)
+
+**Origine.** Une coupure de session dans la nuit du 11 au 12 septembre (timeout du proxy devant le terminal web, sans rapport avec ASPIC — voir journal d'infrastructure) a fait perdre le fil de ce qui avait été lancé la veille au soir : l'extraction Sirene/RNE quasi-exhaustive du Morbihan, décidée section 23 comme canal gratuit de démarrage pour la prospection B2B. Reconstitué avec Jean-Marc au réveil, puis vérifié par comparaison avec l'API Sirene officielle (département 56, tranche par tranche d'effectif) : les 167 468 lignes de `ASP_EntreprisePhase1` sont bien le résultat complet voulu, pas un traitement resté à mi-chemin — écart de 9 lignes sur les tranches connues, imputable à la fraîcheur des données entre l'extraction et la vérification, pas à un trou réel.
+
+**La réflexion nocturne de Jean-Marc, double.** D'une part, pour lui-même : ASPIC peut désormais lui fournir une base de prospection déjà constituée gratuitement, pour se concentrer sur la sélection et la qualification plutôt que sur la collecte. D'autre part, une prise de conscience plus large, déclenchée par un ami rennais dans une situation de projet proche (formation en cours, création de société prévue en janvier 2027) : cet ami envisage uniquement des moyens de prospection passifs (site, bouche-à-oreille, publicité), faute de savoir aborder une prospection active — situation à laquelle Jean-Marc n'avait pas encore songé à le confronter. Conclusion : la ressource en cours de constitution a suffisamment de valeur pour justifier de sortir son organisation du cadre strictement personnel envisagé jusque-là.
+
+**Décision de mutualisation.** La table sort de l'environnement MySQL personnel de Jean-Marc pour rejoindre l'instance `mysql2` — celle qui héberge déjà MIRADOR, la base d'authentification centralisée commune à tous les utilisateurs d'ASPIC (voir section sur MIRADOR, journal de développement). Nouvelle base dédiée : `ENTREPRISES`. Architecture retenue à cette occasion, avec une distinction de principe qui devra rester vraie même quand ASPIC aura plusieurs utilisateurs réels : les données Sirene/RNE brutes (identité, effectif, finances) sont publiques et doivent être **partagées** (une seule synchronisation profite à tous, jamais de copie qui dérive) ; les données de qualification/prospection (statut, canal, notes, rendez-vous) doivent rester **propres à chaque utilisateur/compte**, pour qu'un jour deux prospecteurs ne risquent pas de démarcher la même entreprise sans le savoir l'un de l'autre.
+
+**Une table par département plutôt qu'une table nationale unique**, vu le volume (167 468 lignes pour le seul 56) : `EntreprisesXXPhase1`/`Phase2`/`Phase3` (XX = code département), colonnes uniformément préfixées `ENT_` (la phase étant déjà portée par le nom de table, inutile de la répéter dans le préfixe de colonne comme le faisait l'ancien `EP1_`/`EP2_`).
+
+**`ENT_Communes`, seule table volontairement partagée entre tous les départements** (une ligne par commune, code INSEE en clé) — pour deux raisons distinctes de celle qui vaut pour les finances (voir plus bas) : jamais de doublon possible (une commune n'appartient qu'à un seul département), et surtout, la recherche de proximité doit pouvoir **traverser une frontière départementale** sans que l'utilisateur ait à s'en soucier — une commune du 35 peut être à dix minutes d'une commune du 22.
+
+**Découverte capitale de la soirée : le calcul d'isochrone par l'IGN (Géoplateforme, `data.geopf.fr/navigation/isochrone`)**, service public gratuit et sans clé, fondé sur le réseau routier réel (BD TOPO®) — pas une distance à vol d'oiseau. Un seul appel avec un point de départ quelconque (pas forcément une adresse personnelle) et une durée en minutes renvoie le polygone exact de la zone accessible en voiture ; test réel réussi (30 minutes depuis Lorient → 19 communes environnantes, cohérentes avec la géographie du secteur). Ceci ouvre à Jean-Marc une façon de travailler qu'il juge nouvelle : construire sa tournée de prospection autour de ses propres déplacements (exemple donné : 15 jours à Saint-Malo avec sa compagne) plutôt que l'inverse — la géographie personnelle devient le point de départ de l'organisation commerciale, pas une contrainte à laquelle elle doit se plier après coup.
+
+**Phase3 — l'historique financier, seule question réellement débattue ce soir.** Constat vérifié sur les données réelles du 56 : le champ `finances` de l'API ne renvoie jamais qu'**une seule année à la fois** par entreprise (15 010 entreprises concernées sur 167 468, jamais plus d'une année chacune) — pas une fenêtre glissante de plusieurs années comme le suggérait la documentation générale. Toute resynchronisation qui écraserait ce champ perdrait donc purement et simplement l'année précédente, pas seulement une lointaine année n-4. Décision : `EntreprisesXXPhase3`, table étroite (SIREN, année, CA, résultat net, date de maj), clé composite `(SIREN, année)`, alimentée en `INSERT ... ON DUPLICATE KEY UPDATE` — une nouvelle année crée une nouvelle ligne, elle ne touche jamais celles des années déjà connues. Question annexe tranchée en sens inverse de `ENT_Communes` : Phase3 reste **par département**, pas globalisée — les finances d'une entreprise n'ont pas de besoin de continuité géographique inter-départementale comme les communes, et le prix d'une table nationale unique (clauses `WHERE` partout pour retrouver "les finances des entreprises du 29") ne se justifie pas face au bénéfice réel (éviter la rare duplication d'un SIREN présent dans plusieurs départements).
+
+**Script d'extraction générique, hors dépôt applicatif** (`/docker/aspic/scripts/sirene_extract.py` — délibérément à côté de `src/`, pas dans le code d'ASPIC lui-même, cohérent avec la décision de la section précédente : ce chantier reste "à la mimine" avant toute intégration éventuelle dans l'app). Il crée les trois tables par département à la volée, découpe automatiquement les requêtes par commune puis par section NAF quand une commune dépasse à elle seule le plafond de 10 000 résultats de l'API (deux communes seulement en ont eu besoin sur les 249 du Morbihan : Lorient et Vannes), et neutralise proprement les cas limites découverts en le testant sur trois départements réels (Morbihan en migration, Lozère en test, Finistère en cours) : entités en diffusion partielle RGPD (`[NON-DIFFUSIBLE]`), sièges sociaux à l'étranger (codes postaux non-français), qualités de dirigeant cumulées dépassant la largeur de colonne prévue.
+
+**Confirmation et chiffrage de décisions déjà actées.** Le rejet du scraping LinkedIn (section du 11 septembre) reste confirmé sans hésitation. Les tarifs réels des prestataires de fichiers de contacts complets (dirigeant + email + téléphone) ont été recherchés : 0,15 à 0,50 €/contact à l'achat, 2 à 5 €/contact chez Kompass avec abonnement minimum ~3000 €/an — jugés trop coûteux pour une société qui démarre, ce qui renforce la méthode déjà actée (qualifier gratuitement via Sirene avant d'acheter ou d'enrichir le contact).
+
+**Pistes identifiées pour la synchronisation quotidienne future, non construites ce soir.** Deux API distinctes selon la nature de la donnée : l'API Sirene officielle (`api.insee.fr`, inscription séparée requise) pour l'identité/effectif via une requête par plage de dates (`dateDernierTraitementUniteLegale`) ; l'API différentielle du RNE/INPI (`registre-national-entreprises.inpi.fr/api/companies/diff` et `/api/bilans-saisis`) pour les formalités et les comptes annuels, toutes deux avec un curseur (`searchAfter`) pour contourner leur propre plafond de 10 000 résultats.
+
+**Statut.** Migration du 56 terminée et vérifiée (167 468 lignes, structure `ENT_`). Extraction du 29 en cours au moment de la rédaction ; 48 traité comme département témoin pour les tests (21 859 entreprises). Restent à traiter : 22 et 35 (Bretagne), puis 17 et 64 évoqués pour l'usage "déplacement personnel". `ENT_Communes` alimentée pour 56/48/29. La synchronisation quotidienne (INPI/INSEE) reste à concevoir et construire — rien engagé au-delà de l'identification des bons endpoints. Aucune ligne de code applicatif ASPIC touchée ce soir : tout le travail décrit ici vit hors du dépôt (base `ENTREPRISES` + script autonome), toujours volontairement tenu à l'écart de l'application elle-même.
+
+`<code>` n'avance pas dans cette section (aucune ligne du dépôt applicatif ASPIC touchée) ; `<conception>` avance de 24 à 25 — nouvelle version **V1.23.25**.