CI/CD (intégration et déploiement continus) : définition simple et exemples

Que signifie CI/CD ?

CI/CD est l'abréviation de deux pratiques complémentaires. La CI, Continuous Integration ou intégration continue, est définie par Martin Fowler comme une pratique où chaque membre d'une équipe fusionne ses modifications avec celles de ses collègues au moins une fois par jour, chaque intégration étant vérifiée par une construction automatisée, tests compris. Le CD désigne selon les cas la livraison continue (Continuous Delivery) ou le déploiement continu (Continuous Deployment).

L'origine est documentée. D'après l'article de référence de Martin Fowler, révisé en janvier 2024, l'intégration continue a été développée par Kent Beck dans le cadre de l'Extreme Programming, dans les années 1990, à une époque où l'on n'assemblait le code qu'avant des versions espacées parfois de plusieurs années. Pour la livraison continue, Fowler désigne le livre Continuous Delivery de Jez Humble et Dave Farley, paru en 2010, comme l'ouvrage fondateur.

Comment fonctionne un pipeline CI/CD ?

Un pipeline CI/CD fonctionne comme une ligne de fabrication avec un contrôle à chaque poste plutôt qu'un contrôle unique en bout de chaîne. Une pièce défectueuse arrêtée au premier poste coûte une pièce ; découverte chez le client, elle coûte un rappel. Le pipeline applique la même logique au code :

1. Dépôt : le développeur enregistre sa modification dans le dépôt de code commun.
2. Construction : un serveur assemble automatiquement l'application.
3. Tests : les tests automatisés vérifient que l'existant fonctionne toujours ; au moindre échec, la chaîne s'arrête et l'auteur est prévenu.
4. Contrôles complémentaires : dépendances vulnérables, qualité du code, accessibilité.
5. Préproduction : la version est installée sur un environnement de test où le client peut la vérifier.
6. Production : mise en ligne d'un clic (livraison continue) ou automatique (déploiement continu).

Des services comme GitHub Actions, que GitHub présente comme une plateforme d'intégration et de livraison continues, ou GitLab CI/CD exécutent ces étapes à partir d'un fichier de configuration rangé avec le code. Pour les applications mobiles, la documentation de Flutter cite des services tout-en-un comme Codemagic, Bitrise ou Appcircle, ainsi que l'outil fastlane, pour livrer automatiquement chaque version aux testeurs.

Intégration, livraison et déploiement continus : quelles différences ?

Martin Fowler résume la nuance : avec la livraison continue, on est capable de déployer fréquemment mais on peut choisir de ne pas le faire, souvent parce que l'entreprise préfère un rythme plus lent ; le déploiement continu suppose la livraison continue. Pour un logiciel métier, la livraison continue est souvent le bon réglage : le client garde la main sur le moment de la mise en ligne.

Un exemple concret en logiciel métier

Sur la plateforme Klass., YMHB Web a écrit un programme de vérification qui rejoue 269 contrôles à chaque mise à jour : accès, cloisonnement entre établissements, scénarios métier, liens, données structurées, accessibilité. La règle est simple : zéro erreur, ou la mise à jour ne part pas. Une école ne doit jamais voir les contrats d'une autre, et cette garantie est revérifiée à chaque livraison, pas une fois pour toutes.

Ce dispositif prolonge la façon de travailler décrite sur la page méthode : construction par cycles courts, avec une version testable accessible en permanence au client.

Comment mesurer l'efficacité d'une chaîne CI/CD ?

On mesure une chaîne CI/CD avec les indicateurs du programme de recherche DORA, dont le modèle actuel en compte cinq :

• délai des changements : temps entre l'enregistrement d'une modification et sa mise en production ;
• fréquence de déploiement ;
• temps de rétablissement après un déploiement raté ;
• taux d'échec des changements : part des déploiements qui exigent une intervention immédiate ;
• taux de reprise : part des déploiements non planifiés, déclenchés par un incident en production.

DORA présente la réduction de la taille de chaque changement comme une façon courante d'améliorer ces cinq indicateurs : un petit changement passe plus vite et se rattrape plus facilement en cas d'échec. La question à poser à un prestataire en découle : combien de temps pour corriger une faute de frappe en production, et que se passe-t-il si la correction casse autre chose ?

Idées reçues sur la CI/CD

• « C'est réservé aux grandes équipes. » Un développeur seul gagne aussi à disposer d'une chaîne qui refuse de mettre en ligne un code qui casse la facturation.
• « Déploiement continu veut dire déployer sans contrôle. » Rien ne part sans tests, et la livraison continue laisse la décision finale à une personne.
• « Les tests automatiques remplacent la recette. » Ils vérifient ce qu'on a pensé à vérifier ; la recette par les utilisateurs reste indispensable.

Termes voisins

• Dette technique : les raccourcis accumulés dans le code ; une chaîne CI/CD avec de bons tests permet de la réduire sans crainte de régression.
• Microservices : chaque service se déploie seul, ce qui suppose un pipeline par service.
• DevOps : la culture qui rapproche développement et exploitation, dont la CI/CD est l'un des outils concrets.
• Tests automatisés : les programmes qui vérifient le logiciel à chaque modification, carburant indispensable du pipeline.