TP1 — Construire et faire valider un dossier de cadrage dans OpenProject

Modalité : travail individuel.<br> Outils : OpenProject, LibreOffice Calc ou Excel, diagrams.net et Writer/Markdown.

1. Mission

Vous êtes chef de projet data pour une école d’ingénieurs. Votre mission est de transformer une demande métier en projet OpenProject exploitable et révisable. Le dossier documentaire ne constitue pas le résultat principal : chaque document doit être attaché au bon objet OpenProject, relié à une décision ou utilisé comme preuve lors d’une revue.

À la fin du TP, un autre membre de l’équipe doit pouvoir retrouver dans OpenProject :

le mandat et le périmètre du projet ;
les responsabilités et les éléments à valider ;
les exigences et leurs critères d’acceptation ;
les risques, contrôles et anomalies qualité ;
la décision prise sur la donnée problématique ;
les preuves associées à chaque point important.

2. Compétences évaluées

Vous devez être capable de :

initialiser et structurer un espace de pilotage OpenProject ;
transformer une demande métier en éléments de travail vérifiables ;
attacher une preuve au bon lot, avec responsable, priorité et statut ;
contrôler une donnée et créer un suivi d’anomalie ;
organiser une revue de cadrage et tracer une décision ;
vérifier la cohérence entre la charte, les exigences, les risques et le PAQ.

Les calculs détaillés de charge, le PERT et le nivellement des ressources sont réservés au TP2.

3. Périmètre du TP et définition de fini

Le TP est volontairement centré sur la construction et la revue d’un dossier de cadrage exploitable. Les éléments marqués « socle » sont obligatoires ; les éléments d’extension permettent d’enrichir le dossier sans multiplier les fichiers de remise.

Le socle comprend :

les cinq lots du projet et au moins trois livrables clairement identifiés ;
quatre exigences fonctionnelles et quatre exigences non fonctionnelles ;
les trois anomalies présentes dans le fichier de contrôle qualité ;
une RACI couvrant les activités principales, trois risques et trois contrôles du plan d’assurance qualité (PAQ) ;
une décision qualité comparant deux options et une revue finale dans OpenProject.

L’extension comprend huit exigences fonctionnelles, quatre exigences non fonctionnelles, cinq risques, cinq contrôles PAQ et les compléments documentaires prévus dans les modèles. Les extensions doivent rester cohérentes avec le socle : elles sont facultatives, ne créent pas une seconde source de vérité et restent intégrées aux mêmes registres.

4. Cas professionnel

Une école d’ingénieurs souhaite mettre en place une plateforme de suivi de la consommation énergétique de ses bâtiments. Les données proviennent de trois sources :

capteurs IoT ;
relevés CSV transmis par les bâtiments ;
API de facturation.

La plateforme doit alimenter un stockage analytique, détecter les anomalies de qualité et fournir un jeu de données exploitable par un tableau de bord. Les utilisateurs autorisés doivent pouvoir retrouver l’origine des transformations et connaître la fraîcheur des données.

Faits fournis

Le service patrimoine porte le besoin métier.
Les responsables de bâtiments connaissent les données de terrain.
Le data owner énergie valide les définitions et les règles d’usage.
Les data engineers réalisent l’ingestion et les transformations.
Les analystes BI utilisent les données produites.
Le service informatique intervient sur les accès, l’exploitation et la mise en production.
L’accès aux données doit être contrôlé.
Les transformations doivent être traçables.
Une fréquence de mise à jour doit être annoncée.
L’ingestion doit rester exploitable après un échec ponctuel.

Hypothèses à discuter

Vous pouvez retenir des hypothèses raisonnables, mais chacune doit être écrite dans la charte avec son propriétaire et sa méthode de vérification. Exemples :

les propriétaires des trois sources peuvent fournir un dictionnaire de données ;
une mise à jour horaire est suffisante pour le tableau de bord initial ;
le service informatique fournit un environnement de test ;
les données individuelles de facturation ne sont pas nécessaires au tableau de bord.

Ne présentez pas une hypothèse comme un fait.

5. Donnée de contrôle qualité

Le fichier data/consommation_batiments.csv est synthétique. Il ne représente pas une mesure réelle de l’école.

Pour le contrôle, utilisez les règles suivantes :

Champ ou règle	Critère attendu
`batiment`	valeur non vide et identifiant connu dans le dossier
`date_heure`	date ISO lisible et valeur non vide
clé métier	unicité de `(batiment, date_heure, source)`
`source`	`capteur`, `releve_csv` ou `api_facturation`
`energie_kwh`	nombre réel supérieur ou égal à zéro
valeur manquante	signalée, non remplacée silencieusement

