--- 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. Une petite pipeline exécutée à chaque changement protège mieux qu'une longue procédure manuelle lancée seulement avant une grosse livraison.