ENI-projet-piscine/docs/livrables/EC02/EADL26_EC02 - Rapport Collectif HEADL_015B-G3.md

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