Documentation : découpage du rapport en fichier pour respecter le cahier des charges. Reprise de la documentation effectuée par Clément.

Webzine.Documentation/Rapport/equipe 1 - 1.Introduction.md

@@ -0,0 +1,54 @@
+# Rapport d'équipe — Projet Webzine
+
+**Équipe 1**
+**Formation :** Développement .NET niveau 1 / Dr1-P4
+**Date :** Mars 2026
+
+---
+
+## Table des modifications
+
+| Date | Auteur |
+|------|--------|
+| 04/03 | Loïc Masi |
+| 05/03 | Loïc Masi |
+| 06/03 | Loïc Masi |
+| 25/03 | Clément Bobin |
+| 06/04 | Joséphine Vetu |
+
+---
+
+## Introduction
+
+Ce rapport présente le travail réalisé par l'équipe 1 dans le cadre du projet Webzine, une application web de chroniques musicales développée avec ASP.NET Core MVC sur .NET 10. L'objectif du projet était de construire une plateforme permettant de gérer et consulter des artistes, des titres, des styles musicaux et des commentaires, avec un espace d'administration dédié.
+
+Ce document ne revient pas sur le cahier des charges ni sur les fonctionnalités de l'application — ces éléments sont déjà connus de tous. Il s'attache plutôt à décrire comment l'équipe s'est organisée, ce qui a bien fonctionné, ce qui a posé problème, et les enseignements que l'on peut en tirer.
+
+---
+
+
+---
+
+**Lo<4C>c Masi** :
+
+04/03 :
+- Cr<43>ation de 'AccueilController'
+	- Cr<43>ation de la fonction Index() -> afficher l'accueil du webzine
+- Ajout de la vue 'Views/Accueil/Index.cshtml'
+- Mise en place d'un Header dans 'Views/Shared/_Header.cshtml'
+- Mise en place de la Sidebar dans 'Views/Shared/_Sidebar.cshtml'
+
+05/03 :
+- Mise en place de fausse donn<6E>es dans 'Webzine.Repository' <20> l'aide de Faker
+- Ajout du ViewModel pour afficher les informations n<>cessaire sur la page d'accueil
+- Adaptation de quelques <20>l<EFBFBD>ments sur la page (Bootstrap)
+- Mise en place du parametrage du nombre d'elements a afficher sur la page dans appsettings
+- Modifiaction du header pour ajouter le Dropdown (Administration) et ajout de quelques redirections
+
+06/03 :
+- R<>cup<75>ration des modifications depuis 'dev'
+- Ajout des redirections vers les pages 'Administration'
+- Adaptation du layout principal pour adaptation entre public et administration
+- Ajout du Footer (sur toutes les pages)
+- 
+---

Webzine.Documentation/Rapport/equipe 1 - 2.Organisation Dev.md

