[AI]
rgosPoC conformité ERP
Système opérationnel — Dossier de test prêt

[AI]rgos — Instruction automatisée de dossiers ERP

Pipeline multi-agents qui instruit les dossiers ERP de sécurité incendie au regard de l'Arrêté du 25 juin 1980 modifié. Chaque allégation déclarée est routée vers son article réglementaire, comparée au seuil, puis transformée en prescription formelle.

Lancer le pipeline
11
Agents spécialisés
9
Skills (modules de connaissance)
9
Fichiers KB réglementaires
10
Étapes du pipeline

Flux de délégation — routage des requêtes

Cliquez sur un agent pour voir la tâche qu'il reçoit, les fichiers qu'il lit et les données renvoyées à l'orchestrateur.

0b1233b44b567📄 Dossier ERPerp-orchestratoropus · délègue · agrège · décideTask() × 7 + state JSON0bdocument-extractorExtraction PDF multimodale1completeness-checkerVérification de complétude2classifierClassification + Effectif3notice-parserAnalyse de la notice3bomission-detectorDétection des omissions4plan-verifierVérification des plans4bcoherence-checkerCohérence inter-pièces5article-retrieverRécupération d'articles6prescription-writerRédaction des prescriptions7avis-assemblerAssemblage de l'avis✅ AVIS produitLégendedélégation (appel Task)retour (state JSON mis à jour)sortie finale (avis)

Statut de validation — en toute honnêteté

Ce que nous avons construit ≠ ce que nous avons validé. Voici l'état réel.

Architecture validated
Architecture du pipeline (10 étapes, 11 agents)
Validée par l'évaluateur expert Cdt Lacombe — l'analyse d'écart a fait émerger les étapes manquantes 3.5 et 4.5
Manual smoke test
Base de connaissances réglementaire (9 fichiers KB)
Articles revus manuellement. Non validés quant à leur exactitude par un préventionniste expert.
Manual smoke test
Pipeline exécuté manuellement sur Le Campanile (synthétique)
Mais : j'ai écrit le dossier ET la KB → validation circulaire, simple smoke test
Untested
Dossiers synthétiques en aveugle (boutique, sandwicherie)
Générés par les sous-agents Pierre Lemaire. Pas encore scorés via le modèle de scoring.
Untested
Exécution live de bout en bout via l'orchestrateur
Les appels Task() de l'orchestrateur n'ont jamais été réellement déclenchés
Manual smoke test
Extraction multimodale de PDF réels
Lecture du PDF SDIS-38 (11 pages) réussie. Jamais testée sur un dossier multi-PDF complet.
Untested
Évaluation face à un dossier ERP réel + avis SDIS
Aucun dossier réel disponible. Email au Pr. Guyeux rédigé, pas encore envoyé.
Untested
Métriques quantitatives (précision, rappel, F1)
Modèle de scoring rédigé. Aucune donnée mesurée pour l'instant.
Lecture honnête : la contribution actuelle est méthodologique et architecturale. La contribution empirique constitue la phase suivante, conditionnée à l'accès aux données et à une exécution live de bout en bout.

Feuille de route — ce qui pourrait être ajouté

Priorisé par impact sur la thèse. P0 = avant soutenance · P1 = renforcement · P2 = extension future.

Exécution live de bout en bout

P0

Déclencher réellement les appels Task() de l'orchestrateur sur Le Campanile, et pas seulement rejouer une simulation. Prouve que l'architecture n'est pas du vaporware.

2 heures

Scorer les 2 dossiers en aveugle + générer les 3 manquants

P0

Suivre la méthodologie « commit avant exécution » sur la boutique + la sandwicherie. Générer brasserie + caviste + restaurant méditerranéen. Remplir le tableau de métriques.

8 heures

Obtenir un dossier ERP réel

P0

Envoyer l'email au Pr. Guyeux. Un seul dossier anonymisé avec l'avis SDIS de référence transforme qualitativement la soutenance.

30 min + temps d'attente

Test multimodal de bout en bout sur les PDF Sydonia

P1

Lancer erp-document-extractor sur les 31 vrais PDF. Même si le projet n'est pas un ERP, cela prouve la capacité multimodale en conditions non contrôlées.

1 heure

Audit prompt-engineering des agents 0.5, 3.5, 4.5

P1

Les trois agents ajoutés en seconde phase n'ont pas été audités au regard des bonnes pratiques Anthropic (structure XML, anti-hallucination, format de sortie strict).

2 heures

Extension au-delà du périmètre actuel

P2

4e catégorie (effectif 201-300), types M / L / P / R. Chaque extension exige un ajout à la base de connaissances + une mise à jour de l'agent classifieur + un fichier KB propre au type.

1 jour par type

Limites connues du PoC

Identifiées lors de l'évaluation par un préventionniste expert. Ces points doivent rester sous la responsabilité du préventionniste dans tout déploiement en production.

Pas d'inspection sur site

Le système est 100 % documentaire. Il n'effectue pas la vérification sur site qu'un préventionniste réalise avant ouverture (demande d'ouverture). Cette étape reste obligatoire et humaine.

Limite : pour les demandes d'ouverture, la conformité doit encore être confirmée par une visite en personne.

Pas de courrier automatique « pièces manquantes »

Si le dossier est incomplet, le système le signale (Étape 1 STOP) mais ne rédige pas le courrier formel de demande de pièces adressé au pétitionnaire.

Limite : le préventionniste rédige le courrier manuellement à partir du rapport de complétude.

Pas de consultation de l'historique des avis

Pour un même ERP ayant déjà fait l'objet de dépôts antérieurs (visites périodiques, modifications), le système ne consulte pas les avis passés de la commission de sécurité.

Limite : utilisable pour l'instruction initiale ; les modifications exigent une consultation manuelle des dossiers passés.

Périmètre restreint

Couverture limitée à : ERP de 5e catégorie, types N (restaurants) et M (commerces), sans locaux à sommeil. Les ERP de 1re à 4e catégorie, le type O (hôtels), le type U (établissements de soins) et les IGH sont hors périmètre.

Hors périmètre : le système refuse de produire un avis et renvoie au préventionniste humain.

Agents

cliquez sur une carte pour voir le system prompt complet

Skills

connaissances et procédures chargées par les agents

Base de connaissances — Arrêté du 25 juin 1980

articles encodés, routés par axe CLICDVECRM