CI/CD : définition, étapes d’un pipeline et mise en place

Le CI/CD (intégration continue, livraison continue et déploiement continu) est l’ensemble des pratiques qui font passer chaque modification du code par une chaîne automatique de compilation, de tests et de mise en ligne. Ce guide en donne la définition, distingue ses trois volets, décrit les étapes d’un pipeline, sa sécurité, et la façon de le mettre en place sur une application qui existe déjà.

Il s’adresse aux dirigeants techniques, aux DSI et aux responsables de produit qui veulent livrer plus souvent sans casser la production, et qui se demandent par où commencer. Le CI/CD est au cœur de notre offre infra, DevOps et sécurité web.

Qu’est-ce que le CI/CD ?

Le CI/CD désigne l’automatisation du chemin qui va d’une modification du code à sa mise en production. « CI » signifie intégration continue (continuous integration) ; « CD » signifie, selon le contexte, livraison continue (continuous delivery) ou déploiement continu (continuous deployment). Les trois se suivent : chacun s’appuie sur le précédent.

Martin Fowler, qui a popularisé le terme, définit l’intégration continue comme une pratique où chaque membre d’une équipe fusionne ses modifications dans la base de code commune, avec celles de ses collègues, au moins chaque jour. Jez Humble, coauteur du livre Continuous Delivery, définit la livraison continue comme la capacité à mettre en production des modifications de tout type, de façon sûre, rapide et durable.

Le pipeline CI/CD est la chaîne automatique qui applique ces pratiques : à chaque modification, il compile, teste, analyse, prépare et déploie, et s’arrête dès qu’une étape échoue. Le CI/CD est l’une des pratiques centrales de la démarche DevOps, qui rapproche ceux qui développent et ceux qui exploitent une application.

Intégration continue, livraison continue, déploiement continu : quelle différence ?

La différence tient à l’endroit où l’automatisation s’arrête. L’intégration continue s’arrête à un code fusionné et testé ; la livraison continue, à une version prête à partir ; le déploiement continu va jusqu’à la production, sans validation humaine.

GitLab le résume ainsi dans sa présentation du CI/CD : avec la livraison continue, le logiciel peut être mis en production à tout moment et le déploiement se déclenche manuellement ; le déploiement continu, lui, déploie automatiquement, sans intervention humaine. La plupart des applications métier s’arrêtent à la livraison continue : une personne choisit le moment de la mise en production, souvent pour l’accorder avec les utilisateurs.

Quelles sont les étapes d’un pipeline CI/CD ?

Un pipeline CI/CD enchaîne en général huit étapes, chacune pouvant arrêter la chaîne. Leur détail varie d’une application à l’autre ; leur ordre change peu.

• Le déclenchement. Une modification est poussée sur le dépôt de code ou une demande de fusion est ouverte.
• La compilation (build). Le code est assemblé avec ses dépendances, toujours de la même façon, sans geste manuel.
• Les tests automatiques. Tests unitaires d’abord, rapides ; puis tests d’intégration. Un test qui échoue arrête la chaîne.
• L’analyse du code et des dépendances. Qualité du code, failles connues dans les bibliothèques utilisées, secrets oubliés dans le code.
• Le paquet (artefact). Une image de conteneur ou une archive, construite une seule fois, identifiée par sa version, qui sera la même de la recette à la production.
• Le déploiement en recette. Le paquet est installé sur un environnement aussi proche que possible de la production, avec des données de test.
• La validation. Tests de bout en bout, contrôles de performance ou d’accessibilité, puis la recette fonctionnelle par le client quand elle est prévue.
• La mise en production et la surveillance. Le même paquet part en production ; les journaux et les alertes disent si tout va bien, et un retour à la version précédente reste possible.

Deux règles tiennent l’ensemble. Le pipeline doit rester rapide : Martin Fowler retient la règle d’un build de dix minutes comme raisonnable pour la plupart des projets. Et un pipeline cassé se répare tout de suite, avant toute nouvelle fonction, sinon personne ne lui fait plus confiance.

Les données de recette méritent la même attention que le code : copier la base de production vers un environnement de test pose des questions de protection des données. Notre article sur les données de test et le RGPD détaille les solutions. Les tests eux-mêmes relèvent de notre offre assurance qualité et tests.

Quel outil choisir pour un pipeline CI/CD ?

Le bon outil de CI/CD est d’abord celui qui vit à côté de votre code. GitHub Actions si le code est sur GitHub, GitLab CI s’il est sur GitLab ; Jenkins quand il faut tout héberger chez soi et tout personnaliser ; CircleCI ou d’autres services hébergés quand on veut déléguer l’exécution.

Quatre questions départagent les outils mieux qu’un comparatif de fonctions :

