Réduire les bugs en production
Tests systématiques avant merge.
Qu'est-ce que CI/CD ? Définition et pipeline
CI/CD regroupe deux pratiques complémentaires. L'intégration continue (CI) fusionne fréquemment le code dans une branche partagée et exécute automatiquement builds et tests à chaque changement. La livraison ou le déploiement continu (CD) prépare — et parfois pousse — le logiciel validé vers des environnements de staging ou de production sans étapes manuelles répétitives.
En une phrase
CI/CD, c'est vérifier et livrer le code automatiquement à chaque changement, au lieu de le faire à la main avant chaque mise en ligne.
À retenir
- CI détecte tôt les régressions : un test rouge bloque la merge.
- CD réduit le « day-two drift » entre ce qui a été testé et ce qui tourne en prod.
- Un pipeline typique : commit → build → tests → artefact → déploiement.
- La sécurité s'intègre au pipeline (analyse de dépendances, scans) — souvent appelée DevSecOps.
Fiche du terme
- CI/CD
- Intégration et déploiement continus · Continuous Integration / Continuous Delivery
- Terme anglais
- Continuous Integration / Continuous Delivery
- Domaine
- Cloud et DevOps
- Catégorie
- Automatisation
- Niveau
- Intermédiaire
CI et CD : deux lettres, deux responsabilités
L'intégration continue répond à la question « est-ce que ce changement casse quelque chose ? » dès qu'il rejoint la branche principale. Sans CI, les équipes découvrent les conflits et bugs la veille du go-live — coût maximal.
La livraison continue va jusqu'à un artefact prêt pour la production (bouton ou approbation humaine). Le déploiement continu va plus loin : chaque commit validé part en prod automatiquement — rare en entreprise réglementée, courant pour des microservices internes ou des sites à faible risque.
Pour une PME québécoise, un premier pipeline CI/CD réaliste inclut souvent GitHub Actions ou GitLab CI, tests unitaires, déploiement staging, puis prod manuelle avec un clic — déjà un gain énorme par rapport au FTP.
Anatomie d'un pipeline CI/CD
- 01
Déclenchement
Push, pull request ou tag démarre le workflow.
- 02
Build
Compilation, installation des dépendances, création d'image conteneur ou paquet.
- 03
Tests automatisés
Unitaires, intégration, parfois tests E2E sur staging.
- 04
Déploiement
Promotion vers staging puis prod, avec secrets injectés de façon sécurisée.
Exemple concret
Une équipe Next.js pousse une correction de facturation un mardi 14 h. Le pipeline GitHub Actions installe les dépendances, lance ESLint et Jest, construit l'app, déploie sur Vercel preview pour la QA, puis merge en main déclenche la prod après approbation. Total : 12 minutes sans accès SSH manuel. L'ancien processus demandait 2 h et oubliait parfois de vider le cache CDN.
Pourquoi mettre en place CI/CD ?
Accélérer les correctifs
Hotfix avec trace et rollback versionné.
Onboarding développeurs
Même commande pour tous : push et le pipeline fait le reste.
Audit et conformité
Qui a déployé quoi, quand, à partir de quel commit.
Avantages et limites
- Feedback rapide sur la qualité du code
- Déploiements reproductibles et documentés
- Moins de charge cognitive le jour J
- Facilite le travail à distance et avec des partenaires
- Temps pour écrire et maintenir les tests
- Pipelines mal conçus = fausses alertes ou lenteur
- Secrets et accès prod à gérer avec rigueur
- CD complet inadapté si aucune couverture de tests
CI/CD ou déploiement manuel ?
| CI/CD | Déploiement manuel | |
|---|---|---|
| Tests avant prod | Automatiques à chaque changement | Souvent partiels ou oubliés |
| Traçabilité | Logs de pipeline liés au commit | « C'est Bob qui a uploadé » |
| Rollback | Redéploiement d'un artefact connu | Restauration incertaine |
| Coût humain | Investissement initial, puis faible | Répétitif à chaque release |
Ce que la direction gagne
CI/CD transforme la mise en production d'un événement stressant en routine maîtrisée. Pour un dirigeant non technique, l'indicateur simple est le délai entre « correction approuvée » et « correction en ligne » — mesurable en heures au lieu de semaines quand le pipeline est en place.
Questions fréquentes
Quelle différence entre Continuous Delivery et Continuous Deployment ?
Delivery : prod toujours prête, déploiement sur approbation. Deployment : chaque commit validé part en prod sans intervention.
Quels outils pour commencer ?
GitHub Actions, GitLab CI, Azure DevOps ou CircleCI selon où vit votre code. L'outil compte moins que les tests et la discipline de merge.
CI/CD sans tests, ça vaut le coup ?
Partiellement : build et lint aident, mais sans tests vous automatisez surtout la vitesse de livraison des bugs.
Termes associés
Sources et références
Vous voulez un premier pipeline réaliste pour votre stack actuelle ?
Planifier votre CI/CD