Ingénierie Des Données on Boris Dupoux

Points d'intérêt et flux urbains dans le centre-ville de Fort-de-France à partir de données ouvertes

Thu, 01 Oct 2026 00:00:00 +0000

Contexte

Fort-de-France (Martinique) ne dispose de presque aucune donnée ouverte locale. Les jeux de données de la ville ont été mis à jour pour la dernière fois en 2019, et il n’existe ni compteurs piétons publics, ni chiffres ouverts de fréquentation des transports en commun, ni comptages routiers ouverts à l’échelle du centre-ville. Le projet cherche à savoir jusqu’où les données ouvertes nationales et des flux archivés en continu permettent de décrire le centre-ville comme un système de points d’intérêt (commerces, administrations, établissements scolaires, santé, culture, portes d’entrée) et de flux (résidents, navetteurs, élèves, visiteurs, croisiéristes, véhicules, bus) sur un horizon de dix ans (2016–2026).

Aucune source ne répond seule à cette question. Le répertoire des entreprises sait où sont les établissements, mais pas qui les fréquente. Le recensement sait où les habitants dorment, mais pas où ils passent la journée. Les flux de transport montrent les bus, pas leurs passagers ; les calendriers d’escales montrent les navires, pas les croisiéristes à terre. La démarche consiste donc à croiser de nombreuses sources hétérogènes sur un cadre spatial et temporel commun, pour que chacune comble un angle mort des autres, puis à confronter le résultat aux rares signaux mesurés qui existent.

Approche

La méthode est issue d’un précédent projet de base de connaissances que j’ai mené. Les données brutes sont immuables et adressées par leur contenu. Chaque base de données est jetable et reconstruite à partir d’elles. Chaque valeur conserve sa provenance, et un ensemble d’invariants est vérifié à chaque reconstruction.

