CI/CD (intégration et livraison continues)
CI et CD sont deux questions différentes posées par une même chaîne automatique, qui rejoue les mêmes étapes à chaque poussée de code. La **CI** (intégration continue) demande : ce code peut-il être fusionné sans danger ? Elle installe les dépendances, lance le linter et les tests, compile, cherche les failles connues, et si une étape échoue la chaîne passe au rouge : le code ne se fusionne pas avant correction. La **CD** demande : peut-on le publier sans danger ? Elle fabrique un artefact de release (souvent une image Docker), le déploie en pré-production, puis en production. Le mot CD recouvre deux pratiques que la plupart des gens mélangent. En **livraison continue**, tout changement validé reste prêt à partir, mais une personne clique sur « déployer » pour la production. En **déploiement continu**, ce clic disparaît : tout ce qui passe les contrôles part seul en production. Reste le choix de la sortie. Une version peut remplacer l'ancienne par vagues (*rolling*), être mise en ligne à côté de l'ancienne puis basculée d'un coup (*blue-green*, retour immédiat en rebasculant), ou être servie d'abord à une petite part des visiteurs (*canari* : 5 %, puis 25, 50, 100 %, avec retour arrière si le taux d'erreurs monte). Un déploiement ne se juge pas à « le serveur a démarré » mais à des contrôles de santé qui passent, d'où le lien avec le monitoring. Le vrai gain n'est pas la vitesse, c'est la répétabilité : le déploiement est écrit comme du code, les mêmes étapes tournent à chaque fois. Sans cela, une étape oubliée à la main (la migration de la base) suffit à produire une erreur 502 en production ([reel Instagram DeCf1khst4y](https://www.instagram.com/reel/DeCf1khst4y/), RickTheEngineer, vidéo relevée le 3 octobre 2026).