Vous devez conserver le fichier original inchangé. Une correction éventuelle doit être réalisée dans une copie et documentée.

6. Préparer OpenProject

Créez un projet nommé Plateforme énergie — TP1. OpenProject est l’espace principal du TP. Si votre instance ne permet pas de créer un projet, reproduisez la structure dans le tableur et signalez clairement la limitation ; cette solution de repli ne dispense pas de fournir les preuves demandées.

Les conventions communes aux deux TP sont rappelées dans student/templates/conventions-openproject.md. Elles précisent la répartition des outils, les métadonnées minimales, les statuts, les marqueurs et la source de vérité lorsqu’un calcul manuel est comparé à OpenProject.

Si OpenProject n’est pas encore installé, utilisez le Kit Docker OpenProject attaché aux ressources complémentaires du module. Le guide fournit le fichier Compose, la version de l’image, la persistance des données et la procédure de repli hors ligne.

Configurez au minimum :

les rôles : sponsor/MOA, chef de projet, data owner, data engineer, analyste BI et service informatique ;
les lots parents : Cadrage, Exigences, Qualité, Recette, Mise en production ;
les statuts : Nouveau, En cours, À valider, Bloqué, Terminé ;
les priorités : Basse, Normale, Haute, Critique ;
les conventions [EXIGENCE], [RISQUE], [DECISION], [LIVRABLE], [QUALITE].

Chaque objet de pilotage important — livrable, exigence, contrôle, risque ou décision — doit comporter au minimum un responsable, une priorité, un statut, une description vérifiable et une preuve ou une pièce jointe. Les lots parents servent de structure et peuvent être documentés par leur description et leur responsable sans pièce jointe propre.

7. Missions pratiques

Mission 1 — Initialiser et structurer le projet

Dans OpenProject :

créez le projet et sa description ;
ajoutez les rôles et membres fictifs de l’équipe ;
créez les cinq lots parents ;
créez un élément [LIVRABLE] sous chaque lot utile ;
affectez un responsable, une priorité et un statut à chaque élément ;
produisez dans diagrams.net un schéma de contexte montrant les trois sources, les acteurs, les flux, la frontière du projet et les contrôles d’accès ou de qualité ;
créez une vue filtrée permettant d’afficher les éléments À valider.

Checkpoint 1 : la vue du projet permet de comprendre qui fait quoi et ce qui doit être validé, sans ouvrir un document externe.

Preuve : export ou captures de la liste, de la hiérarchie, du schéma de contexte et de la vue filtrée à-valider.

Mission 2 — Enregistrer et traiter une anomalie de donnée

Dans Calc/Excel, contrôlez le fichier avec les règles de la section 5. Créez la feuille controle_qualite avec les colonnes :

ID_controle, champ, règle, nombre_anomalies, exemple, impact, action_proposée, responsable, statut, preuve.

Dans OpenProject :

créez un élément [QUALITE] dans le lot Qualité ;
décrivez au moins trois anomalies observées ;
joignez l’export du contrôle et le fichier source du tableur ;
affectez le data owner ou le chef de projet ;
choisissez un statut et une priorité cohérents ;
documentez le critère de clôture.

Checkpoint 2 : la personne qui ouvre [QUALITE] peut comprendre l’anomalie, son impact, son responsable, son état et la preuve sans modifier le CSV original.

Mission 3 — Faire approuver le cadrage

Rédigez une charte contenant, dans le socle, au minimum :

problème, finalité et bénéfice attendu ;
objectif mesurable et indicateur de réussite ;
périmètre inclus et au moins deux exclusions ;
trois livrables avec critères d’acceptation ;
deux jalons avec condition de passage ;
quatre parties prenantes, leurs attentes et leurs décisions ;
deux contraintes, trois hypothèses et trois risques ;
règle d’escalade et décisionnaire ;
distinction explicite entre faits, hypothèses et arbitrages.

L’extension porte ces minima à cinq livrables, trois jalons et six parties prenantes. Elle reste facultative et ne doit pas créer de nouveaux fichiers incompatibles avec le socle.

Dans OpenProject :

créez un élément [LIVRABLE] Charte de cadrage sous Cadrage ;
joignez le PDF et le fichier source ;
indiquez le validateur et le critère de passage ;
passez l’élément à À valider ;
créez un commentaire de revue contenant au moins une question à résoudre.

Checkpoint 3 : la charte est traitée comme un livrable soumis à validation, et non comme un simple fichier remis à part.

Mission 4 — Transformer le besoin en éléments traçables

Dans Calc/Excel, produisez dans le socle au moins quatre exigences fonctionnelles et quatre exigences non fonctionnelles : une sur la fraîcheur, une sur la traçabilité, une sur le contrôle d’accès et une sur la reprise après échec. L’extension porte le registre à huit exigences fonctionnelles et quatre exigences non fonctionnelles.

