Le problème traité
Rédiger un cahier de devis techniques part de documents épars — plans, rapports, notes — et se fait à la main, section par section. Le travail est long, et rien ne garantit qu’une clause renvoie bien à la page qui la justifie.
Le fonctionnement
Les documents produisent des observations, chacune rattachée à sa preuve dans la page d’origine. Ces observations deviennent des faits métier, puis des décisions de section, puis des propositions de clauses bornées. Un professionnel révise, et le paquet sort en DOCX, PDF, HTML et JSON.
Capacités principales
- Traçabilité page à page : chaque observation renvoie à la preuve qui la fonde
- Isolation vérifiée entre les projets, pour qu’un dossier ne contamine pas le suivant
- Structure conforme à DDN, MasterFormat et SectionFormat
- Révision en DOCX, diffusion en PDF, HTML et JSON pour l’audit et le rejeu
- Périmètre cadré : immeubles locatifs multirésidentiels neufs, environ 6 à 60 logements
Limites annoncées
- Le contenu rédactionnel n’est pas au niveau : la génération autonome produit un petit nombre de clauses génériques par section
- Comparé à un devis historique réel : précision 0,667, rappel 0,013. Le rappel est le point bloquant, et il est publié tel quel
- Le dépôt porte un indicateur explicite « pas prêt pour un produit » — ce socle n’est pas livrable à un client
- Aucun prix, aucune marge, aucune soumission commerciale n’est produite, par conception
- La révision par un professionnel reste obligatoire à la sortie
Technologies
- Python 3.12, modèles de données Pydantic
- Chaîne documents → observations → faits → décisions → clauses → paquet
- Génération DOCX, PDF, HTML et JSON
- Intégration continue GitHub Actions
Statut
Socle technique vérifiable, pas un produit livrable. La structure, la traçabilité et l’isolation sont acquises et vérifiées; la qualité rédactionnelle ne l’est pas, et le dépôt le dit avant tout le reste.