Automatisation on Boris Dupoux

Automatisation déterministe des processus sous fortes contraintes de sécurité

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

Contexte

Un client soumis à de fortes contraintes de sécurité gère plusieurs centaines de sites et exécute chaque jour quatre processus administratifs récurrents : la maintenance des équipements sur le terrain, le traitement des événements parasites récurrents émis par ces équipements, la rédaction de rapports d’intervention pour ses propres clients et la vérification de la bonne réception du contrôle de santé périodique de chaque site. Les données d’entrée sont dispersées entre trois systèmes aux modes d’accès très différents : des rapports PDF reçus par courriel, un portail web métier sans API publique et des classeurs Excel tenus à la main depuis de nombreuses années.

L’objectif : automatiser ces processus sur un poste de travail de bureau tout en laissant à un opérateur humain le dernier mot sur chaque message adressé aux clients.

Contraintes de conception

Aucun modèle de langage à l’exécution. Chaque décision découle de règles explicites et chaque phrase d’un modèle de texte. La sortie du robot est ainsi reproductible : les mêmes entrées produisent toujours les mêmes brouillons, de sorte qu’une nouvelle version peut être comparée mot pour mot à la production, et que toute modification peut être rattachée à une règle ou à une source de données. Aucune donnée client n’est transmise à un service de modèle externe. Un modèle vision-langage a été utilisé une seule fois, hors ligne, lors de la conception, pour cartographier des sessions d’écran enregistrées d’opérateurs ; il ne fait pas partie du système déployé.
Des brouillons, pas des envois. Le robot se contente de créer des brouillons Outlook ; l’opérateur les relit et les envoie. Un interrupteur d’arrêt global impose le mode brouillon quels que soient les réglages propres à chaque processus.
Exécution locale, sans nouvelle infrastructure. Python sur un poste Windows, tâches planifiées, dossier partagé sur NAS pour l’état et la configuration.
Aucun secret en clair. Identifiants et jetons sont stockés dans le Gestionnaire d’identifiants Windows (DPAPI) ; la configuration est en YAML, modifiable par l’opérateur sans recompilation.

Architecture

flowchart TB
 SCHED["Passages planifiés (matin / après-midi)"] --> ING
 MAIL["Boîte aux lettres (Microsoft Graph, lecture)"] --> ING["Ingestion rapports PDF regroupés par jour"]
 ING --> PARSE["Analyseur PDF (pypdf + expressions régulières)"]
 PORTAL["Portail web métier connexion Playwright → jeton de session → rejeu des points d'accès JSON"] --> RULES
 XLS["Classeurs de référence & d'historique (Excel)"] --> RULES
 PARSE --> RULES["Moteur de règles 4 processus, règles ordonnées & exclusions"]
 RULES --> TPL["Composeur de modèles accords, noms, dates en français"]
 TPL --> DRAFTS["Brouillons Outlook (Graph, jamais envoyés)"]
 RULES --> TRACK["Classeurs de suivi (ajout atomique)"]
 DRAFTS --> OP(["L'opérateur relit & envoie"])
 OP -. "éléments envoyés : destinataires corrigés" .-> RULES
 NAS[("NAS : verrous, battements de cœur, journal, registre d'idempotence")] --- RULES
 RULES --> HEALTH["Alertes de santé webhook + contrôle de l'homme mort"]

Les quatre processus

Maintenance des équipements. Les lignes de panne extraites des rapports PDF quotidiens sont confrontées à l’historique des piles et des réparations de chaque appareil. Un arbre de décision ordonné (la première correspondance l’emporte) choisit entre ignorer, attendre, remplacer la pile, remplacer l’appareil ou tester la portée radio, et rédige un ordre d’intervention pour le technicien ; chaque appareil d’un ordre portant sur plusieurs appareils conserve sa propre décision.

Événements parasites récurrents. Le nombre d’événements par site et par appareil sur 24 heures est comparé à des seuils pour détecter les événements parasites récurrents. Les données du portail (un incident confirmé comme réel, un système mis à l’arrêt quelques minutes après une salve) priment sur ces comptages ; il en résulte un courriel de sensibilisation au client, un ordre d’intervention, ou rien.

