aziz/siop2
1
0
Fork 0
mirror of https://github.com/siop-spelev/siop2.git synced 2026-08-08 12:41:54 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
be5dfb6bc7195df30487b18bdea3c196f0781d78
siop2/docs/00-vision/charte-projet.md
pr-daaif 04e61056f6 docs(r0): kickoff SIOP V2 — vision, cadrage, charte graphique, maquettes HD 
Refondation design-first du projet SIOP (v1 gelée) :
- Playbook 00-vision (charte projet, personas, benchmark Atlas)
- Playbook 01-cadrage (releases R0→R5 + DoD, user-story map, exigences, risques)
- Playbook 02-design : charte graphique, tokens.css bi-thème (palettes
  analytics validées CVD/contraste par script), maquettes HD navigables
  (7 écrans dont démo-login DEMO_MODE, bilan codé, portail QR, mobile)

Prochaine étape : validation des maquettes par le référent avant tout code.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-15 21:06:33 +01:00

3.8 KiB
Raw Blame History

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.