27 lines
2.5 KiB
Markdown
27 lines
2.5 KiB
Markdown
# Rapport d'équipe - Projet Webzine
|
|
|
|
**Équipe 1**
|
|
**Formation :** Développement .NET niveau 1 / Dr1-P4
|
|
**Date :** Mars 2026
|
|
|
|
---
|
|
|
|
# Conclusion
|
|
|
|
Ce projet a été très formateur. Nous avons pour la première fois travaillé avec un **cahier des charges** précis, ce qui nous a obligés à lire attentivement les consignes, à poser des questions, et à ne pas partir dans des directions non demandées. La présence régulière des intervenants a également joué un rôle : savoir que le travail serait relu et évalué de près nous a poussés à être plus rigoureux sur la qualité du code, la documentation et les pratiques Git.
|
|
|
|
Sur le plan technique, la **montée en compétences** a été réelle. En trois semaines, nous sommes passés de données mockées en dur dans les controllers à une application connectée à une base de données, avec des repositories abstraits, une CI/CD fonctionnelle, un middleware de logging et un seeder alimenté par une API externe. Ce n'était pas acquis en début de projet.
|
|
|
|
Pour ma part (Joséphine), c'était la première fois que j'assumais un rôle de **cheffe de projet**. Je l'ai pris très au sérieux, en essayant de structurer le travail de l'équipe sans le surcharger, de maintenir une vision d'ensemble tout en continuant à contribuer au développement. Ce dernier point a été compliqué, j'ai fait autant de revue de code que de développement pur.
|
|
Ce qui m'importait autant que les livrables, c'était que chacun se sente bien dans l'équipe - nous avions des profils très différents, des niveaux différents, et il fallait que tout le monde puisse avancer à sa façon sans se sentir laissé de côté. Je pense que nous y sommes globalement arrivés.
|
|
|
|
Il reste des choses que nous ferions différemment : une conception initiale plus approfondie, des règles de contribution définies dès le départ, et une communication plus formalisée entre dev et ops.
|
|
|
|
### Points qui permettraient d'améliorer le Webzine
|
|
|
|
**Performance du dashboard**
|
|
Le dashboard d'administration effectue plusieurs requêtes `COUNT` distinctes au chargement, ce qui le rend plus lent que le reste de l'application. Des optimisations ont été apportées en cours de projet, mais elles pourraient être encore plus efficaces.
|
|
|
|
**Authentification et gestion des droits**
|
|
L'interface d'administration est accessible sans authentification. Mettre en place un système de connexion avec des rôles (administrateur / visiteur) rendrait l'application utilisable en conditions réelles. Ce point n'était néanmoins pas demandé dans le cahier des charges.
|