Rapports d’intervention. Pour chaque intervention sur site, le robot reconstitue une chronologie unique à partir du journal d’événements du portail, du journal d’appels et des relevés des équipes de terrain, gère les événements à cheval sur minuit et rédige un rapport client accompagné des fichiers médias.

Contrôles de santé périodiques. Les sites dont le contrôle de santé périodique est absent sont identifiés, l’état de chaque canal de connectivité est vérifié sur le portail, puis un courriel au client, un ordre d’intervention ou une note interne est rédigé.

Rédiger un courriel : des paramètres au brouillon

Chaque brouillon est l’aboutissement d’une longue chaîne de décisions explicites. Comptés dans le code source (octobre 2026), les quatre moteurs de règles comportent 53 issues terminales (chaque endroit où une règle rend une décision), réparties sur 37 types de décision et 13 générateurs de brouillons.

Le courriel de sensibilisation du processus « événements parasites » en donne la mesure. Un site n’y aboutit qu’après 14 tests ordonnés au plus dans le moteur de règles (16 issues terminales pour ce seul processus). Le composeur lit ensuite 21 entrées : 17 champs de la fiche de décision du site et de la fiche client, la liste des destinataires, les pièces jointes et deux ressources apprises (les noms de zones du portail et un dictionnaire d’orthographe appris dans le classeur d’historique de l’opérateur lui-même). Entre la décision et le texte final, on compte 108 points de branchement conditionnel (instructions if, expressions conditionnelles et opérandes booléens, comptés sur l’arbre syntaxique du composeur et des dix fonctions auxiliaires qu’il appelle, avant la mise en forme HTML).

