7.3 KiB
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 (
repositorydbpour la prod PostgreSQL,repositorylocalpour le dev SQLite) — décidée le 25 mars - Le découpage de
Program.csen 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.