# Charte projet — SIOP V2

> **Rôle de ce document (playbook)** : la charte projet est le contrat fondateur. Une page
> suffit pour dire *pourquoi* le projet existe, *ce qu'est* le succès et *qui* décide.
> Tout ce qui suit dans le playbook en découle. À rédiger AVANT toute conception.

## 1. Vision

Remplacer le carnet d'intervention papier des ascensoristes par une **GMAO complète et
belle**, pensée pour le métier de la maintenance d'ascenseurs — du signalement d'une panne
par un gardien d'immeuble jusqu'au PV signé par le client, en passant par le préventif
réglementaire et l'assistance IA au technicien.

## 2. Problème

- Le suivi des interventions se fait sur **carnet papier** (perte, illisibilité, aucune analyse).
- Les **périodicités réglementaires** (contrôles mensuels → annuels) sont suivies à la main.
- Le bureau ne sait pas **où en sont les techniciens** ni quels équipements coûtent cher.
- Les GMAO génériques du marché ignorent les spécificités ascenseur (organes, carnet codé,
  PV contradictoire, urgence « personne bloquée »).

## 3. Objectifs jumeaux

| # | Objectif | Mesure de succès |
| --- | --- | --- |
| A | **Produit** : GMAO ascenseurs complète (web + mobile + IA), clone adapté d'Atlas CMMS | Déployée en production (Dokploy), utilisée sur un parc réel de démonstration, releases R0→R5 recettées |
| B | **Playbook** : documentation pédagogique de toutes les phases du cycle de vie | Un étudiant peut refaire chaque phase avec le seul playbook ; le référent l'utilise comme base de sa future entreprise de digitalisation |

## 4. Parties prenantes

| Rôle | Qui | Responsabilité |
| --- | --- | --- |
| Commanditaire & référent métier | Pr. Daaif (ENSET) | Décisions produit, validation des recettes et des maquettes |
| Entreprise partenaire | SPELEV (maintenance d'ascenseurs) | Réalité métier : carnet, périodicités, organisation |
| Équipe de réalisation | Pr. Daaif + assistant IA (puis étudiants ENSET) | Conception, développement, tests, docs |
| Hébergeur | Serveur d'un partenaire (PaaS Dokploy) | Production |
| Bénéficiaires pédagogiques | Étudiants ENSET | Apprennent sur le playbook et contribuent |

## 5. Périmètre (v1 du produit = releases R0 → R5)

**Inclus** : référentiel (sites, ascenseurs, organes, QR), personnes & permissions, ordres
de travail avec bilan codé, portail de demandes, maintenance préventive à périodicité,
compteurs, stock & achats, tiers, coûts (pièces + main-d'œuvre), analytics, bibliothèque de
fichiers, app mobile technicien offline (scan QR, checklist, synchro), IA (assistant RAG,
bilan assisté). Détail par release : `../01-cadrage/releases.md`.

**Exclus (v1)** : facturation client, multi-tenant SaaS, agent vocal temps réel et
affectation géospatiale automatique (étudiés en fin de R5 si le budget temps le permet).

## 6. Contraintes

- **Design-first** : maquettes validées avant le code (leçon de la v1).
- **Langue** : produit et docs en français ; code en anglais.
- **Réglementaire** : loi marocaine 09-08 (données personnelles, géolocalisation, audio).
- **Hébergement** : PaaS auto-hébergé (Dokploy) sur le serveur du partenaire.
- **Équipe réduite** : 1 encadrant + IA, étudiants à intégrer → conventions strictes, CI bloquante.

## 7. Risques majeurs (détail : `../01-cadrage/risques.md`)

Dérive de périmètre (mitigation : releases fermées) ; dette design (mitigation : revue pixel
par release) ; dépendance au serveur partenaire (mitigation : tout est Docker, portable).

## 8. Gouvernance

Le référent tranche toute décision produit (sollicité explicitement à chaque bifurcation).
Les décisions techniques sont consignées en ADR (`../03-architecture/adr/`). Une release se
clôt par : recette formelle signée + déploiement + chapitre de playbook relu.