# EC02 · Management de projet : rapport collectif

**Groupe 3 (HEADL_015B) · Projet EnerVision.**

| | |
|---|---|
| **Fichier source** | `EADL26_EC02 - Rapport Collectif HEADL_015B-G3.md`, encodage UTF-8, aucun média externe |
| **Version figée** | `EADL26_EC02 - Rapport Collectif HEADL_015B-G3.pdf`, produite par la chaîne Markdown → HTML → CSS de pagination → PDF |
| **Dépôt** | Devoir Teams, à côté du ZIP du dépôt Git, **et** dans le dépôt Git lui-même (`docs/livrables/EC02/`) |
| **Échéance** | Vendredi 25/09/2026, 9h00 (gel technique) |
| **Relevé** | **24/09/2026 à 14h25**, sur le commit gelé `9f343e9` (`dev` = `main`) et par l'API GitHub : dépôt, tracker, board, jalons, PR et revues relevés au même instant, heures en heure locale (CEST) |

Chaque chiffre de ce rapport est reproductible par une commande citée en fin de document : le
critère officiel est un compte rendu d'activité « complet et **honnête** ». Les chiffres du
rapport du 23/09 (board du 18/09, tracker du 21/09) sont remplacés, pas complétés.

---

## 1. Organisation de l'équipe

Le pilotage passe par un **GitHub Project** (« EnerVision », projet n°2), avec assignation
nominative, et par le dépôt `ProjetPiscine_EnerVision`, branche d'intégration `dev`, branche de
production `main`.

### Activité par membre

| Membre | Compte GitHub | Commits sur `dev`, hors merges | PR mergées, auteur principal | PR mergées par lui | Board : Done / En cours / Todo | Domaines observés dans ses PR |
|---|---|---|---|---|---|---|
| Johan LEROY (Tech Lead) | `JohanLeroy` | 172 | 34 | 59 | 36 / 0 / 0 | Socle backend (auth, RBAC, audit, contrat OpenAPI), moteur de règles, vues frontend, reverse proxy et certificats, déploiement continu et trois environnements, Terraform, CI unifiée, e2e et charge, supervision, Garage et rétention, tests d'intégration, dérive, documentation |
| Dorian PESCE | `phyri0s` | 42 | 11 | 11 | 16 / 0 / 0 | Terraform k3s, endpoints, pipeline LightGBM, scoring, alertes internes, DAGs ML, DAST, en-tête CORP, réconciliation des sources |
| Inès ZANG | `ineszang` | 54 | 4 | 5 | 5 / 2 / 0 | Terraform initial, pipeline CI, SonarCloud, administration du dépôt, procédures de déploiement |
| Meryem EL GHAM | `Meryemel-gham` | 23 | 6 | 2 | 7 / 2 / 0 | Schéma de données, imports historique et API Mock, DAGs d'import |
| Valentin DE FARIA RODRIGUES | `ValentinDeFaria` | 20 | 8 | 4 | 12 / 0 / 0 | Frontend et ses tests, auth frontend, audit de dépendances, supervision des capteurs, registre MLflow, amorce Garage |
| Dependabot | - | 12 | 12 | - | - | Mises à jour de dépendances |
| *(remontées `dev` → `main`)* | - | - | 6 | - | - | - |
| *(non assigné)* | - | - | - | - | 1 / 0 / 1 | - |

Totaux : **323 commits** hors merges sur `dev` (458 avec merges), **81 PR mergées**, 69 éléments
au board. Méthode : l'**auteur principal** d'une PR est l'auteur majoritaire des commits de sa
branche. Deux PR ouvertes par Valentin reviennent ainsi à Johan : #73 et #164 (5 commits sur 6,
sur une amorce de Valentin). Les six remontées de `dev` vers `main` ne sont attribuées à
personne. Le nombre de commits mesure une activité, pas une valeur : les pratiques de découpage
diffèrent d'un membre à l'autre.

**Correspondances nom / identifiant.** Établies par Git : `Dorian`, `Dorian PESCE` et
`Phyrios` sont le compte `phyri0s` ; `ineszang` et `ineszang44` partagent la même adresse,
`Valentin` et `valentin` aussi.

