Le DevOps n'est ni un outil ni un poste de travail : c'est une culture d'ingénierie qui fait tomber le mur historique entre ceux qui développent le logiciel (Dev) et ceux qui l'exploitent en production (Ops). Au cœur de cette culture se trouve le pipeline CI/CD, une chaîne automatisée qui prend chaque modification de code et l'achemine, 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 se construit un pipeline réel dans 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 recouvre trois pratiques qu'il convient de séparer. L'intégration continue (CI) consiste à ce que chaque développeur fusionne ses modifications avec la branche principale plusieurs fois par jour, et à ce que chaque fusion déclenche automatiquement la compilation et la batterie de tests. Son objectif est de détecter les conflits et les incompatibilités en quelques heures, et non en quelques semaines.
La livraison continue (Continuous Delivery) prolonge la CI : chaque modification qui passe les tests est empaquetée et reste prête à être déployée à tout moment, mais le passage en production requiert une approbation manuelle. Le déploiement continu (Continuous Deployment) supprime même cette approbation : si toutes les vérifications passent, la modification arrive seule 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 relève d'une décision de gouvernance et de risque, non technique.
Anatomie d'un pipeline : les étapes incontournables
Un pipeline mature enchaîne des étapes au cours desquelles le coût d'un échec augmente et le « rayon de dommage » diminue si l'on échoue tôt. Les étapes canoniques sont :
- Build : compilation et construction de l'artefact (binaire, image de conteneur, paquet). Il 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, même si la couverture seule ne garantit pas la qualité.
- Analyse statique et de sécurité (SAST/SCA) : linters, analyse des dépendances vulnérables et analyse de code. C'est l'endroit pour « décaler la sécurité vers la gauche » (shift-left security).
- Empaquetage et publication des artefacts : versionnage 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 parcourt tout le pipeline : construire l'artefact une seule fois et promouvoir exactement cet artefact d'un environnement à l'autre. 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 comme du code YAML versionné aux côtés de l'application, ce qui respecte le principe du pipeline-as-code. Dans GitHub Actions, les flux résident dans .github/workflows/, s'organisent en jobs et steps, et réutilisent des blocs de la communauté via les actions. Dans GitLab CI, la configuration se trouve 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 | Runners GitHub-hosted ou self-hosted | Shared ou specific runners |
| Modèle intégré | Écosystème GitHub + packages | Plateforme DevOps complète d'un fournisseur unique |
Le choix dépend rarement de la capacité technique — les deux couvrent le cycle complet — mais de l'écosystème dans lequel vit 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 as 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 de machines) permettent que l'environnement soit reproductible, versionné et révisable au moyen de pull requests. La conséquence opérationnelle est énorme : recréer un environnement complet cesse d'être un rituel manuel de plusieurs heures pour devenir l'exécution d'un plan.
Le point le plus délicat du pipeline est la gestion des secrets. Les identifiants, les clés d'API et les 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 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 du fournisseur cloud sans stocker aucun secret à longue durée de vie.
Aux côtés des 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'usage d'environnements éphémères de revue : chaque pull request fait apparaître automatiquement une copie jetable de l'application où réviser la modification en direct, qui est détruite à la fusion. La revue cesse ainsi d'être une lecture de code dans l'abstrait pour devenir 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 corrèlent avec la performance de la livraison de logiciels, aujourd'hui référence du secteur :
- Fréquence de déploiement : à quel rythme on met du code en production.
- Délai de livraison de la modification (lead time for changes) : combien de temps met un commit pour arriver en production.
- Taux d'échec des modifications (change failure rate) : quel pourcentage de déploiements provoque une dégradation qui exige une remédiation.
- Temps de restauration du service (time to restore) : combien de temps prend la récupération après un incident.
La nuance clé est que ces métriques ne s'opposent pas : les équipes très performantes déploient plus souvent et avec un taux d'échec moindre. La vitesse bien faite est la conséquence de la stabilité, non son ennemie. Il convient en outre de les lire comme un ensemble et jamais de manière isolée : 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 de CI/CD
- Des tests lents ou intermittents (flaky). Un pipeline qui met quarante minutes ou qui échoue aléatoirement érode la confiance et pousse les gens à le contourner.
- Recompiler par environnement. Générer des artefacts différents pour le staging et la production rompt la garantie que l'on déploie ce qui a été testé.
- Des 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 effacé 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 un incident prolongé.
- Automatiser le chaos. Si le processus manuel est cassé, l'automatiser ne fait que produire des erreurs plus vite ; on ordonne d'abord le processus, on l'automatise ensuite.
Questions fréquentes
Quelle est la différence réelle entre livraison continue et déploiement continu ?
En livraison continue, le logiciel reste prêt pour la production de façon automatique, mais le saut final est autorisé par une personne. En déploiement continu, il n'y a pas d'approbation manuelle : si tous les tests passent, la modification arrive seule 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. Sans conteneurs, c'est possible aussi, mais le risque de différences entre environnements augmente.
Que sont les stratégies blue-green et canary ?
Le blue-green maintient deux environnements identiques et bascule le trafic de l'un (l'ancienne version) à l'autre (la nouvelle) d'un seul coup, avec un retour arrière instantané. Le canary libère la nouvelle version à un petit pourcentage d'utilisateurs, observe les métriques et l'étend progressivement si tout se passe bien. Les deux réduisent le rayon de dommage 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 sur la branche principale. Une fois cette base fiable, on ajoute l'analyse de sécurité, l'empaquetage des artefacts et, en dernier lieu, le déploiement automatisé par environnements.
Conclusion
La valeur d'un pipeline CI/CD ne se mesure pas à la sophistication du YAML, mais à une propriété concrète : que mettre une modification en production cesse d'être un événement stressant pour devenir une routine ennuyeuse et sûre. Lorsque construire une seule fois, tester de manière exhaustive, gérer les secrets en dehors 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 promesse réelle du DevOps : non pas déployer plus vite pour aller vite, mais éliminer la peur du déploiement. Chez Summum Sistemas, nous concevons et mettons en place des pipelines dans GitHub Actions et GitLab CI adaptés à la maturité de chaque équipe.