i

Description

Ouvriers sur une chaîne de montage de roues dans une usine automobile

Source

auteur non indiqué · page d’origine

Licence

PD Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

CI/CD : intégration et livraison continues

Vous saurez définir précisément intégration continue (CI), livraison continue et déploiement continu (les deux « CD » sont différents), décrire un pipeline et ses environnements.

En bref

• Vous saurez définir précisément intégration continue (CI), livraison continue et déploiement continu (les deux « CD » sont différents), décrire un pipeline et ses environnements.
• Vous connaîtrez les stratégies de déploiement (recreate, rolling, blue/green, canary), les feature flags, et les cinq métriques DORA (état 2026-10).
• Vous comprendrez ce que le CI/CD apporte à la conduite de projet (visibilité, risque, cadence, preuve) — et surtout ses limites : coûts, faux sentiment de sécurité, couverture de tests, dette de pipeline, gouvernance, réglementation, legacy, organisation.
• La version spécifique aux données est dans 11 CI/CD pour la data ; ici, le socle commun.

Sur cette page

1. 1. Définitions : CI, livraison continue, déploiement continu
   1. 🟢 Novice — trois notions souvent confondues
   2. 🟡 Pratique — la règle des trois « tout »
   3. 🔴 Expert — CI : ce que l'automatisation ne garantit pas
2. 2. Anatomie d'un pipeline
   1. 🟢 Novice — le pipeline comme chaîne de contrôles
   2. 🟡 Pratique — définition de pipeline « en code »
   3. 🔴 Expert — conception d'un bon pipeline
3. 3. Environnements et promotion
   1. 🟢 Novice — pourquoi plusieurs environnements
   2. 🟡 Pratique — la parité et la promotion
   3. 🔴 Expert — environnements éphémères
4. 4. Stratégies de déploiement
   1. 🟢 Novice — quatre façons de remplacer une version
   2. 🟡 Pratique — choisir
   3. 🔴 Expert — rollback, roll-forward, et irréversibilité
5. 5. Feature flags et dissociation déploiement/livraison
   1. 🟢 Novice — l'interrupteur
   2. 🟡 Pratique — usages et typologie
   3. 🔴 Expert — la dette de flags
6. 6. Les métriques DORA
   1. 🟢 Novice — ce qu'on mesure
   2. 🟡 Pratique — comment les mesurer sans se tromper
   3. 🔴 Expert — au-delà de DORA
7. 7. Ce que le CI/CD apporte à la conduite de projet
   1. 🟢 Novice — pas seulement une affaire technique
   2. 🟡 Pratique — le lien avec les méthodes
   3. 🔴 Expert — « livrer » et « mettre en production » ne sont pas synonymes
8. 8. Les limites du CI/CD
   1. 🟢 Novice — ce que l'automatisation ne fait pas
   2. 🟡 Pratique — huit limites à connaître
   3. 🔴 Expert — les limites en profondeur
9. 9. Mettre en place : trajectoire réaliste
   1. 🟡 Pratique — une trajectoire en cinq paliers
10. 10. Notes de maturité des pratiques
11. 11. Contribution de l'IA
12. 12. Voir aussi

Niveau : 🟢→🔴

1. Définitions : CI, livraison continue, déploiement continu#

🟢 Novice — trois notions souvent confondues#

Historiquement, l'intégration continue est popularisée par l'Extreme Programming (années 1990-2000) ; le livre Continuous Delivery (Humble et Farley, 2010) formalise le pipeline de déploiement. Ces références sont solides ; ne retenez que les idées : petits lots, feedback rapide, tout automatisé et reproductible.

🟡 Pratique — la règle des trois « tout »#

Un CI/CD sain respecte trois principes :

1. Tout est versionné : code, scripts de build, configuration, définition du pipeline, scripts de base de données.
2. Tout est reproductible : un artefact est construit une seule fois puis promu d'environnement en environnement (build once, deploy many) ; on ne recompile pas pour la production.
3. Tout est traçable : de la production, on remonte au commit, à la demande, à la personne qui a approuvé.

🔴 Expert — CI : ce que l'automatisation ne garantit pas#

L'intégration continue réduit le risque d'intégration mais n'exclut pas les erreurs de conception. Une branche « verte » signifie : les tests existants passent. Elle ne dit rien de la qualité de ces tests. Les trois conditions réelles de la CI :

