Dans les coulisses de mon dernier side project: l'architecture technique

Je me suis lancé dans un side project pour gérer les rétrospectives de mon équipe, une application que je construis depuis plusieurs mois et dont j’ai décidé de raconter les coulisses de la création.

Des outils de rétrospective, il y en a énormément. Mais comme tout développeur, j’ai eu envie de créer le mien, celui qui correspond exactement à mes besoins (et bien plus). C’est également un excellent moyen pour apprendre, approfondir et/ou explorer des concepts techniques qui m’intéressent. D’un besoin d’équipe technique et de cette envie est né: Team Retrospective.

Au départ, le besoin était simple: avoir un tableau pour gérer des rétrospectives: 5 colonnes, pour aborder 5 thématiques en équipe et faire le bilan de l’itération écoulée. Les fonctionnalités ont évolué au fil des rituels et des équipes qui l’ont adopté.

D’un point de vue technique, c’est un projet PHP propulsé par le framework Symfony et sa stack Symfony UX. Des technologies simples et maîtrisées que j’utilise dans mon quotidien professionnel. Team Retrospective c’est également 10 contextes bornés pour gérer les utilisateurs et les équipes, les rétrospectives, les actions et accords associés, des modules IA et diverses fonctionnalités additionnelles. S’ajoute à ces contextes un Shared Kernel pour gérer toutes les notions transverses.

Parmi les notions transverses, on retrouve de nombreux concepts et patterns techniques:

• Divers bus de communication: Command Bus, Query Bus et Event Bus,
• Des modules de communication en temps réel basés sur le protocole Mercure,
• Une gestion des healthchecks pour évaluer la santé de l’application,
• Ou des modèles de base communs à tous les modules pour gérer les entités ou l’identification de ces dernières.

Chaque contexte métier est structuré en suivant les principes de la Clean Architecture avec le classique découpage en 4 couches: Domain, Use Case, Infrastructure et Presentation. Pour les besoins de communication entre modules, chaque contexte peut exposer une API publique qui sera matérialisée au sein d’une cinquième couche Contracts.

Le projet possède une documentation riche:

• Une présentation succincte du projet dans un fichier (README.md),
• La présentation de la vision produit dans un fichier (PRODUCT.md),
• Un glossaire et une présentation des différents contextes métier (CONTEXT.md),
• Une liste de changements par version (CHANGELOG.md),
• Les instructions pour les agents de code (AGENTS.md et CLAUDE.md),
• Diverses documentations techniques dans un répertoire docs contenant également l’ensemble des décisions d’architecture du projet.

Le projet est entièrement conteneurisé, aussi bien en développement qu’en production, et son infrastructure est gérée via de l’Infrastructure as Code.

Ce projet concentre beaucoup de concepts. Il s’agit de fondations que j’ai pu mettre en place en un temps record et avec un minimum d’effort grâce aux agents de code. Cette architecture pose un cadre clair, délimité et cohérent qui permet à l’IA de s’y retrouver facilement. Car si cette dernière écrit la majorité du code du projet, je conserve un droit de lecture et de modification et surtout, moi seul conçois l’architecture.