flowchart TB
 IN(["1 · Moteur de règles — 14 tests ordonnés, la première correspondance l'emporte. Entrées : rapports d'événements quotidiens · journal du portail · fiche client · profil appris du site"]) --> T0

 T0["Drapeau bloquant sur la fiche du site ?"] -- oui --> X0["Pas de courriel"]
 T0 -- non --> T1["R6 · incident confirmé comme réel aujourd'hui ?"]
 T1 -- oui --> X1["Pas de courriel"]
 T1 -- non --> T2["R17 · événements médias à moins de 30 s entre zones ?"]
 T2 -- oui --> X2["Arbitrage manuel"]
 T2 -- non --> T3["R12 · cause externe confirmée par les médias ?"]
 T3 -- non --> T4["R8 · ≥ 8 événements d'intégrité ?"]
 T4 -- oui --> T4b["persistants depuis ≥ 3 jours ?"]
 T4b -- oui --> X3["Ordre d'intervention technicien"]
 T4b -- non --> X4["En attente"]
 T4 -- non --> T5["≥ 2 événements d'intégrité, ≥ la moitié de la salve ?"]
 T5 -- oui --> X5["Pas de courriel"]
 T5 -- non --> T6["R16 · ≥ 140 événements, sensibilisation ignorée depuis ≥ 4 semaines ? (désactivée par défaut)"]
 T6 -- oui --> X6["Avis de facturation"]
 T6 -- non --> T7["R15 · drapeau bâtiment partagé ?"]
 T7 -- oui --> X7["Courriel de coordination"]
 T7 -- non --> T8["R5 · week-end + drapeau appareil chroniquement défaillant ?"]
 T8 -- oui --> X8["Demande de masquage temporaire"]
 T8 -- non --> T9["R1 · même appareil ≥ 7 événements ?"]
 T9 -- non --> T10["R2 · ≥ 5 appareils et ≥ 8 événements ?"]
 T10 -- non --> T11["R4 · ≥ 8 événements, ≥ 50 % entre 5 h et 7 h ?"]
 T11 -- non --> T12["R3 · ≥ 8 événements, ≥ 60 % entre 12 h et 18 h, ≥ 70 % en 4 h ?"]
 T12 -- non --> T13["R1bis · total du site ≥ 7 événements ?"]
 T13 -- non --> X9["Pas de courriel"]

 T3 & T9 & T10 & T11 & T12 & T13 -- oui --> ADV

 ADV(["2 · Composeur — courriel de sensibilisation, identifiant de règle transmis. Nom du client : forme juridique retirée, casse rétablie, sigles conservés"])
 ADV --> SUBJ["≥ 30 événements ?"]
 SUBJ -- oui --> S1["Objet avec préfixe d'urgence"]
 SUBJ -- non --> S2["Objet simple"]
 S1 & S2 --> GR["Cellule contact"]
 GR -- "plusieurs personnes, ou mot de fonction / d'organisation" --> G1["Salutation générique"]
 GR -- "civilité + nom" --> G2["Salutation + civilité normalisée (7 abréviations) + NOM"]
 GR -- "nom seul" --> G3["Salutation + NOM"]
 G1 & G2 & G3 --> DEV["Appareils concernés"]
 DEV -- un --> D1["Nom de zone du portail s'il est connu, sinon libellé nettoyé + table de jargon + accents appris"]
 DEV -- plusieurs --> D2["Formule générique + liste de 6 au plus par nombre d'événements, chacun avec son code s'il est connu"]
 D1 & D2 --> HND["Système mis en marche ou à l'arrêt à quelques minutes de la salve ? (R1 à R4 seulement)"]
 HND -- "arrêt juste après" --> C1["Erreur de manipulation, formulation A"]
 HND -- "marche juste avant" --> C2["Erreur de manipulation, formulation B"]
 HND -- non --> ACT["Site en activité ? — toutes les conditions : R1 à R4 ou R1bis · ≥ 2 appareils · ≥ 10 événements · aucune intervention dans la fenêtre · site professionnel · ≥ 90 % dans les heures apprises · capteurs médias seuls : ≥ 90 % système en marche"]
 ACT -- oui --> C3["Formulation « site en activité »"]
 ACT -- non --> RUL["Règle déclenchée"]
 RUL -- "R1, R2" --> C4["Cause environnementale générique"]
 RUL -- "R3, R4" --> C5["Cause : passages du personnel"]
 RUL -- R12 --> C6["Cause externe confirmée par les médias"]
 RUL -- R1bis --> C7["Cause à rechercher sur place"]
 C4 & C5 --> ATT["Médias réellement joints ?"]
 ATT -- oui --> A1["+ renvoi aux pièces jointes"]
 ATT -- non --> FLG
 A1 & C1 & C2 & C3 & C6 & C7 --> FLG["Drapeau du site : travaux fréquents ?"]
 FLG -- oui --> F1["Demande : arrêt avant travaux"]
 FLG -- non --> F2["Demande : traiter la cause"]
 F1 & F2 --> REC["Adresses dans la fiche client ?"]
 REC -- oui --> RC1["Toutes les adresses trouvées"]
 REC -- non --> RC2["Boîte interne de repli"]
 RC1 & RC2 --> DRAFT(["Texte brut → HTML Outlook (dé-repliage, listes, typographie fixe, signature) → dossier des brouillons, jamais envoyé"])
 classDef q stroke-dasharray:4 3,stroke-width:2px;
 class T0,T1,T2,T3,T4,T4b,T5,T6,T7,T8,T9,T10,T11,T12,T13,SUBJ,GR,DEV,HND,ACT,RUL,ATT,FLG,REC q;

L’espace de formulation de ce seul courriel : 2 formes d’objet, 3 formes de salutation, 2 formes de phrase d’ouverture, 7 formulations de cause atteignables (dont deux avec ou sans renvoi aux médias joints), 2 demandes d’action et une liste facultative de 2 à 6 appareils. Tous les seuils ci-dessus sont dans la configuration YAML, pas dans le code.