• une branche principale toujours déployable (si elle casse, tout s'arrête pour la réparer : « arrêter la chaîne ») ;
• un build rapide (idéalement moins de 10 minutes pour le retour essentiel ; ordre de grandeur indicatif) ;
• des branches courtes (quelques heures à 2 jours) ou du développement sur tronc (trunk-based development) — voir stratégies de branches.

2. Anatomie d'un pipeline#

🟢 Novice — le pipeline comme chaîne de contrôles#

Un pipeline est une suite d'étapes automatisées qui transforme une modification de code en logiciel livré, avec des contrôles à chaque étape. Il échoue tôt et vite : les contrôles peu coûteux d'abord.

🟡 Pratique — définition de pipeline « en code »#

Exemple générique en YAML (syntaxe type Azure Pipelines, à adapter) :

trigger:
  branches:
    include: [ main ]
pr:
  branches:
    include: [ main ]

stages:
- stage: Build
  jobs:
  - job: build_test
    pool: { vmImage: windows-latest }
    steps:
    - script: dotnet build --configuration Release
    - script: dotnet test --no-build --logger trx
    - publish: $(Build.ArtifactStagingDirectory)
      artifact: drop

- stage: DeployTest
  dependsOn: Build
  jobs:
  - deployment: deploy_test
    environment: test
    strategy:
      runOnce:
        deploy:
          steps:
          - script: ./deploy.ps1 -Env Test

- stage: DeployProd
  dependsOn: DeployTest
  condition: succeeded()
  jobs:
  - deployment: deploy_prod
    environment: production    # approbation configurée sur l'environnement
    strategy:
      runOnce:
        deploy:
          steps:
          - script: ./deploy.ps1 -Env Prod

Principes : pipeline as code (le YAML est versionné avec le produit), environnements avec approbations configurées, artefact unique publié à l'étape Build et consommé par les suivantes. Détails d'outil : Azure DevOps / TFS en profondeur.

🔴 Expert — conception d'un bon pipeline#

Critères de conception :

3. Environnements et promotion#

🟢 Novice — pourquoi plusieurs environnements#

Un environnement est une instance isolée où le produit tourne : développement, test/recette, préproduction, production. Chacun répond à une question différente.

🟡 Pratique — la parité et la promotion#

Le principe de parité : plus un environnement ressemble à la production (versions, configuration, volume, droits), plus les tests y sont prédictifs. Les écarts typiques qui cassent : versions d'un moteur, niveau de compatibilité, droits des comptes de service, volumétrie, fuseau horaire/langue, configuration régionale.

La promotion déplace le même artefact d'un environnement à l'autre ; ce qui change, c'est la configuration (chaîne de connexion, variables), injectée au déploiement, jamais figée dans l'artefact.

🔴 Expert — environnements éphémères#

Les environnements créés à la demande (par pull request) puis détruits suppriment les files d'attente d'environnement partagé et les « dérives de configuration ». Condition : l'infrastructure décrite en code (Bicep, Terraform, scripts) et des données de test provisionnables. Coût : réel (calcul, licences) ; à arbitrer. Pour la donnée, l'éphémère est difficile (volume, anonymisation) — voir 11 CI/CD pour la data.

4. Stratégies de déploiement#

🟢 Novice — quatre façons de remplacer une version#

🟡 Pratique — choisir#

La clé est la compatibilité ascendante : si la nouvelle version tolère l'ancien schéma de données et l'ancienne tolère le nouveau, tout devient possible (expand/contract : on étend le schéma, on déploie, puis on contracte quand l'ancienne version a disparu). C'est le pont avec le déploiement de bases de données.

🔴 Expert — rollback, roll-forward, et irréversibilité#

• Rollback : revenir à la version précédente. Facile pour du code sans état, impossible ou dangereux dès qu'une donnée a été écrite dans un nouveau format.
• Roll-forward : corriger par une nouvelle version rapide. Souvent plus sûr que le rollback sur un système avec état, à condition que le pipeline soit rapide (le délai de correction devient la mesure de la résilience).
• Désactivation par flag : dans bien des cas, le meilleur « rollback » est d'éteindre une fonctionnalité (section suivante).

5. Feature flags et dissociation déploiement/livraison#

🟢 Novice — l'interrupteur#

Un feature flag (ou feature toggle) est un interrupteur dans le code ou la configuration qui active ou désactive une fonctionnalité sans redéployer. Il permet de déployer du code (le mettre en production) sans le livrer (le rendre visible aux utilisateurs) : le déploiement devient un non-événement technique, la livraison devient une décision métier.

🟡 Pratique — usages et typologie#

Exemple minimal en PowerShell (lecture d'un indicateur de configuration) :

$cfg = Get-Content .\config.json -Raw | ConvertFrom-Json
if ($cfg.features.nouveauCalculCouverture) {
    Invoke-NouveauCalcul
} else {
    Invoke-AncienCalcul
}

🔴 Expert — la dette de flags#

Chaque flag double les chemins de code à tester. Règles : un propriétaire, une date de retrait prévue à la création, un inventaire, un nettoyage régulier ; limiter les combinaisons testées. En data/BI, l'équivalent est une mesure ou une règle alternative versionnée (paramètre de configuration choisissant la règle de calcul), avec la même exigence de retrait — voir 11 CI/CD pour la data.

6. Les métriques DORA#

🟢 Novice — ce qu'on mesure#

DORA (DevOps Research and Assessment) est un programme de recherche, repris par Google Cloud, qui publie depuis 2014 un rapport annuel State of DevOps. Le livre Accelerate (Forsgren, Humble, Kim, 2018) en synthétise les résultats : certaines capacités techniques et organisationnelles sont corrélées à une meilleure performance de livraison et à de meilleurs résultats organisationnels.

Les mesures de performance de livraison (état 2026-10, après l'évolution de 2024) :

Remarque de vérification : le rapport 2024 a formalisé cinq mesures (la cinquième, rework rate, est nouvelle) ; l'ancien « MTTR » avait été rebaptisé failed deployment recovery time dès 2023, et DORA le classe désormais côté débit, avec le délai de mise en production et la fréquence de déploiement. Le rapport 2025, consacré au développement assisté par IA, a abandonné les anciennes catégories « élite/haute/moyenne/faible » au profit de profils (archétypes) d'équipes, et conclut que l'IA est corrélée à un meilleur débit mais encore à plus d'instabilité (état 2026-10 ; recoupement par recherche web, sources secondaires — à vérifier sur les publications de DORA avant de citer un chiffre).

🟡 Pratique — comment les mesurer sans se tromper#

• Source de données : le dépôt (commits, fusions), le pipeline (déploiements), le gestionnaire d'incidents. Définir « déploiement » et « échec » une fois pour toute l'équipe.
• Utiliser comme thermomètre d'équipe, jamais comme objectif individuel ni comme comparaison entre équipes aux contextes différents.
• Lire en tendance et par paires (débit et stabilité) : une fréquence qui monte avec un taux d'échec qui monte n'est pas une victoire.

🔴 Expert — au-delà de DORA#

DORA mesure le flux jusqu'à la production, pas la valeur. Un flux rapide de fonctionnalités inutiles est un mauvais résultat. À compléter par : valeur délivrée (adoption, usage), qualité perçue, santé de l'équipe, et pour la donnée : fraîcheur, fiabilité (voir 10 Métriques et reporting de projet). Pour un projet data peu fréquent en production (livraison mensuelle en kits), la fréquence reste faible par nature : lire plutôt le délai et le taux d'échec. Le cadre d'espace SPACE (Forsgren et coll., 2021) rappelle que la productivité a plusieurs dimensions.

7. Ce que le CI/CD apporte à la conduite de projet#

🟢 Novice — pas seulement une affaire technique#

Le CI/CD modifie la conduite, pas seulement l'outillage :

🟡 Pratique — le lien avec les méthodes#

• Scrum : la Definition of Done doit inclure « déployé en recette par le pipeline » ; l'incrément n'est « Done » que s'il est utilisable. Voir Scrum en pratique et Scrum et data.
• Kanban/Lean : le pipeline rend visibles les files d'attente et les goulots (agiles et Lean).
• Méthodes prédictives : le CI/CD réduit l'effet « intégration tardive » et rend les jalons vérifiables (prédictives).
• Gouvernance : les portes d'approbation (gates) du pipeline matérialisent les revues et recettes ; elles peuvent remplacer un comité de recette par des preuves automatiques pour le risque faible.

🔴 Expert — « livrer » et « mettre en production » ne sont pas synonymes#

Dans un contexte B2B avec clients à version figée ou kits installés par les clients, on livre en continu (un kit toujours prêt) mais on ne déploie pas en continu chez les clients : la cadence d'installation est celle du client. Le CI/CD apporte alors la qualité de l'artefact et la traçabilité, pas la fréquence de production. C'est un cas très courant, mal couvert par la littérature DevOps centrée sur le SaaS.

8. Les limites du CI/CD#

🟢 Novice — ce que l'automatisation ne fait pas#

Le CI/CD est un amplificateur : il rend rapide ce qui est bon et ce qui est mauvais. Il ne fabrique pas la qualité, il l'exécute et la mesure. Les limites ci-dessous sont des raisons de ne pas en attendre trop, pas de ne pas l'adopter.

🟡 Pratique — huit limites à connaître#

🔴 Expert — les limites en profondeur#

Faux sentiment de sécurité et risque d'accélération. Livrer plus vite accroît la quantité de changements en vol ; si la détection d'incidents et la capacité de correction ne suivent pas, l'instabilité augmente. Les travaux récents de DORA sur l'IA vont dans ce sens : débit en hausse, stabilité pas automatiquement améliorée (état 2026-10, voir section 6). Conclusion pratique : plus on accélère, plus la supervision et les tests doivent être sérieux.

Couverture de tests : le vrai problème est la pertinence. Quatre niveaux, du moins au plus utile :

1. couverture de lignes (facile à gonfler) ;
2. couverture de branches ;
3. couverture des règles métier (chaque règle a au moins un test nommé) ;
4. tests mutants (on altère le code, les tests doivent échouer).

Dette de pipeline. Les symptômes mesurables : durée de pipeline qui double sans changement de périmètre ; taux d'échec « d'infrastructure » (agent, réseau) en hausse ; nombre de scripts sans propriétaire. Un pipeline est du code : il se revoit, se teste (sur un projet bac à sable), se versionne.

Gouvernance et réglementation. Le pipeline concentre un pouvoir élevé : il a le droit de déployer en production. C'est une cible d'attaque (chaîne d'approvisionnement logicielle). Mesures : secrets dans un coffre, jetons à durée limitée, agents isolés, approbation à deux personnes pour la production, journaux d'audit conservés. En contexte réglementé, le CI/CD est un atout de preuve (tout est tracé) autant qu'une contrainte — à condition de l'avoir conçu avec l'audit.

Systèmes legacy. Ordre pragmatique : (1) mettre tout le code et les scripts sous contrôle de version ; (2) scripter le déploiement (même si c'est un script manuel au début) ; (3) construire un build reproductible ; (4) ajouter des tests de caractérisation (figer le comportement actuel, même s'il est « mauvais ») sur les zones à risque ; (5) automatiser la promotion. Vouloir tout refaire d'un coup est la meilleure façon de ne rien livrer.

Organisation. Le CI/CD échoue d'abord pour des raisons humaines : équipes qui ne s'intègrent pas souvent, responsabilité d'exploitation ailleurs, recette métier qui ne veut pas d'automatisme, crainte du changement. Un pipeline excellent dans une organisation de peur se contourne.

9. Mettre en place : trajectoire réaliste#

🟡 Pratique — une trajectoire en cinq paliers#

La matrice 05 Intégration et livraison continues et 06 Déploiement et exploitation donnent des jalons vérifiables pour situer l'équipe.

10. Notes de maturité des pratiques#

Appréciations d'expert, contextuelles (équipe de 4 à 10 personnes, produit interne ou B2B, plateforme Microsoft). Voir NOTATION. Les notes expriment la valeur apportée par la pratique à effort raisonnable et sa maturité d'écosystème.

11. Contribution de l'IA#

Prompt d'exemple : « Voici le journal d'un pipeline qui échoue à l'étape de déploiement (secrets masqués). Liste les 3 causes les plus probables, classées par probabilité, avec pour chacune la vérification à faire et la commande correspondante. »

12. Voir aussi#

• Suite directe : 11 CI/CD pour la data · 13 Pièges et bonnes pratiques
• Méthodes : 01 Fondamentaux · 03 Scrum en pratique · 07 Méthodes spécifiques data · 09 Choisir et hybrider
• Outils : Stratégies de branches · Azure DevOps / TFS · TFVC · Git en profondeur
• Matrices : Intégration et livraison continues · Déploiement et exploitation · Tests
• Glossaire · Bibliographie

✻ Rédigé par Claude Sonnet 5.5