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

journal/ASPIC - Journal. Index.md

@@ -178,8 +178,9 @@ Version incrémentée une seule fois pour l'ensemble de cette session (uniquemen
 - Stockage de documents utilisateur (PDF) — architecture actée par anticipation (réflexions stratégiques, section 21 : stockage hors racine servie par le serveur web, endpoint PHP dédié, sous-dossier opaque par client en défense en profondeur), aucun développement engagé, pas de besoin immédiat.
 - **Compétence "sites web" de Sophia (section 31, 10-11 septembre 2026), points laissés ouverts :** lecture réelle du catalogue/documents de l'entreprise (dépend de classeurs encore vides, section 19) ; support des images/fichiers binaires dans un site (texte seul pour l'instant) ; rattachement d'un site publié à un vrai nom de domaine (vhost Apache ou `npm-app-1`, étape manuelle) ; synchronisation du schéma des 5 nouvelles tables vers `MS-TST` (pas encore faite) ; vérification détaillée par Jean-Marc de ce que Sophia a réellement écrit lors du premier essai réel.
 - **BackOffice (section 32, 11 septembre 2026), points laissés ouverts :** `ASP_Agents.AGN_Competences` — **câblé en addendum le 11 septembre 2026** (`agents_competences.php` l'écrase/recalcule à chaque attribution/retrait de compétence ; lu par `mission_agent.php` et par `collaborateur_dialogue.php`, en plus d'`AGN_Identite`/`AGN_Experience`), non encore vérifié en conditions réelles. Endpoint de téléchargement de fichier depuis un espace disque utilisateur (`telecharger_fichier.php` ou équivalent) — architecture posée (section 32), rien construit. Comportement réel du cache de prompt et de la journalisation du coût IA à confirmer sur un premier vrai appel après ce soir (aucun appel réseau réel déclenché depuis l'environnement de développement).
-- **Travail non poussé sur GitHub, découvert le 11 septembre 2026, toujours en attente :** les chantiers des 10 et 11 septembre (collaborateurs, compétences/missions, BackOffice, puis vision des compétences/Relationnel/sortie des prompts le soir) n'ont jamais été committés/poussés — `git status` montre tout en attente. Décision prise par Jean-Marc (11 septembre, soir) : il gère lui-même le commit/push, y compris la rédaction du message — pas une tâche à déléguer à Claude, "ça m'oblige aussi à continuer à manipuler".
+- **Travail non poussé sur GitHub, découvert le 11 septembre 2026 — résolu.** Les chantiers des 10 et 11 septembre étaient restés en attente de commit/push ; `git status` est de nouveau propre au 12 septembre 2026, Jean-Marc ayant fait le commit/push lui-même dans l'intervalle, comme décidé. Rappel de la décision, qui reste valable pour la suite : Jean-Marc gère lui-même tout commit/push sur ce dépôt, y compris la rédaction du message — jamais une tâche à déléguer à Claude, "ça m'oblige aussi à continuer à manipuler". Les fichiers modifiés ce soir (`version.php`, ce document, les réflexions stratégiques section 25) sont prêts sur le disque pour ce même circuit, non commités par Claude.
 - Vérifier que la colonne `AGN_Relationnel` (ajoutée par Jean-Marc le 11 septembre 2026, sans type précisé par Claude) est assez large pour un texte libre, cohérente avec `AGN_Identite`/`AGN_Experience` (MEDIUMTEXT).
 - Affiner individuellement l'identité/le relationnel de chaque collaborateur (Matilda, Viktor, Léon, Nikita, Sophia) — explicitement reporté par Jean-Marc le 11 septembre 2026 à plus tard ("quand je n'aurai que ça à faire").
 - Créer un répertoire dédié sur le serveur pour transmettre directement des fichiers à Claude (photos notamment) — envisagé par Jean-Marc le 11 septembre 2026, pas encore fait.
-- **Services externes pour les futurs chantiers (prospection, réseaux sociaux) — réflexions stratégiques section 23 (11 septembre 2026) :** décision de méthode actée (préférer un service externe existant au cas par cas, internaliser ensuite si besoin réel constaté), mais aucun service concret encore choisi ni intégré — recherche à reprendre spécifiquement pour ces deux chantiers quand ils s'ouvriront.
+- **Services externes pour les futurs chantiers (prospection, réseaux sociaux) — réflexions stratégiques section 23 (11 septembre 2026).** Volet prospection largement avancé dans la nuit du 11 au 12 septembre : canal Sirene/RNE choisi et mis en œuvre pour de bon (voir réflexions stratégiques section 25) — décision de méthode de la section 23 confirmée dans les faits (gratuit d'abord, achat de contact seulement une fois la cible resserrée). Volet réseaux sociaux toujours entièrement ouvert, recherche à reprendre quand ce chantier s'ouvrira.
+- **Prospection B2B (réflexions stratégiques section 25, 11-12 septembre 2026) — suite à donner :** étendre l'extraction Sirene/RNE aux départements 22 et 35 (puis 17 et 64 évoqués pour l'usage "déplacement personnel"), avec le script `/docker/aspic/scripts/sirene_extract.py` (hors dépôt applicatif, non versionné à ce stade — décider un jour s'il mérite son propre dépôt Git). Concevoir et construire la synchronisation quotidienne (API Sirene officielle `api.insee.fr` + API différentielle RNE/INPI `companies/diff`/`bilans-saisis`, toutes deux identifiées mais non implémentées). Phase3 (historique financier) alimentée pour l'instant par le seul script d'extraction ponctuel, pas encore branchée à une tâche récurrente réelle. Écran de sélection par isochrone (temps de trajet depuis un point quelconque, IGN Géoplateforme, démontré fonctionnel) — rien construit côté interface, idée seule actée à ce stade.

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**.

version.php

@@ -50,7 +50,7 @@
  * capacité à détecter un déploiement resté en retard.
  */
 
-const ASPIC_VERSION = 'V1.23.24';
+const ASPIC_VERSION = 'V1.23.25';
 
 if (basename($_SERVER['SCRIPT_NAME']) === 'version.php') {
     header('Content-Type: application/json; charset=utf-8');