17 KiB
# 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 |
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<EFBFBD>c Masi :
04/03 :
- Cr<EFBFBD>ation de 'AccueilController'
- Cr<EFBFBD>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<EFBFBD>cup<EFBFBD>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)
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).
Par exemple, le travail sur l'entité Titre (fichier Webzine.Entity/Titre.cs) a impliqué la définition de toutes les contraintes de validation — longueurs min/max, champs obligatoires, libellés d'affichage — et d'ainsi valider les tests unitaires correspondants dans Webzine.Entity.Tests/TitreTests.cs. Ce type de tâche, apparemment simple, a demandé beaucoup de rigueur pour satisfaire les 40+ tests automatisés.
Concernant les rôles :
- Tout le monde a contribué aux entités, ce qui a favorisé une bonne compréhension commune du modèle de données.
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.
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.
Problèmes techniques (dév / ops)
Ce qui n'a pas été réalisé ou mal réalisé
1. Interfaces de repository incomplètes
Les interfaces IArtisteRepository, ICommentaireRepository et IStyleRepository (dans Webzine.Repository.Contracts/) sont quasiment vides — toutes leurs méthodes sont commentées. Seul ITitreRepository est partiellement implémenté. Cela signifie que les contrôleurs d'administration (ArtisteController, CommentaireController, StyleController) génèrent leurs propres données via DataFactory directement dans le constructeur, au lieu de passer par l'injection de dépendances. C'est une dette technique importante : le code est difficile à tester et ne respecte pas le pattern Repository que le projet était censé illustrer.
2. Données non persistées
Aucune persistance réelle n'est en place. LocalEntityRepository génère des données aléatoires à chaque démarrage, et DbEntityRepository est une classe vide. Cela rend l'application inutilisable pour un usage réel (une suppression de titre est perdue au prochain redémarrage). La branch feature/database avait été créée mais n'a pas abouti dans le temps imparti.
3. Incohérence entre les contrôleurs d'admin et le repository
Le TitreController (public) utilise correctement ITitreRepository injecté, mais les contrôleurs d'administration instancient DataFactory directement. Ce manque de cohérence rend le code plus difficile à maintenir et à faire évoluer.
4. Formulaires d'administration sans validation côté serveur
Les actions POST de création et modification de titres (TitreController.Create(IFormCollection), TitreController.Edit(int, IFormCollection)) redirigent simplement vers l'index sans aucun traitement des données soumises. Le modèle de binding fort n'est pas utilisé — IFormCollection est passé à la place d'un ViewModel typé, ce qui empêche la validation automatique par ASP.NET Core.
Progrès établis en 1 semaines
- 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
DbEntityRepositoryattend 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
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 |