Pipelines CI/CD : automatiser la livraison logicielle
Mise à jour :
Resoudre ce cauchemar sans fin
Imaginez : vous êtes développeur dans une équipe de 5 personnes. Chaque semaine, c’est le même scénario. Quelqu’un pousse du code, ça casse la production. Personne ne sait exactement ce qui a changé. Les mises en production sont stressantes, souvent le vendredi soir. Et quand ça plante, c’est la panique pour revenir en arrière.
Ce chaos a un nom : l’absence d’automatisation fiable.
Une pipeline CI/CD résout ce problème. Elle automatise le chemin entre un commit et la production : compilation, tests, validation, déploiement. Plus de “ça marchait sur ma machine”. Plus de déploiements stressants. Un feedback immédiat sur chaque modification.
Objectif de ce parcours
À la fin de ce parcours, vous saurez :
- Comprendre ce qu’est une pipeline et pourquoi elle change tout
- Distinguer les différents niveaux d’automatisation (CI, Delivery, Deployment)
- Concevoir une pipeline adaptée à votre contexte
- Éviter les pièges classiques qui ruinent l’efficacité
- Sécuriser votre chaîne pour éviter les attaques
Ce n’est qu’après avoir maîtrisé ces fondamentaux que nous aborderons les outils concrets.
À qui s’adresse ce parcours ?
Vous êtes au bon endroit si vous êtes :
- Développeur souhaitant automatiser vos tests et déploiements
- Ops voulant fiabiliser les mises en production
- Tech Lead cherchant à structurer les pratiques de votre équipe
- Débutant curieux de comprendre le DevOps par la pratique
Prérequis :
- Savoir utiliser Git (commits, branches, push)
- Être à l’aise avec la ligne de commande Linux
- Avoir des notions de Docker (recommandé, pas obligatoire)
Votre parcours d’apprentissage
Ce parcours est progressif. Chaque étape s’appuie sur la précédente. Résistez à la tentation de sauter directement aux outils : les concepts sont la clé pour faire les bons choix.
Durée totale estimée : environ 4 heures de lecture active.
Étape 1 — Qu’est-ce qu’une pipeline CI/CD ?
Avant de construire une pipeline, il faut comprendre ce qui la distingue d’un simple script.
Un script Bash, c’est pratique. Vous l’écrivez, vous le lancez, il fait le job. Mais il a des limites :
- Il s’exécute sur votre machine (avec vos configurations)
- Il ne garde aucune trace de ce qui s’est passé
- Il faut le lancer manuellement
- S’il échoue, vous avez juste “erreur”
Une pipeline, c’est autre chose. C’est un système d’exécution gouverné :
| Ce que fait un script | Ce que fait une pipeline |
|---|---|
| S’exécute sur votre machine | S’exécute sur un serveur dédié, environnement contrôlé |
| Succès ou échec, point final | Feedback détaillé par étape : lint ✓, tests ✗, build — |
| Aucun historique | Historique complet : qui, quand, quoi, résultat |
| Déclenché manuellement | Déclenché automatiquement (push, pull request, tag) |
Étape 2 — CI, Delivery, Deployment : trois niveaux d’automatisation
Ces trois termes sont constamment confondus. Ils représentent pourtant des niveaux d’automatisation très différents.
Continuous Integration (CI) — Le minimum vital. Chaque push déclenche compilation, tests, analyse. Le feedback arrive en minutes. Si ça casse, vous le savez immédiatement.
Continuous Delivery — Le code est toujours prêt à partir en production. Mais un humain appuie sur le bouton. Idéal quand vous avez des contraintes réglementaires ou une équipe qui monte en compétence.
Continuous Deployment — Chaque modification validée part automatiquement en production. Zéro intervention humaine. Ça exige une couverture de tests excellente et des mécanismes de rollback solides.
Étape 3 — Anatomie d’une pipeline
Maintenant que vous savez ce qu’est une pipeline et ses niveaux d’automatisation, voyons comment elle est structurée concrètement.
Une pipeline se décompose en stages (phases) qui contiennent des jobs (tâches). Les stages s’exécutent en séquence, les jobs d’un même stage peuvent s’exécuter en parallèle.
Étape 4 — Choisir la bonne architecture
Toutes les pipelines ne se ressemblent pas. Votre architecture dépend de votre contexte : taille de l’équipe, organisation du code, fréquence de déploiement.
Monorepo vs Polyrepo
Trunk-based vs branches longues
Trunk-based : tout le monde travaille sur main. Les feature branches
durent moins de 24h. Exige des feature flags pour les fonctionnalités en cours.
Branches longues : develop, release/*, main. Plus de contrôle, mais
risque de conflits (“merge hell”).
Build once, deploy many
Principe fondamental : l’artefact est construit une seule fois, puis promu d’environnement en environnement. Jamais de rebuild par cible.
Étape 5 — Éviter les pièges classiques
Beaucoup de pipelines échouent non pas à cause de bugs, mais à cause de mauvaises pratiques qui s’accumulent. Voici les anti-patterns les plus fréquents :
| Anti-pattern | Symptôme | Solution |
|---|---|---|
| Pipeline monolithe | 45 min pour un feedback | Découper en stages, paralléliser |
| Tests flaky | ”Relance, ça va passer” | Isoler, corriger ou supprimer |
| Rebuild par environnement | ”Ça marchait en staging” | Build once, deploy many |
| Secrets en clair | Variables d’environnement visibles | Gestionnaire de secrets, OIDC |
| Pas de cache | Téléchargement des dépendances à chaque run | Cache des dépendances |
Étape 6 — Sécuriser la chaîne d’approvisionnement logicielle
Une pipeline CI/CD est une cible de choix pour les attaquants. Elle a accès aux secrets, au code source, aux environnements de production. Si elle est compromise, tout l’est.
Maintenant : choisir un outil
Vous avez maintenant les bases conceptuelles. C’est le moment de passer à la pratique avec un outil concret.
Le choix dépend de votre contexte :
| Outil | Forces | Contexte idéal |
|---|---|---|
| GitHub Actions | Intégration native GitHub, marketplace riche | Votre code est sur GitHub |
| GitLab CI/CD | Solution complète, auto-hébergeable | Votre code est sur GitLab |
| Jenkins | Extensibilité maximale, plugins pour tout | Grandes entreprises, besoins spécifiques |
| Dagger | Pipelines programmables en code | Multi-plateformes, portabilité |
Auto-évaluation
Avant de passer aux guides pratiques, vérifiez votre compréhension :
- Je sais expliquer la différence entre un script et une pipeline
- Je peux distinguer CI, Continuous Delivery et Continuous Deployment
- Je connais les composants d’une pipeline (job, stage, runner, artefact)
- Je comprends le principe “build once, deploy many”
- Je sais identifier les 4 surfaces de contrôle pour la sécurité
- Je reconnais au moins 3 anti-patterns courants
Toutes les cases cochées ? Vous êtes prêt pour la mise en pratique. Commencez par GitHub Actions si votre code est sur GitHub, ou GitLab CI/CD sinon.