**Rôles principaux** (Tech Lead, Cloud/DevOps, Data & IA, Fullstack Dev, PO). Seul celui de
Tech Lead a été nommé au départ ; les autres se lisent dans les PR de chacun :

| Membre | Rôle principal exercé |
|---|---|
| Johan LEROY | **Tech Lead** : architecture, intégration, relecture, sécurité, déploiement |
| Dorian PESCE | **Data & IA** : modèle LightGBM, DAGs ML, scoring ; premier relecteur de l'équipe |
| Inès ZANG | **Cloud / DevOps** : Terraform initial, pipeline CI, SonarCloud, administration du dépôt |
| Meryem EL GHAM | **Data** : schéma de données, imports historique et API Mock, DAGs d'import |
| Valentin DE FARIA RODRIGUES | **Fullstack Dev** : frontend et ses tests, supervision des capteurs, registre MLflow |

Le rôle de **PO** n'a pas eu de titulaire nommé : les arbitrages de périmètre ont été pris aux
points d'avancement, dont la coupe du 21/09. Le formateur demandait une **rotation** des rôles
sur les deux semaines : elle n'a pas eu lieu. Chacun est resté sur son domaine d'origine, ce qui a
favorisé la vitesse au détriment de la polyvalence.

### RACI

Reconstitué depuis l'historique des PR mergées, chaque PR étant rattachée aux chantiers dont elle
touche les fichiers : *Responsible* = qui écrit, *Accountable* = qui valide le merge,
*Consulted* = qui relit (revue ou commentaire), *Informed* = toute l'équipe, par le board et les
points d'avancement.

| Chantier | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Backend / API | `JohanLeroy`, `phyri0s`, `Meryemel-gham` | `JohanLeroy` | `phyri0s` | équipe |
| Frontend | `JohanLeroy`, `ValentinDeFaria`, `ineszang` | `JohanLeroy` | `phyri0s` | équipe |
| Data & ML | `phyri0s`, `Meryemel-gham`, `JohanLeroy`, `ValentinDeFaria` (registre) | `JohanLeroy` | `phyri0s`, `JohanLeroy` | équipe |
| Infra / CI-CD | `JohanLeroy`, `ineszang`, `phyri0s`, `ValentinDeFaria` | `JohanLeroy` | `phyri0s` | équipe |
| Sécurité | `JohanLeroy`, `phyri0s` (DAST) | `JohanLeroy` | `phyri0s` | équipe |

Lecture : le Tech Lead valide l'intégration de tous les chantiers, et `phyri0s` en est le premier
relecteur. Le RACI n'a pas été posé en amont : il se lit a posteriori dans les merges et les revues.

---

## 2. Méthodologie, backlog, user stories

Constat factuel tiré du GitHub Project, du tracker d'issues et du dépôt :

- **Méthodologie** : **Kanban à jalons**, pratiqué sans avoir été nommé en amont. Le board a
  **3 colonnes** (`Todo` / `In progress` / `Done`), découpé en **2 itérations** (« Première
  semaine », « Seconde semaine ») et **6 jalons datés**.
- **Priorisation MoSCoW** appliquée à chaque ticket, et **respectée dans les faits** : au
  24/09, **56 `Must` faits sur 56**, 5 `Should` sur 5, 4 `Could` sur 6. Au 18/09, 66 % des
  `Must` étaient faits contre 0 % des `Should` et des `Could` : aucun ticket de confort n'a été
  pris avant un ticket essentiel.
- **Estimation en taille de tee-shirt** : 48 S, 13 M, 5 XS, 3 sans taille.
- **Traçabilité ticket → PR → commit** : chaque ticket livré porte ses PR liées.
- **Revue de code avant merge.** `JohanLeroy` a relu par écrit **23 PR d'autres membres** :
  15 revues formelles (8 `APPROVED`, 5 `COMMENTED`, 2 `CHANGES_REQUESTED`) et 8 revues publiées
  en commentaire. `phyri0s` a posé 17 approbations formelles, `ValentinDeFaria` 2. Au total,
  **55 des 62 PR de fonctionnalité (89 %)** ont été relues par un autre membre avant merge, par
  revue formelle ou commentaire ; les remontées de `dev` vers `main` ne portent que des PR déjà
  relues.
