# 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" d'une entité, 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 (voir la partie "Répartition des tâches"). 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 travail collectif. La préparation du support de démo (sur Canva) a mobilisé l'ensemble de l'équipe. --- ## 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. A partir du jalon 3, les revues de code ont été réparties entre chaque membre de l'équipe. ### 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.