flowchart TB
 A[Catalogue des sources
sources.yaml] --> B[Stockage brut immuable
sha256 + manifeste JSONL]
 C[Collecteurs planifiés
Meta tous les 14 jours · GTFS-RT 60 s] --> B
 B --> D[Extracteurs versionnés
Parquet normalisé]
 D --> E[Entrepôt spatial DuckDB
reconstruit, jamais modifié]
 E --> F[Invariants QA I1–I6]
 E --> G[Statistiques
requetes/*.sql]
 E --> H[Application de bureau
carte + sélecteur temporel]
 G --> I[Calage sur
des signaux mesurés]

Méthodes

Acquisition. Chaque téléchargement est haché (SHA-256) et consigné dans un manifeste JSONL, et l’acquisition est idempotente. Les fichiers nationaux de plus de 1 Go (répertoire Sirene des entreprises) sont lus sous forme d’extraits distants par requêtes HTTP Range, filtrés sur la commune. La requête de filtrage est enregistrée comme partie intégrante de la provenance.
Sources éphémères. Meta Movement Distribution ne conserve que 90 jours en ligne : une tâche planifiée l’archive donc tous les 14 jours. Un collecteur de bus interroge les positions des véhicules GTFS-RT toutes les 60 s et les prévisions toutes les 10 min, et compresse chaque journée en zip avec une somme de contrôle SHA-256.
Cadre spatial. Les données sont stockées en WGS84 et calculées en EPSG:5490 sur la grille INSEE de 200 m. Les points d’intérêt sont classés selon une typologie unique (codes NAF, balises OSM, arrêts), avec une famille, un poids et un rythme horaire sur sept créneaux.
Modèles. La présence horaire par carreau combine résidents (Filosofi 2021, répartis de manière dasymétrique sur les bâtiments), salariés, élèves et touristes. Un modèle de Huff estime les zones de chalandise. Les croisiéristes à terre sont modélisés à partir des horaires et des capacités des navires. Un modèle gravitaire à l’échelle de l’île, avec affectation BPR, couvre les visiteurs et le trafic de transit.
Qualité. Six invariants sont vérifiés, de la provenance à l’absence de données personnelles. Les paramètres non confirmés sont consignés dans un journal des décisions.

Sources de données

Le croisement des sources est le cœur du projet. Les registres d’entreprises (Sirene, BODACC, URSSAF) donnent le stock et la rotation des activités, mais ne disent rien des personnes qui les entourent. Le recensement et les données fiscales (RP, Filosofi) situent les habitants, leurs revenus et la vacance des logements, mais seulement la nuit. Les fichiers de navettes et l’enquête nationale de mobilité (MOBPRO, MOBSCO, EMP) disent qui se déplace, pourquoi et quand. Les flux de transport, d’accidents et de qualité de l’air (GTFS-RT, BAAC, Madininair) sont les seules traces mesurées du mouvement. Les calendriers d’escales et les capacités des navires apportent une population qu’aucun recensement ne compte. Les référentiels géographiques (IGN, OpenStreetMap, grille INSEE de 200 m) rendent enfin tout cela comparable, carreau par carreau.

Le catalogue recense 120 sources : 51 intégrées, 32 à intégrer, 7 à vérifier, 13 disponibles uniquement sur demande, 5 payantes, 1 sur partenariat et 11 non retenues. Les tableaux ci-dessous listent toutes les sources intégrées et résument les autres par thème.

Entreprises, emplois et équipements

Source	Apport	Période / fréquence	Statut
Base Sirene des entreprises — INSEE	Établissements, code d’activité (NAF), dates de création et de fermeture, tranches d’effectif	Historique complet ; stock reconstituable à toute date 2016–2026	Intégrée
BODACC — DILA	Rotation et défaillances des commerces (ventes de fonds, procédures collectives)	2016–2026, quotidienne	Intégrée
Base permanente des équipements (BPE) géolocalisée — INSEE	Commerces, services, santé, administrations, enseignement, sport, tourisme	Éditions 2024 et 2025, annuelle	Intégrée
Établissements et effectifs salariés commune × APE — URSSAF / Acoss	Emploi salarié privé par activité	2006–2025, annuelle	Intégrée
Annuaire de l’éducation et effectifs d’élèves — MENJ / DEPP	Écoles, localisation, élèves par rentrée, personnels	Effectifs 2016–2025	Intégrée
FINESS — DREES / ARS	Établissements sanitaires et sociaux, pharmacies	Extraction de mai 2026, bimestrielle	Intégrée
Overture Maps (places) — Overture Maps Foundation	Points d’intérêt avec score de confiance (couche de comparaison)	Extrait figé de la release 2026-09-23, mensuelle	Intégrée
OpenStreetMap (Overpass) — contributeurs OpenStreetMap	Points d’intérêt, commerces, voirie, cheminements piétons	État courant	Intégrée
Monuments historiques (Mérimée / POP) — ministère de la Culture	Attracteurs patrimoniaux (cathédrale, bibliothèque Schœlcher, fort Saint-Louis)	Courant	Intégrée
23 autres — par ex. Flores, emploi salarié localisé (INSEE), Foursquare Open Source Places, LOCOMVAC, locaux commerciaux vacants (DGFiP), Google Places			Cataloguées

Population, revenus et logement

Source	Apport	Période / fréquence	Statut
Recensement, bases infracommunales IRIS (RP) — INSEE	Résidents, âge, CSP, logements (vacance, motorisation), actifs	RP 2016 → RP 2022, annuelle	Intégrée
Filosofi par IRIS — INSEE	Revenus disponibles et déclarés, pauvreté	2016–2021, annuelle	Intégrée
Filosofi carroyé 200 m, fichiers — INSEE	Ménages fiscaux, individus, pauvreté, logements sociaux et âges au carreau de 200 m	2015, 2017, 2019, 2021	Intégrée
Filosofi carroyé 200 m, couche WFS Géoplateforme — INSEE	Géométries des carreaux	Couche 2015	Intégrée
IRCOM, impôt sur le revenu par commune — DGFiP	Foyers fiscaux, revenus déclarés	2016–2024, annuelle	Intégrée
Cafdata — CNAF	Allocataires du RSA, des aides au logement et des prestations familiales	2020–2024 (2022 manquant), annuelle	Intégrée
Quartiers prioritaires (QPV) — ANCT / INSEE	Géographie prioritaire, qui inclut le centre-ville	Contours 2024	Intégrée
LOVAC — Cerema / DGALN	Vacance courte et structurelle (≥ 2 ans) du parc privé	Éditions 2020–2026, annuelle	Intégrée
RPLS, parc locatif social — SDES	Logements sociaux (adresse, surface, loyer, vacance)	2023 et 2025	Intégrée
Sitadel, permis de construire — SDES	Logements et locaux autorisés, commencés, démolis	2013–2026, mensuelle	Intégrée
DVF géolocalisées — DGFiP / Etalab	Mutations immobilières (prix, surfaces, locaux commerciaux)	2021–2025, fenêtre glissante de 5 ans	Intégrée
8 autres — par ex. fichiers détail du recensement et populations légales (INSEE), DV3F et Fichiers fonciers (Cerema / DGFiP), population carroyée WorldPop / GHSL			Cataloguées

Mobilité et transports

Source	Apport	Période / fréquence	Statut
Mobilités professionnelles (MOBPRO) — INSEE	Navettes domicile → travail entre communes	2016–2022, annuelle	Intégrée
Mobilités scolaires (MOBSCO) — INSEE	Navettes domicile → études entre communes	2016–2022, annuelle	Intégrée
Enquête mobilité des personnes 2018-2019 (EMP) — SDES	Motifs, horaires de départ et de retour, durées d’activité, distances	2018–2019	Intégrée
GTFS, réseau urbain zone Centre (Mozaïk, BHNS) — Martinique Transport	Offre théorique de transports collectifs	Archives depuis juin 2023	Intégrée
GTFS-RT, collecte continue — Martinique Transport	Vitesses observées des bus, bus en service, remplissage déclaré	Depuis le 7 octobre 2026 ; 60 s (positions), 10 min (prévisions)	Intégrée
GTFS, navettes maritimes — Martinique Transport	Navettes débarquant au front de mer	Versions depuis août 2024	Intégrée
Accidents corporels de la circulation (BAAC) — ONISR	Accidents localisés (piétons, véhicules), avec l’heure	2016–2024 chargés	Intégrée
Movement Distribution — Meta Data for Good / HDX	Part des usagers restés à domicile, à moins de 10 km, entre 10 et 100 km, au-delà de 100 km	Quotidienne ; fenêtre de 90 jours, archivée tous les 14 jours	Intégrée
Movement Range Maps — Meta Data for Good / HDX	Variation des déplacements, part des usagers restés sur place	Mars 2020 → mai 2022, quotidienne (arrêtée)	Intégrée
BD TOPO, réseau routier principal — IGN	Graphe routier de l’île pour l’affectation du trafic	Courant	Intégrée
BD TOPO, tronçons de route — IGN	Largeur de chaussée, voies et sens, pour métrer le stationnement le long des rues	Courant	Intégrée
Parkings OpenStreetMap — contributeurs OpenStreetMap	Parkings, type, capacité déclarée	Courant	Intégrée
18 autres — par ex. fréquentation et validations (Martinique Transport, sur demande), comptages routiers (sur demande), données de téléphonie Orange Flux Vision (payantes), Waze for Cities / Strava Metro (partenariat), campagne de comptages piétons (à créer)			Cataloguées

Tourisme et croisière

Source	Apport	Période / fréquence	Statut
Calendrier des escales du port de Fort-de-France — CruiseMapper	Escales navire par navire, avec heures d’arrivée et de départ	Mars 2026 → mars 2029 ; archivage mensuel, les mois passés disparaissant du site	Intégrée
Fiches navires — CruiseMapper	Capacité passagers, équipage, jauge des navires en escale	Courant	Intégrée
Bilans de saison de croisière — Comité martiniquais du tourisme (CMT), via la presse	Croisiéristes et escales par saison, terminaux de croisière	Saisons 2024-2025 et 2025-2026	Intégrée
PortWatch — FMI / HDX	Escales quotidiennes issues de l’AIS	2019–2026, quotidienne	Intégrée
Trafic aérien commercial mensuel — DGAC	Arrivées à l’aéroport Martinique Aimé Césaire (saisonnalité touristique)	1990–2025, mensuelle	Intégrée
Hébergements touristiques classés — Atout France	Hôtels et résidences classés, chambres et capacité	Stock courant	Intégrée
Capacité des communes en hébergement touristique — INSEE	Hôtels par catégorie, campings, résidences, villages vacances	2015–2026, annuelle	Intégrée
7 autres — par ex. DATAtourisme (ADN Tourisme), enquête de fréquentation hôtelière (INSEE), Inside Airbnb / AirDNA, données d’escales du port			Cataloguées

Contexte : météo, air, calendrier, sécurité

Source	Apport	Période / fréquence	Statut
Données climatologiques de base — Météo-France	Pluie, température, vent (stations de Fort-de-France Desaix et du Lamentin)	2010–2026, horaire / quotidienne	Intégrée
Qualité de l’air — Madininair	NO₂ comme indicateur indirect du trafic, ainsi que PM10, PM2,5, O₃ et H₂S des sargasses	Horaire ; NO₂ mensuel 2016–2026	Intégrée
Base communale de la délinquance enregistrée — SSMSI	Infractions enregistrées	2016–2025, annuelle	Intégrée
Jours fériés en Martinique — DINUM	Calendrier, dont le 22 mai	2006–2031	Intégrée
Calendrier scolaire — MENJ	Vacances scolaires, dont celles de Carnaval	2017-2018 → 2026-2027	Intégrée
Pageviews — Wikimedia Foundation	Intérêt en ligne pour Fort-de-France, le Carnaval et le patrimoine	2016–2026, mensuelle	Intégrée
4 autres — par ex. lumières nocturnes NASA Black Marble, Google Trends / GDELT, agenda des événements (à constituer)			Cataloguées

Géographie et fonds de carte

Source	Apport	Période / fréquence	Statut
Périmètres d’étude — projet	Centre-ville et centre élargi (provisoires, voir D1)	Version 0.1	Intégrée
API Découpage administratif (geo.api.gouv.fr) — DINUM / IGN / INSEE	Contour de la commune et population légale	Courant	Intégrée
Contours IRIS — IGN / INSEE	Maille infracommunale du recensement	Couche courante	Intégrée
BD TOPO — IGN	Bâtiments (hauteur, usage), voirie, équipements	Éditions trimestrielles	Intégrée
BD TOPO, bâtiments résidentiels du centre élargi — IGN	Usage, hauteur et emprise, pour répartir les ménages dans les bâtiments	Édition courante	Intégrée
Fond de carte vectoriel OpenStreetMap — contributeurs OpenStreetMap	Voirie, eau, parcs, littoral dessinés dans l’application	Courant	Intégrée
9 autres — par ex. cadastre Etalab, Base Adresse Nationale, BD ORTHO (IGN), PLU (Géoportail de l’Urbanisme), risques naturels (Géorisques)			Cataloguées

L’application « Cœur de ville »

L’entrepôt s’explore dans une application de bureau (Electron, React, ECharts, Leaflet sur OpenStreetMap, DuckDB lisant une copie de l’entrepôt). Elle est organisée autour de quelques questions — qui est là, quand, qu’est-ce qui attire, le stationnement suffit-il, qui dépend des transports collectifs, le centre gagne-t-il ou perd-il — avec une carte toujours au même endroit, un sélecteur commun jour × créneau, et chaque chiffre accompagné de sa source et de son statut.

Synthèse — le centre en un coup d’œil : rapport jour/nuit, pression de stationnement, commerces 2016 → 2026, pauvreté, prochaine grosse journée d’escale, présence au carreau de 200 m et rythme de la journée des résidents, salariés, scolaires et touristes.

Flux et moments de vie — la présence par carreau pour tout jour et tout créneau, lisible en animation sur la semaine, avec la courbe journalière empilée par population.

Pôles d’attractivité — les établissements par famille (répertoire Sirene et OpenStreetMap), les carreaux les plus attractifs au moment choisi et la part d’établissements ouverts heure par heure.

Zoom sur un îlot — la façade de la rue numéro par numéro, les établissements actifs et fermés depuis 2016, et l’évolution du secteur comparée à l’ensemble du centre.

Évolution 2016–2026 — l’attractivité par carreau avec un curseur d’années, les créations et fermetures, les foyers fiscaux et d’autres signaux croisés sur la même grille.

Stationnement — l’offre reconstruite rue par rue et le taux d’occupation théorique par carreau et par créneau ; chaque hypothèse (longueur de place, largeur de voie, part modale…) est un curseur et le résultat est recalculé en SQL.

Pression de stationnement — mardi, 9-12 h : voitures des résidents et des salariés rapportées aux places publiques à 300 m à pied, carreau par carreau. Le tableau de la semaine montre un taux d’occupation théorique supérieur à 1 les matinées de semaine, alors que les soirées et le week-end restent nettement en dessous.

Escales et événements — le calendrier annuel des escales avec les jours fériés et les vacances scolaires, les navires d’une journée et l’estimation des croisiéristes à terre heure par heure.

Sources et hypothèses — le catalogue derrière chaque chiffre (filtrable par statut), les paramètres de modélisation avec leur justification et les acquisitions archivées.

Résultats

Le projet a démarré en octobre 2026 et en est à un stade précoce, non calé (application v0.6.0). Tous les chiffres relatifs au centre-ville dépendent d’un périmètre provisoire (voir ci-dessous). Chaque résultat ci-dessous précise les sources qu’il croise : aucun ne pourrait être obtenu à partir d’un seul jeu de données.

Catalogue. 120 sources sont cataloguées, dont 51 intégrées.
Entrepôt (première construction). 117 161 entités, environ 25 000 mesures et 1 278 indicateurs, avec les 6 invariants validés.
Déclin commercial et résidents (mesuré, registres × recensement × données fiscales). Le nombre d’établissements actifs d’équipement de la personne (Sirene) est passé de 498 (2016) à 363 (2026), soit une baisse de 27 %, et la part du centre-ville dans la commune pour ce secteur de 75,5 % à 64,7 %. Sur la même période, la population des IRIS du centre-ville (recensement) est passée de 13 444 (2016) à 12 898 (2022), et la vacance des logements de 24,9 % à 27,6 %. 47 % des ménages du centre-ville vivent sous le seuil de pauvreté, contre 30 % pour la commune (Filosofi 2021). Lues ensemble, ces trois sources montrent un centre qui perd en même temps des commerces, des habitants et du pouvoir d’achat.
Rythme jour/nuit (modélisé, six sources croisées). Environ 3 700 personnes sont présentes la nuit et 11 200 le matin, soit un rapport de 3,0. Les résidents de nuit viennent de Filosofi carroyé 200 m réparti dans les bâtiments BD TOPO ; les salariés de jour, des tranches d’effectif Sirene ; les élèves, de l’annuaire de l’éducation ; les touristes, de la capacité des hébergements classés. Le créneau du matin est ajusté sur le profil horaire du NO₂ aux stations trafic.
Vitesse observée des bus et modèle (GTFS-RT × graphe routier × enquêtes de mobilité). Sur une journée complète, les bus roulaient à 12,7 km/h à 5 h, puis à 7 à 8 km/h en journée et à 10,6 km/h à 19 h. Le modèle d’affectation, construit à partir des routes BD TOPO, des navettes MOBPRO, des profils de déplacements EMP et des équipements BPE, prévoit un ralentissement de 20 % aux heures de pointe, alors que les bus en montrent 45 %. La mesure révèle ce que le modèle ne voit pas.
Contrôle croisière (escales × capacités des navires × effectifs publiés). Les croisiéristes à terre sont modélisés à partir du calendrier des escales et des capacités des navires (CruiseMapper). Pour la seule journée d’escale documentée (24 avril 2026), les estimations se sont situées à environ 1 à 2 % des effectifs de passagers publiés dans la presse (3 075 contre 3 112, et 1 995 contre 1 969). Le taux de remplissage du modèle a été fixé sur cette même journée : il s’agit donc d’un contrôle de cohérence, pas d’une validation indépendante.

Limites & suite

D1 : le périmètre du centre-ville est provisoire. Il s’agit d’un rectangle autour du noyau historique, complété d’une zone élargie de 1 km, utilisé dans l’attente d’un périmètre officiel. Tous les chiffres relatifs au centre-ville en dépendent.
Aucune donnée de comptage piéton, de fréquentation ou de comptage routier n’est ouverte. Les rythmes horaires, les poids d’attractivité et les hypothèses de stationnement ne sont pas encore calés. Les seuls contrôles mesurés à ce stade sont le NO₂ horaire aux stations trafic et les vitesses observées des bus.
Le stock d’établissements 2016–2026 est reconstitué uniquement à partir des dates de création et de fermeture.
Prochaines étapes : accumuler plusieurs mois de données GTFS-RT pour mesurer la congestion, solliciter des données d’enquête et de comptage, et caler la présence sur des comptages de terrain.

Stack technique

Python · DuckDB (spatial, httpfs) · Parquet · SQL · GTFS / GTFS-RT · pytest · ruff · Electron · React · TypeScript · ECharts · Leaflet · GitHub Actions

Atomes de traitement explicables pour documents et données

Tue, 01 Sep 2026 00:00:00 +0000

Contexte

Des systèmes de production pour le rapprochement documentaire et l’OCR, développés pour des clients tels qu’un grossiste distributeur et un cabinet d’expertise comptable, ont laissé plusieurs bases de code résolvant chacune les mêmes sous-problèmes (routage des pages, réglage de l’OCR, extraction par LLM, comparaison de champs) avec leurs propres bogues. La bibliothèque d’atomes les consolide en un seul paquet. Sa question centrale est celle qui sous-tendait les systèmes d’origine : peut-on automatiser un contrôle documentaire de sorte qu’un humain puisse auditer et contester chaque verdict ? Extraire un champ ne suffit pas. Le système doit indiquer si deux documents concordent, pourquoi, et sur la base de quels éléments.

Approche

Tout est construit à partir d’atomes. Un atome a une seule responsabilité, des entrées et sorties typées, aucun état global et des dépendances injectées (client LLM, moteur OCR, stockage). Une chaîne de traitement est une composition d’atomes, soit écrite en code, soit déclarée sous forme de recette YAML validée au chargement, avant toute exécution.

flowchart TB
 A["Documents d'entrée (PDF, numérisations, CSV, courriels)"] --> B{"Routage des pages : texte natif ou OCR ?"}
 B -- "natif" --> C["Texte natif positionné"]
 B -- "numérisation" --> D["PaddleOCR (réglages de production)"]
 C --> E["Segmentation & classification"]
 D --> E
 E --> F["Extraction JSON par LLM + vérification d'ancrage verbatim"]
 F --> G["Rapprochement inter-documents (facture / bon de livraison / commande)"]
 G --> H["Verdict tri-état + motif nommé + trace"]
 H --> I["Rapport / revue humaine"]

Le catalogue

Les 459 atomes sont regroupés en 32 familles, un paquet Python chacune, rangées le long de la chaîne de traitement : capter le monde, le comprendre, rapprocher et décider, restituer, puis exploiter en production. Deux paquets supplémentaires les assemblent : steps (77 étapes nommées et paramétrées) et recipes (chargement et validation des recettes YAML).

Série	Famille	Atomes	Rôle
Socle	`core`	25	types pivots, chaîne de traitement, configuration, résilience (reprises, limites de débit), fichiers, concurrence
Capter	`connect`	40	HTTP résilient, boîtes aux lettres (Graph, IMAP), SFTP, OneDrive, source ERP en lecture seule, données ouvertes, piste d’audit
	`google`	24	Gmail, Sheets, Drive, Apps Script, avec exécution résiliente
	`web`	17	robots web indépendants du pilote (Selenium, Playwright) : attentes, squelette à reprise, formulaires
	`pdf`	9	texte natif positionné, décision d’OCR, rendu, pages, doublons
	`ocr`	9	PaddleOCR avec réglages de production, EasyOCR
	`layout`	3	géométrie de page : lignes, colonnes, redressement, rendu monospace
	`audio`	16	transcription par morceaux, post-traitement des segments, recalage micro ↔ écran
	`vision`	32	flux vidéo / RTSP, détection, suivi, profondeur, segmentation, calibration
	`vlm`	10	lecture d’écran par modèle de vision-langage : détection de changement, localisation de libellés
	`geo`	11	mesures géodésiques, position combinée de relevés GPS, filtrage par distance aux lignes, SQL spatial
	`calendar`	4	jours fériés, jours et horaires ouvrés
Comprendre	`text`	32	nombres et montants, dates, normalisation, champs par motifs, identifiants
	`segment`	7	pages → documents logiques, numéros de pièce typés, nature de page
	`classify`	12	classement par nom de fichier, expéditeur, motifs pondérés, TF-IDF, visuel, LLM, cascades
	`llm`	24	contrat indépendant du fournisseur, fournisseurs, pool, prompts, extraction structurée
	`anchor`	5	champs et tableaux situés par rapport aux libellés imprimés, texte natif ou OCR
	`kb`	8	base de connaissances tracée : journal d’événements validé, replié en index SQLite
Rapprocher	`match`	25	EAN/GTIN, index, score multicritère, affectation optimale, résolution d’entités
	`compare`	9	comparateurs tri-états et explicables de champs, d’enregistrements et d’ensembles
	`check`	9	contrôles génériques tri-états : totaux, TVA, balance, complétude, vraisemblance
	`reconcile`	12	appariement d’ensembles, chaînes commande → livraison → facture, N-voies, lettrage, rapprochement bancaire
	`validate`	14	moteur de règles, identifiants, cohérence des montants, verdicts LLM corrigés, décision finale
	`rules`	8	langage de conditions sûr, tables « premier match » explicables, escalade, machines à états
	`events`	11	événements horodatés : fenêtres, veille des événements attendus, sessions, transitions de statut
	`analytics`	18	analyses supply chain sans pandas : demande, ruptures, taux de service, stock de sécurité
Restituer	`export`	8	CSV pour Excel FR, classeurs Excel partagés, rapports HTML / Markdown / PDF
	`report`	6	écarts persistables, synthèses, file de revue
	`render`	12	livrables HTML : diagrammes Mermaid pré-rendus, graphiques ECharts, cartes GeoJSON
	`diagram`	6	diagrammes de processus : lecture draw.io / BPMN JSON, rendu Mermaid et BPMN XML
Exploiter	`ops`	26	haute disponibilité (battements, élection), démon à déclencheurs horaires, surveillance, contrôles préalables
	`qa`	7	non-régression rédactionnelle (fichiers dorés), rejeu de simulations, accord inter-annotateurs

Recettes nommées

Chacune des 17 recettes est une liste YAML d’étapes nommées <famille>.<atome>. Trois exemples :

invoice_multi_doc : un lot de PDF multidocuments devient un ensemble de documents logiques contrôlés. io.collect → pdf.read → segment.documents → classify.documents → llm.extract → validate.ids → validate.amounts → validate.decide → export.csv → google.sheets.upsert → connect.notify. Chaque document finit valide, à vérifier ou invalide.
doc_reconciliation : un dossier de factures, d’avoirs et de bons de livraison, contrôlé par rapport aux commandes. L’extraction LLM gardée (llm.extract_docs) est recoupée avec une extraction par motifs (extract.regex, compare.extractions, reconcile.fields), puis viennent check.document et check.completeness, les lignes face à la commande (compare.reference), la chaîne commande → livraison → facture (reconcile.nway), et enfin un fichier d’écarts et une file de revue (report.discrepancies, report.review). 17 étapes.
meeting_transcript : un enregistrement de réunion devient une transcription horodatée avec locuteurs. audio.decode → audio.vad → audio.transcribe → audio.diarize → audio.speakers → audio.segments → export.csv → export.transcript → connect.notify.

Les autres sont notamment delivery_vs_order, ledger_reconciliation, invoice_dedup, article_base_cleaning, stock_policy, mail_to_sheet, draft_mails, pdf_text_extract, rubric_eval, screen_session, camera_flow et process_from_transcript.

L’Atlas

L’Atlas est une page HTML unique, consultable hors ligne, générée à partir du code lui-même (arbres syntaxiques et YAML), sans aucune donnée saisie à la main. Il dessine le catalogue comme un tableau périodique : chaque famille est un élément doté d’un symbole, chaque module un atome, chaque recette une molécule. Il signale aussi les atomes sans documentation, sans test ou sans exemple d’usage.

La série « Capter » du tableau périodique. Chaque case est une famille, avec son symbole, son nombre de modules et sa taille en milliers de lignes ; chaque tuile en dessous est un atome.

La série « Rapprocher » : les familles qui apparient, comparent, contrôlent et décident.

La fiche d’un atome (compare.fields) : à quoi il sert, d’après sa docstring, puis chaque nom public avec sa signature complète.

La recette invoice_multi_doc en molécule : 11 étapes, les clés de contexte qui les relient et les services requis (en pointillé lorsqu’ils sont facultatifs).

Méthodes

Résultats tri-états. Chaque comparaison renvoie ok ∈ {True, False, None} (conforme / écart / non concluant) avec un code de motif nommé et une trace. Une valeur manquante ou illisible compte comme non concluante, jamais comme une anomalie. Les résultats non concluants sont tout de même comptabilisés, et non écartés en silence.
Routage hybride texte natif/OCR. Chaque page PDF est classée comme native, OCR ou vide, selon la quantité de texte natif qu’elle contient et la part de ce texte couverte par des images. L’OCR n’est exécuté que là où il est nécessaire.
Extraction LLM ancrée. L’extraction JSON structurée est validée par rapport à des schémas Pydantic. Chaque valeur extraite est ensuite vérifiée mot pour mot dans le texte source, de sorte que les valeurs altérées ou inventées sont signalées.
Rapprochement inter-documents. Factures, bons de livraison et commandes sont comparés ligne à ligne à l’aide de tolérances nommées et de règles de dominance. Par exemple, un montant de ligne concordant peut l’emporter sur un écart de prix.
Provenance. Chaque atome porté comporte un en-tête Provenance: et une entrée qui le relie à repo@commit:path:lines dans le code de production d’origine. Les bogues découverts lors du portage ont été corrigés, et chaque correction est couverte par un test de non-régression.
Architecture contrôlée. Le découpage en couches est vérifié par 30 contrats d’import : un atome n’importe que le paquet core. Un typage strict, un seuil de couverture ≥ 80 % et une vérification de l’absence de noms de clients dans le code source sont également imposés.
Abstraction du matériel. Les atomes de vision et d’audio ciblent cuda, mps ou cpu via un seul paramètre.
Évaluation de bout en bout. Les tests s’exécutent avec de vrais moteurs (PaddleOCR, Ollama qwen3:8b et qwen3-vl:8b) sur des données à vérité terrain connue. Chaque métrique est consignée face à un seuil dans un rapport JSON/HTML. Les métriques qui n’atteignent pas leur seuil sont conservées et affichées comme en échec.

Résultats

Base de code (arborescence actuelle) : 459 modules d’atomes répartis en 32 familles, 77 étapes paramétrées, 17 recettes YAML, 30 contrats d’import. La suite collecte 2 959 tests unitaires et de recettes, plus 109 tests de bout en bout exécutés séparément. Les 17 recettes disposent toutes d’au moins un test de bout en bout, et 34 des 35 éléments de l’Atlas sont testés de bout en bout.

Scores de bout en bout sélectionnés (documents synthétiques à vérité terrain connue, modèles 8B locaux) :

Tâche	Moteur	Mesure
Rapprochement facture + bon de livraison / commande	`qwen3:8b`	types de documents et champs 14/14 ; écarts attendus 5/5 ; 0 faux écart sur le cas conforme
Extraction JSON par LLM (4 factures natives)	`qwen3:8b`	JSON valide 4/4 ; champs exacts 28/28 ; toutes les valeurs volontairement altérées détectées par l’ancrage
OCR sur une étiquette photographiée	PaddleOCR	rappel des mots 0,94 sur la photo brute ; un défaut de rehaussement du contraste (0,65–0,71) a été identifié et corrigé (0,88–0,94)
Reconstruction de tableaux à partir de l’OCR	PaddleOCR	100 % de cellules exactes (police proportionnelle), 95 % (chasse fixe)

Limites & suite

L’ancrage verbatim ne peut pas détecter une valeur présente dans le document mais placée dans le mauvais champ : un champ absent a été rempli à tort dans 1 cas sur 8.
Le modèle 8B a jugé un écart de quantité de +50 % comme un écart « mineur », contrairement à la consigne. Les verdicts du LLM sont donc normalisés et maintenus en aval de règles déterministes.
Les scores proviennent principalement de données synthétiques. Un jeu de test sur documents réels est en cours de constitution en dehors du dépôt, et seuls les cas ayant fait l’objet d’une revue sont notés.
Prochaines étapes : mesurer le taux de rapprochement automatique et le taux de faux positifs sur des données de production.

Stack technique

Python · Pydantic · PyYAML · PaddleOCR · Ollama (qwen3:8b, qwen3-vl:8b) · Mistral / Anthropic / OpenAI APIs · pytest · mypy · import-linter · ruff

Codex — archivage physique haute densité de médias sur papier

Tue, 01 Sep 2026 00:00:00 +0000

Contexte

Les médias numériques grand public se dégradent à l’échelle de quelques années. Les SSD non alimentés perdent leur charge, les disques optiques se délaminent, les formats tombent en désuétude et les comptes sont fermés. Le papier peut durer des siècles, ne nécessite aucune électricité et peut être vérifié à l’œil nu. La question est de savoir quelle quantité d’information une feuille A4 ordinaire peut contenir si elle doit encore pouvoir être relue de façon fiable avec un scanner à plat standard, sans matériel spécialisé.

Le problème est difficile car le canal impression-numérisation est bruité de plusieurs manières à la fois. Le toner s’étale et forme des amas, la densité varie sur la page, et les scanners introduisent rotation, mise à l’échelle anisotrope, entraînement irrégulier du papier, flou, vignettage et gamma. Le papier se déforme aussi de façon non linéaire : à la densité visée, un étirement de 0,2 % décale la grille d’environ trois cellules. Les codes 2D courants comme QR et DataMatrix sont conçus pour la robustesse plutôt que pour la densité. Une archive à long terme doit en outre rester décodable lorsque les logiciels actuels auront disparu.

Approche

flowchart TB
 A["Médias sources : photo, vidéo, voix, texte"] --> B["Réduction conservatrice des formats
JPEG baseline · AVI MJPEG/PCM · WAV PCM · UTF-8"]
 B --> C["Archive : tar + zlib + SHA-256"]
 C --> D["Code à effacement inter-pages
MDS de Cauchy sur GF(256) : K pages quelconques parmi N"]
 D --> E["Reed–Solomon + CRC-32 par bloc
entrelacement sur la page, en-tête triplé"]
 E --> F["Rendu de cellules multiniveaux
PDF A4 1 bit à 1200 dpi"]
 F --> G["Impression → numérisation
(canal simulé)"]
 G --> H["Repères → homographie → marqueurs d'alignement locaux"]
 H --> I["Calibration des niveaux de gris à partir de la page elle-même"]
 I --> J["Décodage RS/CRC → décodage d'effacement → contrôle SHA-256"]
 J --> K["Fichiers identiques à l'octet près, ou récupération partielle"]
 F -.-> L["Annexe imprimée : spécification du format + source du décodeur en OCR-B avec CRC-16 par ligne"]
 L -.-> J

À gauche : la page 1 sur 10 de l’archive photo, telle qu’envoyée à l’imprimante (A4, 1200 dpi, une grille de 1 145 × 1 576 cellules), réduite. À droite : le coin supérieur gauche encadré, à la résolution de l’imprimante (environ 10 × 9 mm, chaque point d’imprimante dessiné en 2 × 2 pixels) : le repère d’angle plein, le début du bandeau d’en-tête et les premières cellules de données. Chaque cellule mesure 8 × 8 points (0,169 mm) et son nombre de points encrés code l’un des 4 niveaux. Le carré situé au coin de la grille est un marqueur d’alignement.

Une page de l’annexe imprimée (page 11 sur 30) : le début de cdx_read.py (360 lignes), composé en OCR-B. Chaque ligne porte son numéro et son CRC-16 : une ligne mal relue par l’OCR peut ainsi être repérée et vérifiée à la main.

Méthodes

Cellules multiniveaux plutôt que modules binaires. Chaque cellule porte 2 bits. Les cellules sont dessinées sous forme de points groupés à la résolution native de l’imprimante, de sorte que le pilote n’effectue aucun tramage et ne produit aucun moiré.
Récupération de la géométrie par étapes. Quatre repères d’angle, dont l’un est creux pour fixer l’orientation, donnent une homographie globale. Des marqueurs d’alignement répartis sur la page absorbent ensuite l’étirement local et non linéaire du papier.
Lecteur auto-calibré. Le décodeur estime les niveaux de gris imprimés et l’ombrage spatial à partir de structures de calibration présentes sur chaque page ; il ne dépend donc pas des réglages de points de l’imprimante.
Contrôle d’erreurs à deux niveaux, un code produit. Reed–Solomon et CRC-32 à l’intérieur de chaque page corrigent les erreurs aléatoires et en rafale, comme les taches et les rayures. Un code à effacement MDS de Cauchy entre les pages, décodé bloc par bloc, permet à K pages quelconques parmi N de reconstruire une archive.
Dégradation progressive. Si le contrôle SHA-256 échoue, le décodeur extrait malgré tout chaque fichier complet situé avant la zone endommagée.
Archive autodescriptive. Une annexe imprimée contient la spécification du format, une procédure de lecture et le code source complet du décodeur en OCR-B, avec un numéro de ligne et un CRC-16 sur chaque ligne. Le décodeur ne nécessite que NumPy, Pillow et reedsolo. Le texte utilise DEFLATE (zlib), qui peut être réimplémenté en quelques centaines de lignes, plutôt que LZMA, plus performant.
Prototype antérieur (codex_proto/). Cette version explorait plusieurs supports physiques : papier, acier inoxydable gravé au laser, plaques en taille-douce et images de microfilm. Elle utilisait des cellules de 2 à 16 niveaux, des pages de parité de type fontaine, des lecteurs de niveaux de gris à base de MLP, un calculateur optique imprimé pour la lecture des microfilms, ainsi qu’une réduction des médias avec pertes (codage paramétrique de la voix, codage des photos par résidus d’ondelettes).

Résultats

Tous les chiffres ci-dessous proviennent uniquement de simulations. Le logiciel modélise les défauts laser (flou du spot, grain du toner, engraissement du point, effet de bandes, densité non uniforme, papier texturé), les défauts du scanner (rotation de ±1,2°, échelle x/y de ±0,3 %, oscillation de l’entraînement, flou, vignettage, bruit, gamma 2,2), des taches de café, des rayures et une page volontairement perdue par archive. Aucun essai physique d’impression et de numérisation n’a encore été réalisé.

Charge utile nette : 383 469 octets par page A4, soit environ 59 bits/mm².
De bout en bout : 46 pages sur 50 ont été numérisées et les 4 archives sur 4 ont été restaurées à l’identique, octet pour octet (photo, vidéo, voix, texte). Aucun mot de code Reed–Solomon n’a échoué et aucun bloc inter-pages n’a été perdu.
Taux d’erreur : les pages propres ont nécessité la correction d’environ 0,007–0,008 % des octets. Les pages tachées et/ou rayées en ont nécessité au plus 0,90 %.
Taille des archives : photo 2,86 Mo → 10 pages (8 de données + 2 de parité) ; vidéo (800×600, 24 s, MJPEG + PCM 16 kHz) 8,30 Mo → 25 pages ; voix 0,91 Mo → 5 pages ; texte 5,58 Mo → 10 pages.
Texte : les Mémoires d’outre-tombe, dans le domaine public (5,43 millions de caractères), occuperaient 1 357 pages A4 composées. Encodées, elles tiennent sur 6 pages de données, soit un rapport d’environ 226. zlib compresse cette prose d’un facteur 2,62 et LZMA d’un facteur 3,58.
Récupération partielle : une archive tronquée au quart de sa longueur a encore restitué 1,42 Mo des 5,58 Mo de texte.
Robustesse du décodeur : le décodeur a également fonctionné sur des numérisations tournées de 90° et 180°, sur des numérisations à 600 dpi et sur des numérisations JPEG (q92).
Taille du décodeur : 731 lignes de Python pour les modules du décodeur imprimé.

La même zone de la page photo (380 × 300 points, environ 8 × 6,4 mm), agrandie. À gauche : telle qu’encodée. À droite : après le canal impression-numérisation simulé, rééchantillonnée sur la grille de la page grâce à l’homographie des repères. L’étalement du toner, le flou et le bruit adoucissent les cellules, et le bord d’une tache de café simulée assombrit la partie gauche. Le lecteur calibre les niveaux de gris localement et distingue donc encore les quatre niveaux. Dans la simulation présentée ci-dessus, les pages tachées ou rayées ont nécessité la correction d’au plus 0,90 % des octets.

L’archive vidéo : un plan sous-marin (banc de poissons au-dessus d’un récif) servant de séquence de test. En haut : les images originales HEVC 3840 × 2880 à 3,2 s, 12,8 s et 16,0 s, réduites. En bas : les mêmes instants, décodés à partir des numérisations simulées des 25 pages (dont une volontairement perdue). Le canal papier lui-même ne perd rien : l’AVI restitué est identique, octet pour octet, à l’AVI archivé. Ce qui diffère de l’original, c’est la réduction faite avant l’impression (MJPEG 800 × 600, 12,5 images/s, son mono 16 kHz) pour que 24 s de vidéo tiennent en 8,30 Mo.

Gros plan sur l’image à 12,8 s. À gauche : une zone de 1 152 × 864 pixels de l’original, réduite. À droite : la zone correspondante de 240 × 180 pixels de l’image restituée, agrandie sans lissage. Les poissons et le récif restent reconnaissables. La texture fine et les nuances de couleur sont perdues, et des blocs MJPEG apparaissent. C’est le prix à payer pour faire tenir le plan en 25 pages.

Limites & suite

Pas encore d’essai physique. Les motifs de points des cellules ont été ajustés en simulation. La prochaine étape est une impression réelle à 1200 dpi avec une numérisation à 1200 dpi, afin de les régler et de mesurer la marge d’erreur effective.
Jeu de test restreint. La simulation couvre une seule exécution sur quatre archives. Un balayage en fonction de la sévérité des défauts, de la résolution de numérisation et du type de papier reste nécessaire.
Propriétés physiques non mesurées. Le vieillissement à long terme du papier et du toner, ainsi que la faisabilité pratique de la relecture OCR du décodeur depuis le papier, n’ont pas été mesurés.
Dépendance à une police. Le corps de texte de l’annexe repose sur une police système.

Stack technique

Python · NumPy · SciPy · Pillow · reedsolo · ReportLab · soundfile · ffmpeg · Tesseract (OCR-B)

Identification sur le terrain des véhicules concernés par un rappel

Mon, 01 Jun 2026 00:00:00 +0000

Contexte

Les campagnes de rappel de sécurité supposent d’atteindre chaque véhicule concerné, mais courriers et appels téléphoniques laissent une population résiduelle de propriétaires qui ne répondent jamais. Dans les territoires insulaires et ultramarins, le problème est plus aigu : la couverture réseau est inégale, la logistique de terrain s’étend sur plusieurs territoires et le registre de qui conduit quoi est incomplet. La question pratique devient alors une question de gestion de flotte : quels véhicules du parc en circulation sont encore concernés, où sont-ils aperçus, et où en est chacun d’eux sur le chemin de la réparation ?

Approche

flowchart TB
 A["Liste de rappel
(récupération planifiée du fichier ou CSV manuel)"] --> B["Serveur central
import · versionnage · décodage des noms de modèles"]
 B -->|"diff incrémental"| C["Unités de terrain (ordinateurs portables dans les véhicules des agents)
copie locale de la liste de rappel"]
 D["Flux caméra"] --> E["Détection de plaques + OCR
(sur l'appareil, hors ligne)"]
 E --> F["Correction tenant compte du format
+ confirmation par double lecture"]
 F --> G{"Correspondance avec
la liste de rappel locale ?"}
 G -->|"non"| H["Écartée — rien n'est stocké"]
 G -->|"oui"| I["Alerte à l'agent
+ file d'attente locale"]
 I -->|"synchronisation au retour du réseau"| B
 B --> J["Tableau de bord
unités · tournées · détections · incidents"]
 J --> K["Processus de contact des propriétaires
identifié → contacté → réparé"]

Méthodes

Ingestion et versionnage des données. La liste de rappel est récupérée automatiquement selon un calendrier ou importée manuellement. Chaque import est comparé au précédent à l’aide d’identifiants stables, versionné par empreinte, et seul le delta est envoyé aux unités de terrain. Les codes de type constructeur sont traduits en noms de modèles lisibles lors de l’import.

Correspondance malgré le bruit de l’OCR. La détection des plaques et la reconnaissance des caractères s’exécutent sur l’ordinateur portable de terrain avec des modèles ONNX, sans dépendance au réseau. Deux garde-fous réduisent les fausses correspondances : (i) une étape de correction positionnelle exploite la structure connue des formats de plaques nationaux (actuel et ancien) pour lever les confusions classiques de l’OCR (O/0, I/1, S/5, B/8, Z/2, G/6), en rejetant toute lecture ambiguë ; (ii) une confirmation par double lecture ne comptabilise une plaque que si elle est lue deux fois dans une courte fenêtre de temps. Une page web pour smartphone offre une solution de secours manuelle (photo ou saisie de la plaque, avec validation de la clé de contrôle du VIN).

Synchronisation pensée pour le hors-ligne. Les correspondances sont mises en file d’attente localement et transmises au serveur central à la connexion suivante, de sorte que les détections survivent à des coupures de plusieurs jours. Les unités envoient un signal de vie (version du logiciel, version de la liste de rappel, compteurs de lectures).

Opérations de terrain. Les superviseurs planifient des tournées sous forme de points de contrôle ordonnés et géolocalisés sur une carte, les attribuent aux équipes et aux unités, réutilisent des modèles et suivent l’avancement. Les agents signalent les incidents avec un niveau de gravité. Un processus de contact consigne le résultat de chaque démarche auprès d’un propriétaire, et le tableau de bord en déduit un entonnoir de conversion (identifié → approché → engagé → réparé) avec les tendances hebdomadaires, le délai médian jusqu’à la réparation et une ventilation par territoire.

Protection des données dès la conception. Les plaques qui ne figurent pas sur la liste de rappel ne sont jamais stockées ni transmises ; les enregistrements conservés ont des durées de conservation fixes avec purge automatique ; les actions sont consignées dans un journal d’audit ; l’accès au tableau de bord repose sur des rôles, y compris des comptes en lecture seule ; les données au repos sont chiffrées. Un registre des traitements a été rédigé parallèlement au code.

Déploiement & exploitation (DevOps)

Le système tourne sur deux types de machines très différents : des ordinateurs portables Windows dans les véhicules des agents, qui peuvent rester hors ligne plusieurs jours, et un serveur par instance. Après les premières semaines de terrain, l’essentiel du travail d’ingénierie a consisté à rendre les deux côtés faciles à déployer, à superviser et à remettre en service, par une seule personne, sans interrompre le travail de terrain.

flowchart LR
 subgraph ADM["Poste d'administration"]
 GIT["Dépôt Git
arbre commité uniquement"]
 PROV["Script de provisionnement
un fichier de configuration par unité"]
 BLD["Build terrain
paquet PyInstaller + modèles ONNX"]
 end
 subgraph SRV["Serveur (VPS Ubuntu LTS)"]
 CAD["Caddy
TLS · HSTS · sans journal d'accès"]
 APP["Conteneur Docker
API FastAPI + tableau de bord
port en boucle locale uniquement"]
 VOL[("Volume LUKS2
SQLite · photos · archives")]
 TIM["Timers systemd
supervision · sauvegarde · nettoyage"]
 end
 FLD["Portables de terrain
SQLite local · boucle de synchronisation"]
 OBJ[("Stockage objet externe
sauvegardes chiffrées age")]
 CHAT["Alertes messagerie
changements d'état + bilans quotidiens"]
 GIT -->|"git archive via SSH → script de déploiement"| APP
 PROV -->|"API d'administration"| APP
 PROV -->|"fichier de configuration + LISEZMOI"| FLD
 BLD -->|"archive + installateur en un clic"| FLD
 FLD <-->|"HTTPS : signal de vie · envois · diff des rappels"| CAD
 CAD --> APP
 APP --- VOL
 TIM --> VOL
 TIM -->|"copie chiffrée"| OBJ
 TIM --> CHAT

Portables de terrain : empaquetage, installation et mises à jour

Empaquetage. L’application de terrain (backend Python, interface React) est figée avec PyInstaller en un exécutable Windows « un dossier » qui embarque les modèles ONNX et la configuration de l’OCR : une unité n’a besoin ni d’une installation Python ni du réseau pour lire les plaques. Des modes intégrés --diag et --selftest vérifient l’environnement d’exécution embarqué et lisent une image de test sans lancer l’interface, ce qui a permis de diagnostiquer les échecs de démarrage directement sur la machine de terrain.

Installateur en un clic. Le build est livré sous forme d’archive avec un INSTALLER.bat à lancer d’un double-clic. Il s’élève lui-même en administrateur et exécute un script PowerShell qui retire des fichiers la marque « téléchargé depuis Internet » (sans quoi l’environnement embarqué ne se charge pas), désactive la mise en veille USB pour que le dongle GPS ne soit pas suspendu, et installe le fichier de configuration de l’unité là où l’exécutable le lit. Le script refuse de deviner : si plusieurs fichiers de configuration différents sont présents, il les liste et demande lequel est le nouveau. Une réinitialisation optionnelle efface la base locale lorsqu’une unité change de serveur ; elle affiche le serveur cible avant de demander confirmation et avertit que les détections non synchronisées seraient perdues. Le jeton d’accès de l’unité n’est jamais affiché. Une mise à jour suit le même chemin : nouveau build, nouvelle exécution de l’installateur.

Provisionnement. Un script Python qui n’utilise que la bibliothèque standard, et tourne donc sur un Windows nu, crée les unités à partir d’un fichier CSV via l’API d’administration du serveur et génère, pour chacune, son fichier de configuration (adresse du serveur, code de l’unité, nom affiché, jeton) et un LISEZMOI à remettre avec le portable. La clé d’administration est lue dans une variable d’environnement ou saisie de manière masquée, jamais passée en argument de ligne de commande.

Versionnage : logiciel et liste de rappel

Version du logiciel. Chaque unité indique la version de son application dans son signal de vie. Le tableau de bord la compare à la version attendue et signale les unités qui restent à mettre à jour.

Version de la liste de rappel. La liste de rappel est versionnée par empreinte. À chaque cycle, une unité compare son empreinte locale à celle du serveur : identique, rien à faire ; pas de copie locale, téléchargement complet ; sinon, le serveur ne renvoie que les lignes ajoutées et retirées depuis cette empreinte (et l’unité se rabat sur un téléchargement complet si le serveur ne connaît plus sa version). La modification est appliquée en une seule transaction, et l’empreinte locale n’avance que si tout a été appliqué.

Cette dernière règle vient d’un incident de terrain. Une contrainte de la base de données faisait échouer le diff sur une unité, l’erreur était absorbée par la boucle de synchronisation, et l’unité continuait d’envoyer ses signaux de vie alors que sa liste de rappel restait figée pendant plus de deux semaines : elle alertait donc sur des véhicules déjà réparés. La version 1.4.1 a corrigé la cause, ajouté un retour arrière explicite et livré une migration de schéma qui conserve les données existantes. Elle a été testée par une série de 62 tests, qui reproduisait le bug et migrait une base à l’ancien schéma. La supervision lève désormais une alerte « synchronisation des rappels figée » lorsqu’une unité n’a pas reçu une liste publiée au-delà d’un délai de grâce.

Synchronisation incrémentale et résiliente

Toutes les cinq minutes, ou à la demande, une unité exécute un cycle de synchronisation composé d’étapes indépendantes : signal de vie, envoi des détections (par lots), trace GPS, incidents, mises à jour des points de contrôle, puis récupération de la liste de rappel et des tournées. Les envois passent avant les récupérations, de sorte que les données de terrain partent en premier. Une étape en échec ne bloque plus les autres : dans une version antérieure, le cycle était monolithique, et un signal de vie en échec a un jour retardé les détections de 22 minutes. Les requêtes utilisent des délais d’attente courts, les téléchargements des délais plus longs. Le signal de vie transmet la version du logiciel, la version de la liste de rappel, le nombre de détections en attente et les compteurs de lectures, sur lesquels reposent le tableau de bord et la supervision.

Déploiement du serveur

Kit d’instance. Chaque déploiement est une instance indépendante, décrite par un court identifiant, sur un serveur virtuel Ubuntu LTS. Un script d’amorçage, interactif et relançable sans risque, installe les paquets système, Docker et Caddy depuis leurs dépôts officiels. Il active les mises à jour de sécurité automatiques sans redémarrage automatique, restreint SSH à l’authentification par clé, active un pare-feu en refus par défaut et une protection contre la force brute, et vérifie que l’enregistrement DNS pointe vers le serveur avant d’appliquer la configuration TLS. Les secrets résident dans des fichiers de configuration réservés à root sur le serveur, jamais dans le dépôt.

Conteneur et proxy inverse. Un Dockerfile multi-étapes construit le tableau de bord React avec Node, puis exécute le serveur FastAPI sur une image Python allégée, sous un utilisateur non privilégié. Son contrôle de santé prévoit une période de démarrage de trois minutes, car les modèles de plaques et d’OCR sont chargés avant que le serveur n’écoute. Le conteneur n’est publié que sur l’interface de boucle locale. Caddy est le seul point d’entrée public : certificat Let’s Encrypt automatique, HSTS explicite et aucun journal d’accès, car les URL de scan contiennent des plaques. Le journal d’accès de l’application elle-même est désactivé pour la même raison.

Déploiement et retour arrière. Le code ne quitte le poste d’administration que sous la forme d’un git archive d’un arbre commité : les modifications non commitées sont listées et ne partent pas, et les fins de ligne sont forcées en LF. Sur le serveur, le nouvel arbre est extrait à côté de l’actuel puis permuté, le précédent est conservé, et le commit déployé est consigné. Le script de déploiement se détache ensuite de la session SSH : une connexion coupée n’interrompt ni le déploiement ni un retour arrière. Un verrou empêche les déploiements concurrents. Le script construit l’image (étiquetée avec son commit), conserve l’image précédente comme rollback, recrée le conteneur et attend qu’il se déclare en bonne santé. Il abandonne au bout de cinq minutes, ou dès que le conteneur a redémarré deux fois. En cas d’échec, il revient automatiquement à l’image et à l’arbre source précédents, met de côté le code en échec et envoie une alerte. Revenir à n’importe quelle version antérieure revient à redéployer ce commit. Un retour arrière d’image ne défait pas une migration de schéma : la procédure documentée consiste donc à faire une sauvegarde avant tout déploiement qui modifie le schéma.

Volume chiffré et redémarrages sûrs

Les données du serveur (base, photos de contact, archives des listes de rappel) résident dans un conteneur de fichier LUKS2 monté avec des options restrictives. Sa phrase de passe n’est jamais stockée sur la machine : après un redémarrage, une personne déverrouille le volume. Le conteneur redémarre de lui-même, mais le serveur refuse de démarrer tant qu’un fichier sentinelle situé sur le volume chiffré est absent. Sans lui, un redémarrage aurait laissé un dossier vide à la place du volume, et l’application y aurait créé une base neuve, non chiffrée, et accepté les données de terrain. Cette protection a été vérifiée dans les deux sens sur un conteneur jetable. Un script distinct agrandit le volume pendant qu’il est monté.

Sauvegardes et reprise

Un timer systemd quotidien prend un instantané cohérent de la base SQLite via son API de sauvegarde, l’archive avec les photos et les archives de rappel, et chiffre le résultat avec age vers une clé publique. La clé privée n’est affichée qu’une fois, à sa création, et conservée hors du serveur. Les sauvegardes sont gardées localement et, en option, copiées vers un stockage objet compatible S3 avec rclone, configuré uniquement par variables d’environnement. Un mode de test de restauration déchiffre une sauvegarde dans un dossier temporaire sur le volume chiffré, lance un contrôle d’intégrité, compte les lignes par table, puis efface tout. Le mode d’application déplace l’état courant de côté au lieu de le supprimer. La documentation comprend une reconstruction pas à pas après perte totale du serveur. Le plan de continuité vise un délai de reprise de 4 heures et une perte de données maximale de 24 heures.

Supervision

Un chien de garde s’exécute toutes les 15 minutes et ne publie sur un webhook de messagerie que lorsqu’un état change (problème, puis « rétabli »). Un bilan plus complet est envoyé deux fois par jour, calé sur les horaires de terrain. Il vérifie que le volume chiffré est monté, le point de santé de l’API (avec plusieurs essais, car l’import quotidien peut le bloquer environ une minute), l’état de santé du conteneur, la lisibilité de la base, l’occupation du disque système et du volume chiffré, la taille du journal d’écriture anticipée de SQLite, l’expiration du certificat TLS, l’âge et la taille de la dernière sauvegarde, les unités silencieuses depuis plus de 48 heures (et non 24, car les unités sont éteintes le week-end) et les unités dont la liste de rappel est figée. Un guetteur distinct alerte lorsqu’aucun import de liste de rappel n’a eu lieu depuis plus de 30 heures. Plusieurs de ces contrôles ont été ajoutés après des incidents réels : le volume chiffré a un jour atteint 90 % sans aucune alerte, car seul le disque système était surveillé. Un timer hebdomadaire nettoie les caches de construction Docker et ne conserve que les images courante et de rollback. Un script dédié tronque le journal SQLite avec une attente de verrou courte, afin que les écritures du terrain ne soient jamais bloquées longtemps.

Résilience hors ligne

Le côté terrain est conçu pour continuer à fonctionner pendant une panne du serveur : lecture des plaques, correspondance avec la copie locale de la liste de rappel, alertes, tournées déjà téléchargées et onglet de statistiques local fonctionnent sans réseau, et la file d’attente se vide à la connexion suivante. Seuls le tableau de bord (et la page pour smartphone hébergée sur le serveur) sont indisponibles tant que le serveur est arrêté.

Tests

Le dépôt ne comporte pas de chaîne d’intégration continue. Les versions sont testées avant leur livraison, et les commits consignent ces exécutions : 12/12 et 6/6 pour les étapes de correction des plaques et de confirmation, 62 tests pour la version 1.4.1. Les comportements qui ne se prêtent pas aux tests unitaires, comme la protection du volume ou un déploiement réel, ont été vérifiés sur des conteneurs jetables et sur le point de santé de la production.

Résultats

Lors des premières opérations de terrain, les agents ont signalé 32 % des détections comme des erreurs de lecture sur environ une semaine. Cette mesure a motivé les étapes de correction positionnelle et de confirmation par double lecture, et les statistiques du tableau de bord excluent désormais les détections marquées comme faux positifs.
Les nouvelles étapes ont été livrées avec des tests unitaires : 12/12 pour la correction des plaques et 6/6 pour la confirmation, les réglages et le journal des lectures.
Après l’extension de la table de correspondance des noms de modèles, une seule ligne de la liste de rappel de production restait sans nom de modèle décodé.

Aucun taux de reconnaissance de bout en bout n’a encore été mesuré.

Limites & suite

La précision de la reconnaissance n’a pas été mesurée sur un banc d’essai avec vérité terrain. Les objectifs du cahier des charges (taux de lecture, latence) sont des objectifs de conception, non des résultats.
Aucune lecture de plaque à l’ancien format n’a été observée au départ. Un compteur dédié suit désormais ces lectures de bout en bout, mais le correctif doit encore être vérifié sur le terrain.
Une fausse correspondance avec une liste volumineuse coûte toujours du temps aux agents. L’étape suivante consiste à calibrer le seuil de confiance et la fenêtre de confirmation sur des vidéos de terrain annotées.

Stack technique

Python · FastAPI · SQLite · ONNX Runtime · fast-alpr (détecteur de plaques YOLOv9 + OCR) · OpenCV · PaddleOCR · React · TypeScript · Vite · Leaflet · Docker · Caddy · LUKS · systemd · age · rclone · PyInstaller · PowerShell