CI/CD (Intégration et Déploiement Continus)

La CI/CD désigne l'automatisation de la chaîne qui va du code écrit au logiciel livré : l'intégration continue compile et teste automatiquement chaque modification poussée sur le dépôt, tandis que la livraison ou le déploiement continus préparent puis publient la version validée sur les environnements cibles.

L'image inverse est parlante : un développeur qui transfère des fichiers par FTP un vendredi soir, sans test, sans savoir ce qui part ni comment revenir en arrière. La CI/CD remplace ce geste artisanal par un processus décrit, versionné et rejouable à l'identique.

Une nuance sur le second C : en livraison continue, la version est prête à déployer mais la mise en production reste déclenchée manuellement ; en déploiement continu, elle part automatiquement dès que la chaîne est verte.

Comment ça marche

Un fichier de configuration versionné avec le code décrit le pipeline : les déclencheurs (un push, une demande de fusion, une étiquette, une planification) et les étapes à exécuter. Elles enchaînent typiquement installation des dépendances avec cache, analyse statique, tests, compilation, contrôles de sécurité, production d'un artefact, puis déploiement.

Ces étapes tournent sur des machines fournies par la plateforme ou hébergées par vous, les clés étant stockées comme secrets côté plateforme, jamais dans le dépôt. Le déploiement peut être progressif : bascule entre deux environnements, ou exposition à une fraction du trafic avant généralisation.

À quoi ça sert concrètement

• Détecter une régression en quelques minutes plutôt qu'en production, une semaine plus tard
• Livrer souvent et par petits lots, ce qui réduit le risque de chaque mise en ligne
• Supprimer l'argument « ça marche sur ma machine » en construisant toujours dans le même environnement
• Savoir exactement quelle version du code tourne en production, et pouvoir y revenir
• Générer un environnement de prévisualisation par branche, pour faire valider une évolution avant fusion

Les pièges

Des tests lents ou instables sont le poison le plus courant : quand la chaîne échoue une fois sur trois sans raison, l'équipe cesse de regarder les alertes, et la CI ne sert plus à rien. Traitez un test instable comme un bug, pas comme une fatalité.

Attention aussi aux secrets qui fuient dans les journaux de build, à l'absence de retour arrière — un déploiement automatique sans rollback ni migration réversible est un piège —, au coût des minutes de calcul, et surtout à la confusion entre pipeline vert et qualité : une chaîne qui ne lance aucun test utile ne valide rien.

Quand la mettre en place, quand s'en tenir au minimum

Dès qu'il y a plus d'une personne sur le projet, ou plus d'un déploiement par mois, l'automatisation se rentabilise vite. Pour un site statique publié rarement, restez simple : une construction et un déploiement automatiques suffisent, inutile de monter une usine à gaz que personne ne maintiendra.