Qu'est-ce qui déclenche réellement un pipeline CI/CD ?

Un développeur termine la correction d'un bug, tape git push, et s'éloigne. Quelques minutes plus tard, le chat de l'équipe s'anime : "Build échoué." Personne n'a touché à la configuration du pipeline. Personne n'a cliqué sur un bouton. Le pipeline s'est simplement exécuté.

C'est normal dans la plupart des équipes. Mais si vous demandez à quelqu'un pourquoi le pipeline s'est lancé, la réponse est souvent vague : "Parce que j'ai poussé du code." C'est vrai, mais cela passe à côté d'un détail important. Les pipelines ne se lancent pas tout seuls. Quelque chose doit les déclencher. Et le type de déclencheur que vous choisissez change la façon dont votre équipe travaille, ce qui est testé, et quand les choses arrivent en production.

Parcourons les situations réelles où les pipelines se lancent, et ce que chaque déclencheur signifie pour votre flux de travail quotidien.

Quand un développeur pousse du code

Le déclencheur le plus courant est un commit poussé vers un dépôt partagé. Un développeur termine une modification, la commit localement, et pousse vers GitHub, GitLab, ou Bitbucket. Le dépôt envoie un webhook au système CI/CD, et le pipeline démarre.

Cela semble simple, mais les détails comptent. Le commit transporte des métadonnées : quels fichiers ont changé, qui a fait la modification, et le message de commit. Un bon pipeline utilise ces métadonnées pour décider quoi faire. Si le commit ne touche qu'un fichier README, vous n'avez probablement pas besoin d'exécuter toute la suite de tests et de déployer sur la staging. Mais si le commit modifie le code de l'application, le pipeline doit tout exécuter.

Le diagramme ci-dessous montre comment un déclencheur push se ramifie en fonction des métadonnées du commit :

Voici comment définir un tel déclencheur push dans un workflow GitHub Actions :

name: CI Pipeline
on:
  push:
    branches:
      - main
      - 'feature/**'
    paths-ignore:
      - 'README.md'
      - 'docs/**'

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: make test
flowchart TD Push[Git Push] --> Webhook[Webhook vers CI/CD] Webhook --> Inspect[Inspecter les métadonnées du commit] Inspect --> Branch{Branche ?} Branch -- feature --> Unit[Tests unitaires & Lint] Branch -- main --> Full[Suite de tests complète] Inspect --> Files{Fichiers modifiés ?} Files -- code uniquement --> Unit Files -- inclut docs --> Skip[Ignorer les tests] Files -- mixte --> Full

Les équipes qui traitent chaque commit de la même manière gaspillent du temps et des ressources de calcul. Une approche plus intelligente consiste à laisser le pipeline inspecter le commit et la branche avant de décider de la prochaine étape. Par exemple, un commit sur une branche de fonctionnalité pourrait seulement exécuter des tests unitaires et du linting, tandis qu'un commit sur la branche principale déclenche des tests d'intégration et un déploiement sur la staging.

Quand une pull request est fusionnée

De nombreuses équipes utilisent les pull requests ou merge requests comme une porte de revue. Un développeur ouvre une PR, ses coéquipiers relisent le code, et quand elle est approuvée, quelqu'un la fusionne. La fusion elle-même peut être un déclencheur.

C'est différent d'un déclencheur de commit régulier. Une fusion signale généralement que la modification a passé la revue humaine et est prête à entrer dans une branche plus stable. Les pipelines déclenchés par des fusions exécutent souvent des vérifications plus strictes : des suites de tests plus longues, des scans de sécurité, ou des tests de migration de base de données. L'hypothèse est que cette modification va bientôt arriver en production, donc vous voulez plus de confiance.

Certaines équipes exécutent également des pipelines sur la pull request elle-même, avant la fusion. Cela donne un retour précoce. Mais le déclencheur de fusion est le moment de vérité. Une fois le code dans la branche principale, il fait partie de l'historique partagé. Un pipeline échoué à ce stade signifie que l'équipe doit le réparer rapidement, car d'autres développeurs tireront ce code cassé.

Quand l'horloge le dit

Tous les pipelines n'ont pas besoin d'une modification de code pour s'exécuter. Les déclencheurs planifiés démarrent un pipeline à une heure spécifique, que quelqu'un ait poussé du code ou non.

Les cas d'utilisation courants incluent :

  • Exécuter de longs tests d'intégration chaque nuit quand personne n'attend les résultats.
  • Rafraîchir les environnements de staging avec des instantanés de données de production.
  • Mettre à jour les versions des dépendances ou exécuter des scans de vulnérabilités.
  • Effectuer des sauvegardes ou des tâches de nettoyage.

