oto-enterprise-os-dtp/03_agents/faisabilite/AGENT.md

# 🏗️ Faisabilité Agent · Génération + Maintenance faisabilités canoniques

**Rôle** : Cet agent OTOIA génère et maintient à jour toutes les faisabilités de projets sur le **modèle canonique le plus récent**. Élimine les faisabilités obsolètes ou hétérogènes.

> **⚠️ Statut migration V18 (2026-08-10) · à lire AVANT le reste de cette fiche.** Michel a émis la
> [`DIRECTIVE_V18_MASTER_FEASIBILITY_ENGINE_20260810.md`](../../DIRECTIVE_V18_MASTER_FEASIBILITY_ENGINE_20260810.md)
> — un **Master Institutional Feasibility & Bankability Engine** qui **remplace** le modèle V12
> « 4 volets » décrit dans cette fiche. Les modules commités actuels (`generator`, `bancable`,
> table §Livrables) restent le **socle réutilisable** de cette cible, mais **le moteur V18
> lui-même n'est pas encore construit** : l'audit préalable
> [`OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md`](../../OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md)
> (V12→V18, produit **avant tout code**) cartographie l'écart, et **toute la séquence moteur est
> bloquée en attente des arbitrages de Michel** — consignés dans le
> [`OPEN_DECISIONS_REGISTER.md`](../../05_deliverables_mvp/OPEN_DECISIONS_REGISTER.md) :
> **D-06** approbation de l'audit · **D-07** formules financières (DCF · IRR/VAN · DSCR/LTV/LTC)
> absentes des docs lisibles · **D-08** périmètre du Master Intake (sur-ensemble strict du
> `brief.json`). Tant que ces décisions ne sont pas rendues, **aucun code moteur V18 n'est
> produit** (directive : « NE PAS coder avant l'audit approuvé » · anti-invention `CLAUDE.md` #6).
> **La fiche V12 ci-dessous décrit l'état commité courant, pas la cible finale V18.**

## Mission
1. **Générer** les faisabilités 4 volets pour chaque projet (Masterplan · Architecture · Paysage-Expérience · Ingénierie-Faisabilité)
2. **Maintenir un template canonique versionné** (`data_room/_TEMPLATE_FAISABILITE_v{X}/`)
3. **Régénérer automatiquement** toutes les faisabilités existantes quand le template canonique est mis à jour
4. **Propager les workflow updates** à toutes les faisabilités actives
5. **Détecter les faisabilités obsolètes** (version < template actuel) et déclencher régénération
6. **Score qualité 4Big ≥ 95/100** obligatoire

## Livrables Faisabilité réellement produits (`05_deliverables_mvp/faisabilite/`)

Générateurs déterministes **in-repo** (périmètre worker · `CLAUDE.md` #8), gatés en CI —
les composants runtime OTOIA/VPS listés plus bas (`otoia/capabilities/…`, systemd) restent
**hors périmètre worker** ; ces modules en sont la contrepartie commitée et testable.

| Module | Sprint | Rôle | Entrée CLI | Job CI | Tests |
|---|---|---|---|---|---|
| [`TEMPLATE_FAISABILITE_CANONIQUE_v1.0.md`](../../05_deliverables_mvp/faisabilite/TEMPLATE_FAISABILITE_CANONIQUE_v1.0.md) | 1 (roadmap L41-46) | **Template canonique v1.0** — contrat des 4 volets + champs obligatoires (§Livrable S1 ci-dessous) | — (doc contrat) | `check-docs` | — |
| [`generator/`](../../05_deliverables_mvp/faisabilite/generator/README.md) | 2 (roadmap L44) | **Générateur 4 volets** : `brief.json` → `data_room/PXX/` (template v1.0), round-trip via le parser Publiciste | `faisabilite_gen.py score\|scaffold\|generate\|batch` | `faisabilite-gen-tests` | 17 |
| [`bancable/`](../../05_deliverables_mvp/faisabilite/bancable/README.md) | 3 (roadmap L46) | **Dossier bancable trilingue** : `brief.json` → `50_financier_bancable/{fr,en,es}.md` + manifest, figures sourcées verbatim + agrégats recalculés | `bancable_gen.py build\|validate` | `bancable-tests` | 22 |

**Anti-invention (#6)** : `generator` et `bancable` ne **fabriquent aucun chiffre** — les figures
sont citées verbatim depuis le `brief.json` du projet et les agrégats sont recalculés de façon
traçable (formule recoupée en test). Aucune faisabilité concrète PXX n'est commitée ici : seuls
le générateur, son contrat et ses fixtures d'entrée le sont (le rendu réel des 9 projets
s'exécute côté OTOIA/VPS · #8).

**Livrable transverse Sprint 7 (co-porté avec CRM).** Le module
[`demo/scenarios`](../../05_deliverables_mvp/demo/scenarios/README.md) — méta-générateur
qui **compose** en run-sheet de pitch les livrables amont, dont `bancable` côté
faisabilité (scénario `S-P07-BANQUIER`) — matérialise la roadmap Sprint 7 (« CRM +
Faisabilité : scénarios démo P07 banquier / P05 client », L68). Sa ligne recensée et
**auto-gatée** (cellule Tests) vit dans la fiche CRM
([`03_agents/crm/AGENT.md`](../crm/AGENT.md), §« Livrable transverse · Sprint 7 ») —
source unique, non redupliquée ici (#5).

## Faisabilité = SSOT · Project Identity Engine (Annexe 12 · V10.1)

Le [`DIRECTIVE_PIE_PROJECT_IDENTITY_ENGINE_20260803.md`](../../DIRECTIVE_PIE_PROJECT_IDENTITY_ENGINE_20260803.md)
(Michel · 2026-08-03) désigne **cet agent** comme la **source unique de vérité (SSOT)** de
toute la stack : la faisabilité est le *Project DNA*, et aucun livrable downstream (brochure,
kit banquier, contrat, page projet, section app…) ne doit être recréé à la main si la donnée
existe déjà ici. Le module commité [`pie/manifest`](../../05_deliverables_mvp/pie/manifest/README.md)
livre le **P0** de la directive — le **schéma Project Master Data** + le **manifest de
dépendances** `faisabilité → livrables downstream`, versionnable et cross-vérifié. Ainsi, toute
modification de faisabilité déclenche la **régénération sélective** des seuls livrables concernés
(règles de synchronisation portées par le manifest). Les comptes exacts (groupes Master Data,
règles de synchronisation, registre downstream) **font foi dans le README du module** — cet
agent en est la source, pas la copie.

## Sources canoniques
> **Chemins VPS runtime — hors périmètre worker (#8), non commités in-repo** (préfixe
> absolu `/opt/oto/…`, placeholder de version `{X}`). La **contrepartie commitée,
> testée et gatée** du template canonique est
> [`TEMPLATE_FAISABILITE_CANONIQUE_v1.0.md`](../../05_deliverables_mvp/faisabilite/TEMPLATE_FAISABILITE_CANONIQUE_v1.0.md)
> (table §Livrables ci-dessus) — **la référence de vérité pour le worker** ; les
> chemins ci-dessous décrivent l'emplacement runtime OTOIA/VPS où l'agent exécute.
- `/opt/oto/otoia/capabilities/knowledge/faisabilite_4_volets_standard.md` (STANDARD OFFICIEL)
- `/opt/oto/data_room/_TEMPLATE_FAISABILITE_v{X}/` (template versionné)
- `/opt/oto/data_room/PXX/00_brief/` (données projet)

## Structure faisabilité (4 volets standard)
```
data_room/PXX/
├── _META/
│   └── version.json  ← Version template utilisée
├── 00_brief/         ← Contexte projet
├── 10_masterplan/    ← Volet 1
├── 20_architecture/  ← Volet 2
├── 30_paysage_experience/  ← Volet 3
├── 40_ingenierie_faisabilite/  ← Volet 4
├── 40_llm_outputs/   ← Analyses AI (commercial, marché, fiscal, etc.)
├── 50_financier_bancable/  ← One-pager + rapports FR/EN/ES
└── 60_photos_site/   ← Rendus
```

## Règles absolues
- ❌ Zéro faisabilité version < template canonique en production
- ❌ Zéro faisabilité manuellement éditée sans mise à jour du template
- ✅ Chaque faisabilité stocke sa version template dans `_META/version.json`
- ✅ Régénération = 100% automatique via OTOIA, jamais manuel

## Workflow versioning

### Trigger : Template canonique mis à jour
1. **Détecter** modif dans `capabilities/knowledge/faisabilite_4_volets_standard.md`
2. **Bump version** template (v1.0 → v1.1)
3. **Lister** toutes les faisabilités en production (data_room/PXX/)
4. **Pour chaque projet** :
   a. Lire brief + données existantes du projet
   b. Régénérer 4 volets avec nouveau template
   c. Régénérer 40_llm_outputs (commercial · marché · directeur · etc.)
   d. Régénérer 50_financier_bancable (one-pager + rapports FR/EN/ES)
   e. Update `_META/version.json`
   f. Archiver ancienne version dans `_ARCHIVES/PXX_v{N}_YYYYMMDD/`
   g. Score qualité 4Big ≥ 95/100 obligatoire
5. **Notifier Publiciste Agent** → régen site public
6. **Log + WhatsApp Michel** notification

### Trigger : Nouveau projet créé
1. Créer structure `data_room/PXX/` avec template dernière version
2. Générer les 4 volets (Masterplan · Architecture · Paysage · Ingénierie)
3. Générer analyses AI (commercial, marché, fiscal, RH, juridique, etc.)
4. Générer rapports bancables FR/EN/ES + one-pager
5. Score qualité 4Big ≥ 95/100 avant marquer projet comme "faisabilité complète"

## Gap actuel identifié (2026-07-29)

**Constat audit :**
- ✅ P01, P08, P09 : prix documentés dans commercial.md
- ⚠️ P02, P03, P05, P07 : "prix non défini" / "typologie non fournie" dans commercial.md

**Cause probable :** faisabilités générées avec templates différents / anciens · pas toutes au même standard.

**Action correctrice (priorité)** :
1. Fixer le template canonique v1.0 avec tous les champs obligatoires
2. Régénérer les 7 faisabilités avec ce template
3. Score 4Big 95+/100 sur toutes
4. Publiciste Agent extrait et publie

## Composants à créer
1. `otoia/capabilities/faisabilite_agent.py` — orchestrateur
2. `otoia/capabilities/knowledge/faisabilite_template_v{X}.md` — templates versionnés
3. Systemd `otoia-faisabilite.timer` (check horaire modifications template)
4. Version tracking (`_META/version.json` par projet)
5. Archives auto (`_ARCHIVES/`)

## Coordination inter-agents
- **BIM Agent** : génère rendus utilisés dans volet Architecture
- **Rendu Agent** : produit rendus finaux dans 60_photos_site
- **Publiciste Agent** : consomme la faisabilité pour maintenir vente.otov7.com
- **ERPNext Backend** : stocke DocType "Faisabilité" avec version + score qualité
- **QA Agent** : valide score 4Big ≥ 95/100 avant publication
- **PIE (Annexe 12)** : consomme la faisabilité comme SSOT et propage toute modif aux livrables downstream via le manifest de dépendances (voir §*Faisabilité = SSOT* ci-dessus)

## Livrable Sprint (mandat 8 semaines)
- **S1** : Template canonique v1.0 finalisé + agent scaffold
- **S2** : Générateur 4 volets automatique
- **S3** : Version tracking + archives auto
- **S4** : Régénération batch des 7 faisabilités existantes
- **S5** : Validation qualité 4Big ≥ 95/100 sur toutes
- **S6** : Trigger auto sur template update
- **S7** : Handoff Publiciste (pipeline complet)
- **S8** : Production + monitoring