C'est quoi l'intégration continue (CI/CD) ?

L'intégration continue (continuous integration, CI) est une pratique de développement : chacun intègre son travail dans la branche commune plusieurs fois par jour, et chaque intégration est vérifiée automatiquement par une compilation, des analyses et des tests. Le CD prolonge la CI jusqu'à la mise en ligne : c'est la livraison continue quand un humain décide du passage en production, le déploiement continu quand ce passage est automatique. Ce chapitre explique le problème que la CI/CD résout, ces trois notions, les outils du marché et la place de la CI/CD dans le référentiel du BTS SIO.

Le problème : l'intégration de dernière minute

Lina développe le calcul des indemnités kilométriques sur sa branche. Hugo, de son côté, refond la validation des notes de frais. Chacun travaille trois semaines, teste sur son ordinateur, et tout fonctionne. Le vendredi de la livraison, ils fusionnent : quarante fichiers en conflit, des tests qui ne passent plus, une dépendance installée par Hugo que Lina n'a pas, et une version de Node.js différente sur le serveur. La livraison glisse d'une semaine. Ce scénario porte un nom : l'intégration « big bang ».

Ses causes sont toujours les mêmes :

• Des intégrations rares. Plus on attend pour fusionner, plus les écarts entre les branches grossissent, et plus les conflits coûtent cher.
• Des vérifications manuelles. Les tests ne tournent que si quelqu'un pense à les lancer, sur sa machine, avec sa configuration.
• Le « ça marche chez moi ». Le poste du développeur contient des fichiers, des variables d'environnement et des versions d'outils que le serveur n'a pas.
• Des livraisons artisanales. Copier des fichiers par FTP, lancer des commandes de mémoire sur le serveur : une étape oubliée, et la production tombe.

La CI/CD répond à chacune de ces causes : on intègre souvent par petits morceaux, une machine vérifie chaque intégration dans un environnement neuf, et la livraison suit une procédure écrite, versionnée et rejouée à l'identique.

L'intégration continue

L'intégration continue repose sur trois habitudes et un outil.

1. Intégrer souvent. Les branches vivent quelques heures ou quelques jours, pas des semaines. Chaque fusion apporte peu de changements, donc peu de conflits.
2. Tout vérifier automatiquement. À chaque push ou à chaque pull request, un serveur d'intégration récupère le code, installe les dépendances, lance l'analyse et les tests.
3. Réparer tout de suite. Un pipeline rouge sur la branche principale est la priorité de l'équipe : on corrige ou on annule le commit fautif avant d'ajouter autre chose.

L'outil est le serveur d'intégration continue (GitHub Actions, GitLab CI, Jenkins…). Il exécute un pipeline : une suite d'étapes décrite dans un fichier versionné avec le code. Le résultat s'affiche sur le commit et sur la pull request.

Livraison continue et déploiement continu

Le « D » de CI/CD a deux sens, que les sujets et les entretiens distinguent :

• Livraison continue (continuous delivery) : chaque version qui passe le pipeline est prête à partir en production. Elle est construite, testée, déployée automatiquement dans un environnement de recette, mais le passage en production reste une décision humaine, un clic sur un bouton d'approbation.
• Déploiement continu (continuous deployment) : il n'y a plus de bouton. Toute version qui passe les vérifications part automatiquement en production.

La plupart des organisations s'arrêtent à la livraison continue : la mise en production reste choisie (pas la veille d'un pont, pas pendant la clôture comptable). Le déploiement continu se rencontre surtout dans les entreprises du Web qui livrent plusieurs fois par jour.

DevOps : la culture derrière les outils

La CI/CD est la partie outillée d'une démarche plus large, DevOps : rapprocher ceux qui développent (dev) et ceux qui exploitent les serveurs (ops), pour livrer plus souvent sans sacrifier la stabilité. On la représente par une boucle sans fin : planifier, coder, construire, tester, livrer, déployer, exploiter, surveiller, puis replanifier à partir de ce qu'on a observé.

Pour mesurer si une équipe livre bien, le programme de recherche DORA (DevOps Research and Assessment, rattaché à Google) suit quatre indicateurs devenus classiques :

Les deux premiers mesurent la vitesse, les deux derniers la stabilité. Depuis 2024, DORA y ajoute un cinquième indicateur, le taux de reprise (rework rate) : la part des déploiements non prévus, faits pour corriger un incident en production. Le message des études DORA est que les équipes les plus rapides sont aussi les plus stables : livrer souvent de petits changements est moins risqué que livrer rarement un gros paquet.

Ce que la CI/CD apporte, et ce qu'elle coûte

Les outils de CI/CD

Tous les outils reposent sur les mêmes notions : un déclencheur, des jobs composés d'étapes, des machines d'exécution, des artefacts, des secrets et des déploiements conditionnels. Seule la syntaxe change.