- **Intégration.** **81 PR mergées** : 62 vers `dev`, 19 vers `main` (6 remontées, 1 réglage
  Sonar, 12 Dependabot). `JohanLeroy` en a mergé 59, dont 42 vers `dev` ; parmi elles, 13 PR
  écrites par d'autres membres et 12 PR Dependabot.
- **Décisions écrites.** **20 ADR** : 17 rédigés par `JohanLeroy` (0001 à 0004, 0006 à 0010,
  0013 à 0020), 1 par `phyri0s` (0005, LightGBM), et 2 procédures de déploiement versées par
  `ineszang` (0011, 0012), qui relèvent davantage de la note d'exécution que de l'ADR.
- **Points d'avancement** les 15, 17, 18 et 21/09, chacun terminé par une décision ; ceux du 15
  et du 18/09 sont versionnés dans `docs/dailies/`. Le compte rendu du 18/09 a été rédigé après
  coup, le 21/09.
- **Étiquettes par domaine** sur les issues (`feature`, `backend`, `frontend`, `ml`, `infra`,
  `ci/cd`, `test`, `securite`, `pipeline ETL`, `accessibility`).
- **User stories formalisées** (« en tant que... je veux... afin de... ») : non retrouvées
  telles quelles, le besoin fonctionnel est porté par le corps des issues.

---

## 3. Planning, jalons, gestion des risques

### Jalons internes du projet

À ne pas confondre avec la numérotation J1 à J10 du calendrier de formation : ce sont deux
échelles différentes.

| Jalon projet | Échéance (API) | Fermées / total au 24/09 | État |
|---|---|---|---|
| J1 · Environnement et dépôt | 14/09 | 5/5 | clos le 15/09 |
| J2 · Périmètre et choix technologiques | 15/09 | 4/4 | clos le 16/09 |
| J3 · Ingestion et backend | 21/09 | 22/22 | tout fermé, jalon laissé ouvert |
| J4 · Architecture, sécurité, frontend | 22/09 | 24/24 | tout fermé, jalon laissé ouvert |
| J5 · Robustesse et livrables | 23/09 | 5/6 | reste #154 (déclaration IA et RGPD, portée par ce rapport) |
| J6 · Amélioration possible | 28/09 | 7/9 | créé le 21/09 pour le périmètre coupé (§5) ; restent #11 et #54 |

Le point d'avancement du 21/09 donnait le 18/09 et le 21/09 pour J3 et J4 ; l'API donne
aujourd'hui le 21/09 et le 22/09. L'API ne garde pas l'historique des échéances : l'écart est
signalé, pas expliqué.

### Calendrier institutionnel

| Jalon | Contenu | Date |
|---|---|---|
| J1 | Rendu EC01, dossier de conception individuel | fait, 14/09 |
| J9 | Oral EC01, 15 min + ~10 min de questions | jeudi 24/09 |
| J10 | Gel technique 9h00, rendu EC02 à EC06, oral EC02 (15 min + ~5 min de vidéo + ~5 min de questions) | vendredi 25/09 |

### Risques identifiés et leur traitement

