Une pipeline CI/CD automatise le chemin d'un commit jusqu'à la production : compilation, tests, publication et déploiement, à chaque modification et de la même façon. Cette formation vous apprend le modèle avant l'outil : lire n'importe quelle pipeline, écrire ses étapes dans le dépôt, construire un artefact une fois puis le promouvoir de la recette à la production, et repérer les risques de la chaîne. Elle s'adresse aux admins, ops et développeurs qui n'ont jamais conçu de chaîne, ou qui en copient une sans la comprendre. La pratique se fait sur une forge locale, sans compte GitHub ni GitLab, avant de choisir GitHub Actions, GitLab CI ou Argo CD.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Lire une pipeline et dire ce qu'elle exécute pour un événement donné
- Écrire lint, tests et build comme des cibles du dépôt, orchestrées par la pipeline
- Publier un artefact identifié par sa version et son empreinte
- Promouvoir le même artefact entre environnements, puis revenir en arrière
- Repérer les risques d'une chaîne : secrets, déclencheurs, dépendances, runners
À qui s'adresse cette formation ?
Section intitulée « À qui s'adresse cette formation ? »Elle vise un débutant en CI/CD, pas un débutant en informatique. Trois prérequis suffisent : faire un commit, une branche et une fusion avec Git ; lancer des commandes et lire un code de sortie dans un terminal, ce qu'enseigne la formation Linux ; lire un fichier YAML simple, puisque chaque pipeline en est un. Aucun compte sur un service en ligne n'est demandé.
Ce que la formation n'enseigne pas est renvoyé à la formation qui le
traite : la syntaxe d'un moteur (GitHub Actions, GitLab CI), l'écriture
d'un Dockerfile, le déploiement sur Kubernetes et le GitOps outillé
(Argo CD, Flux CD), le durcissement détaillé d'une pipeline et la chaîne
d'approvisionnement en profondeur, traités par la formation DevSecOps.
Pourquoi automatiser la livraison ?
Section intitulée « Pourquoi automatiser la livraison ? »Prenons une équipe de cinq développeurs. Chaque semaine, le même scénario : un changement casse la production, personne ne sait exactement ce qui a changé, les mises en production se font le vendredi soir et le retour arrière tourne à la panique. Ce chaos a un nom : l'absence d'automatisation fiable du chemin entre le code et la production.
Une pipeline CI/CD résout ce problème : elle construit, teste, valide et déploie chaque modification de la même façon, à chaque fois. Fini le « ça marchait sur ma machine » : le retour arrive en minutes, et ce qui part en production est ce qui a été testé.
CI/CD : que signifie ce sigle ?
Section intitulée « CI/CD : que signifie ce sigle ? »CI/CD désigne l'intégration continue (Continuous Integration) et la
livraison ou le déploiement continus (Continuous Delivery ou
Continuous Deployment). L'intégration continue teste chaque modification à
chaque git push ; la livraison continue garde le code toujours prêt à
déployer, la mise en production restant décidée par un humain ; le déploiement
continu envoie chaque changement validé en production sans intervention.
Ces trois niveaux s'enchaînent : chacun inclut le précédent, et la plupart des équipes ont intérêt à commencer par une CI solide. La leçon CI, Continuous Delivery, Continuous Deployment aide à choisir le niveau adapté, et dit pourquoi une validation humaine est souvent la bonne réponse.
De quoi se compose une pipeline ?
Section intitulée « De quoi se compose une pipeline ? »Une pipeline n'est pas un script : c'est un système d'exécution gouverné. Elle découpe le travail en jobs isolés, regroupés en stages qui s'exécutent dans l'ordre ; des runners exécutent ces jobs, et des artefacts transmettent les résultats d'un job à l'autre. Elle conserve l'historique de chaque exécution, se déclenche sur des événements Git, et expose le statut de chaque étape.
Le tableau résume ce qui sépare un script d'une pipeline. La leçon Qu'est-ce qu'une pipeline CI/CD ?, qui ouvre la formation, détaille chacun de ces composants, la différence entre cache et artefact, et les trois invariants qu'une vraie pipeline doit tenir.
| Ce que fait un script | Ce que fait une pipeline |
|---|---|
| S'exécute sur votre machine | S'exécute dans un environnement contrôlé |
| Succès ou échec, sans détail | Retour par étape : lint passé, tests en échec, build non lancé |
| Aucun historique | Historique complet : qui, quand, quoi, résultat |
| Lancé à la main | Déclenché par un push, une pull request ou un tag |
Comment la formation est-elle organisée ?
Section intitulée « Comment la formation est-elle organisée ? »La formation suit le chemin d'un changement, en quatre modules de cœur, puis deux modules facultatifs. Un apprenant pressé s'arrête au bout du cœur avec les quatre compétences de la formation ; le plan de cours, dans la colonne de gauche, donne chaque leçon et sa durée, et la page Mon parcours suit votre progression.
Comprendre une chaîne de livraison pose le vocabulaire d'une pipeline et le
choix du niveau d'automatisation. Intégrer en continu fait écrire les
étapes dans le dépôt, sous forme de cibles make, puis la pipeline qui ne fait
que les orchestrer ; il place les tests au bon moment et apprend à échouer
vite. Livrer vers des environnements fait construire un artefact une
seule fois, le publier, le promouvoir de la recette à la production et revenir
en arrière, puis présente les stratégies de déploiement progressif et le
GitOps. Sécuriser et faire vivre la chaîne traite les secrets, les
quatre surfaces d'attaque d'une pipeline et les anti-patterns qui la dégradent.
Les deux modules facultatifs approfondissent sans rien exiger du cœur. Organiser la livraison couvre l'architecture des pipelines, le trunk-based development, les feature flags, les causes organisationnelles des échecs et les métriques DORA. Approfondir la sécurité de la chaîne couvre les dix risques OWASP CI/CD, la confiance implicite, les gates qui ne protègent pas et la provenance SLSA.
Comment pratiquer sans compte GitHub ni GitLab ?
Section intitulée « Comment pratiquer sans compte GitHub ni GitLab ? »Les trois leçons pratiques tournent sur une forge locale : une instance
Forgejo 16 et son runner, installés dans une machine virtuelle que
DSOXLab monte sur votre poste. La forge porte le dépôt du fil rouge,
inventaire, un petit service Python sans dépendance. Rien ne part sur
Internet hormis le téléchargement des outils, et la machine se détruit à la fin.
Le fichier de pipeline y suit une syntaxe proche de celle de GitHub
Actions, mais la formation ne l'enseigne pas pour elle-même : la pipeline ne
fait qu'appeler make lint, make test et make build, que vous lancez à
l'identique sur votre poste. C'est ce qui rend le modèle transférable : le
même dépôt se branche ensuite sur GitHub Actions ou GitLab CI en changeant
quelques lignes. L'installation de DSOXLab est décrite dans
la documentation DSOXLab.
Comment la formation se valide-t-elle ?
Section intitulée « Comment la formation se valide-t-elle ? »Chaque leçon, hors cette présentation et l'épreuve finale, se termine par un quiz qui vérifie ce qu'elle enseigne. Les trois leçons pratiques portent chacune un lab DSOXLab, noté sur l'état laissé dans la forge et sur la machine (pipeline verte, artefact publié, même empreinte en recette et en production), jamais sur les commandes tapées.
Le cœur forme un niveau unique, « Comprendre et construire une chaîne de livraison », qui porte quatre compétences propres à la formation : lire une pipeline et dire ce qu'elle fait à chaque événement, écrire les étapes d'intégration dans le dépôt, construire un artefact une fois et le promouvoir, repérer les risques d'une chaîne. Les leçons partagées avec la formation DevSecOps y ajoutent le choix d'une stratégie de livraison et une première approche de la sécurité d'une pipeline, que DevSecOps approfondit.
Quiz et labs entraînent ; ils ne suffisent pas à prouver le niveau. Cette preuve revient à une épreuve de fin de niveau, une chaîne cassée à réparer en lab : une pipeline verte qui ment, à rendre honnête, puis une version corrigée à publier et à promouvoir jusqu'en production. Elle se joue sans indice, notée sur l'état obtenu, et a sa page : Épreuve CI/CD : réparer une chaîne de livraison cassée. Elle demande aussi de savoir lire et corriger une fonction Python de quelques lignes.
Pourquoi la pipeline est-elle une cible ?
Section intitulée « Pourquoi la pipeline est-elle une cible ? »Une pipeline a accès aux secrets, au code source et aux environnements de
production : la compromettre revient à compromettre tout ce qu'elle livre. En
mars 2025, l'action GitHub tj-actions/changed-files, utilisée par plus de
23 000 dépôts, a vu ses tags redéplacés vers un code qui écrivait les
secrets des runners dans les journaux des pipelines qui l'exécutaient. Ces attaques exploitent la confiance implicite accordée aux
dépendances et aux actions tierces.
Le module « Sécuriser et faire vivre la chaîne » traite ce sujet, à commencer par les quatre surfaces de contrôle : identités, dépendances, runners et artefacts. Retenez dès maintenant qu'une sécurité structurelle, qui rend une attaque impossible, vaut mieux qu'un contrôle qui la constate après coup.
Comment choisir son outil de CI/CD ?
Section intitulée « Comment choisir son outil de CI/CD ? »L'outil se choisit d'abord selon l'endroit où vit votre code, puis selon le mode de déploiement. Le tableau compare les options couvertes sur ce site, chacune par sa propre formation ou son guide ; aucune n'est meilleure dans l'absolu, et une même équipe combine souvent un outil de CI et un outil de déploiement GitOps. Le modèle appris ici vaut pour toutes.
| Outil | Forces | Contexte idéal |
|---|---|---|
| GitHub Actions | Intégré à GitHub, catalogue d'actions | Code hébergé sur GitHub |
| GitLab CI/CD | Solution complète, auto-hébergeable | Code hébergé sur GitLab |
| Jenkins | Extensible par plugins, auto-hébergé | Besoins spécifiques, contrôle total |
| Argo CD | GitOps, interface riche, synchronisation | Déploiement continu sur Kubernetes |
| Flux CD | GitOps par contrôleurs, multi-tenancy | Plateformes Kubernetes gérées par Git |
GitOps : quand le cluster tire ses déploiements
Section intitulée « GitOps : quand le cluster tire ses déploiements »Pour le déploiement sur Kubernetes, une autre approche s'est imposée : le
GitOps. Dans le modèle classique, la CI pousse les changements en appelant
kubectl apply ou helm upgrade : le cluster est passif, et une modification
manuelle n'est pas détectée. Dans le modèle GitOps, un opérateur tourne dans
le cluster, lit Git en permanence et réconcilie l'état réel avec ce que Git
décrit.
La CI ne touche alors jamais le cluster : elle pousse un commit, et l'opérateur déploie. Un changement fait à la main sur le cluster est corrigé automatiquement. Le tableau résume la différence ; la leçon GitOps du module « Livrer vers des environnements » la développe, et les formations Argo CD et Flux CD la mettent en pratique.
| Approche | Modèle | Déclencheur | Dérive |
|---|---|---|---|
| CI qui pousse | Impératif | La CI appelle le cluster | Non détectée |
| GitOps qui tire | Déclaratif | L'opérateur lit Git | Détectée et corrigée |
À retenir
Section intitulée « À retenir »- Une pipeline CI/CD automatise le chemin d'un commit à la production, à chaque modification et de la même façon.
- CI, livraison continue et déploiement continu sont trois niveaux, chacun incluant le précédent ; commencez par une CI solide.
- Une pipeline se compose de jobs, de stages, de runners et d'artefacts, et conserve l'historique de chaque exécution.
- Cette formation enseigne le modèle avant l'outil : étapes dans le dépôt, pipeline qui les orchestre, artefact construit une fois et promu.
- La pratique se fait sur une forge locale Forgejo, sans compte en ligne, et chaque lab est noté sur l'état laissé.
- La pipeline est une cible : elle détient secrets, code et accès à la production.
- L'outil se choisit selon l'hébergement du code et le mode de déploiement ; le GitOps fait tirer les déploiements par le cluster.
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »Les questions ci-dessous reviennent le plus souvent chez ceux qui découvrent la CI/CD : la différence entre les trois niveaux, les étapes d'une pipeline, le choix d'un outil et d'une stratégie de déploiement. Chaque réponse résume ce que les leçons de la formation développent.