Paramètre	Source	Effet sur le courriel
Nombre d’événements sur 24 h	rapports quotidiens	chiffre de la phrase d’ouverture ; à partir de 30, préfixe d’urgence dans l’objet
Règle déclenchée	moteur de règles	choisit la formulation de la cause ; conditionne les vérifications « erreur de manipulation » et « site en activité »
Appareils concernés (nettoyés, dédoublonnés)	rapports quotidiens	un appareil nommé, ou une formule générique suivie d’une liste de 6 lignes au plus, par nombre d’événements
Code de l’appareil sur chaque ligne de rapport	rapports quotidiens	ajouté entre parenthèses à chaque appareil listé, seulement s’il est connu
Nom de zone de l’appareil principal	portail	remplace le libellé brut du rapport lorsqu’il est disponible
Graphies apprises	classeur d’historique de l’opérateur	rétablit accents et casse des noms d’appareils
Cellules civilité et nom du contact	fiche client	l’une des 3 formes de salutation ; plusieurs personnes, une fonction ou un nom d’organisation ramènent à la forme générique
Raison sociale	fiche client	forme juridique retirée, casse rétablie en conservant les sigles, utilisée dans l’objet et le corps
Type de site, heures d’ouverture apprises, interventions dans la fenêtre	classeur de suivi, journal du portail	active ou neutralise la formulation « site en activité »
Mise en marche ou à l’arrêt autour de la salve	journal du portail	formulation « erreur de manipulation » (2 variantes), prioritaire sur toute autre cause
Drapeaux du site	fiche client	choix entre les 2 demandes d’action
Présence de pièces jointes	médias du portail	renvoi aux pièces jointes, ou rien
Adresses des destinataires	fiche client	toutes les adresses trouvées ; à défaut, une boîte interne de repli

Les autres brouillons s’appuient sur les mêmes fonctions partagées de rédaction en français : la préposition devant un nom de site s’accorde avec son premier nom (6 formes, de « chez » à « à l’ » et « aux ») ; les titres des rapports s’accordent en genre et en nombre ; les dates sont écrites en toutes lettres ; l’intitulé « Contact » passe au pluriel dès que plusieurs contacts sont listés ; et une table de 8 entrées traduit le jargon technique des équipements en vocabulaire client.

Ingénierie de la fiabilité

Idempotence. Un registre quotidien indexé par site, type de message et empreinte de l’objet empêche les brouillons en double ; un registre inter-jours empêche de réémettre un ordre d’intervention avant que l’intervention précédente n’ait eu lieu. Les jours manqués sont rattrapés automatiquement.
Concurrence sur un NAS partagé. Fichiers de verrou exclusifs (O_CREAT|O_EXCL) avec une durée de vie pour les verrous orphelins ; deux postes publient des battements de cœur, et le poste secondaire ne prend le relais que lorsque le principal est silencieux depuis deux minutes.
Écritures sûres dans les classeurs. Les écritures passent par un fichier temporaire et un remplacement atomique, avec nouvelles tentatives lorsque le classeur est ouvert par un utilisateur ; les lignes insérées décalent les formules de pied de tableau pour que les totaux restent justes.
Robustesse réseau. Les appels Graph gèrent le renouvellement des jetons, l’en-tête Retry-After des réponses HTTP 429 et le repli progressif sur les erreurs 5xx.
Échec explicite. Une enveloppe de plantage, sans dépendance au paquet principal, envoie une alerte expurgée et un signal d’homme mort même lorsque les imports échouent ; une sentinelle déclenche une alerte lorsque le portail ne renvoie aucune donnée au lieu de signaler un succès.
Évaluation en parallèle (shadow). Une version bac à sable rejoue une journée en lecture seule et compare ses brouillons à ceux de la production. Le critère d’acceptation est la part des brouillons que l’opérateur envoie sans en modifier un seul mot.

Résultats

1 766 tests automatisés dans le dépôt (octobre 2026), reposant sur des adaptateurs simulés de messagerie et de portail, les tests sur systèmes réels étant marqués à part.
Un audit du corpus de rapports reçus a montré que 9,5 % des lignes d’événements étaient écartées silencieusement, parce que les codes et libellés d’événements sont concaténés dans le texte extrait des PDF ; l’analyseur a été réécrit pour reconnaître les formes de codes effectivement émises.
La mise en cache du classeur d’historique des pannes (1,49 Mo, 15 533 lignes) a réduit la durée du processus de maintenance des équipements, sur un rejeu de rapports réels, de 161,1 s à 23,3 s ; le nombre d’ouvertures du classeur est passé de 26 à 3.
Première comparaison en parallèle sans écart avec la production : 14 brouillons de chaque côté, 14 en commun, 0 manquant, 0 en trop.

Stack technique

Python 3.11 · Microsoft Graph · MSAL · httpx · Playwright · pypdf · openpyxl · pydantic · keyring · pytest · PyInstaller