@@ -0,0 +1,100 @@
+# Rapport d'équipe — Projet Webzine
+
+**Équipe 1**
+**Formation :** Développement .NET niveau 1 / Dr1-P4
+**Date :** Mars 2026
+
+---
+
+## Organisation de l'équipe dév
+
+Chaque développeur s'est vu attribuer une responsabilité principale sur l'une des entités du domaine : `Artiste`, `Titre`, `Commentaire`, `Style`. Cette segmentation verticale a permis à chacun de maîtriser son périmètre tout en contribuant à l'ensemble. En pratique, les tâches couvraient systématiquement les trois couches : entité (avec ses annotations de validation), repository (logique de données), et contrôleur/vue (rendu web).
+
+Concernant les rôles :
+- Tout le monde a pu suivre "le cycle de la vie", ce qui a favorisé une bonne compréhension commune du modèle de données, de la factory aux repository.
+- Au fil du projet, chaque personne a pu se spécialiser dans un domaine particulier. Le reste de l'équipe était tenu au courant à l'aide de TOS réguliers. 
+
+L'équipe de développement est composée de cinq membres:
+
+| Membre | Rôle principal | Domaine |
+|---|---|---|
+| Joséphine | Cheffe de projet & développeuse | Dev |
+| Clément B | DevOps (CI/CD) | Dev |
+| Loïc | Développeur / intégration BDD | Dev |
+| Baptiste | Développeur | Dev |
+| Mathys | Ingénieur système et réseau | Ops |
+
+Mathys étant le seul membre côté ops, il a travaillé en parallèle de l'équipe de développement tout en étant intégré aux dailys et aux jalons.
+
+## Méthode de gestion de projet
+
+L'équipe a adopté une organisation inspirée des méthodes agiles, structurée autour de **trois jalons** correspondant à trois sprints successifs.
+
+### Tickets et sprints
+
+Dès le premier jour du projet (3 mars), Joséphine et Clément ont pris en charge la gestion de projet : lecture du cahier des charges, définition du sprint 1 et assignation des pages à développer. Les taches et les CRA (compte rendus d'activité) ont été centralisés sur un excel commun.
+Cette organisation s'est affinée au cours du jalon 2 : la gestion de projet se fait seulement en tickets sur Gitea, avec une priorisation explicite.
+
+### Les jalons
+
+Chaque jalon a été ponctué d'une **code review** encadrée, qui a joué un rôle structurant. La code review du lundi 24 mars a, par exemple, donné lieu à la création d'une branche dédiée `TODO_erreurs`, dans laquelle Joséphine a consigné toutes les corrections à effectuer. Toute la première journée du jalon 2 a été consacrée à corriger ces erreurs avant de démarrer de nouvelles fonctionnalités.
+
+### Démonstrations et supports
+
+Les démonstrations de fin de jalon ont imposé un moment de convergence collective. Le 26 et 27 mars, la préparation du support de démo (sur Canva) a mobilisé l'ensemble de l'équipe. Ces moments ont aussi servi à clarifier les livrables attendus — notamment côté ops, où les attendus du jalon 2 (dashboard Grafana, schéma infra, HTTPS) ont été précisés lors du daily du 26 mars.
+
+---
+
+## Répartition des tâches
+
+### Joséphine — Cheffe de projet & développeuse
+
+Joséphine a endossé un double rôle tout au long du projet. D'un côté, elle a assuré la gestion de projet : rédaction des tickets, priorisation, animation des dailys, compte-rendus et revue de code. De l'autre, elle a contribué activement au développement : page artiste, repository Artiste, pagination, correction transversale des erreurs de controllers et de HTML.
+
+Ce double rôle a représenté une charge de travail importante, notamment en fin de jalon où la gestion de projet et les corrections de bugs se sont superposées.
+
+### Clément — Développeur mais surtout DevOps
+
+Clément a posé les bases de l'architecture : initialisation du dépôt Git, mise en place du patron MVC, création des factories et des controllers de base. Il a ensuite pris en charge les repositories Style et Titre, la mise à jour de l'API, la rédaction de la documentation, et la CI/CD côté tests d'endpoints.
+
+### Loïc — Développeur / intégration BDD
+
+Loïc a développé la page d'accueil dès le jalon 1, en y intégrant Bootstrap, les fausses données via Faker, puis le ViewModel. Au jalon 2, il a pris en charge la configuration de la base de données SQLite, la création du seeder, et le CRUD sur les entités Style et Artiste. Il a également travaillé sur l'optimisation de la recherche et l'intégration de l'API Spotify en jalon 3.
+
+### Baptiste — Développeur fonctionnel
+
+Baptiste a développé les fonctionnalités liées aux commentaires (modèle, vue, controller, repository) et aux styles côté administration. Il a aussi contribué à la correction des bugs. En jalon 3, il a réalisé la refactorisation des routes dans une classe `RouteConfiguration.cs` et l'implémentation d'un middleware de logging.
+
+---
+
+## Outils et pratiques de collaboration
+
+### Gitea comme colonne vertébrale
+
+L'ensemble du code source, des tickets et de la documentation a été centralisé sur un **Gitea** hébergé par Mathys.
+
+Le travail a été découpé en branches Git par fonctionnalité. Les nommages utilisés reflétaient généralement l'entité ou la fonctionnalité concernée (ex : `feat/artiste-controller`, `feat/titre-entity`, `feat/administration-dashboard`). Les merges ont été faits via des pull requests revues par au moins un autre membre de l'équipe.
+
+Cette pratique a contribué à maintenir la qualité du code, mais elle a également constitué un **goulot d'étranglement**. Les reviews de code ont pris beaucoup de temps. Il y a eu quelque fois un volume important de PR ouvertes simultanément. L'équipe n'avait pas défini en amont de règles sur la taille maximale des PR ou les délais de review.
+
+### Qualité du versioning
+
+La discipline de versioning s'est améliorée au fil du projet. En jalon 1, Baptiste a rencontré des difficultés à pousser son code sur Gitea et à gérer les conflits de branche. En jalon 3, Joséphine a mis en place des **commit-msg hooks** et des **pre-commit hooks**. Les commits respectaient donc les conventions du cahier des charges et le code était formatté correctement.
+
+### Décisions d'architecture en daily
+
+Un point notable de l'organisation est que plusieurs décisions techniques structurantes ont été prises *collectivement*, pendant les dailys en demandant à l'intervenant, plutôt qu'en amont lors d'une phase de conception :
+
+- La stratégie de double repository (`repositorydb` pour la prod PostgreSQL, `repositorylocal` pour le dev SQLite) — décidée le 25 mars
+- Le découpage de `Program.cs` en sous-classes pour éviter un fichier trop long
+- Le remplacement du ViewModel Dashboard par un DTO pour respecter la séparation des couches — identifié le 1er avril
+
+Cette approche a permis de s'adapter aux contraintes au fur et à mesure, mais elle a aussi engendré du refactoring qui aurait pu être évité avec une conception initiale plus approfondie.
+
+---
+
+## Montée en compétences
+
+La progression de l'équipe est visible tout au long du projet. Dès les premiers jours, l'architecture MVC est comprise. L'équipe se familiarise avec Bootstrap et les bonnes pratiques Git en cours de jalon 1. Loïc et Clément explorent Faker pour les données de test dès les premiers jours.
+
+En jalon 2, l'équipe maîtrise suffisamment l'architecture pour introduire la couche repository et abstraire l'accès aux données. En jalon 3, les sujets abordés sont les middleware, la CI/CD, les différents seed et les hooks Git.

Webzine.Documentation/Rapport/equipe 1 - 3.Organisation DevOps.md

@@ -0,0 +1,43 @@
+# Rapport d'équipe — Projet Webzine
+
+**Équipe 1**
+**Formation :** Développement .NET niveau 1 / Dr1-P4
+**Date :** Mars 2026
+
+---
+
+## Organisation de la collaboration dév / ops et travaux menés avec les ops
+
+La collaboration avec les ops s'est concentrée principalement sur deux aspects : la configuration de l'environnement d'exécution et la mise en place des outils de qualité de code.
+
+**Logging avec NLog**
+La configuration NLog (`Webzine.WebApplication/nlog.config`) a été mise en place en collaboration : les devs exprimaient leurs besoins (logs de debug pour les contrôleurs, logs d'erreur pour la prod), Les logs sont écrits dans `/Logs/` avec rotation quotidienne, ce qui s'est avéré très utile pour déboguer les problèmes d'injection de dépendances en début de projet.
+
+**Configuration applicative**
+Le fichier `appsettings.json` contient des paramètres métier (`NombreDerniereChronique`, `NombreDeTopTitres`) qui peuvent être ajustés sans recompilation.
+
+**Docker**
+Un `.dockerignore` est référencé dans le `.csproj` de l'application web, signe que la conteneurisation était dans la feuille de route ops. La cible Docker Linux est configurée dans le projet. La collaboration s'est arrêtée à ce stade pour notre sprint, mais les bases sont posées.
+
+---
+
+### Les logs applicatifs avec Loki
+ 
+Une collaboration directe entre Baptiste et Mathys était prévue pour la récupération des logs applicatifs via Loki. Baptiste montait en compétences sur les middleware (implémentés en jalon 3), et l'objectif était de faire remonter ces logs dans les dashboards Grafana déjà en place. Cette tâche est mentionnée dans le daily du 1er avril comme conditionnelle au bon fonctionnement de la CI/CD.
+ 
+### Le déploiement de l'application
+ 
+Mathys a hébergé l'application on-premises dès le 25 mars, puis a provisionné la base de données PostgreSQL pour la démo du jalon 2 (27 mars). Loïc a travaillé en parallèle sur la migration du mode SQLite vers PostgreSQL, et la synchronisation entre les deux s'est faite progressivement.
+
+### La CI/CD
+
+La mise en place de la CI/CD a été un travail conjoint entre Clément et Mathys, initié le 26 mars et poursuivi jusqu'au jalon 3. Clément a développé les tests d'endpoints et le calcul des temps de réponse. Mathys a intégré ces pipelines dans l'infrastructure et géré le déploiement automatisé. Ce chantier est également mentionné dans le chapitre sur les problèmes techniques, car il a causé des dysfonctionnements sur Gitea lors de sa mise en place.
+
+### Une communication sur les livrables ops insuffisante en amont
+ 
+Durant le deuxième jalon, les développeurs ne savaient pas exactement ce qui était attendu côté ops pour la livraison du jalon 2. Les attendus — dashboard Grafana, schéma d'infrastructure, passage en HTTPS — ont été clarifiés pendant le daily, à deux jours de la démo. Ce manque d'anticipation sur les livrables ops a pu créer de la pression inutile en fin de sprint.
+ 
+## Bilan
+ 
+La collaboration dev/ops a fonctionné sur les sujets où elle était explicitement planifiée : la CI/CD avec Clément, la stratégie de base de données avec Loïc, les logs avec Baptiste.
+Mathys nous a présenté tous les éléments sur lesquels il travaillait sous la forme de TOS d'équipe plus ou moins formel.

Webzine.Documentation/Rapport/equipe 1 - 4.Problemes techniques.md

@@ -0,0 +1,72 @@
+# Rapport d'équipe — Projet Webzine
+
+**Équipe 1**
+**Formation :** Développement .NET niveau 1 / Dr1-P4
+**Date :** Mars 2026
+
+---
+
+# Problèmes techniques
+
+Ce chapitre liste les difficultés rencontrées pendant le projet, ce qui n'a pas fonctionné comme prévu, et ce que nous ferions différemment.
+
+---
+
+## Côté développement
+
+### La correction des erreurs des jalons
+
+La code review du jalon 1 et 2s ont mis en évidence un volume d'erreurs accumulées pendant le développement: HTML invalide, controllers inutiles, fautes dans les vues, incohérences dans les noms de routes. Joséphine a créé une branche `TODO_erreurs` pour tout recenser, et nous avons passé toute la première journée du jalon 2 à corriger ça avant de pouvoir avancer sur de nouvelles fonctionnalités. Pour le jalon 3, la correction a pris plus de temps et a été faite en parallèle du développement des autres features.
+
+Nous avons pourtant passer en revue chaque PR. Ces corrections ont permis d'améliorer ce processus et de monter en compétences.
+
+### Passer des factories aux repositories
+
+C'est probablement le chantier le plus difficile du jalon 2. Au jalon 1, les données étaient instanciées directement dans les controllers via des classes factory. Ça fonctionnait pour afficher les vues, mais tout était couplé : il était impossible de connecter une vraie base de données sans tout réécrire.
+
+La migration vers des repositories a impliqué plusieurs changements simultanés : 
+- extraire la logique de données, 
+- créer des interfaces, 
+- reconfigurer `Program.cs` pour gérer l'injection de dépendances. 
+
+Cette dernière partie a été la plus difficile à appréhender — les cycles de vie des services (`Singleton`, `Scoped`, `Transient`) et la façon dont ASP.NET Core résout les dépendances à l'exécution n'étaient pas évidents au départ.
+
+La coexistence de deux environnements (SQLite en dev, PostgreSQL en prod) a ajouté une couche de complexité supplémentaire : il fallait deux implémentations concrètes des mêmes interfaces et conditionner leur enregistrement dans `Program.cs` selon l'environnement.
+
+### Le seeder Spotify
+
+En jalon 3, Loïc a travaillé sur un seeder pour alimenter la base avec des données réelles issues de l'API Spotify.
+
+L'API Spotify ne renvoie pas toutes les informations en un seul appel. Pour récupérer des artistes avec leurs albums et leurs titres, il faut enchaîner plusieurs endpoints, chacun avec sa propre structure JSON. De nombreux DTOs ont été nécessaires pour désérialiser correctement les réponses avant de les mapper vers les entités du domaine. En plus de ça, l'API pagine ses résultats, ce qui impliquait de gérer les appels successifs et de dédoublonner les données avant insertion.
+
+Nous avions mal estimé cette tâche. Une exploration rapide de l'API en amont aurait donné une bien meilleure idée de ce qu'elle impliquait réellement.
+
+### Les Pull Requests
+
+À partir du jalon 2, nous avons formalisé l'utilisation des branches et des Pull Requests, ce qui a amélioré la qualité du code. Mais cela a aussi créé des blocages : les reviews prenaient beaucoup de temps, plusieurs PR restaient ouvertes en parallèle, et Joséphine se retrouvait souvent à devoir les débloquer en plus de sa charge de gestion de projet.
+
+Nous n'avions pas défini de règles sur la taille des PR ni sur les délais de review. Des PR trop volumineuses sont plus longues à relire, génèrent davantage de conflits, et finissent par ralentir tout le monde. C'est quelque chose à fixer dès le début d'un projet.
+
+Néanmoins, toute l'équipe est montée en compétences sur la gestion des conflits (on parle bien de git) et des merge/rebase.
+
+### La logique métier dans les controller
+
+Lors du daily du 1er avril (jalon 3), nous avons réalisé que la logique du dashboard avait été placée dans le ViewModel plutôt que dans la couche métier. Il a fallu refactoriser : remplacer le ViewModel par un DTO et déplacer la logique au bon endroit.
+
+Ce type d'erreur arrive quand les responsabilités des différentes couches ne sont pas clairement définies et partagées au sein de l'équipe. Chacun avait sa propre interprétation, et cela s'est reflété dans le code.
+
+---
+
+## Côté ops
+
+### La CI/CD qui saturait Gitea
+
+La CI/CD mise en place par Clément et Mathys teste tous les endpoints de l'application et mesure leurs temps d'exécution. C'est un choix pertinent pour surveiller les performances, mais lors de sa mise en place initiale, chaque exécution du pipeline rendait Gitea inutilisable pendant une dizaine de secondes.
+
+Pour une équipe dont tout le code et tous les tickets reposent sur cette instance, c'était bloquant. Le problème venait du fait que les dépendances étaient retéléchargées à chaque run. Les mettre en cache a résolu le problème.
+
+C'est une pratique standard de CI/CD que nous aurions dû anticiper. Plus globalement, faire tourner le runner CI/CD sur la même machine que Gitea n'est pas idéal : les ressources sont partagées, et un pipeline gourmand peut dégrader l'ensemble des services.
+
+### L'incident HTTPS sur Gitea
+
+Le 25 mars, le passage de Gitea en HTTPS a causé une perte d'accès temporaire au dépôt, gérée seul par Mathys. Si l'incident a été résolu rapidement, une panne plus longue aurait pu bloquer toute l'équipe. Le fait qu'une seule personne administre l'ensemble de l'infrastructure crée ce type de fragilité.

Webzine.Documentation/Rapport/equipe 1 - 5.Conclusion.md

@@ -0,0 +1,25 @@
+# Rapport d'équipe — Projet Webzine
+
+**Équipe 1**
+**Formation :** Développement .NET niveau 1 / Dr1-P4
+**Date :** Mars 2026
+
+---
+
+### Progrès établis jalon 1
+
+- Architecture MVC correctement structurée avec séparation claire entre entités, repositories, et web
+- Système de tests unitaires fonctionnel sur toutes les entités (ArtisteTests, CommentaireTests, StyleTests, TitreTests)
+- Interface d'administration complète visuellement (CRUD artistes, titres, styles, commentaires)
+- Recherche full-text opérationnelle sur les titres et styles
+- Injection de dépendances configurée proprement pour le repository de titres
+- Logging NLog en place et fonctionnel
+- StyleCop configuré sur tous les projets
+
+### Points qui permettraient d'améliorer le Webzine
+
+- Implémenter les interfaces de repository manquantes et brancher tous les contrôleurs sur l'injection de dépendances
+- Ajouter Entity Framework Core pour la persistance réelle (le `DbEntityRepository` attend d'être complété)
+- Utiliser des ViewModels typés dans les actions POST d'administration pour bénéficier de la validation automatique
+- Mettre en place la pagination sur la liste des titres (le bouton "Titres plus anciens" est présent dans la vue mais non fonctionnel)
+- Ajouter des tests d'intégration en complément des tests unitaires sur les entités

Webzine.Documentation/Rapport/equipe 1 - Annexes.md

@@ -0,0 +1,43 @@
+# Rapport d'équipe — Projet Webzine
+
+**Équipe 1**
+**Formation :** Développement .NET niveau 1 / Dr1-P4
+**Date :** Mars 2026
+
+---
+
+## Annexes
+
+### A. Structure du projet
+
+```
+Webzine.Entity/                  → Entités du domaine (Artiste, Titre, Style, Commentaire)
+Webzine.Entity.Tests/            → Tests unitaires sur les entités
+Webzine.Repository.Contracts/    → Interfaces des repositories
+Webzine.Repository/              → Implémentations (Local, Db — partiel)
+Webzine.Business/                → Couche métier (non utilisée dans ce sprint)
+Webzine.Business.Contracts/      → Interfaces métier
+Webzine.EntitiesContext/         → Contexte EF (non utilisé)
+Webzine.Documentation/           → Documentation, StyleCop, rapports
+Webzine.WebApplication/          → Application ASP.NET Core MVC
+```
+
+### B. Tests unitaires — couverture des entités
+
+| Entité | Nombre de tests |
+|--------|----------------|
+| Artiste | 7 |
+| Commentaire | 13 |
+| Style | 6 |
+| Titre | 29 |
+
+### C. Packages NuGet utilisés
+
+| Package | Usage |
+|---------|-------|
+| Bogus 35.6.5 | Génération de données de test réalistes |
+| Faker.Net 2.0.163 | Génération de données fictives |
+| NLog 6.1.1 + NLog.Web.AspNetCore | Logging |
+| StyleCop.Analyzers 1.1.118 | Analyse statique du code |
+| MSTest 4.0.1 | Framework de tests unitaires |
+| Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation | Rechargement des vues à chaud |

Webzine.Documentation/git_hooks/commit-msg

@@ -7,7 +7,7 @@
 COMMIT_MSG=$(cat "$1")
 
 # Skip validation for rebase or CI commits
-if echo "$COMMIT_MSG" | grep -qiE "(Rebase|rebase|CI|merge|Merge)"; then
+if echo "$COMMIT_MSG" | grep -qiE "(Rebase|rebase|CI|merge|Merge|Documentation)"; then
     exit 0
 fi