Qu'est-ce que CI/CD (Intégration et Livraison Continues) ?

Ce que CI et CD veulent vraiment dire

Les deux acronymes sont souvent confondus. CI (Continuous Integration) désigne la discipline qui consiste à fusionner le travail de chaque développeur dans une branche partagée plusieurs fois par jour, avec des builds et des tests automatisés qui détectent les conflits en quelques minutes. CD (Continuous Delivery) étend cette discipline au déploiement : chaque commit qui passe la CI produit un artefact prêt à partir en production. Une variante plus stricte, le Continuous Deployment, supprime l'approbation manuelle et déploie automatiquement tout commit qui passe les tests.

Le trio CI + CD vit dans un pipeline : un graphe d'étapes automatisées déclenchées par les changements de code, qui tournent typiquement sur un runner hébergé et qui se gèrent depuis votre fournisseur Git (GitLab CI, GitHub Actions, Jenkins, ArgoCD).

À quoi ressemble un pipeline pragmatique

Dans une mise en place saine, nous déployons typiquement :

1. Lint + format : vérifications statiques rapides qui attrapent fautes de frappe et problèmes de style en quelques secondes.
2. Build : compiler, packager, produire une image de conteneur avec un tag déterministe.
3. Tests unitaires : qui tournent en parallèle, échouent vite.
4. Scans de sécurité : SAST sur le code source, scan de vulnérabilités sur l'image conteneur.
5. Push de l'artefact : vers un registry avec le tag du SHA du commit.
6. Déploiement vers staging : automatique, avec des smoke tests sur la version déployée.
7. Déploiement en production : sous approbation humaine, ou automatique pour les services à faible risque.
8. Vérification post-déploiement : un monitoring synthétique confirme que la nouvelle version répond correctement.

L'enchaînement complet termine généralement en 5–15 minutes pour une appli web typique. Les pipelines plus lents sont le signe que les tests sont trop couplés ou que les builds ne sont pas mis en cache.

Pourquoi c'est important au-delà du confort développeur

Le CI/CD est le moyen le plus simple de réduire le taux d'échec des changements : l'un des quatre indicateurs DORA. Chaque commit part en isolation, donc quand quelque chose casse, la cause est dans les 50 dernières lignes de code, pas dans le dernier trimestre de travail. Le rollback se fait en un clic. Les auditeurs disposent d'un journal chronologique de chaque changement en production avec le commit, le résultat des tests et l'approbateur.

Pour les industries suisses régulées, un pipeline CI/CD bien conçu est aussi la façon la plus propre d'imposer le principe des quatre yeux : chaque changement requiert l'approbation d'un relecteur avant fusion, tracée pour toujours dans l'historique Git.

Anti-patterns courants

• Pipelines qui prennent 90 minutes : les développeurs attendent, regroupent leur travail, et la valeur de la CI s'évapore.
• Un seul script "deploy.sh" lancé par une seule personne : ce n'est pas du CI/CD, c'est un facteur de bus de un.
• Tests qui échouent aléatoirement : dits flaky ; les équipes les désactivent, et les vrais bugs passent.
• Approbations manuelles pour des changements à faible risque : des goulots d'étranglement qui existent parce que personne ne fait confiance aux tests.

Services Hidora associés

• Consulting : design de pipeline, mise en place GitLab CI / GitHub Actions, formation.
• Managed Services : exploitation des runners, secrets et registries dont dépend le CI/CD.