| Risque | Impact | Statut au 24/09 |
|---|---|---|
| **`main` en retard sur `dev`** | `main` est la branche par défaut et celle de la production | **Traité.** Six remontées (#125, #152, #160, #161, #163, #165) ; au gel, `main` et `dev` portent le même commit. Sept déploiements de production réussis, le dernier sur le commit gelé |
| Tickets sans assigné (17 au 21/09) | Aucun responsable identifié | **Traité par arbitrage** : coupe du 21/09 (§5), puis assignation. Restent 2 issues ouvertes sans assigné, #55 et #154 |
| Jalon J5 sans assigné (#41, #45, #46, #47) | Preuves attendues pour EC03 et EC04 | **Traité** : les quatre livrés et assignés, DAST (#140), tests d'intégration (#147), e2e Playwright et charge k6 (#148) |
| Aucun scan de code dans le pipeline | Note DevSecOps EC03 / EC04 | **Traité** : SAST Bandit bloquant (#121), DAST OWASP ZAP (#140). **Restent hors CI** : Trivy et gitleaks, joués à la main pour le rapport EC04 |
| Aucun déploiement | Attendu explicite d'EC03 et EC04 | **Traité et constaté** : trois environnements sur la machine du groupe (production sur `main`, recette sur `dev`, dev à la demande), certificats Let's Encrypt, runner auto-hébergé (ADR 0009, 0017, 0018) |
| Montée de version majeure d'Airflow par Dependabot (#135) | Provisionnement et déploiement cassés | **Traité le jour même** (#143) |
| Trois PR immobilisées par un quality gate mal configuré | Blocage de la chaîne de merge | **Traité le 18/09**, en configuration et non par contournement |
| Mémoire de la machine (8 Go) insuffisante pour trois stacks | Arrêts par manque de mémoire | **Traité** : portée à 32 Go sur demande à l'école (ADR 0017) |
| Chiffrement au repos (#42) | Données en clair sur le disque | **Partiel, découvert le 24/09** : la machine est un conteneur LXC où LUKS est impossible ; seules les archives sont chiffrées (SSE-C, ADR 0020), demande adressée à l'école |
| Production sans approbation humaine, branches non protégées | Un push non relu part en production | **Ouvert** : annoncés par l'ADR 0009, laissés à poser par l'ADR 0014, jamais activés ; seule l'administratrice du dépôt peut le faire |
| Services hors dépôt sur la machine : k3s et trois serveurs Vault, installés depuis une branche de travail non fusionnée | Surface exposée que le code livré ne documente pas : l'API k3s et les trois Vault écoutent sur toutes les interfaces, k3s redémarre en boucle depuis le 17/09 | **Découvert le 24/09**, à arbitrer par l'administratrice : le code livré n'en dépend pas (rapport EC04, constat 1) |

---

## 4. Compte rendu d'activité honnête

### Indicateurs, depuis la baseline

**Baseline : 57 issues créées le 14/09**, jour 1. Série quotidienne relevée par l'API :

| Jour | Issues créées | Périmètre | Fermées | Cumul fermées | Ouvertes | PR mergées | Cumul PR |
|---|---|---|---|---|---|---|---|
| 14/09 | 57 | 57 | 5 | 5 | 52 | 3 | 3 |
| 15/09 | 1 | 58 | 10 | 15 | 43 | 7 | 10 |
| 16/09 | 1 | 59 | 8 | 23 | 36 | 10 | 20 |
| 17/09 | 6 | 65 | 10 | 33 | 32 | 9 | 29 |
| 18/09 | 2 | 67 | 6 | 39 | 28 | 9 | 38 |
| 21/09 | 5 | 72 | 16 | 55 | 17 | 11 | 49 |
| 22/09 | 1 | 73 | 2 | 57 | 16 | 18 | 67 |
| 23/09 | 3 | 76 | 11 | 68 | 8 | 12 | 79 |
| 24/09 | 0 | 76 | 4 | 72 | 4 | 2 | 81 |

| Indicateur | 16/09 | 18/09 | 24/09 |
|---|---|---|---|
| Board : Done / In progress / Todo | 19 / 6 / 26 | 33 / 6 / 21 (16h) | **66 / 2 / 1** |
| `Must` faits | 45 % | 66 % | **100 %** (56/56) |
| `Should` et `Could` faits | 0 % | 0 % | 100 % et 67 % |
| Issues fermées / périmètre | 23 / 59 | 39 / 67 | **72 / 76** |

**Deux lectures à défendre.** La priorisation est tenue dans les faits : le premier `Should`
n'a été fermé que le 23/09 à 11h10, quand 54 des 56 `Must` l'étaient déjà. Et le périmètre a dérivé de
57 à 76 issues (+33 %), dont 19 créées en cours de route : la dérive a été absorbée par la coupe
du 21/09 (§5) plutôt que laissée ouverte. Le 22/09 illustre la limite du comptage : 2 issues
fermées, mais 18 PR mergées, le déploiement continu et Terraform, les plus lourdes du projet.

### Livré depuis le 18/09 à 16h00

| PR | Mergée le | Auteur principal | Contenu |
|---|---|---|---|
| #113, #118 | 18 et 21/09 | `phyri0s` | Détection des alertes internes ; entraînement et scoring LightGBM orchestrés par deux DAGs |
| #114, #124 | 21/09 | `JohanLeroy` | Moteur de règles de recommandation (ADR 0006) ; DAG d'alertes et de recommandations (ADR 0008) |
| #112, #138, #146 | 21 et 22/09 | `Meryemel-gham` | Import depuis l'API Mock borné ; import historique, puis import horaire, orchestrés par Airflow |
| #107, #123 | 21 et 22/09 | `ValentinDeFaria` | Supervision des capteurs par site ; enregistrement du modèle dans le registre MLflow |
| #117, #121 | 21/09 | `JohanLeroy` | Reverse proxy Nginx et TLS (ADR 0007) ; SAST Bandit et vue CI/CD |
| #136, #137 | 21/09 | `JohanLeroy` | Flux d'alertes du tableau de bord ; vue recommandations |
| #139, #143, #144 | 22/09 | `JohanLeroy` | Déploiement continu, runner auto-hébergé (ADR 0009) ; réalignement Airflow 3 ; Terraform provisionne la machine (ADR 0010) |
| #140 | 22/09 | `phyri0s` | Scan dynamique OWASP ZAP de l'API |
| #147 | 22/09 | `JohanLeroy` | Tests d'intégration API, base et ML ; surveillance de dérive (ADR 0013) |
| #148 | 23/09 | `JohanLeroy` | CI unifiée (ADR 0014), e2e Playwright et charge k6 (ADR 0015), supervision Prometheus, Alertmanager, Grafana (ADR 0016) |
| #149 | 23/09 | `phyri0s` | En-tête `Cross-Origin-Resource-Policy` sur toutes les réponses |
| #151 | 23/09 | `JohanLeroy` | Troisième environnement, `dev`, déployé à la demande (ADR 0017) |
| #156, #159 | 23/09 | `JohanLeroy` | Noms publics, certificats Let's Encrypt par DNS-01, frontal SNI (ADR 0018) |
| #162 | 23/09 | `phyri0s` | Réconciliation des deux sources de relevés |
| #164 | 24/09 | `JohanLeroy` | Garage par environnement, rétention exportée des relevés, chiffrement des archives (ADR 0019, 0020) |
| 6 remontées, #142, 12 Dependabot | 21 au 24/09 | - | Mises en production, analyse Sonar sautée sur les PR Dependabot, mises à jour de dépendances |

### Ce qui n'a pas été livré, et pourquoi

- **#11 Responsive et #54 comparateur de scénarios** : `Could`, en cours au gel, jalon J6.
  Démonstration sur poste, sans usage mobile dans le scénario du client pilote.
- **#55 Bouton de pic fictif** : ni assigné, ni au board, rien dans le code.
- **#43 Accessibilité** : fermée en doublon le 23/09, au motif qu'elle serait couverte par les
  tests Playwright ; **aucun test d'accessibilité n'existe**. La fermeture est à corriger dans
  l'outil, pas à défendre.
- **#42 Chiffrement au repos** : fermée comme faite, livrée **en partie** (archives seulement),
  pour une raison d'infrastructure découverte le 24/09 (§3).
- **Loki, Trivy et gitleaks en CI, approbation de la production** : prévus ou annoncés, non
  faits.
- **Rotation des rôles** : elle n'a pas eu lieu (§1).

Lecture honnête : tout ticket assigné à quelqu'un a été mené au bout ou reste en cours au gel.
Le retard du 21/09 n'était pas un problème d'exécution individuelle mais de **répartition** : il
a été traité par la coupe et l'assignation, puis rattrapé. Les faiblesses restantes sont de
rigueur de processus, pas de livraison : fermetures d'issues trop généreuses (#42, #43) et
réglages de protection jamais activés.


---

## 5. Périmètre coupé

**Un périmètre coupé et argumenté est un acte de management ; une issue laissée ouverte sans
rien est un trou.** La coupe a été faite le 21/09, jour de l'échéance du J4, et tracée dans
l'outil : un jalon **J6 « Amélioration possible »**, échéance 28/09, donc après le gel. Elle a
servi à ordonner, pas à renoncer : une fois les `Must` faits, une partie du J6 a été livrée
avant le gel.

| Issue | Sujet | Raison de la coupe au 21/09 | Au gel |
|---|---|---|---|
| #11 | Responsive | Démonstration sur poste, aucun usage mobile | en cours, non livré |
| #24 | MinIO, couche bronze | La charge brute est déjà en base (`raw_data`) | **livré autrement** : Garage, jugé plus léger (ADR 0019) |
| #26 | Monitoring Prometheus et Grafana | Classé bonus par le sujet | **livré** (#148, ADR 0016) |
| #36 | Rétention des données | Jeu de démonstration borné | **livré** : export vers Garage puis suppression (#164) |
| #42 | Chiffrement au repos | Données synthétiques, priorité au chiffrement en transit | **partiel** : archives chiffrées, base en clair (ADR 0020) |
| #43 | Accessibilité | Hors des critères de notation technique | fermée en doublon, **non livrée** |
| #54 | Comparateur de scénarios | Confort (`Could`) | en cours, non livré |

Les tests e2e (#46) et de charge (#47), dont la coupe était proposée le 21/09, ont finalement
été livrés (#148). Deux sacrifices restent assumés : **Big Data**, hors de portée dans le temps
imparti, et **RPA avancé**, au-delà de l'orchestration Airflow.

---

## 6. Écarts entre conception (EC01) et réalisation

Le guide d'évaluation le dit : **les écarts entre conception et réalisation font partie du
compte rendu d'activité**. Chaque écart ci-dessous porte sa trace.

| # | Choix du dossier EC01 (14/09) | Réalisé au gel | Verdict |
|---|---|---|---|
| 1 | FastAPI / Python pour l'API | FastAPI, contrat OpenAPI versionné et testé | ✅ Tenu |
| 2 | PostgreSQL 17 + TimescaleDB | Identique, relevés en hypertable (ADR 0001) | ✅ Tenu |
| 3 | JWT + Argon2id, RBAC à 3 rôles | Identique, plus rotation du jeton de rafraîchissement (ADR 0002, 0003) | ✅ Tenu |
| 4 | Une valeur nulle n'est jamais effacée | Qualité de donnée et imputation tracées, gravées par une contrainte `CHECK` | ✅ Tenu |
| 5 | Contrats d'interface figés | Contrat OpenAPI testé, table `prediction` comme frontière ML | ✅ Tenu |
| 6 | Docker Compose plutôt que Kubernetes | Compose, un projet par environnement (ADR 0009, 0017) | ✅ Tenu |
| 7 | On-premise plutôt que cloud public | Machine de l'école, aucune ressource cloud | ✅ Tenu |
| 8 | Traefik en terminaison TLS | Nginx par stack (ADR 0007) et frontal SNI (ADR 0018) | 🔁 Substitué |
| 9 | Prophet + IsolationForest | LightGBM, un modèle global (ADR 0005), alertes internes par règles, dérive surveillée (ADR 0013) | 🔁 Substitué |
| 10 | APScheduler pour l'ETL | Airflow, 7 DAGs : imports, entraînement, scoring, alertes, dérive, rétention | 🔁 Substitué |
| 11 | MinIO, couche bronze | Garage par environnement (ADR 0019) | 🔁 Substitué |
| 12 | Ansible, durcissement et déploiement | Terraform et script rejouable (ADR 0010) ; durcissement non automatisé | ⚠️ Partiel |
| 13 | SOPS + age pour les secrets | Secrets générés sur la machine, hors de Git | ❌ Non fait |
| 14 | Trivy, Bandit, gitleaks en CI | Bandit (#121) et un DAST ZAP non prévu (#140) ; Trivy et gitleaks hors CI | ⚠️ Partiel |
| 15 | Prometheus, Grafana, Loki | Prometheus, Alertmanager, Grafana actifs en production (ADR 0016) ; pas de Loki | ⚠️ Partiel |
| 16 | Runner auto-hébergé, déploiement automatique | `deploy.yml` sur runner auto-hébergé, sept déploiements de production | ✅ Tenu |
| 17 | Deux réseaux Docker, données jamais exposées | Un seul composant exposé, le frontal ; tout le reste sur la boucle locale | 🔁 Intention tenue, autre moyen |

**Décompte sur les 17 choix du dossier : 8 tenus, 5 substitués, 3 partiels, 1 non fait.** Au
23/09, il était de 8 tenus, 4 substitués, 3 partiels et 2 non faits : MinIO est passé de « non
fait » à « substitué » par Garage.

**Hors de cette liste**, le dashboard était prévu en React / Vite ; il est en **Angular 22**
depuis son initialisation le 14/09 (commit `49f4697`, PR #52). Sans effet sur le reste de
l'architecture, puisque le frontend ne connaît que le contrat d'API. Motif : choix de Valentin, développeur
full stack de l'équipe, qui maîtrisait Angular ; aucune objection dans le cadre du projet.

---

## 7. Usage de l'intelligence artificielle

Déclaration exigée par le formateur : outils utilisés, tâches réalisées, valeur ajoutée,
limites constatées, vérifications humaines.

### Déclaration de Johan LEROY (Tech Lead)

| | |
|---|---|
| **Outil** | Claude Code (Anthropic), en assistant de développement dans le terminal et l'IDE |
| **Tâches** | Aide à la rédaction de code backend, d'infrastructure et de tests, relecture de PR en amont de la revue humaine, rédaction et mise à jour de la documentation d'architecture et des ADR, analyse d'écarts entre le dépôt et les attendus, relevés chiffrés de ce rapport |
| **Valeur ajoutée** | Vitesse sur le travail répétitif (gabarits de tests, migrations, documentation), et surtout **recoupement systématique** : détection d'incohérences entre documentation et code qu'une relecture humaine laisse passer |
| **Limites constatées** | Des **chiffres plausibles mais faux** quand ils ne sont pas recalculés ; des **références à des fichiers inexistants** ; une tendance à **présenter comme acquis** ce qui n'est que prévu (l'approbation de la production, annoncée par deux ADR, n'a jamais été activée) ; des **horodatages en UTC recopiés comme heure locale** |
| **Vérifications humaines** | Tout code généré passe par la CI (lint, typage, tests, couverture, SAST) et par une revue de PR. Tout chiffre publié est réobtenu par une commande (`gh`, `git log`) au moment de la rédaction. Les décisions d'architecture restent prises et signées en ADR par un humain |

### Déclarations des autres membres

Non transmises au moment du gel. Le gabarit reste celui de la déclaration ci-dessus : outil,
tâches, valeur ajoutée, limites, vérifications.

---

## 8. Licences logicielles

**Licence du dépôt** : aucun fichier `LICENSE` au gel. Faute de licence explicite, le code reste
sous le régime par défaut : tous droits réservés à ses auteurs, aucune réutilisation accordée.

**Dépendances, relevées le 24/09** par `pip-licenses` (verrous figés, sans dépendances de dev)
et `license-checker --production` :

| Périmètre | Résultat |
|---|---|
| Backend, ML, Airflow (Python) | MIT, BSD, Apache 2.0 et PSF pour l'essentiel. **Aucune GPL ni AGPL embarquée.** À noter : `psycopg` (ML) sous LGPL 3.0, utilisé comme bibliothèque, sans obligation sur le code appelant ; `certifi` et `pathspec` sous MPL 2.0, copyleft limité au fichier, non modifiés ; `text-unidecode` (Airflow) sous double licence Artistic ou GPL, retenue sous Artistic |
| Frontend, dépendances de production | 12 paquets : 10 MIT, 1 Apache 2.0, 1 0BSD |

**Composants exécutés à côté du produit**, chacun dans son conteneur, sans modification :

| Composant | Rôle | Licence |
|---|---|---|
| Nginx | Reverse proxy, frontal SNI | BSD 2-Clause |
| PostgreSQL · TimescaleDB | Base, séries temporelles | PostgreSQL License · Apache 2.0 pour le cœur, Timescale License pour certaines fonctions de l'image utilisée |
| Apache Airflow, MLflow | Orchestration, registre de modèles | Apache 2.0 |
| Prometheus, Alertmanager, exporteurs, cAdvisor | Supervision | Apache 2.0 |
| **Grafana, Garage, k6** | Tableaux de bord, stockage objet, tirs de charge en CI | **AGPL 3.0** |
| acme.sh | Certificats Let's Encrypt | GPL 3.0 |
| Mailpit | Courriel de développement et d'alerte | MIT |
| Terraform | Infrastructure as code | **BUSL 1.1** : usage interne autorisé, redistribution concurrente interdite |

Les composants AGPL et GPL tournent sans modification, dans des conteneurs séparés : ils
n'imposent rien au code du produit. Point de cohérence : l'ADR 0019 écarte MinIO en citant
notamment sa licence AGPL, que Garage partage ; les autres raisons de l'ADR restent.

---

## 9. Anonymisation et conformité RGPD

- **Les données du projet sont synthétiques.** Les séries de consommation proviennent des CSV
  fournis par l'organisme de formation et de l'API Mock simulée. Aucune donnée de consommation
  réelle d'un client identifiable n'est présente dans le dépôt.
- **Les sites sont désignés par identifiants** (`SITE001` à `SITE007`), sans raison sociale ni
  adresse.
- **Les comptes applicatifs** de test utilisent des adresses de domaine fictif et des mots de
  passe de test. Le compte du scan DAST est un compte `lecteur` jetable.
- **Aucun secret dans le dépôt, vérifié** : scan gitleaks sur tout l'historique le 24/09, 342
  commits hors merges, 8 constats, tous faux positifs après tri ligne à ligne ; aucun `.env`,
  clé, certificat ni state Terraform jamais commité (rapport EC04, preuve 05). C'est le ZIP
  `.git` complet qui est remis au jury : le contrôle porte donc bien sur l'historique.
- **Adresse de la machine** : l'adresse privée de la machine du groupe apparaît dans des
  documents d'exploitation de l'historique git. Adresse non routable, joignable depuis le seul
  réseau de l'école ; elle est masquée dans l'arbre livré.
- **Journal d'audit** : les accès sont tracés en ajout seul (ADR 0004). Cette table contient des
  identifiants d'utilisateurs applicatifs : sur un déploiement réel, elle relèverait d'une durée
  de conservation définie. Elle n'est pas fixée à ce jour : à arrêter avant tout déploiement réel.
- **Dans ce rapport et les supports d'oral** : aucune URL, adresse IP, identifiant de connexion
  ou coordonnée personnelle n'est reproduite. Les identifiants GitHub sont des pseudonymes
  publics, conservés parce qu'ils sont la seule clé de traçabilité vérifiable.

---

## Sources

Relevé du 24/09/2026 à 14h25, commit `9f343e9` :

- **Git** : `git rev-list --count origin/dev` et `--no-merges` · `git log origin/dev
  --no-merges --format=%an | sort | uniq -c` (alias regroupés) · `git log --no-merges
  <merge>^1..<merge>^2` (auteur principal) · `git ls-tree --name-only origin/main docs/adr/` ·
  `git rev-list --count origin/main..origin/dev`
- **API GitHub** : `gh issue list --state all --limit 300 --json
  number,state,assignees,milestone,createdAt,closedAt` · `gh project item-list 2 --owner
  ineszang --format json` · `gh api repos/ineszang/ProjetPiscine_EnerVision/milestones?state=all`
  · `gh pr list --state all --limit 300 --json number,author,mergedBy,mergedAt,baseRefName,reviews`
  · `gh api .../deployments?environment=prod`
- **Licences** : `uv run --frozen --no-dev --with pip-licenses pip-licenses --from=mixed` dans
  chaque projet Python · `npx license-checker@25 --production --summary` dans `apps/frontend`
- `CONSIGNES-PROJET.md`, documents officiels 01, 02 et 05, points d'avancement des 15, 17, 18 et
  21/09, rapport de sécurisation EC04