Pipeline CI/CD expliqué : du code à la production étape par étape

J’ai pushé sur main un vendredi après-midi. Pas de tests, pas de staging, rien du tout. Juste git push origin main et un script de déploiement qui se lançait à chaque merge. J’ai fermé mon laptop, je suis rentré chez moi, et j’ai commencé à faire des pâtes.

Le temps que l’eau bouille, mon téléphone vibrait. Slack. PagerDuty. Un message de mon manager qui disait juste “le site est down.” J’ai passé les quatre heures suivantes à faire un rollback d’un changement CSS de trois lignes qui avait mystérieusement cassé le formulaire de login en production. Un vendredi soir. Avec des pâtes froides.

C’est cette nuit-là que j’ai décidé d’apprendre ce qu’un pipeline CI/CD était vraiment, au lieu de faire semblant que mon script de déploiement en était un.

CI vs CD vs CD (oui, il y a deux CD)

La soupe d’acronymes perd tout le monde. Laisse-moi démêler ça.

L’Intégration Continue (CI) c’est le fait de merger du code dans une branche partagée fréquemment — plusieurs fois par jour, idéalement — et de lancer des vérifications automatisées à chaque fois. Tests, linting, scans de sécurité, tout ce que ton équipe juge important. Le but c’est d’attraper les problèmes tôt, quand le changement est petit et que le contexte est encore frais dans ta tête.

Avant la CI, les équipes développaient en isolation pendant des semaines, puis mergeaient tout d’un coup. Ce jour de merge était toujours un carnage. La CI rend la douleur petite et continue au lieu de grande et catastrophique. Des petites coupures de papier plutôt qu’une fracture ouverte.