• Où est le code ? Un outil intégré au dépôt évite de gérer un accès de plus.
• Où tournent les traitements ? Sur les machines de l’éditeur, ou sur les vôtres quand le code ou les données ne doivent pas sortir.
• Comment sont gardés les secrets ? Mots de passe et clés d’accès à la production doivent être stockés à part, chiffrés, et accessibles aux seules étapes qui en ont besoin.
• Qui saura le maintenir ? Un pipeline écrit en fichiers lisibles, versionnés avec le code, se reprend ; une configuration cliquée dans une interface se perd.

L’équipe iones met en place des pipelines sur GitHub Actions, GitLab CI, Jenkins ou CircleCI, selon l’existant du client. Le choix de l’outil compte moins que la discipline : des tests qui tournent à chaque modification, et un pipeline que l’on répare dès qu’il casse.

Comment sécuriser un pipeline CI/CD ?

Un pipeline CI/CD se sécurise comme un système de production, parce qu’il en a les clés : il lit le code, détient des secrets et écrit en production. Une attaque sur le pipeline est une attaque sur l’application.

La fondation OWASP a publié une liste des dix principaux risques de sécurité propres au CI/CD (Top 10 CI/CD Security Risks). On y trouve notamment l’absence de contrôle sur ce qui peut partir en production, une gestion des identités et des accès trop large, l’abus de la chaîne de dépendances, l’exécution de code malveillant dans le pipeline, une mauvaise hygiène des secrets, et l’absence de vérification de l’intégrité des paquets. Aux États-Unis, le NIST a consacré en février 2024 une publication entière à la sécurité de la chaîne d’approvisionnement logicielle dans les pipelines CI/CD (SP 800-204D).

• Personne ne pousse seul en production. Une modification de la branche principale passe par une relecture et par le pipeline, sans exception.
• Des droits au plus juste. Chaque étape du pipeline n’a accès qu’à ce dont elle a besoin ; les comptes de service sont distincts des comptes personnels.
• Des secrets hors du code. Stockés dans un coffre ou dans le gestionnaire de secrets de l’outil, changés régulièrement, jamais affichés dans les journaux.
• Des dépendances surveillées. Versions figées, analyse des failles connues à chaque build, mises à jour suivies.
• Des paquets vérifiables. Ce qui part en production est bien ce que le pipeline a construit et testé.
• Des journaux conservés. Qui a lancé quoi, quand, avec quel résultat.

Pour un éditeur de logiciel, ces mesures préparent aussi les obligations du Cyber Resilience Act : savoir ce que contient chaque version et corriger vite une faille dans une dépendance.

Comment mettre en place le CI/CD sur une application existante ?

Sur une application existante, le CI/CD se met en place par étapes, en commençant par ce qui protège le plus : un build automatique et quelques tests, avant tout déploiement automatique.

• Faire l’état des lieux. Où est le code, comment se fait aujourd’hui une mise en production, qui la fait, combien de gestes manuels, quels tests existent. Un audit de l’existant répond à ces questions.
• Mettre tout le code sous contrôle de version. Le code, mais aussi la configuration et les scripts de déploiement. Ce qui n’est pas versionné ne peut pas être automatisé.
• Automatiser le build. Une seule commande, lancée à chaque modification, qui produit l’application sans intervention.
• Ajouter des tests sur les fonctions critiques. Une application sans tests n’en aura pas des centaines en une semaine : on commence par les parcours dont l’activité dépend.
• Automatiser le déploiement en recette. Puis la mise en production, d’abord déclenchée à la main (livraison continue).
• Surveiller et savoir revenir en arrière. Des alertes sur la production et une procédure de retour à la version précédente, testée.

Une application ancienne, sans tests ni documentation, rend ce chemin plus long : chaque étape révèle une part de dette technique. C’est souvent le cas lors d’une reprise d’application web, où le pipeline devient le premier filet de sécurité de la nouvelle équipe.

Comment mesurer ce que le CI/CD change ?

Ce que le CI/CD change se mesure avec quelques indicateurs de livraison, relevés avant et après sa mise en place. Le programme de recherche DORA, aujourd’hui porté par Google Cloud, en retient cinq dans son guide mis à jour le 5 janvier 2026 :

Les trois premiers disent si l’on livre vite, les deux derniers si l’on livre bien. Les suivre ensemble évite de gagner en vitesse au prix de la stabilité. Pour une application en maintenance, le taux d’échec rejoint les indicateurs de la maintenance corrective : moins de déploiements ratés, ce sont moins d’anomalies à corriger en urgence.

Questions fréquentes

CI/CD : commencez par un build qui se teste seul

Le CI/CD ne commence pas par un outil, mais par une habitude : intégrer souvent, compiler et tester à chaque modification, réparer tout de suite ce qui casse. Le déploiement automatique vient ensuite, quand les tests méritent la confiance qu’on leur donne.

L’équipe iones conçoit et met en place des pipelines CI/CD, de l’état des lieux à la mise en production, dans le cadre de son offre infra, DevOps et sécurité web. Pour faire le point sur votre chaîne de livraison, écrivez-nous.