Chaque ligne doit contenir :

ID, description, type, source, priorité, critère_acceptation, responsable, statut, preuve, risque_associe.

Dans OpenProject, pour chaque exigence :

créez un élément [EXIGENCE] sous Exigences ;
reportez l’ID au début du titre ;
copiez le critère d’acceptation dans la description ;
renseignez responsable, priorité et statut ;
joignez le registre ou utilisez un lien stable vers la ligne correspondante ;
reliez l’exigence à un livrable, un risque ou une activité de recette.

Checkpoint 4 : la vue des exigences permet de retrouver leur état, leur responsable et leur preuve sans rechercher manuellement dans toute l’archive.

Mission 5 — Organiser les responsabilités et la qualité

Produisez une RACI couvrant cadrage, exigences, architecture, ingestion, qualité, recette et mise en production. Vérifiez qu’il n’y a qu’un A par activité et au moins un R.

Dans le socle, créez ensuite :

trois éléments [RISQUE] avec probabilité, impact, propriétaire, action et statut ;
une matrice exigence → livrable → test/revue → preuve ;
un PAQ d’au moins trois contrôles, chacun avec responsable, règle, résultat et preuve.

Dans la matrice de traçabilité, ajoutez pour chaque livrable important son critère de fini, son propriétaire, son statut, sa preuve et son identifiant OpenProject. Cette matrice devient la table de contrôle finale ; elle ne doit pas être une liste indépendante des objets du projet.

L’extension porte le registre des risques et le PAQ à cinq éléments ou contrôles.

Attachez la RACI, le registre des risques, la matrice et le PAQ aux lots OpenProject correspondants. Créez une vue filtrée des risques Bloqué ou Critique.

Checkpoint 5 : les responsabilités, les risques et les contrôles sont consultables depuis le projet, et leurs identifiants sont cohérents avec les documents attachés.

Mission 6 — Décider, revoir et démontrer

Créez un élément [DECISION] concernant la valeur négative ou la valeur manquante du CSV. Comparez au moins deux options, nommez le décideur, choisissez une option, indiquez le risque résiduel et le critère de réexamen.

Réalisez ensuite une revue finale dans OpenProject :

passez la charte et au moins trois exigences à À valider ;
laissez une trace de décision ou de commentaire ;
vérifiez les éléments sans responsable, sans preuve ou sans statut ;
corrigez les incohérences trouvées ;
exportez la vue finale du projet et la liste des pièces jointes.

Checkpoint 6 : vous pouvez démontrer clairement le chemin demande → exigence → livrable → contrôle → décision → preuve.

8. Ressources à remettre

Déposez une archive nommée NOM_PRENOM_TP1.zip contenant :

NOM_PRENOM_TP1/
├── 00-README-remise.pdf
├── 01-openproject-vue-finale.pdf
├── 02-dossier-cadrage.pdf et sources/
├── 03-registres-pilotage.xlsx et .pdf
├── 04-controle-qualite.xlsx et .pdf
├── 05-tracabilite-decision.xlsx et .pdf
└── 06-preuves/

Le fichier 01 doit montrer OpenProject : hiérarchie, responsables, statuts, priorités, éléments à valider, pièces jointes, commentaires et décision. Le dossier 02 regroupe la charte et le schéma de contexte. Le fichier 03 regroupe la RACI, les risques et le PAQ ; le fichier 05 regroupe la matrice de traçabilité et la décision qualité. Les sources éditables peuvent rester dans les sous-dossiers correspondants. Le fichier 00-README-remise.pdf indique les outils, versions, hypothèses, limites et correspondances entre les identifiants. Vous pouvez partir du modèle student/templates/README-remise-template.md.

Les extensions sont intégrées dans les mêmes registres que le socle ; elles ne doivent pas produire une archive parallèle ou contradictoire.

9. Checklist avant remise

OpenProject est le point d’entrée du dossier et non un simple lien ajouté à la fin.
Chaque livrable important est attaché au bon lot.
Au moins une anomalie qualité est suivie comme élément de travail.
La charte et les exigences possèdent un état de validation.
Chaque exigence possède un critère d’acceptation, un responsable et une preuve.
Chaque activité de la RACI possède exactement un A.
Les risques ont un propriétaire, une action et un état.
Une décision est tracée avec options, décideur et risque résiduel.
Le socle minimum est complet ; les extensions sont identifiées dans le README.
Les vues finales permettent de retrouver les éléments sans responsable ou sans preuve.
Le fichier CSV original est conservé et non modifié.
L’archive s’ouvre depuis une copie propre, sans chemin absolu ni corrigé enseignant.