CI/CD
Définition
Continuous Integration / Continuous Deployment. Pipeline automatisé qui lance les tests, build le projet et déploie en production à chaque commit. Standard via GitHub Actions ou GitLab CI.
Comment ça marche
CI/CD signifie Continuous Integration et Continuous Deployment. Le principe : chaque commit pushé sur le dépôt Git déclenche automatiquement un pipeline qui lance les tests, build l'application, vérifie la qualité (linter, typecheck) et déploie sur un environnement de preview ou directement en production. Le pipeline est défini en YAML (GitHub Actions, GitLab CI) ou via une config dédiée (Vercel, Netlify). Il tourne sur des runners (machines virtuelles éphémères) qui exécutent les étapes une à une. Si une étape échoue, le merge sur main est bloqué jusqu'à correction.
À quoi ça sert
Trois bénéfices majeurs. La détection précoce : un test qui casse en CI signale le bug avant qu'il n'arrive en production, où il coûte 10 à 100 fois plus à corriger. La vitesse de livraison : une équipe avec CI/CD solide déploie plusieurs fois par jour sans peur ; sans CI/CD, on déploie une fois par semaine en transpirant. La cohérence : tout passe par les mêmes étapes automatisées, plus de "chez moi ça marche". Pour un projet sérieux qui veut grossir et accueillir plusieurs développeurs, c'est non négociable, autant que les tests ou Git.
Les outils
GitHub Actions domine sur les projets Git hébergés chez GitHub : intégration native, écosystème d'actions réutilisables, free tier généreux pour les repos publics. GitLab CI est l'équivalent pour les équipes GitLab, souvent self-hosted dans les entreprises. Vercel et Netlify intègrent leur propre CI/CD orientée déploiement, sans configuration : tu push, ça build, ça déploie. CircleCI et Buildkite ciblent les équipes plus mûres avec besoins de parallélisme avancé. Pour les projets sensibles à la souveraineté, on auto-héberge Forgejo Actions ou Drone CI sur un VPS interne.
Les étapes typiques
Un pipeline Next.js standard enchaîne : install des dépendances (cache pnpm pour gagner du temps), typecheck avec tsc, linter (ESLint, Biome), tests unitaires (Vitest, Jest), build de l'application, déploiement sur preview ou production. Pour un projet avec base de données, on ajoute la vérification des migrations, voire un test d'intégration sur une base éphémère. Pour un SaaS, on ajoute les tests E2E avec Playwright sur l'environnement de preview avant production. La durée totale doit rester sous 5 minutes pour ne pas freiner l'équipe.
Quand l'utiliser
Toujours, dès le premier commit d'un projet sérieux. Même un MVP solo bénéficie d'un build automatique qui vérifie que tout compile à chaque push. Sur un projet à plusieurs développeurs, la CI/CD est ce qui empêche les régressions d'arriver en main sans qu'on le sache. Pour un SaaS B2B, c'est ce qui permet de pousser des correctifs en production sans interrompre les utilisateurs. Le coût d'entrée est faible : 2 à 4 heures pour un pipeline Next.js complet sur GitHub Actions. Le retour sur investissement est immédiat dès la première semaine de production.
Les bonnes pratiques
On bloque le merge sur main si la CI n'est pas verte : c'est non négociable, sinon la CI ne sert à rien. On garde le pipeline court : tout ce qui dépasse 10 minutes pousse les devs à contourner ou à attendre, ce qui dégrade la qualité. On cache agressivement (node_modules, .next/cache) pour accélérer. On parallélise les étapes indépendantes (tests + lint en même temps). On utilise des environnements éphémères par PR pour valider visuellement. Et on logue les déploiements (qui, quoi, quand) pour pouvoir auditer ou revenir en arrière rapidement en cas d'incident.
Les pièges à éviter
Le piège du "vert même quand c'est cassé" : des tests fragiles qui passent en local mais échouent aléatoirement en CI poussent à les désactiver progressivement. On les corrige plutôt que de les ignorer. Le piège du pipeline trop lent : 30 minutes pour merger un fix d'une ligne, c'est insupportable, l'équipe contourne. On surveille la durée, on optimise. Le piège des secrets en clair : ne jamais commit des credentials, toujours passer par les secrets manager de la plateforme (GitHub Secrets, Vercel Encrypted Env Vars). Et le piège du déploiement automatique en prod sans tests E2E : on garde un garde-fou humain sur les changements critiques.