De l'enregistrement multipiste à la timeline éditable : transcription, diarisation et export AAF

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

Contexte

Une conférence enregistrée sur plusieurs microphones (intervenants, salle, musique) produit des heures d’audio multipiste brut. L’essentiel du temps de montage est consacré à repérer la matière — qui parle quand, sur quelle piste, où se trouvent les silences — avant toute coupe.

Les outils vocaux open source (Whisper et ses dérivés, pyannote, Silero VAD) résolvent bien la transcription et la question « qui a parlé quand », mais s’arrêtent au texte. La question traitée ici est de savoir si cette analyse peut être livrée sous la forme d’un objet de montage : une timeline multipiste au format AAF, le format d’échange que les stations audionumériques ouvrent nativement, avec des pistes qualifiées et les temps morts supprimés.

Avant → après

Un vrai projet traité de bout en bout : une conférence enregistrée sur 16 pistes. Toute la colonne de droite est produite automatiquement, sans aucune coupe manuelle ; les chiffres sont lus dans la base d’analyse du projet et dans l’AAF livré.

	Entrée (enregistrement brut)	Sortie générée (timeline AAF)
Pistes	16 × 1 h 32 min 54 s (≈ 24 h 46 min d’audio à parcourir)	16 pistes conservées dans l’AAF, dont 6 portent des clips
Rôles des pistes	4 parole · 2 musique (dont une détectée comme ambiance) · 10 silencieuses	10 pistes silencieuses laissées vides, sans tri manuel
Matière	204 régions de parole et 5 passages musicaux détectés	41 clips (37 parole, 4 musique)
Coupes	—	40 coupes franches entre sources, dont 33 changements de micro
Transitions	—	0 fondu enchaîné : coupes franches, chaque clip de parole prolongé de 0,3 s
Temps morts	—	3 trous ≥ 4,5 s supprimés en ripple (36,9 s) ; timeline de 1 h 32 min 17 s

En haut : les 16 pistes d’entrée sur toute la durée de l’enregistrement, colorées selon le rôle et l’activité détectés ; les quatre micros de parole sont actifs presque en permanence, car chacun capte aussi ses voisins. En bas : le montage généré, une ligne par piste comme dans l’AAF — une seule source est retenue à chaque instant, les repères marquent les 40 changements de source, les zones hachurées du panneau supérieur sont les temps morts supprimés.

Les clips de parole sont peu nombreux et longs (médiane 79 s, le plus long 10 min 11 s) : le montage suit l’intervenant actif au lieu de couper à chaque respiration, et les micro-bascules de moins de 0,8 s sont absorbées par le lissage anti-scintillement. Dix clips durent encore moins de 6 s — de brèves interjections, premier endroit à vérifier lors de la relecture du montage.

Approche

flowchart TB
 A["Enregistrement WAV multipiste"] --> B["Décodage en mono 16 kHz + énergie RMS par 100 ms"]
 B --> C["Détection d'activité vocale (Silero)"]
 C --> D["Transcription (Whisper large-v3, par segments)"]
 D --> E["Alignement forcé des mots (WhisperX / wav2vec2)"]
 C --> F["Diarisation des locuteurs (pyannote)"]
 E --> G["Attribution des locuteurs + post-traitement des segments"]
 F --> G
 B --> H["Rôle de la piste : parole / musique / silence"]
 G --> H
 H --> I["Montage : micro actif par trame de 100 ms"]
 I --> J["Export AAF (lié aux noms WAV d'origine)"]
 I --> K["Mixage mono WAV"]

Méthodes

Transcription. Whisper large-v3 via faster-whisper (CTranslate2), exécuté sur des segments de longueur fixe dans un processus de travail isolé et persistant : le modèle n’est chargé qu’une fois, et un plantage natif ne fait perdre qu’un segment, signalé plutôt qu’ignoré silencieusement. Le décodage utilise une recherche en faisceau avec filtrage Silero VAD, et condition_on_previous_text est désactivé pour limiter les boucles de répétition.

Horodatage des mots et locuteurs. Les horodatages au niveau du mot proviennent de l’alignement forcé de WhisperX (wav2vec2). Les tours de parole proviennent de la diarisation pyannote et sont attribués aux mots par recouvrement temporel.

