CI/CD, c’est quoi ? Le pipeline de déploiement expliqué

La CI/CD, c’est la chaîne automatisée qui assemble, vérifie puis met en ligne chaque modification d’un site ou d’une application, en lui faisant franchir toujours les mêmes étapes, dans le même ordre : le pipeline de déploiement. Le sigle réunit l’intégration continue (CI, pour continuous integration), qui teste chaque changement dès qu’il est enregistré, et la livraison ou le déploiement continus (CD, pour continuous delivery ou continuous deployment), qui l’amènent jusqu’à vos visiteurs. Concrètement, à quoi sert la CI/CD ? À mettre en ligne plus souvent, avec moins de risques, et à revenir vite en arrière si une version pose problème.

Ce guide, écrit pour les dirigeants non développeurs, détaille chaque étape, les indicateurs à suivre et les précautions de sécurité à exiger. Il complète nos conseils pour sécuriser et faire durer un projet web.

L’intégration continue : chaque modification vérifiée

Le code d’un site ou d’une application est rangé dans un dépôt, géré par un outil de gestion de versions comme Git : chaque modification y est enregistrée, datée et attribuée à son auteur. Avec l’intégration continue, chaque enregistrement déclenche automatiquement la construction du logiciel et une série de tests. Si un test échoue, la modification est bloquée et l’équipe la corrige avant d’aller plus loin.

Le programme de recherche DORA (DevOps Research and Assessment), mené par Google Cloud, en décrit les bonnes pratiques : des tests qui rendent leur verdict en quelques minutes, avec un plafond d’environ dix minutes, et un travail intégré à la version principale au moins une fois par jour (l’intégration continue selon DORA, en anglais). Une petite modification vérifiée aussitôt se corrige vite ; trois semaines de travail fusionnées la veille d’une livraison peuvent demander des jours de démêlage.

Selon le projet, les tests vérifient par exemple :

• les règles métier : un prix TTC, une remise, un droit d’accès ;
• les parcours essentiels, rejoués dans un vrai navigateur : connexion, demande de devis, commande ;
• la qualité du code et les failles connues des briques logicielles utilisées ;
• pour un site éditorial, les liens, les titres et une partie de l’accessibilité.

Sur le site que vous lisez, par exemple, la construction s’arrête si un seul lien interne est cassé. La CNIL recommande elle aussi, dans son guide RGPD du développeur, un système d’intégration continue qui lance les tests automatiquement à chaque modification du code (fiche « Tester vos applications »).

Livraison continue ou déploiement continu : qui décide ?

Le « CD » recouvre deux pratiques souvent confondues. Tout se joue sur une question : qui décide du moment de la mise en production ?

• La livraison continue (continuous delivery) : chaque version qui a passé les contrôles est prête à partir, et une personne choisit le moment. DORA la définit comme la capacité de mettre en production des changements de toute nature, à la demande, rapidement, en sécurité et durablement.
• Le déploiement continu (continuous deployment) : chaque modification qui franchit toutes les étapes part en production, sans intervention humaine. DORA précise que cette pratique convient bien aux services web, mais ne s’applique pas aux applications mobiles ni aux logiciels embarqués (la livraison continue vue par DORA, en anglais).

Nous privilégions la livraison continue : tout est automatisé jusqu’à l’environnement de recette, et la mise en production part après validation. Garder la main a un autre avantage : avant un temps fort commercial, on peut geler les mises en production, sauf correctif de sécurité ; notre méthode pour préparer son site au Black Friday en fixe les dates et détaille les autres préparatifs.

Prévisualisation, préproduction, production : trois environnements

Avant d’atteindre vos visiteurs, chaque modification traverse plusieurs environnements : des copies du site, chacune avec son rôle.

