Durant mon stage chez Prokov Editions, j’ai développé le backend d’un module de génération de sites web pour professionnels de santé, intégré à un logiciel médical existant. L’objectif : permettre à n’importe quel utilisateur de créer sa présence en ligne sans aucune compétence technique, à partir de données déjà présentes dans leur dossier professionnel.
Architecture — NestJS comme hub central
Le problème initial : aucune communication automatique entre le CMS Flutter et le builder Astro. J’ai développé une API NestJS qui fait office de point de connexion unique entre tous les modules.
Workflow complet :
- L’utilisateur configure son site via le CMS Flutter
- Le CMS envoie la configuration à l’API qui la stocke
- L’API déclenche un build Astro via un token sécurisé
- Astro récupère la configuration depuis l’API et génère le site statique en moins de 2 secondes
- En mode preview : le site est exposé localement pour que le CMS puisse afficher un aperçu
- En mode production : déploiement automatique vers un serveur de test sous domaine existant
Pourquoi NestJS ? Architecture modulaire native, TypeScript first, DI intégré : le bon choix pour un hub qui doit communiquer avec plusieurs systèmes tout en restant maintenable par d’autres développeurs après le stage.
Décision technique — Bull/Redis plutôt que Docker
Le problème de concurrence : plusieurs utilisateurs peuvent déclencher un build simultanément, mais le serveur ne fait tourner qu’une seule instance du builder Astro.
Ma première approche : plusieurs containers Docker en parallèle. Rejetée rapidement. Astro buildant un site en moins de 2 secondes, le temps de démarrage d’un container dépassait largement le temps de build. Overhead inutile et complexité injustifiée.
Solution retenue : une job queue Redis/Bull. Chaque demande de build est ajoutée à la queue avec ses métadonnées. Un worker dédié traite les tâches séquentiellement, ce qui élimine les race conditions et les conflits sur le système de fichiers. Bull a été choisi pour sa fiabilité, son support des retries et de la priorisation, et sa capacité à scaler horizontalement (ajout de workers sur plusieurs serveurs) sans changer l’architecture.
Validation — Zod à la frontière API/Builder
Pour garantir l’intégrité des données entre le CMS et le builder, j’ai intégré Zod : chaque configuration JSON est validée contre un schéma strict avant d’être traitée. Les erreurs de validation sont capturées tôt avec des messages précis, ce qui réduit considérablement le temps de débogage en cas de données malformées côté CMS.
Initiative personnelle — Dashboard analytique Angular
En avance sur mon planning, j’ai remarqué lors d’une discussion avec l’équipe d’un autre logiciel interne qu’ils disposaient d’un tableau de bord complet pour suivre l’usage de leur produit. L’idée : la donnée est la clé pour prendre de bonnes décisions techniques et produit. J’ai décidé de construire quelque chose de similaire pour notre plateforme.
Pipeline de données :
- Chaque build écrit ses métriques directement dans QuestDB, une base orientée colonnes optimisée pour les séries temporelles
- Les agrégations (totaux, moyennes, distributions, comparaisons de périodes) sont calculées à la volée à chaque requête
- L’API expose les endpoints de stats consommés par le dashboard Angular
Dashboard Angular (choix justifié par ma maîtrise du framework pour livrer un MVP rapide) :
- Vue Bull Board : inspection de la queue, retry des jobs échoués, analyse des logs d’erreur
- Statistiques : nombre de builds totaux, temps moyen de build (2.814s en prod), utilisateurs les plus actifs, taux de réussite/échec
- Distribution par heure et par jour pour identifier les pics d’usage
- Vue comparaison : semaine vs semaine, mois vs mois, avec Chart.js pour visualiser les tendances
Tests & Documentation
L’API était au départ un prototype de connexion temporaire. Sa stabilité en a fait une brique de production du projet. Pour en garantir la fiabilité sur le long terme, j’ai mis en place une suite de tests unitaires Jest avec un objectif de 80% de coverage, un seuil qui permet d’attraper les régressions sans sur-tester l’accessoire.
En parallèle : documentation MkDocs (contexte, décisions d’architecture, guide de contribution) et Swagger sur chaque endpoint (format attendu, réponses possibles, liste des applications consommatrices). Objectif : que quelqu’un puisse reprendre le projet sans moi.