Post-traitement. Des filtres purs suppriment les hallucinations connues de Whisper (crédits de sous-titrage types, formules du genre « merci d’avoir regardé », segments purement musicaux), les sorties en écriture non latine sur de l’audio français et les doublons, puis fusionnent les segments consécutifs d’un même locuteur.

Qualification des pistes et montage. Chaque piste est classée en parole, musique ou silence en combinant l’énergie par trame, la couverture VAD et des statistiques de transcription. Le montage sélectionne, pour chaque trame de 100 ms, le microphone présentant le meilleur rapport signal sur bruit au-dessus de son propre bruit de fond (ce qui réduit la diaphonie entre micros), applique un lissage anti-papillotement et resserre la timeline en supprimant les temps morts globaux.

Synchronisation. Les enregistreurs distincts sont alignés en appariant des mots caractéristiques entre transcriptions (médiane robuste des décalages), après un placement grossier fondé sur l’horloge et corrigé de la dérive d’horloge.

Export. La liste de montage est écrite sous forme d’AAF multipiste avec pyaaf2, en intégrant l’audio ou en le référençant.

Déploiement. Un portail web reçoit les tâches et un nœud de calcul distinct l’interroge en HTTPS. Les clients ne téléversent que des copies d’analyse compressées accompagnées d’un manifeste de leurs fichiers d’origine ; l’AAF livré référence les noms des WAV d’origine, de sorte que le monteur reconnecte localement les sources en pleine qualité et que les originaux ne quittent jamais la machine du client.

Résultats

Banc d’essai (bench_stt.py) sur de l’audio réel de conférence : fenêtres de parole d’une minute sélectionnées par VAD sur quatre pistes de parole, Whisper large-v3 dans tous les cas, ordinateur portable Apple Silicon, mesures à chaud hors chargement du modèle. Aucune transcription de référence n’étant disponible, les indicateurs de qualité sont des divergences par rapport à une pseudo-référence (sortie de WhisperX), et non des erreurs absolues.

Chaîne de traitement (CPU)	Facteur temps réel
openai-whisper	0,43
WhisperX	0,51
WhisperX + alignement forcé	0,54
openai-whisper + horodatage des mots	0,57
faster-whisper (faisceau 5 + VAD)	0,66
faster-whisper + horodatage des mots	0,70

Horodatage des mots : les horodatages natifs s’écartent de l’alignement forcé d’environ 205 ms en médiane (faster-whisper) et d’environ 210 ms (openai-whisper) ; l’alignement forcé ajoute environ 1,2 s par minute d’audio.
Divergence des transcriptions : 7 à 11 % de divergence au niveau du mot entre chaînes, essentiellement de la ponctuation, de la segmentation et de la normalisation après inspection manuelle.
Répétitions : 1 à 2 % de contenu répété ; aucun passage halluciné observé sur ces extraits.
Détection des pistes : les trois pistes de musique ou de silence de l’enregistrement à sept pistes ont été identifiées par VAD et écartées automatiquement.

Limites & suite

La qualité est mesurée par rapport à une pseudo-référence ; un jeu de test transcrit manuellement est nécessaire pour rapporter un véritable taux d’erreur sur les mots et un taux d’erreur de diarisation.
Les extraits du banc d’essai sont courts (une minute par piste) et ne comportent qu’un seul locuteur par fenêtre : la précision de la diarisation en cas de chevauchement de plusieurs locuteurs n’est donc pas encore quantifiée.
CTranslate2 n’a pas de backend Metal : sur Apple Silicon, faster-whisper et WhisperX s’exécutent sur CPU, tandis que CUDA est utilisé lorsqu’il est disponible. Le choix du matériel pour chaque étape a été mesuré plutôt que présumé ; une comparaison sous CUDA reste à effectuer.
L’export AAF cible l’import dans Logic Pro ; les autres logiciels de montage n’ont pas été testés de manière systématique.

Stack technique

Python · faster-whisper · CTranslate2 · WhisperX · pyannote.audio · Silero VAD · PyTorch (MPS / CUDA) · ffmpeg · pyaaf2 · SQLite · PHP · MySQL

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