La magie des pipelines CI/CD dans le développement moderne
Anatomie d'un pipeline CI/CD : du code à la production en 10 minutes
Un pipeline CI/CD bien construit est invisible : les développeurs pushent du code, et quelques minutes plus tard, il tourne en production. Mais derrière cette simplicité apparente, il y a une orchestration minutieuse de dizaines d'étapes. Voici comment je construis mes pipelines, avec des exemples tirés de mes missions.
Étape 1 : Le build et le lint
Tout commence par la validation du code. Le lint (ESLint, Ruff, golangci-lint selon le langage) est la première étape car c'est la plus rapide. Si le code ne respecte pas les conventions, inutile de continuer.
Sur WizOps.fr, le pipeline commence par pnpm lint (ESLint) et pnpm typecheck (TypeScript) pour le frontend Nuxt.js, et poetry run ruff check pour le backend Django. Ces deux étapes prennent moins de 30 secondes et attrapent les erreurs de style, les imports inutilisés, les erreurs de typage.
Étape 2 : Les tests
Après le lint, les tests. Chez Bloomflow, nous avions structuré les tests en deux niveaux. Le niveau 1 (tests unitaires et tests de composants) tournait sur chaque PR et prenait 3 minutes. Le niveau 2 (tests d'intégration, tests e2e) tournait uniquement sur main après le merge et prenait 15 minutes.
Cette séparation est cruciale pour le feedback rapide. Un développeur qui ouvre une PR obtient un résultat en 3 minutes. S'il doit attendre 15 minutes, il passe à autre chose et perd le contexte.
Étape 3 : Le build Docker
Le build de l'image Docker est souvent le goulot d'étranglement du pipeline. Les optimisations que j'applique systématiquement : builds multi-stage (séparer les dépendances de build du runtime), cache des couches Docker (les dépendances changent moins souvent que le code), et utilisation de Buildx pour les builds multi-plateforme (amd64 + arm64).
Chez TEKYN, ces optimisations ont réduit le build Docker de 8 minutes à 90 secondes. La clé était l'ordre des instructions dans le Dockerfile : COPY des fichiers de dépendances (package.json, poetry.lock) avant le COPY du code source. Ainsi, tant que les dépendances ne changent pas, la couche est réutilisée depuis le cache.
Étape 4 : Les scans de sécurité
Après le build, le scan de l'image Docker avec Trivy (ou Snyk) détecte les vulnérabilités. Chez KNDS dans le secteur de la Défense, cette étape était bloquante : aucune image avec une CVE critique ne pouvait être déployée. Chez Bloomflow en contexte ISO 27001, les CVE étaient remontées et suivies dans un registre de vulnérabilités avec des SLA de correction.
J'ajoute aussi gitleaks pour détecter les secrets accidentellement commités dans le code. C'est rapide (quelques secondes) et ça attrape les tokens AWS, les mots de passe, les clés privées qui n'auraient jamais dû être versionnés.
Étape 5 : Le push et le déploiement
L'image est buildée, testée, scannée. Elle est maintenant poussée vers le registre Docker (GHCR pour WizOps.fr, ECR pour les projets AWS, Artifact Registry pour GCP). Puis le déploiement est déclenché.
Sur mes projets Kubernetes, le déploiement passe par ArgoCD en mode GitOps : le pipeline met à jour le tag de l'image dans le repo GitOps, et ArgoCD synchronise le cluster. Chez Padam Mobility, ce processus était entièrement automatisé : du push du code au déploiement en production, 10 minutes sans intervention humaine.
Le pipeline en chiffres
Sur les projets que j'ai accompagnés, voici les benchmarks que je vise : lint et typecheck en moins de 1 minute, tests unitaires en moins de 5 minutes, build Docker en moins de 2 minutes, scans de sécurité en moins de 1 minute, push de l'image en moins de 1 minute. Total du pipeline CI : moins de 10 minutes. Le déploiement CD via ArgoCD ajoute 2-3 minutes. Du commit à la production : moins de 15 minutes.