CI/CD : comprendre l'intégration et le déploiement continus

Une fois que le code est versionné avec Git, une question se pose vite : comment s’assurer que chaque changement fonctionne vraiment, et comment le faire arriver en production sans stress ? C’est le rôle du CI/CD, l’intégration continue et le déploiement continu.

Ces deux sigles désignent en réalité deux pratiques distinctes mais complémentaires. La CI (intégration continue) vérifie automatiquement que chaque changement de code s’intègre proprement au reste du projet. Le CD (déploiement continu, ou livraison continue) automatise ensuite le chemin qui mène ce code jusqu’en production. Ensemble, ils forment un pipeline : une chaîne d’étapes automatisées qui transforme un commit en une version livrée, sans intervention manuelle à chaque étape.

Cet article suit la même logique que celui sur Git et GitHub : comprendre les grands principes : partir du problème concret que ces pratiques résolvent, puis construire progressivement une compréhension plus technique, jusqu’aux stratégies de déploiement avancées.

Le problème que le CI/CD est venu résoudre

Avant l’intégration continue, une pratique répandue consistait à laisser chaque développeur travailler de son côté pendant plusieurs jours ou semaines, puis à fusionner tout le monde en une seule fois. Ce moment, souvent redouté, portait un nom : l’“integration hell” (l’enfer de l’intégration). Plus le délai entre deux fusions est long, plus les changements divergent, et plus les conflits à résoudre sont nombreux et difficiles à comprendre.

Le problème ne s’arrête pas à la fusion : même un code qui fusionne proprement peut casser silencieusement une fonctionnalité ailleurs dans le projet. Sans vérification systématique, ce genre de régression n’est souvent découvert que bien plus tard, une fois en production, au pire moment possible.

L’intégration continue part d’un principe simple : intégrer le code le plus souvent possible, plusieurs fois par jour dans l’idéal, et vérifier automatiquement à chaque fois que rien n’est cassé. Plus la boucle de retour est courte, moins un problème coûte cher à corriger.

Ce qu’est concrètement un pipeline

Techniquement, un pipeline CI/CD est une suite d’étapes automatisées, déclenchées à chaque changement dans le dépôt Git, typiquement à chaque push ou à chaque pull request. Chaque étape doit réussir pour que la suivante se lance ; si une étape échoue, le pipeline s’arrête et prévient l’équipe.

Les étapes les plus courantes sont : l’installation des dépendances, la compilation ou le build, l’exécution des tests automatisés (unitaires, puis souvent d’intégration), l’analyse statique du code (linting, sécurité), et enfin l’empaquetage du résultat, une image Docker, un binaire, ou un autre type d’artefact.

Cette suite d’étapes est décrite dans un fichier de configuration versionné avec le code lui-même, souvent au format YAML. Sur GitHub, ce sont les GitHub Actions ; des équivalents existent ailleurs sous d’autres noms (GitLab CI, CircleCI, Jenkins). Un exemple minimal avec GitHub Actions :

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test

Chaque exécution du pipeline se fait sur un “runner” : une machine, souvent une machine virtuelle éphémère, provisionnée juste pour l’occasion, qui exécute les étapes puis disparaît. Cette approche garantit un environnement propre et reproductible à chaque exécution, indépendant de la machine de tel ou tel développeur.

De l’intégration continue à la livraison continue

Une fois que le code est vérifié automatiquement, l’étape suivante consiste à automatiser aussi son chemin vers la production. C’est là que la distinction entre les deux définitions du “CD” devient importante, et c’est un point souvent confondu.

La livraison continue (continuous delivery) garantit que le code est, à tout moment, dans un état prêt à être déployé, mais le déploiement effectif reste déclenché manuellement, généralement par une validation humaine. Le déploiement continu (continuous deployment) va un cran plus loin : chaque changement qui passe tous les tests est automatiquement déployé en production, sans intervention humaine.

Le choix entre les deux n’est pas qu’une question d’outillage, c’est une question de confiance : plus la suite de tests automatisés est fiable et complète, plus il devient réaliste d’aller jusqu’au déploiement continu sans risque excessif.

Les environnements et la promotion du code

En pratique, le code saute rarement directement du poste du développeur à la production. Il traverse généralement plusieurs environnements successifs : développement, staging (ou recette, un environnement qui imite la production), puis production. On parle de “promotion” du code d’un environnement à l’autre, chaque étape servant de filet de sécurité supplémentaire.

Cette progression permet de détecter des problèmes qui n’apparaissent que dans des conditions proches du réel (volume de données, configuration réseau, services externes), avant qu’ils n’atteignent les utilisateurs finaux. Un pipeline CI/CD bien construit orchestre cette promotion automatiquement : le code qui réussit tous les tests sur staging devient candidat au déploiement en production, souvent via une pull request ou une validation explicite.

Pour aller plus loin

Cet article s’arrête à une compréhension générale du CI/CD, mais plusieurs pratiques plus avancées méritent d’être creusées séparément : les stratégies de déploiement comme le blue-green (deux environnements de production identiques, on bascule le trafic de l’un à l’autre) ou le canary (on déploie d’abord à une petite portion des utilisateurs avant de généraliser), la gestion des secrets (clés API, mots de passe) dans un pipeline sans jamais les exposer en clair, le cache des dépendances pour accélérer les exécutions, ou encore les pipelines en matrice, qui testent un même code sur plusieurs versions de langage ou plusieurs systèmes d’exploitation en parallèle.

Associé à Git et GitHub, le CI/CD complète le socle de base pour faire tourner un projet de développement avec sérénité : versionner le code, vérifier automatiquement chaque changement, et le livrer sans stress.