La préproduction doit ressembler le plus possible à la production : mêmes versions, même configuration, même type d’hébergement. C’est là que se déroule la recette, cette phase de vérification avant la mise en ligne, et c’est là que nous faisons la démo du vendredi pendant un développement : vous testez la vraie version, pas une capture d’écran. Elle sert aussi sans pipeline, pour essayer les mises à jour d’un CMS avant de toucher au site public, comme le rappelle notre guide pour entretenir un site et planifier ses mises à jour.

Côté données, la CNIL est claire dans la même fiche : les données « réelles » de production ne doivent pas être utilisées pendant le développement et les tests. On travaille donc avec des données fictives, ou avec des copies anonymisées.

À quoi ressemble un pipeline de déploiement

Le tour du monde de Phileas Fogg reposait sur un itinéraire calculé d’avance, correspondance par correspondance. Le pipeline est l’itinéraire de votre code : un fichier texte rangé avec lui, dans le dossier .github/workflows pour GitHub Actions ou dans un fichier .gitlab-ci.yml pour GitLab, qui se relit, se versionne et se transmet comme le reste.

Pour un site ou une application web, les escales sont presque toujours les mêmes :

1. Déclenchement : un développeur enregistre une modification ou propose de la fusionner dans la version principale.
2. Construction : le pipeline installe les dépendances, aux versions exactes prévues, puis construit le site ou l’application.
3. Contrôles automatiques : tests, qualité du code, recherche de failles connues.
4. Relecture : une autre personne de l’équipe relit la modification avant qu’elle soit fusionnée.
5. Préproduction : la version est déployée sur l’environnement de recette, où l’on vérifie et valide.
6. Mise en production : la nouvelle version est mise en ligne sans couper le service, puis des vérifications automatiques confirment que les pages clés répondent.
7. Retour arrière : si un indicateur se dégrade, la version précédente, gardée prête, reprend la main.

Pour une application ou une boutique en ligne

Quelques étapes s’ajoutent quand le site manipule des données et des transactions. Les modifications de la base de données passent par le pipeline et restent compatibles avec la version précédente, sans quoi le retour arrière devient délicat. Les parcours critiques — connexion, panier, paiement en mode test — sont rejoués à chaque version.

Une nouveauté peut aussi être livrée désactivée, puis activée le jour de son lancement commercial. Dans nos projets de développement d’applications métier sur mesure, les tests automatisés tournent à chaque modification, et chaque version passe par l’environnement de recette avant la production.

L’infrastructure aussi passe par le pipeline

Serveurs, réseaux, bases de données : avec l’infrastructure as code, tout cela est décrit dans des fichiers, avec des outils comme Terraform ou OpenTofu. Le pipeline calcule d’abord un plan qui montre ce qui sera créé, modifié ou supprimé ; une personne le relit, puis le pipeline l’applique. C’est ainsi que nous bâtissons des infrastructures cloud reproductibles : la préproduction et la production sortent des mêmes fichiers, au lieu de dépendre de réglages faits à la main.

Ce que vous y gagnez : les indicateurs DORA

DORA mesure la performance de livraison logicielle avec cinq indicateurs (le guide des indicateurs DORA, en anglais). Les trois premiers mesurent le débit, les deux derniers l’instabilité.

Les recherches de DORA vont contre une idée reçue : vitesse et stabilité ne s’opposent pas. Les équipes les plus performantes obtiennent de bons résultats sur les cinq indicateurs à la fois, les moins performantes de mauvais résultats sur tous. DORA associe aussi la livraison continue à une meilleure qualité, à des mises en production moins pénibles et à moins d’épuisement dans les équipes. Il met toutefois en garde : ces indicateurs servent à suivre une même application dans le temps, pas à comparer des équipes, et en faire des objectifs incite à les manipuler plutôt qu’à progresser.

Dans son rapport 2025, DORA décrit l’IA comme un amplificateur des forces comme des faiblesses d’une organisation (State of AI-assisted Software Development 2025, en anglais). Plus de code écrit plus vite par les assistants de programmation, ce sont aussi plus de modifications à vérifier : le pipeline sert alors de garde-fou.