Ce cours détaille GitHub Actions (chapitres 3 et 4), le plus utilisé par les étudiants, puis GitLab CI (chapitre 5), très présent dans les entreprises qui accueillent des stagiaires. Qui maîtrise l'un lit l'autre en une heure.

La CI/CD dans le référentiel du BTS SIO

Le référentiel du BTS SIO (arrêté du 8 juillet 2024, sessions 2025 et suivantes) cite la CI/CD à plusieurs endroits :

En SISR, tu croiseras la même démarche sous le nom d'infrastructure as code : des fichiers de configuration versionnés (Ansible, Docker Compose, Terraform) appliqués par un pipeline plutôt que par des commandes tapées à la main (chapitre 10). Le cours Automatisation avec Ansible en fait le cœur de son approche, jusqu'à versionner l'infrastructure et la tester en CI.

Organiser les branches pour intégrer souvent

L'intégration continue suppose des branches courtes. Deux organisations dominent (workflows Git) :

• Le développement sur tronc commun (trunk-based development) et sa variante GitHub Flow : une branche principale main toujours livrable, des branches de fonctionnalité qui vivent un ou deux jours, une pull request vérifiée par la CI pour chaque fusion. C'est l'organisation naturelle de la CI/CD.
• Git Flow : des branches longues (develop, release/*, hotfix/*) pour des versions planifiées. La CI tourne sur chaque branche, mais les intégrations sont plus espacées.

Pour un projet de BTS à deux ou trois, choisis GitHub Flow : une branche par fonctionnalité, une pull request, une CI verte, une fusion.

Exercices

Exercice 1 sur 3 CI, livraison ou déploiement continu ? Réussi À revoir

Pour chaque situation, dis si l'équipe pratique seulement l'intégration continue, la livraison continue ou le déploiement continu.

1. À chaque pull request, GitHub Actions lance les tests. La mise en production se fait une fois par mois : l'administrateur copie les fichiers sur le serveur en suivant une procédure papier.
2. Chaque fusion sur main construit une image Docker, la déploie sur le serveur de recette, puis attend qu'une responsable clique sur « Approuver » pour la déployer en production.
3. Chaque fusion sur main qui passe les tests part en production sans intervention, une dizaine de fois par jour.
4. Les développeurs fusionnent leurs branches tous les deux mois. Un serveur Jenkins lance alors les tests.

Voir la réponseMasquer la réponse de l'exercice 1

1. Intégration continue seulement : la vérification est automatique, mais la livraison reste manuelle et rare.
2. Livraison continue : tout est automatique jusqu'à la recette, la production attend une décision humaine.
3. Déploiement continu : aucune barrière humaine avant la production.
4. Aucune des trois, malgré l'outil : des intégrations tous les deux mois, c'est l'intégration « big bang ». La pratique compte plus que le serveur.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 3 Les causes d'une livraison ratée Réussi À revoir

Relis l'histoire de Lina et Hugo au début du chapitre. Pour chacun des quatre problèmes (conflits, tests qui échouent, dépendance manquante, version de Node.js différente), indique la pratique de CI/CD qui l'aurait évité.

Voir la réponseMasquer la réponse de l'exercice 2

• Conflits nombreux : intégrer souvent, par petites pull requests fusionnées en un ou deux jours ; les conflits restent petits.
• Tests qui échouent à la fusion : lancer les tests automatiquement à chaque pull request ; l'échec apparaît le jour même, sur la branche fautive.
• Dépendance manquante : installer les dépendances dans un environnement neuf à chaque exécution, avec npm ci et le package-lock.json versionné ; une dépendance non déclarée fait échouer le pipeline.
• Version de Node.js différente : fixer la version dans le workflow (node-version: 24) et, mieux, construire une image Docker qui embarque cette version, déployée telle quelle sur le serveur (chapitre 9).

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 3 Argumenter devant un jury Réussi À revoir

Un membre de la commission d'E6 te demande : « Votre application fonctionne, pourquoi avoir passé du temps à mettre en place GitHub Actions ? » Rédige une réponse de quatre ou cinq phrases, en citant au moins deux apports concrets et un indicateur.

Voir la réponseMasquer la réponse de l'exercice 3

Une réponse possible : « Sans pipeline, les tests ne tournaient que quand j'y pensais, sur ma machine. Aujourd'hui, mes 42 tests et le linter tournent à chaque pull request dans un environnement neuf : une régression est détectée en trois minutes, avant la fusion, et la branche main reste toujours livrable. La règle de protection de branche m'empêche de fusionner un code rouge, même pressé. Le déploiement en recette est automatique : le délai entre un commit et sa mise à disposition pour les tests utilisateurs est passé d'une demi-journée à une dizaine de minutes. C'est aussi la compétence “Intégrer en continu les versions” du référentiel. »

Les éléments attendus : la détection précoce, l'environnement reproductible, la barrière avant la fusion, un indicateur chiffré (délai ou fréquence), et le lien avec le référentiel.

Tu avais trouvé ?

Oui, j'avais bonPas encore