La Livraison Continue (CD #1) signifie que ton code est toujours dans un état déployable. Chaque commit qui passe le pipeline pourrait aller en production. Mais un humain appuie encore sur le bouton. T’as un candidat de release qui attend là, testé et empaqueté, jusqu’à ce que quelqu’un dise “go.”

Le Déploiement Continu (CD #2) supprime l’humain. Chaque commit qui passe toutes les vérifications va directement en production. Automatiquement. Pas de bouton. Pas d’attente. Flippant ? Un peu. Mais si tes tests sont solides, c’est en fait moins risqué que d’accumuler deux semaines de changements et de tout déployer en même temps en croisant les doigts.

La plupart des équipes commencent par la CI, ajoutent la Livraison Continue, et ne passent au Déploiement Continu que quand elles font confiance à leur suite de tests. Cette confiance prend du temps. Et c’est normal.

Un pipeline en français simple

Enlève l’outillage et un pipeline c’est juste une série d’étapes automatisées que ton code traverse entre “je l’ai écrit” et “les utilisateurs le voient.” Voilà le parcours :

1. Commit. Tu pushes du code vers un dépôt. Git le récupère. C’est le déclencheur — le coup de pistolet.

2. Build. Le pipeline compile ton code, installe les dépendances, bundle les assets. Tout ce que “préparer le code” veut dire pour ta stack. Pour une app Node, c’est npm install et peut-être un build webpack. Pour du Go, c’est go build. Si cette étape échoue, rien d’autre ne tourne. Aucun intérêt de tester du code qui compile pas.

3. Test. Les tests unitaires d’abord — rapides, isolés, couvrant des fonctions individuelles. Ensuite les tests d’intégration — vérifier que les composants se parlent correctement. Peut-être des tests end-to-end si t’en as. Le pipeline s’arrête au premier échec. C’est le filet de sécurité. C’est ce qui aurait attrapé mon désastre du vendredi.

4. Vérifications qualité. Linting, formatage, scan de sécurité, peut-être un seuil de couverture de tests. Certaines équipes bloquent sur tout. D’autres choisissent ce qui compte le plus pour elles. Le point c’est la constance — ces vérifications tournent à chaque fois, pas juste quand quelqu’un y pense.

5. Déploiement en staging. Si tout passe, le code atterrit dans un environnement qui ressemble à la production. C’est là que t’attrapes ce que les tests automatisés loupent — des bugs visuels, des problèmes de performance, des cas limites bizarres qui n’apparaissent qu’avec des données quasi-réelles.

6. Déploiement en production. L’étape finale. Soit un humain valide (Livraison Continue) soit ça se fait automatiquement (Déploiement Continu). Dans les deux cas, le code est maintenant live.

C’est tout. Six étapes. Tous les systèmes CI/CD du monde sont une variation de cette séquence, avec des étapes supplémentaires boulonnées dessus selon les besoins de l’équipe.

Un vrai exemple avec GitHub Actions

La théorie c’est bien. Laisse-moi te montrer à quoi ça ressemble concrètement. Voilà un workflow GitHub Actions pour une app Node.js — le genre de fichier que tu mettrais dans .github/workflows/ci.yml :

name: Pipeline CI/CD

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Run tests
        run: npm test

      - name: Build
        run: npm run build

  deploy:
    needs: build-and-test
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy to production
        run: ./scripts/deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Je t’explique.

Le bloc on définit les déclencheurs. Ce pipeline se lance à chaque push sur main et chaque pull request ciblant main. Les pull requests passent par le build et les tests — tu sais si ton code est cassé avant de merger. Les pushes sur main ont le pipeline complet, déploiement inclus.

build-and-test est un job. Il tourne sur une machine Ubuntu toute fraîche. Les étapes s’exécutent dans l’ordre : cloner le repo, installer Node, installer les dépendances avec npm ci (installations déterministes, pas npm install), lint, test, build. Une étape échoue, tout le job échoue.

deploy est un job séparé qui ne tourne qu’après la réussite de build-and-test (needs: build-and-test). La condition if le restreint aux pushes sur main — les pull requests ne déclenchent pas de déploiement. Le script de déploiement utilise un token secret stocké dans les secrets de GitHub, jamais en dur dans le code.

Trente lignes de YAML. C’est suffisant pour attraper la majorité des problèmes catastrophiques. Mon désastre des pâtes du vendredi aurait été arrêté à l’étape des tests, et j’aurais eu une croix rouge sur ma pull request au lieu d’une alerte PagerDuty pendant le dîner.

Les outils courants (choisis-en un, apprends-le bien)

Le marché des outils CI/CD est bondé. Voici ceux qui comptent :

GitHub Actions. Intégré à GitHub. Gratuit pour les repos publics, free tier généreux pour les privés. Si ton code est déjà sur GitHub, commence par là. L’écosystème d’actions pré-construites est énorme, et la syntaxe YAML est assez claire une fois passée la courbe d’apprentissage initiale.

GitLab CI/CD. Intégré à GitLab. Même idée, format YAML différent. Si ton équipe utilise GitLab, te bats pas. Le CI de GitLab est vraiment bon — certains diraient meilleur que GitHub Actions pour les pipelines complexes.

Jenkins. La vieille garde. Open source, auto-hébergé, configurable à l’infini. Et aussi infiniment frustrant à maintenir. Jenkins peut tout faire, mais ça demande plus de boulot pour le mettre en place et le faire tourner. J’ai vu des serveurs Jenkins traités comme des animaux de compagnie — nommés, choyés, redoutés. Si ta boîte utilise déjà Jenkins, tu apprendras Jenkins. Si tu pars de zéro, prends un truc hébergé.

CircleCI. Hébergé dans le cloud, interface propre, bon support Docker. Populaire chez les startups. Fait le taf sans prise de tête.

Honnêtement, l’outil compte moins que tu penses. Les concepts se transfèrent. J’ai utilisé les quatre, et le modèle mental est le même partout : déclencheur, build, test, déploiement. Le YAML est différent. Les dashboards sont différents. La boucle de base est identique.

Si t’es en train d’apprendre, utilise GitHub Actions. C’est gratuit, c’est là que vivent la plupart des projets open source, et t’auras un truc qui tourne en moins d’une heure.

Les anti-patterns des pipelines (apprends de mes erreurs)

J’ai construit des mauvais pipelines. Plus que j’aimerais l’admettre. Voilà ce que j’ai appris à la dure.

Pas de tests dans le pipeline. Un pipeline qui fait juste build et déploie, c’est un script FTP glorifié. Le but c’est d’attraper les problèmes avant la production. Si ton pipeline ne lance pas de tests, c’est pas un pipeline CI/CD. C’est de l’imprudence automatisée.

Des tests qui prennent 45 minutes. J’ai bossé sur un projet où la suite de tests prenait presque une heure. Les gens commençaient à pusher sans attendre les résultats. Ils mergeaient les PRs avec une attitude “ça devrait aller”, et ça allait pas. Si ton pipeline est trop lent, les gens vont le contourner. Optimise les tests lents. Parallélise. Lance les rapides d’abord pour échouer tôt.

Déployer le vendredi après-midi. Je t’ai déjà raconté cette histoire. Ne déploie pas le vendredi. Ou alors, seulement si t’as une stratégie de rollback solide et rien de prévu le soir. Et encore.

Des secrets dans le repo. J’ai vu des clés API committées dans .github/workflows/ci.yml en clair. Une fois. Ce repo était public. La clé était pour un service payant. Tu devines la suite. Utilise la gestion de secrets de ton outil CI. Tous en ont une.

Ignorer les tests instables. Un test qui passe 90% du temps, c’est pas un test. C’est un générateur de nombres aléatoires qui parfois te dit que ton code est cassé. Corrige les tests instables immédiatement ou supprime-les. Ne relance pas le pipeline jusqu’à ce que ça passe au vert — ça apprend à ton équipe à ne plus faire confiance au système.

Pas d’environnement de staging. Déployer directement de “les tests passent” à la production, c’est audacieux. Parfois trop. Un environnement de staging attrape ce que les tests loupent. Des bugs de mise en page. Des régressions de performance. Ce truc bizarre qui n’apparaît que quand la base a plus de dix mille lignes.

Ton premier pipeline : étape par étape

Si t’as jamais mis en place un pipeline, voilà comment démarrer. Vingt minutes, grand maximum.

1. Crée un dépôt GitHub avec un projet simple. Une app Node.js avec quelques tests, un script Python avec pytest, peu importe ta stack. L’app n’a pas d’importance. Le pipeline si.

2. Crée le fichier de workflow. Fais un dossier .github/workflows/ dans ton repo. Ajoute un fichier ci.yml. Colle l’exemple ci-dessus, ajusté pour ton langage.

3. Pousse-le. Commit et push. Va dans l’onglet “Actions” de ton repo GitHub. Regarde ça tourner. Y’a quelque chose de satisfaisant à voir ces coches vertes apparaître une par une. Et quelque chose d’utile à voir une croix rouge apparaître quand tu casses un test exprès.

4. Casse un truc volontairement. Écris un test qui échoue. Pousse-le. Regarde le pipeline l’attraper. C’est le moment où ça fait clic — le pipeline est ton filet de sécurité, pas un obstacle bureaucratique.

5. Ajoute une étape de déploiement. Même si elle fait juste un echo “Deploying…” pour l’instant. La structure compte. Plus tard, tu remplaceras cet echo par une vraie commande de déploiement.

6. Configure la protection de branche. Dans les paramètres de ton repo, exige que le check CI passe avant de merger les pull requests. C’est là que le pipeline passe de “sympa à avoir” à “vraiment appliqué.”

Voilà un pipeline CI/CD fonctionnel. C’est basique, mais c’est réel. À partir de là, tu ajoutes de la complexité au fur et à mesure — mise en cache des dépendances pour accélérer, builds matriciels pour tester sur plusieurs versions, déploiement sur des environnements cloud. Si tu te diriges vers l’infrastructure cloud, notre guide pour apprendre le cloud computing en partant de zéro couvre les bases dont t’auras besoin pour les déploiements en production.

Mais le squelette est toujours le même : déclencheur, build, test, déploiement.

Où le CI/CD s’inscrit dans le tableau global

Le CI/CD n’existe pas dans le vide. C’est une pièce d’un écosystème plus large. Les outils d’Infrastructure as Code comme Terraform définissent où ton code tourne. L’orchestration de conteneurs avec Kubernetes gère comment ça scale. Les outils de monitoring comme Prometheus te disent si ça marche vraiment après le déploiement.

Si tu penses aux certifications pour formaliser ces connaissances, notre arbre de décision des certifications cloud peut t’aider à trouver quel parcours a du sens pour là où tu en es maintenant.

Mais le CI/CD c’est la pièce qui relie tout le workflow. Sans lui, tout le reste est manuel. Avec lui, tu livres plus vite et tu dors mieux. Littéralement. Je dors mieux maintenant que j’ai des pipelines. Vendredis soirs inclus.

FAQ

Est-ce que je dois connaître Docker pour utiliser le CI/CD ?

Non. Docker est courant dans les pipelines — la plupart des runners CI utilisent des conteneurs en coulisses — mais t’as pas besoin de comprendre Docker pour mettre en place un pipeline basique. GitHub Actions, par exemple, gère la partie conteneurs pour toi. Tu écris tes étapes et il les exécute. Cela dit, quand tu commences à construire des pipelines plus complexes avec des environnements personnalisés, la connaissance de Docker devient vraiment utile.

C’est quoi la différence entre CI/CD et DevOps ?

Le DevOps c’est la culture plus large et l’ensemble de pratiques autour de la collaboration entre développement et opérations. Le CI/CD c’est une pratique technique spécifique à l’intérieur de ça. Tu peux faire du CI/CD sans te dire équipe DevOps, et tu peux te prétendre équipe DevOps sans avoir de CI/CD — même si je recommanderais pas ce dernier cas.

Un pipeline devrait prendre combien de temps ?

Moins de dix minutes c’est l’objectif. Moins de cinq c’est l’idéal. Une fois que tu dépasses quinze minutes, les développeurs commencent à faire autre chose en attendant, et ça tue l’élan. Si ton pipeline est lent, regarde du côté de la parallélisation des tests, de la mise en cache des dépendances, et ne lance la suite complète que sur main pendant que les PRs ont un sous-ensemble plus rapide.

Est-ce que je peux utiliser le CI/CD pour mes projets perso ?

Carrément. Je l’utilise pour tout, même les petits projets perso. Ça prend cinq minutes à mettre en place et ça te sauve du problème “ça marche sur ma machine” pour toujours. En plus, avoir du CI/CD dans tes repos perso rend bien sur un CV. Ça montre que tu te soucies de la qualité du code même quand personne regarde.

Prêt à structurer ton apprentissage ? Découvre SkillRealm Learn —>