Sécuriser la chaîne : secrets, dépendances, accès

Un pipeline détient les clés de la production : mots de passe de base de données, clés d’API, accès à l’hébergement. C’est donc une cible à part entière. L’ANSSI le dit nettement dans ses « Essentiels » consacrés au DevSecOps, publiés en 2024 : les actions réalisées par la CI/CD de production doivent être considérées comme des actions d’administration.

Les 14 et 15 mars 2025, tj-actions/changed-files, un composant tiers de GitHub Actions (une « action »), a été compromis : ses étiquettes de version ont été redirigées vers du code malveillant qui recopiait les secrets des projets dans leurs journaux d’exécution, publics lorsque le dépôt l’est. Selon l’avis de sécurité publié par GitHub (en anglais), plus de 23 000 dépôts étaient concernés. La documentation de sécurité de GitHub Actions le rappelle : une action compromise aurait accès à tous les secrets configurés sur le dépôt. Elle recommande donc de figer chaque action sur un enregistrement précis de son code, de préférence avec un fichier de verrouillage, sinon par son empreinte complète (SHA), car une étiquette peut être déplacée.

Posez ces questions, inspirées des recommandations de l’ANSSI, à votre équipe ou à votre prestataire :

• Les secrets sont-ils rangés dans un coffre dédié, distinct pour la préproduction et la production, et absents du code, des dépôts et des journaux d’exécution ?
• Les accès au dépôt sont-ils nominatifs et protégés par une authentification à plusieurs facteurs ? Qui peut déclencher une mise en production, et ces actions sont-elles journalisées ?
• Les dépendances, composants tiers du pipeline compris, sont-elles limitées au nécessaire, évaluées, et leurs correctifs de sécurité appliqués avant chaque déploiement ?
• Les infrastructures de CI/CD de développement et de production sont-elles séparées, et non exposées directement sur Internet ?

Si plusieurs réponses restent floues, un audit de sécurité qui passe en revue comptes, secrets et dépendances permet de faire le point avant qu’un incident ne s’en charge.

Un pipeline pour un petit site, est-ce utile ?

Oui, à condition de rester léger. Pour un site vitrine statique, comme ceux que nous recommandons, trois étapes suffisent : construire le site, vérifier ses pages et ses liens, puis le publier, d’abord en prévisualisation, ensuite en production. Un site statique est un ensemble de fichiers générés à l’avance : revenir en arrière consiste à republier la version précédente.

Le gain n’est pas la vitesse, c’est la tranquillité : fini les fichiers envoyés à la main sur le serveur et les mises en ligne suspendues à une seule personne, et chaque version publiée laisse une trace. L’outillage, lui, coûte peu. Pour les dépôts privés, l’offre gratuite de GitHub inclut chaque mois 12 dollars d’exécution, soit l’équivalent de 2 000 minutes sur une machine Linux standard facturée 0,006 dollar la minute ; ces machines standard sont gratuites pour les dépôts publics (la facturation de GitHub Actions). L’offre gratuite de GitLab.com inclut 400 minutes de calcul par mois (les quotas de GitLab, en anglais), mais un groupe privé y est limité à cinq utilisateurs (en anglais).

Ces conditions, relevées le 4 novembre 2026, peuvent changer. Le vrai coût est ailleurs : le temps de mettre en place le pipeline et d’écrire des tests utiles, puis de les entretenir. Pour un projet qui exige davantage — boutique à fort trafic, application métier, produit SaaS —, la mise en place d’une infrastructure cloud par notre studio démarre à 4 900 € HT, pipeline compris (nos tarifs d’infrastructure cloud).

Trois questions suffisent pour savoir où vous en êtes : comment une modification arrive-t-elle en production ? Combien de temps faut-il pour revenir à la version précédente ? Où le pipeline est-il décrit, et à qui appartient-il ? Si vous souhaitez en parler, le premier rendez-vous de 30 minutes est gratuit, au studio à Nantes ou en visio.