- Description
- Convoyeurs à rouleaux et à bande d'une usine, en courbes bleues enchaînées.
- Source
- falco (Pixabay) · page d’origine
- Licence
- CC0 Domaine public
Intégration et livraison continues
Ce thème mesure la vitesse et la sûreté avec lesquelles un changement validé devient un livrable déployable. Les indicateurs sont ceux de la recherche DORA (fréquence de livraison, délai de…
En bref
Ce thème mesure la vitesse et la sûreté avec lesquelles un changement validé devient un livrable déployable. Les indicateurs sont ceux de la recherche DORA (fréquence de livraison, délai de mise à disposition, taux d'échec, durée de rétablissement) appliqués à la chaîne de construction et de promotion ; l'exploitation en production relève de 06.
Niveau : 🟢→🔴 · Code thème : CIC (matrice DL)
Pourquoi ce thème#
L'intégration continue vérifie à chaque changement que l'ensemble tient debout ; la livraison continue garantit qu'on peut livrer à tout moment, sans cérémonie. Sans cela, la livraison est un événement rare, tendu, manuel, qui dépend de personnes précises — le contraire d'une capacité d'équipe. Le travail de recherche Accelerate et les rapports DORA ont montré que les équipes performantes combinent vitesse et stabilité : livrer plus souvent ne dégrade pas la qualité, cela la renforce, parce que les lots sont petits.
Les quatre mesures historiques de DORA : fréquence de déploiement, délai entre le changement validé et sa mise en production, taux de changements en échec, temps de rétablissement. DORA a depuis enrichi son modèle : le temps de rétablissement est devenu « failed deployment recovery time » (limité aux échecs causés par un changement) et une cinquième mesure, le taux de reprises de travail (« deployment rework rate »), est apparue ; les seuils actuels sont à vérifier sur le site DORA. Ce thème s'appuie sur l'esprit des mesures, sans en recopier les seuils comme dogme.
Le cas de la donnée a ses particularités : une chaîne qui livre un modèle sémantique ou des procédures SQL doit gérer l'état persistant (schéma, historique chargé) ; on en parle dans CI/CD pour la data. La construction d'un kit d'installation est aussi un « artefact » à produire de façon reproductible.
Ce que mesure le thème#
- Axe : du « build sur le poste du développeur » à « chaîne automatisée, reproductible, rapide, qui promeut le même artefact jusqu'à la production ».
- Indicateurs clés : délai commit → artefact validé (minutes) ; fréquence de livraison (par semaine) ; taux d'échec de pipeline non dû au code (%) ; reproductibilité (même commit → même artefact).
- Unité : minutes ; livraisons/semaine ; %.
Tableau des cinq niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Artisanale | Une livraison se construit à la main, par quelqu'un qui connaît la recette. | Build sur poste ; livraison tous les 3 à 6 mois |
| 2 | Scriptée | N'importe qui de l'équipe peut produire le livrable en suivant un script. | Script de build ; livraison mensuelle |
| 3 | Automatisée | À chaque changement, un livrable testé est produit sans intervention. | Pipeline CI ; retour < 15 min ; livraison hebdomadaire |
| 4 | Promue | Le même artefact traverse tous les environnements ; une livraison est une décision métier, pas un effort technique. | Un artefact unique ; livraison à la demande ; échec < 15 % |
| 5 | Continue | Chaque changement validé peut partir en production en moins d'une heure, avec retour arrière automatique. | Délai changement → production < 1 jour (souvent < 1 h) ; rétablissement < 1 h |
Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| DL-CIC-1.1 | Le livrable peut être reconstruit depuis la source versionnée | Reconstruction par une tierce personne |
| DL-CIC-1.2 | Les étapes de build sont listées | Document rejouable |
| DL-CIC-1.3 | Les versions livrées portent un numéro unique | Numérotation tracée |
| DL-CIC-2.1 | Un script unique produit le livrable (sans étape cachée sur un poste) | Exécution sur machine neuve réussie |
| DL-CIC-2.2 | Les dépendances sont déclarées et figées (versions, verrouillage) | Fichier de verrouillage versionné |
| DL-CIC-2.3 | Un serveur de build dédié existe (pas le poste d'un développeur) | Identité de la machine de build |
| DL-CIC-2.4 | Les prérequis de build sont documentés ou provisionnés en code | Environnement reconstructible |
| DL-CIC-3.1 | Un pipeline se déclenche automatiquement à chaque changement | Journal des exécutions |
| DL-CIC-3.2 | Le pipeline exécute compilation, analyse statique et tests rapides en moins de 15 min | Durée médiane mesurée |
| DL-CIC-3.3 | Un pipeline rouge est traité en priorité (règle d'équipe) et rétabli en < 1 h | Délai de retour au vert mesuré |
| DL-CIC-3.4 | Le pipeline est décrit en code et versionné avec l'application | Définition dans le dépôt |
| DL-CIC-3.5 | Les artefacts sont publiés dans un référentiel avec empreinte et provenance | Référentiel d'artefacts consultable |
| DL-CIC-4.1 | Un seul artefact est promu d'environnement en environnement (on ne reconstruit pas) | Même empreinte en test et en production |
| DL-CIC-4.2 | La configuration est séparée du code et injectée par environnement | Aucun secret ou URL dans l'artefact |
| DL-CIC-4.3 | Les portes de promotion sont automatisées (tests, analyse, sécurité) avec approbation métier si requise | Journal des portes |
| DL-CIC-4.4 | La chaîne mesure les quatre indicateurs de livraison et les publie | Tableau de bord à jour |
| DL-CIC-4.5 | La construction est reproductible (même commit → même contenu, à l'horodatage près) | Reconstruction à l'identique prouvée |
| DL-CIC-5.1 | Un changement validé atteint la production en < 1 jour sans intervention manuelle technique | Mesure sur 20 changements |
| DL-CIC-5.2 | Un échec détecté en production déclenche un retour arrière automatique ou une bascule | Exercice réussi |
| DL-CIC-5.3 | Le pipeline s'auto-surveille (durée, instabilité, files d'attente) et sa dette est pilotée | Indicateurs de santé de la chaîne |
| DL-CIC-5.4 | La chaîne est elle-même testée et reconstructible (infrastructure de build en code) | Reconstruction complète de l'usine en < 1 jour |
Lecture détaillée par niveau#
🟢 Niveau 1 — Artisanale#
- Signes : « seul Pierre sait faire le build » ; le livrable dépend de la machine ; étapes manuelles non écrites.
- Gain : rapidité initiale.
- Ne garantit pas : la reproductibilité ni la continuité si la personne part.
- Difficulté : 1/5 · Effort : 1/5.
🟢 Niveau 2 — Scriptée#
- Signes : un script sait tout faire, des dépendances figées, un serveur de build.
- Gain : n'importe qui peut livrer ; les erreurs de recette baissent.
- Ne garantit pas : le retour automatique à chaque changement.
- Difficulté : 2/5 · Effort : 2/5.
🟡 Niveau 3 — Automatisée#
- Signes : le pipeline est déclenché par le changement, rapide, décrit en code. Un pipeline rouge est un incident d'équipe.
- Gain : le retour d'information passe de jours à minutes ; la qualité devient continue.
- Ne garantit pas : que l'artefact testé soit celui qu'on déploie.
- Difficulté : 3/5 · Effort : 3/5.
🔴 Niveau 4 — Promue#
- Signes : « construire une fois, déployer partout » ; la configuration est externe ; les portes sont automatisées. La livraison devient une décision.
- Gain : les surprises d'environnement disparaissent ; l'audit est trivial.
- Ne garantit pas : l'exploitation sûre — voir 06.
- Difficulté : 4/5 · Effort : 4/5.
🔴 Niveau 5 — Continue#
- Signes : changement → production en heures, avec retour arrière automatique, sans personne qui « appuie sur le bouton » technique ; la chaîne est surveillée comme un produit.
- Gain : l'équipe apprend de la production à rythme élevé.
- Ne garantit pas : que livrer vite soit toujours désirable — certains contextes (réglementés, produit livré sur site) cadencent légitimement la mise en production.
- Difficulté : 5/5 · Effort : 5/5.
Atteinte partielle et notation#
Appliquez la règle de notation.
- 0,5 sur DL-CIC-4.1 : l'artefact est promu pour l'application mais la base de données est reconstruite à chaque environnement.
- 0,5 sur DL-CIC-3.3 : pipeline rétabli en 4 h en moyenne.
- Un 5 partiel : production atteinte en 2 jours sans manuel technique, sans retour arrière automatique.
Pipeline théâtre. Symptôme : pipeline vert, déploiement manuel, tests désactivés « temporairement ». Cause : portes affaiblies pour tenir un délai. Remède : une porte contournée est comptée ; compter les contournements.
Reconstruire pour chaque environnement. Symptôme : « ça marchait en test ». Cause : un artefact différent par environnement. Remède : une seule construction, configuration injectée.
Distinguez livraison (disponible) et déploiement (en production) : un produit livré en kit d'installation a une fréquence de livraison élevée mais un déploiement dicté par le client. Mesurez ce que vous contrôlez.
Passer au niveau suivant#
Moyens possibles (facultatifs)
- 1 → 2 : remplacer les étapes manuelles par un script ; figer les dépendances.
- 2 → 3 : serveur de pipeline, déclenchement automatique, pipeline décrit en code ; règle d'équipe « pipeline rouge = stop ».
- 3 → 4 : référentiel d'artefacts, configuration externalisée, portes automatisées, mesure des indicateurs.
- 4 → 5 : bascules et déploiements progressifs, retour arrière automatique, surveillance de la chaîne.
Kit d'installation d'un datamart : au niveau 2, un script produit le kit en 25 min sur un poste identifié. Au niveau 4, le pipeline compile les scripts, rejoue une installation sur une base vierge et sur une base de la version précédente, puis publie un kit unique à empreinte contrôlée ; le même kit est utilisé en recette et en production.
Génération de pipelines et diagnostic d'échecs : gain 3/5, risque 3/5 (actions tierces non épinglées, secrets exposés dans les journaux). Garde-fou : revue des définitions de pipeline comme du code, versions d'actions épinglées, aucun secret en clair.
Récompenser la fréquence de déploiement incite à découper artificiellement ; la combiner au taux d'échec et au rétablissement évite ce travers.
Voir aussi#
- Voisins : 03 Tests · 04 Gestion de version · 06 Déploiement et exploitation · 07 Sécurité · 12 Expérience développeur.
- Autres matrices : Data — délais et industrialisation DataOps · BI — versionnement et industrialisation · Projet — livraison et mise en production.
- Pratique : CI/CD · CI/CD pour la data · Azure DevOps / TFS · métriques et reporting.
- Glossaire · Notation.
✻ Rédigé par Claude Sonnet 5.5
