---
title: Principes de la CI/CD
description: Comprendre la chaîne qui transforme un changement en version déployable.
---

CI/CD désigne un ensemble de pratiques, pas un outil. GitHub Actions, GitLab CI ou Jenkins exécutent la chaîne, mais sa valeur vient surtout de règles simples : retours rapides, branche principale saine et livraison reproductible.

## CI et CD ne font pas le même travail

| Étape | Question | Résultat |
| --- | --- | --- |
| intégration continue (CI) | le changement est-il valide ? | code testé et branche principale saine |
| livraison continue | cette version peut-elle être livrée ? | artefact versionné et prêt |
| déploiement continu (CD) | la version doit-elle être mise en ligne ? | production mise à jour et vérifiée |

Une équipe peut automatiser la livraison tout en gardant une approbation manuelle avant la production. Le « D » de CD ne signifie donc pas toujours déploiement automatique.

## Les trois propriétés recherchées

### Une branche principale toujours livrable

Les branches restent courtes, les changements petits et les contrôles obligatoires avant fusion. Une erreur est plus simple à comprendre lorsqu'elle porte sur quelques commits.

### Des boucles de retour rapides

Lance d'abord les vérifications rapides : formatage, lint et tests unitaires. Les builds Docker et tests e2e plus coûteux viennent ensuite. Un développeur doit savoir rapidement si son changement peut avancer.

### Un artefact unique

La CI produit une image versionnée. La recette de production déploie cette même image ; elle ne reconstruit pas le projet sur le serveur.

```text
commit → contrôles → image versionnée → registry → déploiement → vérification
```

## Répartir les responsabilités

| Niveau | Exemples |
| --- | --- |
| poste du développeur | formatage, lint, tests ciblés, hooks Git |
| pull request | lint complet, tests, build, revue |
| branche principale | image candidate, scans et tests d'intégration |
| version | publication dans le registry |
| environnement | approbation éventuelle, déploiement, smoke test |

Les hooks Git améliorent le confort local, mais la CI reste la source de vérité : un hook peut être désactivé ou ne pas exister sur une autre machine.

## Une politique minimale efficace

- aucune fusion si un contrôle obligatoire échoue ;
- aucun déploiement depuis une branche non approuvée ;
- chaque image porte un tag immuable ;
- les secrets sont limités à l'environnement qui en a besoin ;
- un seul déploiement de production s'exécute à la fois ;
- chaque mise en ligne possède une vérification et un rollback.

<Callout title="La confiance vient de la répétition" type="info">
  Une petite pipeline exécutée à chaque changement protège mieux qu'une longue procédure manuelle lancée seulement avant une grosse livraison.
</Callout>

