Refactor & Improve CI

[Dercraker]

Contexte

La pipeline actuelle de CI (build.yml) nécessite une refactorisation complète afin de la rendre plus claire, modulaire et performante.
Un contributeur avait déjà proposé une base très propre dans la PR suivante :
🔗 #49

L’objectif est de reprendre ce travail, de l’adapter à l’état actuel du projet, et de préparer le terrain pour une future CI/CD plus complexe.
La séparation des responsabilités (build, test, audit, déploiement, etc.) doit être nette, afin de faciliter les évolutions et la maintenance.

Design

No response

Frontend

No response

Backend

• Reprendre la PR feat(ci): modularize CI/CD pipeline with dedicated workflows for dependencies, linting, building, and deployment #49 comme référence technique principale.
• Refactoriser le fichier .github/workflows/build.yml :
  • Séparer clairement les étapes : checkout, setup, install, build, test, audit, artefacts.
  • Optimiser les actions communes (caching PNPM, dépendances, etc.).
  • Ajouter des jobs distincts (ex. build, lint, test, audit, deploy) au lieu d’un seul bloc monolithique.
  • Introduire des conditions de déclenchement selon la branche (develop, main, feature/*).
  • Gérer la stratégie de concurrence (ex. concurrency: ci-${{ github.ref }}) pour éviter les exécutions simultanées inutiles.
  • Activer le caching PNPM via actions/cache pour réduire le temps d’installation.
  • Rendre la pipeline extensible pour l’ajout futur de tests E2E, audits Lighthouse, déploiement staging, etc.
• Nettoyer les variables et secrets inutiles.

• Documenter la structure dans un fichier documentation/tech/ci-cd-pipeline.md :
  • Description de chaque job
  • Règles de déclenchement
  • Gestion des artefacts
  • Bonnes pratiques d’extension

Trigger

• Manuellement par un utilisateur sur n'importe quelle branche
• Création de PR sur la branche develop ou main
• Push sur la branche develop
• tag de version v* v1.2.3

Intégration

• Tester la pipeline sur une branche temporaire avant merge sur develop.

• Comparer les performances avant/après (durée moyenne du job, taille des artefacts, etc.).

• Valider la compatibilité avec :

  • Node 20+
  • PNPM 9+
  • GitHub Actions v4

• Préparer une base pour la future pipeline CD (ex. déploiement staging/production conditionnel).

Avant de vous jeter dans le code

• La refactorisation doit être structurelle et pérenne, pas seulement cosmétique.
• Le but est d’avoir une pipeline clairement lisible, maintenable et modulaire.
• Inspirez-vous de la PR feat(ci): modularize CI/CD pipeline with dedicated workflows for dependencies, linting, building, and deployment #49 mais actualisez les dépendances et conventions du projet.
• Privilégiez la lisibilité et la cohérence : chaque job doit avoir une responsabilité unique.