L'intégration continue fusionne le code plusieurs fois par jour et déclenche la compilation et les tests automatiques ; la livraison continue rend le changement prêt pour la production mais exige une approbation manuelle, et le déploiement continu supprime cette approbation et ne libère que si toutes les vérifications passent. La différence entre les deux « CD » est ce bouton humain, une décision de gouvernance et de risque, pas technique.
DevOps n'est ni un outil ni un poste de travail : c'est une culture d'ingénierie qui abat le mur historique entre ceux qui développent le logiciel (Dev) et ceux qui l'exploitent en production (Ops). Au centre de cette culture se trouve le pipeline CI/CD, une chaîne automatisée qui prend chaque changement de code et l'amène, avec une vérification continue, jusqu'aux utilisateurs. Cet article explique en détail technique ce que signifient l'intégration continue, la livraison continue et le déploiement continu, comment on construit un pipeline réel avec GitHub Actions et GitLab CI, et quelles métriques démontrent que le système fonctionne.
Intégration continue, livraison continue et déploiement continu : trois concepts distincts
Le sigle CI/CD cache trois pratiques qu'il convient de distinguer. L'intégration continue (CI) consiste, pour chaque développeur, à fusionner ses changements avec la branche principale plusieurs fois par jour, chaque fusion déclenchant automatiquement la compilation et la batterie de tests. Son objectif est de détecter les conflits et les incompatibilités en quelques heures, pas en quelques semaines.
La livraison continue (Continuous Delivery) prolonge la CI : chaque changement qui passe les tests est empaqueté et reste prêt à être déployé à tout moment, mais le passage en production exige une approbation manuelle. Le déploiement continu (Continuous Deployment) supprime même cette approbation : si toutes les vérifications passent, le changement arrive seul en production. La différence entre les deux « CD » — livraison face à déploiement — est précisément ce bouton humain, et choisir l'un ou l'autre est une décision de gouvernance et de risque, pas technique.
Anatomie d'un pipeline : les étapes indispensables
Un pipeline mature enchaîne des étapes où le coût d'un échec augmente et où le « rayon de dégâts » diminue si l'échec survient tôt. Les étapes canoniques sont :
- Build : compilation et construction de l'artefact (binaire, image de conteneur, paquet). Elle doit être reproductible et partir d'un état propre.
- Tests unitaires et d'intégration : ils valident la logique métier. C'est ici que l'on mesure la couverture, bien que la couverture seule ne garantisse pas la qualité.
- Analyse statique et de sécurité (SAST/SCA) : linters, analyse des dépendances vulnérables et analyse du code. C'est l'endroit pour « déplacer la sécurité vers la gauche » (shift-left security).
- Empaquetage et publication des artefacts : versionnement immuable de l'image dans un registre de conteneurs.
- Déploiement par environnements : d'abord en staging, puis en production, idéalement avec des stratégies à faible risque comme blue-green ou canary.
Un principe d'or traverse tout le pipeline : construire l'artefact une seule fois et promouvoir exactement cet artefact entre les environnements. Recompiler pour la production introduit le risque que ce qui est déployé ne soit pas ce qui a été testé.
GitHub Actions face à GitLab CI : comment cela se concrétise
Les deux plateformes décrivent le pipeline sous forme de code YAML versionné aux côtés de l'application, ce qui respecte le principe du pipeline-as-code. Dans GitHub Actions, les flux vivent dans .github/workflows/, s'organisent en jobs et steps, et réutilisent des blocs de la communauté via des actions. Dans GitLab CI, la configuration réside dans .gitlab-ci.yml, se structure en stages et jobs, et tire parti de l'intégration native avec le registre de conteneurs et le suivi des incidents de GitLab lui-même.
| Aspect | GitHub Actions | GitLab CI/CD |
|---|---|---|
| Fichier de configuration | .github/workflows/*.yml | .gitlab-ci.yml |
| Unité d'organisation | Jobs et steps | Stages et jobs |
| Réutilisation | Marketplace d'actions | Modèles include et CI components |
| Exécuteurs | GitHub-hosted ou self-hosted runners | Shared ou specific runners |
| Modèle intégré | Écosystème GitHub + packages | Plateforme DevOps complète d'un seul fournisseur |
Le choix dépend rarement de la capacité technique — les deux couvrent le cycle complet — mais plutôt de l'écosystème dans lequel évolue déjà l'équipe et de la préférence pour une plateforme tout-en-un (GitLab) face à un modèle modulaire et ouvert (GitHub).
Infrastructure en tant que code et gestion des secrets
Un pipeline qui déploie a besoin d'une infrastructure sur laquelle déployer, et cette infrastructure doit elle aussi être du code. Des outils comme Terraform (déclaratif, orienté vers le provisionnement de ressources cloud) ou Ansible (orienté vers la configuration des machines) permettent que l'environnement soit reproductible, versionné et révisable via des pull requests. La conséquence opérationnelle est énorme : recréer un environnement complet cesse d'être un rituel manuel de plusieurs heures et devient l'exécution d'un plan.
Le point le plus délicat du pipeline est la gestion des secrets. Identifiants, clés API et jetons ne doivent jamais être écrits dans le YAML ni dans le dépôt. Ils sont stockés dans des coffres spécifiques — GitHub Secrets, variables protégées de GitLab, ou des gestionnaires comme HashiCorp Vault — et injectés à l'exécution avec le privilège minimal nécessaire. Des tendances actuelles comme l'authentification OIDC permettent au pipeline d'obtenir des identifiants temporaires auprès du fournisseur cloud sans stocker aucun secret de longue durée.
Outre les secrets, deux pratiques élèvent la maturité du pipeline. La première est le stockage de l'état de l'infrastructure de façon distante et verrouillée (par exemple, le state de Terraform dans un bucket avec verrouillage), de sorte que deux exécutions simultanées ne corrompent pas l'environnement. La seconde est l'utilisation d'environnements éphémères de revue : chaque pull request fait apparaître automatiquement une copie jetable de l'application où réviser le changement en direct, copie détruite à la fusion. Ainsi, la revue cesse d'être une lecture de code dans l'abstrait et devient une vérification fonctionnelle réelle, sans contaminer les environnements partagés ni laisser des ressources orphelines consommer du budget.
Métriques DORA : comment savoir si le DevOps fonctionne
La recherche DORA (DevOps Research and Assessment) a proposé quatre métriques qui sont corrélées à la performance de la livraison logicielle, aujourd'hui une référence du secteur :
- Fréquence de déploiement : à quelle cadence le code est mis en production.
- Délai de mise en œuvre du changement (lead time for changes) : le temps que met un commit pour arriver en production.
- Taux d'échec du changement (change failure rate) : le pourcentage de déploiements qui provoquent une dégradation nécessitant une remédiation.
- Temps de restauration du service (time to restore) : le temps nécessaire pour se remettre d'un incident.
La nuance clé est que ces métriques ne s'opposent pas : les équipes les plus performantes déploient plus souvent et avec un taux d'échec plus faible. La vitesse bien menée est la conséquence de la stabilité, pas son ennemie. Il convient en outre de les lire comme un ensemble et jamais isolément : optimiser uniquement la fréquence de déploiement sans surveiller le taux d'échec et le temps de restauration produit des équipes qui livrent vite mais cassent souvent la production, ce qui détruit la confiance et finit par ralentir la livraison réelle. L'équilibre entre les quatre métriques est, en soi, l'indicateur de santé du processus.
Erreurs courantes lors de la mise en place du CI/CD
- Tests lents ou instables (flaky). Un pipeline qui prend quarante minutes ou qui échoue de façon aléatoire érode la confiance et pousse les gens à le contourner.
- Recompiler par environnement. Générer des artefacts différents pour staging et production casse la garantie que l'on déploie ce qui a été testé.
- Secrets dans le dépôt. L'erreur de sécurité la plus fréquente et la plus coûteuse à corriger, car un secret divulgué doit être renouvelé même s'il est supprimé de l'historique.
- Déployer sans stratégie de retour arrière. Sans rollback automatique ni feature flags, tout déploiement défectueux se transforme en incident prolongé.
- Automatiser le chaos. Si le processus manuel est cassé, l'automatiser ne fait que produire des échecs plus rapidement ; on met d'abord de l'ordre dans le processus, puis on l'automatise.
Questions fréquentes
Quelle est la différence réelle entre livraison continue et déploiement continu ?
Dans la livraison continue, le logiciel est prêt pour la production de façon automatique, mais le passage final est autorisé par une personne. Dans le déploiement continu, il n'y a pas d'approbation manuelle : si tous les tests passent, le changement arrive seul en production. Le choix dépend de la maturité des tests et de l'appétit pour le risque de l'entreprise.
Ai-je besoin de conteneurs pour faire du CI/CD ?
Ce n'est pas obligatoire, mais les conteneurs (Docker) facilitent énormément la reproductibilité : le même artefact s'exécute de la même façon sur le portable du développeur, dans le pipeline et en production. On peut aussi s'en passer, mais le risque de différences entre environnements augmente.
Que sont les stratégies blue-green et canary ?
Blue-green maintient deux environnements identiques et bascule le trafic de l'un (l'ancienne version) vers l'autre (la nouvelle) d'un coup, avec un retour arrière instantané. Canary libère la nouvelle version à un petit pourcentage d'utilisateurs, observe les métriques et l'étend progressivement si tout va bien. Les deux réduisent le rayon de dégâts d'un déploiement défectueux.
Par où commence une entreprise sans aucun pipeline ?
Par l'intégration continue de base : automatiser le build et les tests à chaque fusion vers la branche principale. Une fois cette base fiable, on ajoute l'analyse de sécurité, l'empaquetage des artefacts et, enfin, le déploiement automatisé par environnements.
Conclusion
La valeur d'un pipeline de CI/CD ne se mesure pas à la sophistication du YAML, mais à une propriété concrète : que mettre un changement en production cesse d'être un événement stressant et devienne une routine ennuyeuse et sûre. Quand construire une seule fois, tester de façon exhaustive, gérer les secrets hors du code et déployer avec des stratégies réversibles font partie du flux de travail normal, les métriques DORA s'améliorent d'elles-mêmes et l'équipe récupère le temps qu'elle passait auparavant à éteindre des incendies. C'est là la vraie promesse de DevOps : non pas déployer plus vite pour aller plus vite, mais éliminer la peur du déploiement. Chez Summum Sistemas, nous concevons et mettons en place des pipelines sur GitHub Actions et GitLab CI adaptés à la maturité de chaque équipe.