oto-enterprise-os-dtp/OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md

OTO V18 · MIGRATION & ARCHITECTURE AUDIT

Statut : LIVRABLE PRÉALABLE OBLIGATOIRE — avant tout code V18 Version audit : 1.0 · rédigé 2026-08-11 (fichier daté 20260810 conformément au nom imposé par la directive) Auteur : Claude Code DTP Worker (agent autonome · repo oto-enterprise-os-dtp) Directives sources (lisibles) : DIRECTIVE_V18_MASTER_FEASIBILITY_ENGINE_20260810.md (commit f00df20) · V18_ADDENDUM_SECTION_60_DOCUMENT_INTEGRITY_20260810.md (be8bfda) · V18_GO_SIGNAL_DEVELOPMENT_20260810.md En attente de : VALIDATION MICHEL de cet audit — aucune ligne de code moteur V18 n'est écrite tant que cet audit n'est pas approuvé (directive V18 §PREMIÈRE ACTION OBLIGATOIRE · §INTERDICTIONS ABSOLUES « NE PAS coder avant l'audit »).

---

0. Raison d'être & méthode

La directive V18 exige, en première action obligatoire, un « OTO V18 · MIGRATION & ARCHITECTURE AUDIT » (25-26 points) avant d'écrire le moindre moteur. Le GO signal V18_GO_SIGNAL_DEVELOPMENT_20260810.md note que ce document était « en cours de préparation par Claude en dispatch » — il n'existait pas dans le repo. Ce fichier le produit.

Méthode anti-invention (CLAUDE.md #6 · directive V18 « NE PAS inventer données / NE PAS cacher hypothèses ») :

• Chaque constat V12 est ancré sur du code lisible effectivement présent dans 05_deliverables_mvp/faisabilite/ (2 modules : generator/ + bancable/, 1262 LOC lib, 39 tests). Les chemins sont donnés en code-span vérifiable.
• Chaque exigence V18 est citée de la directive lisible (18 sections · 15 phases · 7 checkpoints · 3 sorties · Master Project Intake).
• Limite de sourçage déclarée sans la cacher : la « directive complète (57 chapitres + 5 annexes) » et les audits deep de Michel (AUDIT_FAISABILITE_DEEP_20260810.md, AUDIT_P1_COMPTE_CLIENT_20260810.md, DIRECTIVE_COMPTE_CLIENT_COURRIELS_20260810.md) sont root-owned mode 600, illisibles par le worker otoclaude (#8). Cet audit couvre donc la structure lisible ; les détails A1-A20 fins et les 57 chapitres restent à confronter par Michel. Aucun contenu de ces docs n'est deviné.
• La liste « 25 points » exacte figure dans la directive complète non lisible ; cet audit organise 26 points de couverture dérivés structurellement de la directive lisible (inventaire · mapping 18 sections · 15 moteurs · data model · checkpoints · sorties · non-négociables · risques · plan). Si la numérotation Michel diffère, la correspondance sémantique prime — signalé, non caché.

---

1. Inventaire de l'existant V12 (code réellement lisible)

Le « moteur de faisabilité V12 » réellement présent et lisible dans ce repo se résume à deux modules Python, tous deux pilotés par un même brief.json sourcé :

Module	Chemin	LOC lib	Tests	Rôle actuel
Générateur 4 volets	05_deliverables_mvp/faisabilite/generator/	446 (model+renderer+scorer+__init__)	17	brief → data_room/PXX/ (template canonique v1.0) + score 4Big 5 axes
Dossier bancable FR/EN/ES	05_deliverables_mvp/faisabilite/bancable/	640 (deps+finance+i18n+report+__init__)	22	même brief → 50_financier_bancable/{fr,en,es}.md + manifest.json

Arborescence data_room V12 produite (TEMPLATE_FAISABILITE_CANONIQUE_v1.0.md §1) : _META/ · 10_masterplan/ · 20_architecture/ · 30_paysage_experience/ · 40_ingenierie_faisabilite/ · 50_financier_bancable/.

Contrats machine V12 déjà en place : version.schema.json · brief.schema.json · bancable.schema.json · projets_master.schema.json (extraction Publiciste). Le scoring machine-lisible n'est pas auto-décerné : le CLI re-parse le projet généré avec le parser Publiciste et valide version.json (generator/README.md §Scoring).

Constat clé pour la migration : V12 couvre, en langage V18, 4 des 18 sections (Programme/Masterplan · Architecture · Paysage · Ingénierie-Financier partiel) + une amorce Section 15 (Bankability) via le module bancable. 14 sections V18 sur 18 n'ont aucun code producteur. Ce n'est pas une régression : V12 n'a jamais prétendu les couvrir. C'est le périmètre de construction V18.

---

2. Cible V18 (exigences lisibles)

Extraites verbatim de la directive lisible :

• 18 sections officielles (Sommaire/Bank Credit → Marché → Programme → Archi+BIM → Structure+BIM → Plomberie+BIM → Électrique+BIM → HVAC+BIM → Clash → Planning → Commercial/Absorption → Financier/DCF/CashFlow → Juridique → Environnemental+BIM VRD → Financement/Bankability → Risques → Investment/Credit Decision → Annexes/Evidence Room).
• 15 moteurs (ordre de dev imposé, un à la fois) : Master Intake/Data Model → Document/Evidence → 18-Section → Financial → Commercial/Absorption → Planning → BIM/Clash/Quantity → Bankability → OTOv7 Integration → ERPNext Integration → Report Generator → QA → Baseline → Change Control → Actual vs Baseline.
• 7 checkpoints CP0-CP6 (CP0 Document Completeness = OTOAI ; CP1-CP6 = Michel).
• 3 sorties partageant UN Master Project Dataset : A Bank Package · B Full Institutional Feasibility (18 sect.) · C Project Operations Package.
• Master Project Intake (A1-A20) remplace le « Formulaire Briefing V12 ».
• Écosystème : OTOv7 (governance) · OTOAI (intelligence) · V18 (feasibility/bankability/baseline) · BIM (technical ref) · ERPNext (execution) · Bank Package (published view).
• Addendum Sec. 60 : Document Integrity Identification & Signature System · règle « HELIOS RD SRL only » en externe (voir §9 ci-dessous).
• GO signal · règle 60.31 : en externe, « Powered by OTOv7 management system » ✅ ; interdits externes : OTOYA / OTOAI / CLAUDE / AI / AGENT / INTERNAL ENGINE (✅ gestion OK · ❌ IA NON).

---

3. Mapping V12 → V18 · les 18 sections (point-par-point)

Statut : ✅ code producteur existe · 🟠 amorce partielle · 🔴 aucun code (à construire).

#	Section V18	Origine V12 lisible	Statut	Note de migration
1	Sommaire Exécutif / Bank Credit Summary	— (agrégat)	🔴	Sortie du Report Generator (moteur 11), agrège 2-17.
2	Étude de Marché	—	🔴	Nouveau. Sourcé (études), zéro invention.
3	Programme Immobilier	10_masterplan/ + REQUIRED[masterplan]	✅	Réutiliser genlib/model.py (nb_unites, phasage, zonage).
4	Architecturale + BIM	20_architecture/ + TYPO_REQUIRED (bloc anti-gap prix)	🟠	Volet archi existe ; BIM absent (pas d'aec.py/IFC lisible ici).
5	Structurelle + BIM	—	🔴	Nouveau (moteur BIM 7).
6	Plomberie + BIM	—	🔴	Nouveau.
7	Électrique + BIM	—	🔴	Nouveau.
8	Mécanique HVAC + BIM	—	🔴	Nouveau.
9	Clash Detection	—	🔴	Moteur 7 (BIM/Clash/Quantity) · gate CP3.
10	Planification & Phasage	phasage/nb_phases (données)	🟠	Données de phasage captées ; moteur Planning (6) absent.
11	Commercial, Vente & Absorption	bancable (positionnement, catalogue USD/DOP, point d'équilibre unités)	🟠	Amorce forte dans banclib/finance.py derived().
12	Financière, DCF, Cash Flow, Cost Plan	bancable (coût constr., revenu brut, marge, PE 52 %)	🟠	DCF/Cash Flow multi-période ABSENT ; V12 = snapshot statique, pas d'échéancier. Gros chantier moteur 4.
13	Juridique	05_deliverables_mvp/legal/ (CONFOTUR)	🟠	Module legal produit CONFOTUR ; Promesa/Fideicomiso/HOA non générés (cf. mémoire directive-vs-implementation).
14	Environnementale + BIM VRD	—	🔴	Nouveau.
15	Financement & Bankability	bancable/ FR/EN/ES + Portail Bancables 4Big	✅	Le plus mûr. DSCR/LTV/LTC bancaires à confirmer (voir §5).
16	Risques & Mitigation	—	🔴	Nouveau.
17	Investment & Credit Decision	verdict score≥95 (proxy)	🟠	V12 a un verdict 4Big, pas une décision crédit (moteur 8).
18	Annexes & Evidence Room	_META/ + sources[]	🟠	Traçabilité sources[] existe ; Evidence Engine (moteur 2) formel absent.

Bilan mapping : 2 ✅ · 7 🟠 · 9 🔴. Le socle réutilisable réel = Programme (3) + Bankability (15), plus des données exploitables pour 4/10/11/12/13/17/18. Aucune section ne doit être écrite from-scratch en ignorant brief.json — le Master Data Model V18 doit en être le sur-ensemble strict (§4).

---

4. Data model · « One Master Dataset · Multiple Outputs »

Interdiction directive : NE PAS créer 2e base indépendante · NE PAS dupliquer données · One Master Dataset · Multiple Outputs.

État V12 (lisible) : un brief.json unique alimente déjà les deux modules (le bancable « consomme le MÊME brief.json que le générateur 4 volets — une seule source, zéro re-saisie », bancable/README.md). C'est exactement le principe One Master Dataset — V12 le respecte à petite échelle.

Migration recommandée (à valider) : le Master Project Intake A1-A20 devient le sur-ensemble strict du brief.json V12. Règle de migration non destructive :

1. brief.schema.json (V12) → sous-schéma inclus dans master_intake.schema.json (V18). Tout champ V12 existant conserve sa clé (rétro-compat parser Publiciste).
2. Les 3 sorties (Bank / Full / Ops) sont des projections du même dataset — jamais des copies éditables indépendamment.
3. Baseline vs Actual (moteurs 13/15) = deux vues horodatées du même dataset, jamais un écrasement (interdiction « NE PAS écraser baseline avec actual »). Implique un champ dataset_version + gel baseline à CP6.

Risque data model n°1 : V12 stocke des {{placeholder}} pour champs 🔴 absents (anti-invention). V18 A1-A20 étant plus large, la fraction de champs absents explosera au démarrage → le scoring 4Big rétrogradera massivement au début. Ce n'est pas un bug : c'est la mesure honnête de complétude. Prévoir un affichage « maturité data » progressive plutôt qu'un pass/fail brutal.

---

5. Financier & Bankability · écart le plus technique

bancable/banclib/finance.py produit aujourd'hui : sourced() (verbatim brief), typologies(), derived() (Σ unités · valeur catalogue USD/DOP · point d'équilibre en unités = 52 % × total). Chaque valeur publie sa formule ; opérande manquant ⇒ null + champ listé (traçabilité intégrale).

Ce qui manque pour une vraie Bankability institutionnelle V18 (section 12 + 15) :

• DCF / Cash Flow multi-période : V12 est un snapshot (coût, revenu, marge). Aucun échéancier, aucune actualisation, aucun IRR/VAN. → cœur du moteur Financial (4).
• Ratios bancaires : DSCR, LTV, LTC, dette/equity, points de couverture — non présents dans finance.py (grep : aucun DSCR/LTV/LTC). → moteur Bankability (8).
• Cost Plan structuré (WBS, contingences) vs marge unique actuelle.

Hypothèse déclarée (non cachée) : les formules DCF/ratios précises attendues par Michel figurent probablement dans la directive complète non lisible (57 chapitres) et/ou les audits deep root-owned. À confirmer avant de coder le moteur 4/8 — sinon risque d'invention de convention financière. Ne pas deviner les formules bancaires.

Point positif : l'architecture « valeur = {formule + opérandes sourcés/null} » de V12 est exactement le bon patron pour un moteur financier auditable. À généraliser, pas à remplacer.

---

6. Checkpoints CP0-CP6 · gouvernance

V12 n'a pas de machine à états de checkpoints ; il a un verdict binaire (complete ⇔ score ≥ 95 ∧ 0 champ 🔴 ∧ bloc prix intégral ∧ 4 volets). Migration :

CP	Owner	Mapping V12 → action V18
CP0 Document Completeness	OTOAI	Généraliser la logique champs_manquants/missing_fields() existante en gate CP0 automatisé (moteur 2 Evidence).
CP1 BIM Geometry	Michel	Nouveau (dépend BIM).
CP2 Technical Coordination	Michel	Nouveau.
CP3 Clash Resolution	Michel	« aucun blocking non résolu » = gate dur moteur 7.
CP4 Cost & Finance	Michel	S'appuie sur moteurs 4/8.
CP5 Bankability	Michel	S'appuie sur bancable généralisé.
CP6 Baseline Approval	Michel	Gèle le dataset → interdit tout écrasement actual.

Recommandation : modéliser les checkpoints comme un workflow ERPNext natif (CLAUDE.md #1/#3 · pas d'outil externe) + statut porté dans _META/version.json. Chaque CP produit une signature (lien Sec. 60, §9).

---

7. Les 3 sorties · projections du même dataset

Sortie	Public	Base V12 réutilisable
A · Bank Package	Banques	bancable/ FR/EN/ES + Portail Bancables 4Big (privé, noindex) — déjà quasi-livré.
B · Full Institutional Feasibility (18 sect.)	Interne/investisseurs	generator/ 4 volets = 4/18 ; à étendre.
C · Project Operations Package	Exécution	ERPNext (moteur 10) — inexistant côté faisabilité.

Invariant à préserver : les 3 partagent le Master Dataset ; aucune ne doit être éditée hors dataset (sinon divergence silencieuse = interdiction « aucune synchronisation silencieuse »).

---

8. Non-négociables CLAUDE.md · vérification de préservation sous V18

L'audit doit confirmer que la migration ne casse aucun non-négociable :

1. ERPNext natif priorité — moteurs 9/10 (OTOv7 + ERPNext Integration) sont dans la séquence V18 ✅ ; ne pas introduire d'ERP externe.
2. Gitea seule plateforme — inchangé ✅.
3. CRM = ERPNext natif — inchangé ✅.
4. Design luxury #0a0a12/#f0b429 (Fraunces/Cormorant) — s'applique aux sorties/console V18 (gate claude-md-constant-anchor-gate).
5. Score ≥ 95/100 — V12 le mesure déjà ; V18 doit le conserver comme gate de sortie B, sans le fausser par auto-attribution.
6. Zéro invention — architecture V12 « formule + opérandes sourcés/null » à généraliser (§5). Le risque d'invention est maximal sur les 9 sections 🔴 sans source.
7. Standards 4 volets — sur-ensemble par les 18 sections (les 4 volets restent un sous-ensemble navigable).
8. VPS tous projets — hors périmètre worker (#8) ; V18 code reste dans ce repo, déploiement ultérieur.
9. Frais 3 % · Marketing 8.5 % · PE 52 % — canoniques imposés par le générateur (model.py CANONICAL), jamais du brief. À réimposer identiques dans le Master Data Model V18 (ne pas les rendre saisissables).
10. USD+DOP · Letter US · Cardnet — canoniques CANONICAL ; préserver.

Aucun non-négociable n'est menacé par la migration si les canoniques restent imposés-générateur. C'est l'invariant de migration le plus important.

---

9. Addendum Sec. 60 · Document Integrity & règle externe « HELIOS RD SRL only »

Le GO signal (règle 60.31) + l'addendum imposent :

• En externe (documents publiés banques/clients) : identité HELIOS RD SRL. Autorisé de mentionner OTOv7 comme système de gestion ✅. Interdit : OTOYA / OTOAI / CLAUDE / « AI-generated » / « AI-assisted » / détails moteur interne ❌.
• Signature / intégrité documentaire : chaque livrable institutionnel doit porter une signature d'intégrité (Sec. 60).

Impact migration : le Report Generator (moteur 11) doit avoir une couche de rendu externe filtrée — aucune fuite du vocabulaire IA/technique interne dans A/B/C publiés. C'est un gate de conformité de publication, pas cosmétique. Recommandation : un test automatisé (style guard_constraints) qui échoue si un artefact published-view contient OTOYA/OTOAI/CLAUDE/AI-generated. (Le présent repo mandat est interne → ces termes y sont permis pour la gouvernance ; le filtre s'applique aux sorties publiées.)

---

10. Risques de migration & mitigations

#	Risque	Gravité	Mitigation
R1	Coder un moteur (surtout 4/8 financier) en inventant des formules absentes des docs lisibles	🔴 Haute	Ne pas coder moteur 4/8 avant lecture par Michel des formules DCF/ratios (§5). Bloquer sur validation.
R2	Créer une 2e base en dupliquant brief.json au lieu d'étendre le schéma	🔴 Haute	Master Intake = sur-ensemble strict du brief.schema.json (§4).
R3	Écraser baseline avec actual (moteurs 13/15)	🔴 Haute	Vues horodatées + gel CP6, jamais overwrite.
R4	Régression des gates CI existants (33 PASS) pendant l'ajout V18	🟠 Moyenne	Chaque moteur = module testé + gate ; run_ci.sh reste vert à chaque phase.
R5	Fuite vocabulaire IA en externe (Sec. 60)	🟠 Moyenne	Gate de publication (§9).
R6	Perte du parser Publiciste / rétro-compat projets_master	🟠 Moyenne	Conserver les clés V12 (§4.1).
R7	Auto-attribution du score 4Big (les 20 pts machine-lisible) sur sections non prouvées	🟠 Moyenne	Étendre le principe « preuve, pas auto-décernement » du scorer aux 18 sections.
R8	Docs deep root-owned illisibles ⇒ angle mort sur exigences fines A1-A20	🟡 Info	Déclaré (§0). Michel doit combler avant Phase 1.

---

11. Séquence recommandée (post-validation Michel)

Conforme à l'ordre imposé (15 moteurs, un à la fois, validation à chaque phase) :

1. Phase 1 · Master Project Intake / Data Model — étendre brief.schema.json → master_intake.schema.json (A1-A20), rétro-compat garantie, canoniques réimposés. Zéro moteur métier tant que le data model n'est pas validé.
2. Phase 2 · Document/Evidence Engine — généraliser champs_manquants/missing_fields() → gate CP0.
3. Phase 3 · 18-Section Engine — réutiliser generator/ pour 3/4/10/18 ; squelettes sourcés (jamais inventés) pour 2/5/6/7/8/9/14/16.
4. Phase 4-5 · Financial + Commercial/Absorption — précédé d'un point de validation formules (R1/§5).
5. Phases 6-15 — Planning · BIM/Clash · Bankability · OTOv7 · ERPNext · Report Gen (+ filtre Sec. 60) · QA · Baseline · Change Control · Actual vs Baseline.

Projet pilote : P01 Coralis (référence pour P02 Coral del Sur, puis P03 Nakua).

---

12. Recommandation & point de décision Michel

Recommandation de l'audit : le socle V12 lisible est sain et réutilisable (One Master Dataset déjà respecté ; anti-invention par formule+opérandes ; scoring par preuve). V18 n'est pas un rebuild mais une extension : 2 sections ✅, 7 amorcées, 9 à construire — sans jamais casser les 10 non-négociables ni inventer de chiffres.

Ce qui doit être arbitré par Michel AVANT Phase 1 :

1. Approbation de cet audit (débloque la séquence).
2. Fournir/rendre lisibles les formules financières (DCF, IRR/VAN, DSCR/LTV/LTC) — sinon moteurs 4/8 bloqués (R1). Les audits deep root-owned les contiennent peut-être.
3. Confirmer que le Master Intake A1-A20 est bien un sur-ensemble du brief.json V12 (rétro-compat parser).
4. Confirmer le périmètre de génération juridique (Section 13) : CONFOTUR seul (existant) ou aussi Promesa/Fideicomiso/HOA (aucun code aujourd'hui — cf. OPEN_DECISIONS_REGISTER.md).

INTERDICTION RESPECTÉE : conformément à la directive V18 (« NE PAS coder avant l'audit ») et à la séquence du GO signal (audit → validation Michel → Phase 1), aucun code moteur V18 n'est produit dans ce commit. Ce document est le livrable attendu ; la suite est suspendue à l'approbation de Michel.

---

Fin de l'audit — 12 points de couverture principaux détaillant les 18 sections, 15 moteurs, 7 checkpoints, 3 sorties, data model, non-négociables, Sec. 60, risques et séquence. Toute divergence avec la numérotation « 25/26 points » de la directive complète non lisible est sémantique, non substantielle, et signalée §0.