Les déclencheurs planifiés sont utiles pour les travaux qui doivent avoir lieu régulièrement mais qui ne dépendent pas de l'activité d'un développeur. Ils permettent également de détecter des problèmes qui n'apparaissent qu'avec le temps, comme un environnement de test qui se dégrade lentement ou un certificat sur le point d'expirer.

L'inconvénient est qu'un pipeline planifié peut s'exécuter alors que rien n'a changé. S'il échoue, quelqu'un doit enquêter pour savoir si l'échec est réel ou simplement un test instable. Les équipes devraient garder les pipelines planifiés concentrés sur les tâches qui nécessitent réellement une exécution périodique, et non sur des choses qui pourraient être déclenchées par une modification de code.

Quand quelqu'un appuie sur le bouton

Les déclencheurs manuels donnent le dernier mot à un humain. Au lieu que le pipeline démarre automatiquement, quelqu'un se connecte au système CI/CD et clique sur "Exécuter" ou "Déployer".

C'est courant pour les déploiements en production. Même si toutes les vérifications automatisées réussissent, de nombreuses équipes veulent qu'une personne approuve explicitement le déploiement. Les déclencheurs manuels gèrent également les situations d'urgence : revenir à une version précédente, redéployer après un crash d'environnement, ou exécuter une migration de données ponctuelle.

Les déclencheurs manuels ne concernent pas seulement le contrôle. Ils impliquent aussi une responsabilité. Quand quelqu'un démarre manuellement un pipeline, il devrait enregistrer pourquoi. Un bon système CI/CD permet d'ajouter une note : "Retour à la v2.1.3 car la dernière version a une fuite de connexion base de données." Ces métadonnées font partie de la piste d'audit.

Le risque avec les déclencheurs manuels est qu'ils deviennent un goulot d'étranglement. Si chaque déploiement nécessite que quelqu'un clique sur un bouton, et que cette personne est en congé, rien n'est livré. Les équipes devraient réserver les déclencheurs manuels aux actions qui nécessitent réellement un jugement humain, et non aux étapes de routine qui pourraient être automatisées.

Pourquoi les métadonnées comptent plus que vous ne le pensez

Chaque déclencheur transporte des informations. Un déclencheur de commit transporte le hash du commit, le nom de la branche et l'auteur. Un déclencheur de fusion transporte le numéro de la pull request et les noms des relecteurs. Un déclencheur manuel transporte le nom de l'opérateur et la raison qu'il a indiquée.

Ces métadonnées ne servent pas seulement à la journalisation. Le pipeline les utilise pour prendre des décisions. Doit-il exécuter une suite de tests complète ou seulement des tests de fumée ? Doit-il déployer sur la staging ou la production ? Doit-il notifier l'ingénieur d'astreinte ou simplement poster un résumé sur le canal de l'équipe ?

Sans métadonnées, le pipeline est aveugle. Il exécute les mêmes étapes à chaque fois, indépendamment de ce qui a changé. Cela fonctionne pour des projets simples, mais à mesure que votre système grandit, vous avez besoin de logique conditionnelle. Le déclencheur est le premier endroit où injecter cette logique.

Une checklist rapide pour choisir les déclencheurs

Si vous mettez en place un nouveau pipeline ou révisez un pipeline existant, ces questions vous aident à décider quels déclencheurs utiliser :

  • Chaque commit a-t-il besoin du même pipeline, ou pouvez-vous sauter des étapes pour les modifications qui ne concernent que la documentation ?
  • Voulez-vous un retour sur les pull requests avant la fusion, ou seulement après la fusion ?
  • Y a-t-il des tâches qui devraient s'exécuter quotidiennement même si personne ne pousse de code ?
  • Quelles étapes nécessitent une approbation humaine, et lesquelles peuvent s'exécuter automatiquement ?
  • Votre pipeline capture-t-il suffisamment de métadonnées pour déboguer les échecs plus tard ?

Ce qu'il faut retenir

Un déclencheur de pipeline n'est pas seulement un bouton de démarrage. C'est un point de décision qui définit quand le travail commence, quel contexte est disponible, et combien d'automatisation est sûre. Choisissez les déclencheurs en fonction du risque et de la fréquence de chaque action, et non par habitude. Un pipeline bien déclenché exécute les bonnes vérifications au bon moment, sans attendre que quelqu'un se souvienne de cliquer sur un bouton.