diff --git a/fdr/1. Évolutions BDD ENTREPRISES V6.pdf b/fdr/1. Évolutions BDD ENTREPRISES V6.pdf deleted file mode 100644 index 0f3edf5..0000000 Binary files a/fdr/1. Évolutions BDD ENTREPRISES V6.pdf and /dev/null differ diff --git a/fdr/1. Évolutions BDD ENTREPRISES V8.docx b/fdr/1. Évolutions BDD ENTREPRISES V8.docx new file mode 100644 index 0000000..b543cc9 Binary files /dev/null and b/fdr/1. Évolutions BDD ENTREPRISES V8.docx differ diff --git a/fdr/3. Sélection des Entreprises V6.pdf b/fdr/3. Sélection des Entreprises V6.pdf new file mode 100644 index 0000000..52cf6cb Binary files /dev/null and b/fdr/3. Sélection des Entreprises V6.pdf differ diff --git a/fdr/3. Sélection des Entreprises V7.docx b/fdr/3. Sélection des Entreprises V7.docx new file mode 100644 index 0000000..cbf5354 Binary files /dev/null and b/fdr/3. Sélection des Entreprises V7.docx differ diff --git a/fdr/3. Sélection des entreprises. Ecrans V1.xlsx b/fdr/3. Sélection des entreprises. Ecrans V1.xlsx new file mode 100644 index 0000000..a7800fb Binary files /dev/null and b/fdr/3. Sélection des entreprises. Ecrans V1.xlsx differ diff --git a/fdr/detecteur_metaux_traces_disque_variante_4.png b/fdr/detecteur_metaux_traces_disque_variante_4.png new file mode 100644 index 0000000..d19436d Binary files /dev/null and b/fdr/detecteur_metaux_traces_disque_variante_4.png differ diff --git a/fdr/detecteur_metaux_un_seul_courbe_conservee.png b/fdr/detecteur_metaux_un_seul_courbe_conservee.png new file mode 100644 index 0000000..a4f0230 Binary files /dev/null and b/fdr/detecteur_metaux_un_seul_courbe_conservee.png differ diff --git a/journal/ASPIC - Journal. Index.md b/journal/ASPIC - Journal. Index.md index fc8397d..8b6334f 100644 --- a/journal/ASPIC - Journal. Index.md +++ b/journal/ASPIC - Journal. Index.md @@ -183,4 +183,4 @@ Version incrémentée une seule fois pour l'ensemble de cette session (uniquemen - 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).** 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) — mise à jour du 12 septembre 2026 (après-midi) : les 4 départements bretons sont désormais tous extraits.** `Entreprises56/29/22/35Phase1` alimentées via `src/scripts/sirene_extract.py` (déplacé de `/docker/aspic/scripts/` dans le dépôt applicatif ce même après-midi, pour bénéficier du même suivi Git que le reste — voir `.gitignore` mis à jour pour exclure `scripts/__pycache__/`) : 167 468 + 174 691 + 128 904 + 227 713 = **698 776 entreprises** (chiffre après correction Rennes, voir juste après), Phase3 (historique financier) alimentée en parallèle pour chacun. Cas limite rencontré puis corrigé le même après-midi : sur la commune de **Rennes** (35238, pas Saint-Malo comme noté par erreur dans un premier temps), la section NAF "L" (activités immobilières) restait plafonnée à 10 000 même après repli par section — ajout d'un 3e niveau de repli par code NAF précis (liste complète des 732 codes récupérée depuis le message d'erreur de validation de l'API elle-même). Rennes réextraite avec ce correctif : 69 115 entreprises retrouvées pour la seule commune (dont 50 857 bien rattachées à Rennes elle-même comme siège), portant le total du 35 de 221 646 à 227 713. **Mise à jour de la nuit du 12 au 13 septembre 2026 (réflexions stratégiques, section 26).** Comptes INSEE et INPI créés (identifiants dans `src/scripts/.env`, jamais commité). Backfill historique des comptes annuels (le **BFH**, `src/scripts/inpi_bilans_backfill.py`) conçu et lancé sur le 56 — a provoqué un incident sérieux (OOM ayant tué le script et systemd), corrigé (garde-fou de pagination + `ulimit -v` désormais systématique sur ces scripts). Tables `ENT_Departements`/`ENT_Config` ajoutées. Compression InnoDB appliquée à Phase1 (-60% de taille disque, projection nationale ramenée de ~70 à ~28-30 Go). Plan pour la suite de la nuit, sans supervision : une fois le BFH du 56 terminé, extraction + BFH enchaînés pour **44, 49, 85, 17, 40, 64, 65**. Toujours à faire : synchronisation quotidienne par API différentielle (`companies/diff`/`bilans-saisis`) déclenchée par n8n plutôt qu'une crontab — comptes créés mais rien construit côté n8n. Écran de sélection par isochrone (IGN Géoplateforme, démontré fonctionnel) — idée actée, rien construit côté interface. **Mise à jour du 13 septembre 2026 (réflexions stratégiques, section 27).** Chaîne 44/49/85/17/40/64/65 terminée sans incident dans la nuit. Champ `ENT_CodeCommune` ajouté à Phase1 (backfill sans nouvel appel API) et cinq compteurs par taille d'entreprise (`COM_EI/TPE/PME/ETI/GE`) ajoutés à `ENT_Communes`, calculés quotidiennement par `ent_communes_stats.py` (deux bugs corrigés : agrégat `SUM()` sur ensemble vide, et pollution inter-département des stats d'une commune). Quatre prototypes de carte de prospection géographique publiés en Artifacts (Lorient, Lanester, Concarneau, Beuzec-Cap-Sizun) : commune de départ + communes accessibles en 30 min de route réelles (isochrone IGN), avec effectifs réels par taille — navigation par cliquer-glisser (clic gauche et droit) après un premier essai à l'ascenseur natif jugé peu lisible. Deuxième chaîne lancée pour 31/32/33/46/47/09/13/66 : bug de fond découvert et corrigé sur le repli NAF à 3 niveaux (retestait les 732 codes NAF entiers à chaque section plafonnée au lieu des seuls codes de la section — bloquait Toulouse depuis des heures), département 31 relancé et terminé après correctif. Cap des 2 millions d'entreprises cumulées franchi (2,23M sur 15 départements). Premières réflexions actées sur la refonte du module Contacts (lien entreprise↔contact non exclusif, qualification portée par l'entreprise) — rien construit, sujet remis à l'ouverture formelle du chantier. **Mise à jour du 14-15 septembre 2026 (réflexions stratégiques, section 28).** Deux bugs supplémentaires trouvés et corrigés sur le BFH (curseur de pagination basé sur le SIREN au lieu de l'identifiant unique du bilan, perdant ~14% des lots ; jeton INPI expirant en cours d'exécution sans reconnexion automatique), puis un vrai quota INPI dépassé rencontré (`quota_exceeded`) — **BFH suspendu entièrement** sur décision de Jean-Marc (risque de bannissement jugé disproportionné), à reprendre progressivement dans les mois à venir. Découverte indépendante et majeure sur l'extraction Sirene : **Paris, Lyon et Marseille étaient massivement sous-captées** (les entreprises y sont rattachées à un code arrondissement, jamais au code commune englobant qu'utilisait la liste de communes) — corrigé dans `sirene_extract.py`, `ENT_Communes` réparée pour le 13, réextraction replanifiée. Nouvelle chaîne d'extraction Sirene seule (aucun appel INPI) lancée pour la France entière restante, **DOM-TOM inclus** à la demande de Jean-Marc (La Réunion en tête). Statut au 15 septembre : 55 départements, 7 036 958 entreprises (~83% du national), BFH à l'arrêt. Piste d'export en masse du RNE par FTP/SFTP (`opendata`/`www.inpi.net`) identifiée via un contact de Jean-Marc, vérifiée réelle et testée en lecture seule (stock formalités 15,1 Go incluant le capital social, dernier stock à 6 mois d'écart, pas de flux quotidien visible) — accès obtenu, rien exploité encore. Jean-Marc est revenu sur sa décision initiale : le capital social doit être mutualisé dans `ENTREPRISES` (donnée factuelle), pas privé par compte, avec une exception assumée au principe de non-écriture applicative pour ce champ précis. Feuille de route formelle déposée (`src/fdr/1. ENTREPRISES V1.0`) et relue en détail (retour donné, pas d'implémentation) — découverte au passage que le champ JSON `matching_etablissements[]` donne probablement l'adresse des établissements secondaires. Trombinoscope des cinq collaborateurs ASPIC clarifié : Matilda, Viktor (commercial/qualification), Sophia, Léon (gestion/`ENTREPRISES`), Nikita. **Mise à jour du 16 septembre 2026 (réflexions stratégiques, section 29).** Méthode des feuilles de route institutionnalisée : dépôt PDF/`.docx` numéroté (1 à 11) dans `src/fdr`, retour de Claude Code toujours intégré dans une nouvelle version du fichier (plus seulement en conversation). Outillage installé (`python-docx`, `openpyxl`) pour générer des `.docx` éditables et lire des maquettes Excel. Vérification empirique demandée par Jean-Marc pour trancher un doute : **7 802 SIREN confirmés présents en double entre les tables du 35 et du 44** (établissement secondaire compté aussi bien dans le département du siège que dans celui où il se trouve) — le stockage des filiales devra être repensé, noté pour la suite. Nouvelle feuille de route "3. Sélection des Entreprises" déposée et itérée. **Cible nationale recalibrée de 8,5M à 13,4M** (un site tiers cite le chiffre SIRENE brut "établissements sièges", à distinguer de l'agrégat statistique INSEE qui regroupe les filiales d'un groupe) — projection disque recalculée à ~43,5 Go (toujours confortable). Lyon (69) extrait avec succès : 506 425 entreprises, le plus gros département à ce jour, correctif arrondissements validé en conditions réelles. Statut extraction : 74/101 départements, 9 855 993 entreprises. Clarifications hors chantier : abonnement Claude Max ≠ API Anthropic (deux facturations séparées) ; piste Claude Cowork pour les fonctionnalités réseaux sociaux côté utilisateur final (hors budget API d'ASPIC). +- **Prospection B2B (réflexions stratégiques section 25, 11-12 septembre 2026) — mise à jour du 12 septembre 2026 (après-midi) : les 4 départements bretons sont désormais tous extraits.** `Entreprises56/29/22/35Phase1` alimentées via `src/scripts/sirene_extract.py` (déplacé de `/docker/aspic/scripts/` dans le dépôt applicatif ce même après-midi, pour bénéficier du même suivi Git que le reste — voir `.gitignore` mis à jour pour exclure `scripts/__pycache__/`) : 167 468 + 174 691 + 128 904 + 227 713 = **698 776 entreprises** (chiffre après correction Rennes, voir juste après), Phase3 (historique financier) alimentée en parallèle pour chacun. Cas limite rencontré puis corrigé le même après-midi : sur la commune de **Rennes** (35238, pas Saint-Malo comme noté par erreur dans un premier temps), la section NAF "L" (activités immobilières) restait plafonnée à 10 000 même après repli par section — ajout d'un 3e niveau de repli par code NAF précis (liste complète des 732 codes récupérée depuis le message d'erreur de validation de l'API elle-même). Rennes réextraite avec ce correctif : 69 115 entreprises retrouvées pour la seule commune (dont 50 857 bien rattachées à Rennes elle-même comme siège), portant le total du 35 de 221 646 à 227 713. **Mise à jour de la nuit du 12 au 13 septembre 2026 (réflexions stratégiques, section 26).** Comptes INSEE et INPI créés (identifiants dans `src/scripts/.env`, jamais commité). Backfill historique des comptes annuels (le **BFH**, `src/scripts/inpi_bilans_backfill.py`) conçu et lancé sur le 56 — a provoqué un incident sérieux (OOM ayant tué le script et systemd), corrigé (garde-fou de pagination + `ulimit -v` désormais systématique sur ces scripts). Tables `ENT_Departements`/`ENT_Config` ajoutées. Compression InnoDB appliquée à Phase1 (-60% de taille disque, projection nationale ramenée de ~70 à ~28-30 Go). Plan pour la suite de la nuit, sans supervision : une fois le BFH du 56 terminé, extraction + BFH enchaînés pour **44, 49, 85, 17, 40, 64, 65**. Toujours à faire : synchronisation quotidienne par API différentielle (`companies/diff`/`bilans-saisis`) déclenchée par n8n plutôt qu'une crontab — comptes créés mais rien construit côté n8n. Écran de sélection par isochrone (IGN Géoplateforme, démontré fonctionnel) — idée actée, rien construit côté interface. **Mise à jour du 13 septembre 2026 (réflexions stratégiques, section 27).** Chaîne 44/49/85/17/40/64/65 terminée sans incident dans la nuit. Champ `ENT_CodeCommune` ajouté à Phase1 (backfill sans nouvel appel API) et cinq compteurs par taille d'entreprise (`COM_EI/TPE/PME/ETI/GE`) ajoutés à `ENT_Communes`, calculés quotidiennement par `ent_communes_stats.py` (deux bugs corrigés : agrégat `SUM()` sur ensemble vide, et pollution inter-département des stats d'une commune). Quatre prototypes de carte de prospection géographique publiés en Artifacts (Lorient, Lanester, Concarneau, Beuzec-Cap-Sizun) : commune de départ + communes accessibles en 30 min de route réelles (isochrone IGN), avec effectifs réels par taille — navigation par cliquer-glisser (clic gauche et droit) après un premier essai à l'ascenseur natif jugé peu lisible. Deuxième chaîne lancée pour 31/32/33/46/47/09/13/66 : bug de fond découvert et corrigé sur le repli NAF à 3 niveaux (retestait les 732 codes NAF entiers à chaque section plafonnée au lieu des seuls codes de la section — bloquait Toulouse depuis des heures), département 31 relancé et terminé après correctif. Cap des 2 millions d'entreprises cumulées franchi (2,23M sur 15 départements). Premières réflexions actées sur la refonte du module Contacts (lien entreprise↔contact non exclusif, qualification portée par l'entreprise) — rien construit, sujet remis à l'ouverture formelle du chantier. **Mise à jour du 14-15 septembre 2026 (réflexions stratégiques, section 28).** Deux bugs supplémentaires trouvés et corrigés sur le BFH (curseur de pagination basé sur le SIREN au lieu de l'identifiant unique du bilan, perdant ~14% des lots ; jeton INPI expirant en cours d'exécution sans reconnexion automatique), puis un vrai quota INPI dépassé rencontré (`quota_exceeded`) — **BFH suspendu entièrement** sur décision de Jean-Marc (risque de bannissement jugé disproportionné), à reprendre progressivement dans les mois à venir. Découverte indépendante et majeure sur l'extraction Sirene : **Paris, Lyon et Marseille étaient massivement sous-captées** (les entreprises y sont rattachées à un code arrondissement, jamais au code commune englobant qu'utilisait la liste de communes) — corrigé dans `sirene_extract.py`, `ENT_Communes` réparée pour le 13, réextraction replanifiée. Nouvelle chaîne d'extraction Sirene seule (aucun appel INPI) lancée pour la France entière restante, **DOM-TOM inclus** à la demande de Jean-Marc (La Réunion en tête). Statut au 15 septembre : 55 départements, 7 036 958 entreprises (~83% du national), BFH à l'arrêt. Piste d'export en masse du RNE par FTP/SFTP (`opendata`/`www.inpi.net`) identifiée via un contact de Jean-Marc, vérifiée réelle et testée en lecture seule (stock formalités 15,1 Go incluant le capital social, dernier stock à 6 mois d'écart, pas de flux quotidien visible) — accès obtenu, rien exploité encore. Jean-Marc est revenu sur sa décision initiale : le capital social doit être mutualisé dans `ENTREPRISES` (donnée factuelle), pas privé par compte, avec une exception assumée au principe de non-écriture applicative pour ce champ précis. Feuille de route formelle déposée (`src/fdr/1. ENTREPRISES V1.0`) et relue en détail (retour donné, pas d'implémentation) — découverte au passage que le champ JSON `matching_etablissements[]` donne probablement l'adresse des établissements secondaires. Trombinoscope des cinq collaborateurs ASPIC clarifié : Matilda, Viktor (commercial/qualification), Sophia, Léon (gestion/`ENTREPRISES`), Nikita. **Mise à jour du 16 septembre 2026 (réflexions stratégiques, section 29).** Méthode des feuilles de route institutionnalisée : dépôt PDF/`.docx` numéroté (1 à 11) dans `src/fdr`, retour de Claude Code toujours intégré dans une nouvelle version du fichier (plus seulement en conversation). Outillage installé (`python-docx`, `openpyxl`) pour générer des `.docx` éditables et lire des maquettes Excel. Vérification empirique demandée par Jean-Marc pour trancher un doute : **7 802 SIREN confirmés présents en double entre les tables du 35 et du 44** (établissement secondaire compté aussi bien dans le département du siège que dans celui où il se trouve) — le stockage des filiales devra être repensé, noté pour la suite. Nouvelle feuille de route "3. Sélection des Entreprises" déposée et itérée. **Cible nationale recalibrée de 8,5M à 13,4M** (un site tiers cite le chiffre SIRENE brut "établissements sièges", à distinguer de l'agrégat statistique INSEE qui regroupe les filiales d'un groupe) — projection disque recalculée à ~43,5 Go (toujours confortable). Lyon (69) extrait avec succès : 506 425 entreprises, le plus gros département à ce jour, correctif arrondissements validé en conditions réelles. Statut extraction : 74/101 départements, 9 855 993 entreprises. Clarifications hors chantier : abonnement Claude Max ≠ API Anthropic (deux facturations séparées) ; piste Claude Cowork pour les fonctionnalités réseaux sociaux côté utilisateur final (hors budget API d'ASPIC). **Mise à jour du 17 septembre 2026 (réflexions stratégiques, section 30).** Incident de parallélisme causé par Claude Code lui-même : une reprise du 74 lancée en même temps que la chaîne principale a saturé l'API Sirene (429), cascadant sur 75 (Paris)/76/77 — corrigé (script durci, plus jamais de traitement en parallèle) et reprise séquentielle programmée ; un second incident sans lien (verrou MySQL) a ensuite ajouté le 88 à la liste. **Naissance du projet dérivé `entreprises.bzh`** (domaine acquis) : accès aux données d'entreprises par isochrone plutôt que rayon, mis en ligne visé à la création de la société début 2027 (un an avant ASPIC), avec un objectif d'entraînement (paiement en ligne, facturation électronique, réseaux sociaux) autant que commercial. Dossier de marché commandé à une autre session Claude, relu : confirme un vrai créneau libre (fraîcheur quotidienne + géographie fine, aucun concurrent ne combine les deux) et révèle que le statut "P" (diffusion partielle, ex-non-diffusible) n'est pas capturé dans `ENTREPRISES` — à corriger lors du remodelage prévu, pas maintenant. Discussion approfondie sur les limites de l'enrichissement LinkedIn (Waalaxy et assimilés, risque d'éditeur distinct du risque utilisateur). Double-comptage inter-départements mesuré précisément : 1 189 137 doublons sur 12,3M lignes (9,6%), ~4,18 Go de poids disque. Feuilles de route ENTREPRISES (V7) et Sélection des Entreprises (V7) mises à jour. Fin d'extraction estimée pour le week-end du 19-20 septembre. **Mise à jour du 18 septembre 2026 (réflexions stratégiques, section 31).** Alerte disque serveur (84% d'occupation) : diagnostic révèle 79 Go de binlogs MySQL jamais purgés sur l'instance mysql2 (rétention à 30 jours, disproportionnée face au volume d'écriture de l'extraction), pas un problème de données — `ENTREPRISES` elle-même ne pèse que 52 Go, croissance normale. Purgé avec l'autorisation explicite de Jean-Marc (bloqué une première fois par le classificateur de sécurité du mode auto, qui l'a pris pour une altération de journaux d'audit) : disque ramené de 84% à 43%. Rétention réduite temporairement à 3 jours le temps du chantier. **Mise à jour du 18-19 septembre 2026 (réflexions stratégiques, section 32).** Bug de fond découvert et corrigé sur la Corse : le paramètre `code_commune` de l'API Sirene échoue silencieusement sur les codes alphanumériques (2A/2B), remplacé par une requête directe au niveau département pour ces deux cas — `sirene_extract.py` modifié en conséquence. Deux départements orphelins retrouvés en vérifiant l'état de `ENT_Departements` (88, planté le 17 septembre mais jamais réintégré à la reprise ; 48, données déjà extraites mais jamais finalisées) et ajoutés à la file de reprise, désormais 74/75/76/77/88/2A/2B/48 derrière la fin de la chaîne principale (13, Marseille). Total national fait le point : 94 départements fiables à 13 088 450 entreprises, Paris déjà à 831 979 avant même la fin de sa reprise. Exploration du logo (détecteur/pépite) refermée sans aboutir : Pippit AI a fini par signaler son incapacité à retoucher précisément (pas de calques), une alternative vectorielle proposée par Claude Code jugée trop abstraite — piste de retouche manuelle (Photopea) identifiée mais reportée. Recherche du nom de domaine d'`entreprises.bzh` close après plusieurs vérifications systématiques (marque INPI + collision de nom, conformément au principe explicite de Jean-Marc "éviter les problèmes plutôt que devoir les gérer") : `prospecter.bzh` écarté (marque française active "PROSPECTER" détenue par TESSI, classe 35) ; piste `fichiers-prospects.fr` explorée puis délaissée en cours de route ; API Pappers étudiée pour ses numéros de téléphone d'entreprise mais écartée (CGU interdisant explicitement toute réutilisation pour alimenter un service tiers). Nom définitivement retenu : **`entreprizh.bzh`**, disponible, accordé par l'association .bzh, vérifié propre par Claude Code puis confirmé sans résultat par Jean-Marc lui-même sur data.inpi.fr — achat décidé le soir même. **Mise à jour du 19-20 septembre 2026 (réflexions stratégiques, section 33) : extraction Sirene entièrement terminée.** La file de reprise a enchaîné sans incident sur 74/75(Paris)/76/77/88/2A/2B/48 ; le correctif Corse a fonctionné du premier coup (2A : 55 190, 2B : 54 823 entreprises). **Total national final : 101 départements, 15 972 915 entreprises.** Plus aucun processus d'extraction actif. Le chantier de restructuration ENTREPRISES (siège/filiale, partitionnement, statut "P") peut désormais démarrer sur des données complètes — Jean-Marc prévoit une session neuve pour ce chantier. Rétention des binlogs MySQL toujours à 3 jours (section 31), à remettre à 30 jours maintenant que l'extraction est finie. diff --git a/journal/ASPIC - Reflexions strategiques.md b/journal/ASPIC - Reflexions strategiques.md index 47babf0..3be06d0 100644 --- a/journal/ASPIC - Reflexions strategiques.md +++ b/journal/ASPIC - Reflexions strategiques.md @@ -545,3 +545,61 @@ Restait un point sans case évidente : la dimension relationnelle envers l'équi **Statut.** Extraction Sirene : 74/101 départements, 9 855 993 entreprises, en cours sans incident. BFH toujours suspendu (section 28). Deux feuilles de route actives dans `src/fdr` : "1. Évolutions BDD ENTREPRISES" (V6, renommée par Jean-Marc) et "3. Sélection des Entreprises" (V5) — aucune des deux encore validée pour passage à l'implémentation. Accès FTP RNE toujours inexploité. Collaborateurs ASPIC (Matilda, Viktor, Sophia, Léon, Nikita) et leurs rôles connus consignés en mémoire pour la suite. `` n'avance pas dans cette section (feuilles de route et scripts d'outillage PDF/docx/xlsx vivent hors du dépôt applicatif ASPIC) ; `` avance de 28 à 29 — nouvelle version **V1.23.29**. + +## 30. Incident de parallélisme sur l'extraction, naissance du projet entreprises.bzh, et mesure réelle du double-comptage (17 septembre 2026) + +**Nouvel incident, cette fois provoqué par Claude Code lui-même.** En tentant de rattraper le département 74 (interrompu la veille par un aléa réseau), un script de reprise a été lancé **en parallèle** de la chaîne principale — erreur de jugement, l'hypothèse que `recherche-entreprises.api.gouv.fr` n'avait jamais montré de limite s'est révélée fausse sous charge concurrente. Les deux traitements simultanés ont fini par saturer l'API (HTTP 429 soutenu), faisant planter en cascade **75 (Paris), 76 et 77** en plus du 74 déjà en cours de reprise. Aucune perte de données (conception UPSERT), mais quatre départements incomplets. Corrigé sur deux plans : `http_get_json()` dans `sirene_extract.py` durci (retries avec backoff exponentiel sur 429 et respect de `Retry-After`, rattrapage de `http.client.HTTPException`/`ConnectionError` en plus de `URLError` — un `RemoteDisconnected` n'était pas rattrapé avant, cause du tout premier plantage du 74) ; et surtout, **plus aucun traitement en parallèle désormais, toujours strictement séquentiel**, leçon actée en mémoire. Une reprise séquentielle de 74/75/76/77 a été programmée pour démarrer automatiquement une fois la chaîne principale entièrement terminée, sans chevauchement possible. Un second incident, sans lien, a suivi le 17 au soir : le département 88 a échoué sur un verrou MySQL (`Lock wait timeout`), probablement lié à la charge d'un calcul de dédoublonnage lancé en parallèle par Claude Code — ajouté à la liste des départements à reprendre. + +**Naissance d'un projet dérivé : `entreprises.bzh`.** Une observation de Jean-Marc sur le modèle économique de nouvelles-entreprises.com (revenu réel sur l'envoi de courrier postal, pas l'abonnement) a fait germer l'idée d'un site indépendant, construit sur la même base `ENTREPRISES`, proposant l'accès aux données d'entreprises via une méthode de recherche originale (isochrone/temps de trajet réel, pas un simple rayon en km — confusion de vocabulaire de Jean-Marc corrigée en cours de route). Jean-Marc a demandé à une autre session Claude un dossier d'analyse de marché complet (tarifs, structure de facturation, contraintes légales) — document de grande qualité, sourcé et prudent sur ses propres limites, déposé et relu en détail. Trouvailles marquantes : **aucun concurrent recensé ne combine fraîcheur quotidienne et sélection géographique fine** (Smappen s'en approche mais avec une base trimestrielle) — le créneau existe réellement. Structure de facturation suggérée : pas de prix à la ligne (course au prix bas déjà occupée), mais deux prestations distinctes, extraction brute alignée marché et "étude de zone" au forfait, seule cette dernière valorisant réellement l'outil. Point juridique découvert en cours de lecture, avec impact technique direct : depuis mars 2023, le statut "non-diffusible" est remplacé par un statut **"P" (diffusion partielle)**, à exclure de toute redistribution commerciale — or `statut_diffusion` n'est capturé nulle part comme colonne exploitable dans `ENTREPRISES` aujourd'hui, seulement noyé dans le JSON brut. Décision actée : ne pas modifier l'extraction en cours (au-delà de 80% de la France) pour ce champ, le rattacher au grand remodelage de Phase1 déjà prévu. + +**Objectif du projet précisé par Jean-Marc, plus riche qu'une simple opportunité commerciale.** Visée : mise en ligne à la création de la société (**début 2027**, soit environ un an avant le lancement commercial d'ASPIC), avec cinq finalités explicites — avoir quelque chose en vente dès le début d'activité, s'affronter concrètement à une solution de paiement en ligne, à la facturation électronique, se pousser à communiquer sur les réseaux sociaux via les fonctionnalités mêmes d'ASPIC, et dégager un peu de trésorerie pour financer un futur serveur OVH dédié (non mutualisé). Coût d'entrée dérisoire : le seul nom de domaine, `entreprises.bzh`, acquis dans la foulée. Jean-Marc reste "à l'affût comme un chien de chasse" si un vrai modèle économique se dessinait, sans en faire une condition. Le module de sélection sera construit une fois pour ce site puis répliqué dans ASPIC — et Jean-Marc envisage déjà l'argument marketing du jour où ASPIC sortira : ces fonctionnalités y seront incluses gratuitement. + +**Discussion approfondie sur l'enrichissement de contact via LinkedIn, questionnement personnel de Jean-Marc sur l'exposition légale.** Un partenaire commercial de Jean-Marc a vanté l'usage quotidien de Waalaxy sans jamais avoir été banni — argument que Jean-Marc a lui-même écarté par une analogie efficace (rouler à 100 km/h sur une route de campagne sans jamais croiser de gendarme n'en fait pas une pratique sûre). Question soulevée par Jean-Marc : LinkedIn tolérerait-il tacitement ce type d'usage dans une mesure raisonnable ? Réponse nuancée apportée : LinkedIn a un historique documenté de poursuites actives contre des **éditeurs** d'outils d'automatisation (affaire hiQ Labs, mises en demeure), même si la détection au niveau utilisateur individuel reste probabiliste — donc la distinction pertinente pour Jean-Marc n'est pas "combien de temps avant d'être banni" mais "éditeur vs utilisateur isolé", un éditeur étant une cible bien plus exposée. Piste connexe soulevée par Jean-Marc et laissée ouverte, explicitement qualifiée de "borderline" par lui-même : faire réaliser la qualification via Claude Cowork en local chez l'utilisateur plutôt qu'un scraping centralisé — analysé comme une **dilution** du risque (compte individuel, détection plus difficile à grande échelle) mais pas une **élimination** de sa nature (toujours hors CGU si l'extraction reste automatisée), avec la même question de responsabilité d'éditeur si la fonctionnalité était packagée comme telle. + +**Mesure réelle du double-comptage inter-départements, chiffrée pour la première fois.** Calcul `COUNT(DISTINCT SIREN)` sur l'ensemble des tables Phase1 existantes : **12 331 573 lignes brutes, 11 142 436 SIREN réellement distincts, soit 1 189 137 doublons (9,6%)** — cohérent avec la découverte de la section 29 (35 vs 44). Poids disque correspondant : ~4,18 Go sur les 43,33 Go actuels de Phase1, présenté comme plafond théorique (le futur modèle allégera ces lignes plutôt que de les supprimer, l'info des établissements secondaires restant voulue). Conséquence rassurante sur la question "va-t-on dépasser 13,4M ?" : le total réellement distinct progresse normalement, la marge restante (Île-de-France complète, Marseille, Corse, DOM-TOM) ajoutera du vrai volume, pas seulement du doublon. + +**Feuilles de route ENTREPRISES et Sélection des Entreprises, nouvelles versions.** "1. Évolutions BDD ENTREPRISES" passée en V7 (le point statut "P" y a été ajouté). "3. Sélection des Entreprises" largement étoffée par Jean-Marc (V6) : le projet devient l'épine dorsale d'`entreprises.bzh`, méthodes de recherche listées, trois premières briques d'écran détaillées (avertissement RGPD, localisation géographique, type d'entreprise) accompagnées de leurs maquettes Excel. Relecture complète, correction actée (rayon en km → temps de trajet), confirmation de la sélection géographique limitée à une valeur unique par niveau (région/département/ville), passée en V7 avec les retours intégrés. Deux bugs supplémentaires de génération `.docx` trouvés et corrigés : langue par défaut du document (anglais au lieu de français, `w:lang` absent du style Normal) et titre manquant sur "Sélection des Entreprises" (même bug que la section 29 sur ENTREPRISES, pas encore appliqué à ce fichier-là). + +**Statut.** Extraction Sirene : reste l'Île-de-France (91 à 95), la Corse, les DOM-TOM restants (971/972/973/976) et le 13 (Marseille) dans la chaîne principale, puis une reprise séquentielle de 74/75/76/77/88. Fin réaliste estimée pour le week-end du 19-20 septembre, largement avant l'indisponibilité de Jean-Marc le lundi 21 — reprise du chantier de restructuration ENTREPRISES prévue mardi ou mercredi. BFH toujours suspendu (section 28). Accès FTP RNE toujours inexploité. Projet `entreprises.bzh` acté, domaine acquis, encore au stade de réflexion sur les écrans. + +`` n'avance pas dans cette section (deux scripts modifiés — `sirene_extract.py` durci — et outillage de feuilles de route, toujours hors du dépôt applicatif ASPIC) ; `` avance de 29 à 30 — nouvelle version **V1.23.30**. + +## 31. Alerte disque serveur — 79 Go de binlogs MySQL jamais purgés (18 septembre 2026) + +**Alerte remontée par Jean-Marc** : 160 Go occupés sur 193 Go (84%), sans lien apparent avec l'avancement de l'extraction. Diagnostic mené avec Claude Code : la base `ENTREPRISES` elle-même ne pèse que 52 Go, croissance normale et attendue vu le volume actuel (~13M lignes). Le vrai responsable : **79 Go de journaux binaires MySQL (binlogs) accumulés dans 76 fichiers sur l'instance `mysql2`**, jamais purgés. Cause identifiée, pas une erreur de configuration à proprement parler : la purge automatique était bien active (`binlog_expire_logs_auto_purge=ON`), mais réglée à 30 jours de rétention — un réglage raisonnable pour l'usage CRM habituel, disproportionné face au volume d'écriture exceptionnel généré par une semaine d'extraction intensive (le chantier ayant commencé il y a moins de 30 jours, rien n'avait encore pu être purgé automatiquement). + +**Vérifié avant toute action** : aucune réplication ne dépend de ces binlogs (`SHOW REPLICAS` vide) — purge sans risque pour l'intégrité des données. Un premier essai (`PURGE BINARY LOGS`) a été bloqué par le classificateur de sécurité du mode auto de Claude Code, qui l'a signalé comme une possible altération de journaux d'audit — un principe de précaution générique s'appliquant même à un cas légitime. Plutôt que de chercher un contournement, Claude Code a exposé clairement la situation et les deux options à Jean-Marc (exécuter lui-même la commande, ou autoriser explicitement l'action) ; Jean-Marc a choisi d'autoriser, la commande a alors été acceptée et exécutée sans encombre. + +**Résultat : 79 Go libérés, disque ramené de 84% à 43% d'occupation** (161 Go → 83 Go utilisés sur 193 Go). Rétention réduite temporairement à 3 jours (`binlog_expire_logs_seconds=259200`) le temps que dure l'extraction intensive, à remettre à 30 jours une fois celle-ci terminée si c'est le réglage voulu en régime de croisière. + +**Suite envisagée par Jean-Marc** : intégrer une surveillance de l'espace disque au BackOffice d'ASPIC (déjà home des outils internes — voir section 32 mentionnée dans le journal Index pour le BackOffice existant) plutôt que de compter sur une vérification manuelle occasionnelle. Raison donnée : la console Hostinger elle-même n'affiche pas l'occupation disque en temps réel (données remontées avec un délai notable), d'où l'intérêt d'un indicateur suivi en direct côté ASPIC plutôt que de dépendre de ce tableau de bord tiers. Idée notée, pas encore développée. + +`` n'avance pas dans cette section (intervention d'infrastructure sur le serveur, hors dépôt applicatif ASPIC) ; `` avance de 30 à 31 — nouvelle version **V1.23.31**. + +## 32. Bug Corse identifié et corrigé, deux départements orphelins retrouvés, et nom définitif d'entreprises.bzh trouvé — entreprizh.bzh (18-19 septembre 2026) + +**Un troisième "monstre" découvert dans la dernière ligne droite de l'extraction : la Corse (2A/2B) revenait systématiquement à 0 entreprise, sans aucune erreur.** En creusant à la demande de Jean-Marc ("chez moi les tables sont vides"), diagnostic isolé et vérifié empiriquement par appels directs à l'API : le paramètre `code_commune` de `recherche-entreprises.api.gouv.fr` échoue silencieusement (0 résultat, HTTP 200, aucune erreur) dès qu'il reçoit un code commune alphanumérique (`2A004`, `2B033`...), alors qu'un code numérique classique (`01004`) fonctionne normalement — bug propre à l'API officielle, pas au script. La Corse est le seul territoire français dont les codes commune INSEE ne sont pas purement numériques, ce qui explique pourquoi ce cas n'était jamais apparu ailleurs. Le paramètre `departement` de la même API, lui, fonctionne correctement même pour `2A`/`2B`. Corrigé dans `sirene_extract.py` : nouvelle fonction générique `fetch_entreprises_for_filter()` (factorisée depuis l'ancienne `fetch_commune_entreprises()`, même cascade de repli section NAF → code NAF précis), et `fetch_departement_entreprises_direct()` qui interroge le département entier d'un coup pour tout code non purement numérique — `run_department()` bascule automatiquement sur ce mode via `dep.isdigit()`. + +**Deux départements orphelins supplémentaires retrouvés en vérifiant l'état réel de `ENT_Departements` avant de répondre à une question de Jean-Marc sur le total nationale.** Le **88 (Vosges)**, planté sur le verrou MySQL déjà repéré le 17 septembre (section 30), n'avait en fait jamais été réintégré dans le script de reprise malgré l'intention notée à l'époque — 33 457 lignes partielles en base, aucune ligne dans `ENT_Departements`. Le **48 (Lozère)**, découverte inédite, avait 21 859 entreprises déjà correctement extraites mais aucune ligne finale écrite (interruption juste avant cette dernière étape, cause non identifiée, sans doute un arrêt de processus isolé antérieur) — n'était dans aucune file d'attente. File de reprise (`/tmp/redo_74_75_76_77.sh`) mise à jour et relancée avec la liste complète : **74, 75, 76, 77, 88, 2A, 2B, 48**, toujours strictement séquentielle derrière la fin de la chaîne principale (13/Marseille, dernier département de cette dernière). + +**Total national fait le point à la demande de Jean-Marc, chiffré précisément.** 94 départements bien terminés et fiables : **13 088 450 entreprises**. Les 9 restants (13 en cours + les 8 de la file de reprise) totalisaient à cet instant ~1,51M de lignes déjà en base mais partielles pour la plupart — notamment 76 et 77, très en dessous de ce qu'ils devraient contenir. Confirmation chiffrée d'une intuition de Jean-Marc : Paris (75) affichait déjà 831 979 entreprises avant même la fin de sa reprise, proche du million pressenti. + +**Exploration visuelle du logo (détecteur de métaux/pépite) refermée pour l'instant, sans aboutir.** Jean-Marc a itéré des dizaines de fois avec l'outil Pippit AI sur une variante ajoutant des traces de balayage au sol, jusqu'à ce que l'outil lui-même signale son incapacité à retoucher précisément (absence de calques, dérive cumulative après trop d'itérations). Une tentative de Claude Code de proposer une alternative vectorielle (SVG, deux versions publiées en Artifact) a été jugée trop abstraite/schématique par rapport au rendu quasi-photo recherché — écartée. Piste de sortie identifiée mais reportée par Jean-Marc à une prochaine session (fatigue du sujet ce soir-là) : retoucher manuellement l'image déjà quasi satisfaisante dans un éditeur à calques (Photopea suggéré, gratuit, en ligne) plutôt que de continuer à batailler avec la génération IA — le changement demandé (supprimer une ligne, limiter le nombre de traces) est une retouche localisée sur fond presque uni, largement à la portée d'un éditeur classique. + +**Recherche du nom de domaine d'entreprises.bzh reprise et closes après plusieurs allers-retours, tous vérifiés avant achat conformément au principe explicite de Jean-Marc ("éviter les problèmes plutôt que devoir les gérer", répété ce soir-là).** `prospecter.bzh`, pourtant validé une première fois, écarté après vérification INPI : une marque française active **"PROSPECTER"** (FR4532717) existe, détenue par **TESSI**, déposée en classe 35 (publicité, gestion commerciale, télémarketing, acquisition de données) — recoupement direct avec l'activité visée, risque jugé trop sérieux malgré la nature partiellement descriptive du mot. `fichiers-prospects.fr`/`.com`, repérés disponibles par Jean-Marc, vérifiés propres (aucune marque, aucun site homonyme) mais la piste a été abandonnée en cours de route sans avoir été formellement invalidée, Jean-Marc étant parti explorer un concurrent adjacent (`easyfichiers.com`) puis, de fil en aiguille, l'API de Pappers. Vérification de l'API Pappers menée à la demande de Jean-Marc : modèle freemium (100 crédits gratuits à l'inscription puis facturation au crédit, abonnements à partir de 20€/mois) — mais surtout, ses CGU interdisent explicitement toute extraction/réutilisation de sa base de données et, clause spécifique, toute utilisation "pour alimenter, enrichir ou nourrir un service, produit, système ou solution tiers" : exactement l'usage qu'envisageait Jean-Marc pour les numéros de téléphone qu'il y avait repérés (donnée absente des sources SIRENE/INPI/BODACC officielles, donc nécessairement un enrichissement propriétaire de Pappers) — piste abandonnée sur ce constat, sans ambiguïté. + +**Nom finalement retenu : `entreprizh.bzh`** (jeu de mots entreprise/Breizh), trouvé par Jean-Marc, disponible et déjà accordé par l'association gestionnaire du `.bzh` — contrairement à `entreprises.bzh` en son temps. Vérifié par Claude Code (aucune marque, aucun site homonyme, le plus proche étant `entreprendre.bzh` et `mon-entreprise.bzh`, tous deux trop différents pour prêter à confusion) puis confirmé directement par Jean-Marc lui-même sur data.inpi.fr : aucun résultat. Achat décidé le soir même. + +**Statut.** Extraction Sirene : chaîne principale sur le 13 (Marseille, dernier département), file de reprise (74/75/76/77/88/2A/2B/48) prête à démarrer automatiquement à sa suite, code Corse corrigé et non encore testé en conditions réelles — premier point à vérifier à la prochaine reprise de session. Nom de domaine d'`entreprises.bzh` définitivement tranché (`entreprizh.bzh`), achat en cours par Jean-Marc. Logo toujours en réflexion, retouche manuelle envisagée mais pas commencée. Restructuration ENTREPRISES (siège/filiale, partitionnement, statut "P") toujours en attente de la fin complète de l'extraction, Jean-Marc envisageant d'ouvrir une session neuve à ce moment-là plutôt que de poursuivre celle-ci. + +`` avance : correctif du bug Corse dans `src/scripts/sirene_extract.py` (hors dépôt applicatif ASPIC comme les autres scripts d'extraction) ; `` avance de 31 à 32 — nouvelle version **V1.23.32**. + +## 33. Extraction Sirene France entière terminée — 15 972 915 entreprises (19-20 septembre 2026) + +**Fin complète de l'extraction, sans incident sur la dernière ligne droite.** La chaîne principale a bouclé le 13 (Marseille) dans la nuit du 18 au 19 septembre, puis la file de reprise a enchaîné automatiquement et sans supervision sur les huit départements restants : 74 (terminé dans la nuit), 75/Paris (le plus gros morceau, ~15h de traitement à lui seul vu son volume), 76, 77, 88, puis **2A et 2B — premier vrai test du correctif Corse de la section 32, réussi du premier coup** (55 190 et 54 823 entreprises, aucune anomalie), et enfin 48 pour clore la liste. Le recalcul des statistiques par commune (`ent_communes_stats.py`) a suivi automatiquement en bout de chaîne (34 916 communes mises à jour). + +**Total national final : les 101 départements de France (métropole + DOM-TOM) sont extraits, pour 15 972 915 entreprises** — sensiblement au-dessus des projections successives de la conversation (8,5M initialement, recalibré à 13,4M section 29, puis à ~15-15,5M au fil de la reprise des derniers départements), l'écart provenant essentiellement des trois départements les plus lourds (Paris, Seine-Maritime, Seine-et-Marne) qui étaient restés très sous-captés depuis l'incident du 17 septembre jusqu'à leur réextraction complète. Disque à 60% d'occupation (115 Go/193 Go) une fois tout terminé, aucun processus d'extraction encore actif. + +**Statut.** Extraction Sirene : **terminée, définitivement**. Plus aucun script en tâche de fond. Le chantier de restructuration `ENTREPRISES` (siège/filiale, partitionnement natif MySQL évoqué section 29, split de `Phase4`, capture du statut "P") peut désormais démarrer sur des données complètes — Jean-Marc prévoit d'ouvrir une session neuve pour ce chantier plutôt que de poursuivre celle-ci. Nom de domaine `entreprizh.bzh` (section 32) en cours d'achat. Rétention des binlogs MySQL toujours réduite à 3 jours (section 31) — à remettre à 30 jours maintenant que la période d'écriture intensive est terminée, point non encore traité. + +`` n'avance pas dans cette section (fin d'un traitement déjà en cours, aucune modification) ; `` avance de 32 à 33 — nouvelle version **V1.23.33**. diff --git a/scripts/sirene_extract.py b/scripts/sirene_extract.py index 12f58a0..9c38f08 100644 --- a/scripts/sirene_extract.py +++ b/scripts/sirene_extract.py @@ -19,6 +19,7 @@ Usage : (ou export ENTREPRISES_DB_PASS=... pour ne pas passer le mot de passe en argument) """ import argparse +import http.client import json import os import sys @@ -240,15 +241,39 @@ def log(msg): print(msg, file=sys.stderr, flush=True) -def http_get_json(url, retries=5): +def http_get_json(url, retries=8): + # Durci le 17/09/2026 : la version precedente ne rattrapait que + # urllib.error.URLError/TimeoutError, avec un backoff court (1-5s) -- + # insuffisant face a deux incidents reels constates le meme jour : + # http.client.RemoteDisconnected (pas une URLError, jamais rattrapee, + # a fait planter le departement 74) et HTTP 429 Too Many Requests + # soutenu (deux extractions tournant par erreur en parallele ont fait + # plafonner l'API, cascadant sur 3 departements avant plantage). Meme + # esprit que le durcissement deja fait sur inpi_bilans_backfill.py. for attempt in range(retries): try: with urllib.request.urlopen(url, timeout=20) as resp: return json.load(resp) - except (urllib.error.URLError, TimeoutError) as e: + except urllib.error.HTTPError as e: + if e.code == 429: + if attempt == retries - 1: + raise + retry_after = e.headers.get("Retry-After") if e.headers else None + wait = int(retry_after) if retry_after and retry_after.isdigit() else min(10 * (2 ** attempt), 300) + log(f" !! 429 Too Many Requests -- pause de {wait}s avant nouvelle tentative " + f"({attempt + 1}/{retries})") + time.sleep(wait) + continue if attempt == retries - 1: raise - time.sleep(1 + attempt) + log(f" retry apres erreur HTTP ({e})") + time.sleep(2 + attempt) + except (urllib.error.URLError, TimeoutError, http.client.HTTPException, + ConnectionError) as e: + if attempt == retries - 1: + raise + log(f" retry apres erreur reseau ({e})") + time.sleep(2 + attempt) # Paris, Lyon et Marseille (PLM) : dans les donnees Sirene, le siege d'une @@ -389,13 +414,16 @@ def paginate_all(params, seen): return out -def fetch_commune_entreprises(code_commune, seen): - base = {"code_commune": code_commune, "etat_administratif": "A"} +def fetch_entreprises_for_filter(base, seen, label): + """Cascade de repli generique (section NAF puis code NAF precis si + plafonnee a CAP resultats), utilisee aussi bien pour un filtre par + commune que, depuis le 18/09/2026, par departement entier (cas 2A/2B, + cf. fetch_departement_entreprises_direct).""" total = probe_total(base) if total < CAP: return paginate_all(base, seen) - log(f" commune {code_commune} plafonnee ({total}), repli par section NAF") + log(f" {label} plafonnee ({total}), repli par section NAF") out = [] for section in NAF_SECTIONS: sec_params = dict(base, section_activite_principale=section) @@ -410,7 +438,7 @@ def fetch_commune_entreprises(code_commune, seen): # ex. Rennes/section L). On decoupe par code NAF precis (732 codes possibles) -- # un code implique deja sa section, donc on l'utilise seul, sans le combiner # au filtre de section. - log(f" commune {code_commune} section {section} encore plafonnee ({sec_total}), " + log(f" {label} section {section} encore plafonnee ({sec_total}), " f"repli par code NAF precis") for code in codes_for_section(section): code_params = dict(base, activite_principale=code) @@ -418,12 +446,30 @@ def fetch_commune_entreprises(code_commune, seen): if code_total == 0: continue if code_total >= CAP: - log(f" !! commune {code_commune} code {code} encore plafonnee " + log(f" !! {label} code {code} encore plafonnee " f"({code_total}) -- a decouper manuellement (ex: par tranche_effectif_salarie)") out.extend(paginate_all(code_params, seen)) return out +def fetch_commune_entreprises(code_commune, seen): + base = {"code_commune": code_commune, "etat_administratif": "A"} + return fetch_entreprises_for_filter(base, seen, f"commune {code_commune}") + + +def fetch_departement_entreprises_direct(dep, seen): + """Repli specifique aux departements dont le code commune INSEE n'est pas + purement numerique (2A, 2B -- Corse) : le parametre `code_commune` de + l'API recherche-entreprises echoue silencieusement (0 resultat, HTTP 200, + aucune erreur) sur ces codes alphanumeriques, verifie empiriquement le + 18/09/2026 (2A004/2B033 -> 0 alors que 01004 -> 6124). Le parametre + `departement`, lui, fonctionne normalement -- on interroge donc le + departement entier d'un coup, avec la meme cascade de repli que pour une + commune plafonnee.""" + base = {"departement": dep, "etat_administratif": "A"} + return fetch_entreprises_for_filter(base, seen, f"departement {dep}") + + def upsert_entreprise(conn, table, row): cols = list(row.keys()) placeholders = ", ".join(["%s"] * len(cols)) @@ -504,8 +550,9 @@ def run_department(conn, dep): seen = set() total_upserts = 0 total_finances = 0 - for c in communes_geo: - results = fetch_commune_entreprises(c["code"], seen) + + def store(results): + nonlocal total_upserts, total_finances for r in results: row = map_entreprise(r) if row["ENT_Siren"]: @@ -514,8 +561,20 @@ def run_department(conn, dep): if row["ENT_FinancesAnnee"] is not None: upsert_finances(conn, table3, row) total_finances += 1 - if results: - log(f" {c['nom']} ({c['code']}) : {len(results)} entreprises") + + if not dep.isdigit(): + # Code commune INSEE alphanumerique (2A, 2B) : le filtre code_commune + # de l'API echoue silencieusement, on interroge le departement entier + # d'un coup (cf. fetch_departement_entreprises_direct). + results = fetch_departement_entreprises_direct(dep, seen) + store(results) + log(f" departement {dep} (requete directe) : {len(results)} entreprises") + else: + for c in communes_geo: + results = fetch_commune_entreprises(c["code"], seen) + store(results) + if results: + log(f" {c['nom']} ({c['code']}) : {len(results)} entreprises") with conn.cursor() as cur: cur.execute(f"SELECT COUNT(*) FROM `{table1}`") diff --git a/version.php b/version.php index 44c4afe..435950c 100644 --- a/version.php +++ b/version.php @@ -50,7 +50,7 @@ * capacité à détecter un déploiement resté en retard. */ -const ASPIC_VERSION = 'V1.23.29'; +const ASPIC_VERSION = 'V1.23.33'; if (basename($_SERVER['SCRIPT_NAME']) === 'version.php') { header('Content-Type: application/json; charset=utf-8');