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, ce qui est conçu pour permettre de comparer mot pour mot une nouvelle version à la production, et 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 une vingtaine d’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 une centaine de 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. La plupart des seuils ci-dessus sont dans la configuration YAML ; quelques-uns (urgence, site en activité, concentration sur 4 h) restent 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 sera la part des brouillons que l’opérateur envoie sans en modifier un seul mot ; il n’a pas encore été mesuré.

Résultats

1 766 tests automatisés collectés dans le dépôt (octobre 2026 ; statut de réussite non consigné), reposant sur des adaptateurs simulés de messagerie et de portail ; les tests qui exigent de vraies données de référence sont ignorés lorsque celles-ci sont absentes.
9,5 % (132/1 383) des lignes d’événements de 12 jours de rapports réels étaient écartées silencieusement, ce qui a été découvert après qu’un site a manqué dans une exécution : 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 ; depuis, aucune ligne n’est perdue sur 11 rapports réels.
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 de 161,1 s à 23,3 s, sur un rejeu des rapports réels d’une journée (une seule exécution) ; le nombre d’ouvertures du classeur est passé de 26 à 3.
Première journée en parallèle sans écart avec la production : 14 brouillons de chaque côté, mêmes décisions et mêmes objets, 0 manquant, 0 en trop. Les corps n’ont pas encore été comparés, et une journée ordinaire compte environ 90 brouillons.

Stack technique

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

Analyse De Pdf on Boris Dupoux