--- title: "CI/CD, c’est quoi ? Le pipeline de déploiement expliqué" description: "CI/CD, c’est quoi ? Nous expliquons sans jargon l’intégration, la livraison et le déploiement continus, la préproduction, les indicateurs DORA et la sécurité." canonical_url: "https://studiofogg.fr/journal/ci-cd-pipeline-de-deploiement" --- > Index of every page on this site: [llms.txt](https://studiofogg.fr/llms.txt) 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](https://studiofogg.fr/journal/rubrique/projet-web-budget-methode). ## 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](https://dora.dev/capabilities/continuous-integration/), 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 »](https://www.cnil.fr/fr/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](https://dora.dev/capabilities/continuous-delivery/), en anglais).
Critère Intégration continue Livraison continue Déploiement continu
Ce qui est automatisé Construction et tests de chaque modification En plus : préparation de la version et déploiement en préproduction En plus : mise en production
Qui déclenche la mise en ligne Une personne, par une procédure à part Une personne, d’un clic Le pipeline, dès que tous les contrôles passent
Pour qui Tout projet qui comporte du code Sites et applications dont les mises en ligne suivent une validation ou un calendrier Services web bien couverts par les tests et surveillés en continu
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](https://studiofogg.fr/journal/preparer-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.
Environnement À quoi il sert Qui s’en sert Quelles données
Prévisualisation Montrer une modification isolée, à une adresse dédiée, avant qu’elle rejoigne le reste L’équipe, et vous pour un avis rapide Fictives
Préproduction (ou recette) Valider la version complète dans des conditions proches du réel Vous et l’équipe, pendant la recette Fictives ou anonymisées
Production Servir vos visiteurs et vos clients Tout le monde Réelles
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](https://studiofogg.fr/glossaire#recette), 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](https://studiofogg.fr/journal/maintenance-site-internet-que-prevoir). 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](https://studiofogg.fr/services/developpement-web-sur-mesure-nantes), 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](https://studiofogg.fr/services/infrastructure-cloud-nantes) : 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](https://dora.dev/guides/dora-metrics/), en anglais). Les trois premiers mesurent le débit, les deux derniers l’instabilité.
Indicateur Ce qu’il mesure La question pour vous
Délai de mise en production ( change lead time ) Le temps entre l’enregistrement d’une modification et son arrivée en production Combien de temps une correction déjà écrite attend-elle avant d’être en ligne ?
Fréquence de déploiement ( deployment frequency ) Le nombre de mises en production sur une période À quel rythme vos clients voient-ils les améliorations ?
Temps de rétablissement ( failed deployment recovery time ) Le temps pour se remettre d’un déploiement qui exige une intervention immédiate Combien de temps dure une panne causée par une mise à jour ?
Taux d’échec des changements ( change fail rate ) La part des déploiements qui exigent une intervention immédiate Combien de mises à jour cassent quelque chose ?
Taux de déploiements correctifs ( deployment rework rate ) La part des déploiements non planifiés, faits pour réparer un incident en production Quelle part du travail sert à réparer plutôt qu’à avancer ?
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](https://dora.dev/research/2025/dora-report/), 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](https://messervices.cyber.gouv.fr/guides/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](https://github.com/advisories/GHSA-mrrh-fwg8-r2c3) (en anglais), plus de 23 000 dépôts étaient concernés. [La documentation de sécurité de GitHub Actions](https://docs.github.com/fr/actions/reference/security/secure-use) 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](https://studiofogg.fr/services/audit-securite-site-web-nantes) 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](https://docs.github.com/fr/billing/concepts/product-billing/github-actions)). L’offre gratuite de GitLab.com inclut 400 minutes de calcul par mois ([les quotas de GitLab](https://docs.gitlab.com/ci/pipelines/compute_minutes/), en anglais), mais un groupe privé y est [limité à cinq utilisateurs](https://docs.gitlab.com/user/free_user_limit/) (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](https://studiofogg.fr/tarifs#infrastructure-cloud-nantes)). 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. ## Sitemap See the full [sitemap](https://studiofogg.fr/sitemap.md) for all pages.