Délais et industrialisation (DataOps)

Le DataOps applique à la donnée les principes de la livraison continue : changement petit, testé, rejouable, réversible, observable. Il se distingue du DevOps classique par trois…

Guide≈ 8 min de lectureVérifiéLecture

Sur cette page

Pourquoi ce thème
Ce que mesure le thème
Les cinq niveaux
Jalons par niveau
Lecture détaillée par niveau
Atteinte partielle et notation
Passer au niveau suivant
Voir aussi

Niveau : 🟢→🔴 · Code thème : DOP

Pourquoi ce thème#

Le DataOps applique à la donnée les principes de la livraison continue : changement petit, testé, rejouable, réversible, observable. Il se distingue du DevOps classique par trois contraintes : l'état (une base ne se « redéploie » pas, elle se migre en conservant ses données), le volume (rejouer coûte cher) et la dépendance aux sources (le déploiement ne dépend pas que de l'équipe). Une équipe sans DataOps livre lentement et par peur : chaque déploiement est un événement, la production diverge du développement, et un retour arrière n'existe que sur le papier. Les pratiques détaillées (pipelines, bases de données, tests) sont dans CI/CD pour la data et le CI/CD général ; la mesure de la livraison de code est côté matrice DL — intégration et livraison continues. Ici, on juge la capacité à livrer des changements de données sûrement et vite.

Ce que mesure le thème#

Axe : de la livraison artisanale à la mise en production continue, sûre et mesurée.
Indicateur clé : délai de bout en bout d'un changement de données (de la demande validée à la production) et taux d'échec des déploiements.
Unité : jours ou heures ; % de déploiements nécessitant correctif ou retour arrière ; temps de restauration. Les quatre mesures DORA (fréquence de déploiement, délai de livraison, taux d'échec, temps de restauration — cf. Accelerate) servent de repères.

Les cinq niveaux#

Niveau	Nom court	Promesse	Indicateur type (ordre de grandeur)
1	Manuel	Un changement arrive en production grâce à une personne qui connaît la marche à suivre.	Délai en semaines ; échec fréquent ; restauration en jours
2	Reproductible	Le même changement se déploie de la même façon par n'importe quel membre de l'équipe (scripts, kits).	Délai en jours ; déploiement documenté
3	Versionné et testé	Tout changement vient du dépôt, passe des tests automatiques et se déploie par un pipeline vers des environnements identiques.	Délai < 3 jours ; ≥ 80 % de déploiements sans correctif
4	Continu et réversible	Un changement validé arrive en production sans intervention, avec contrôle d'effet et retour arrière vérifié.	Plusieurs déploiements par semaine ; restauration < 1 h
5	À la demande	Le déploiement est un non-événement ; l'organisation l'optimise par la mesure et l'expérimentation.	Déploiement quotidien ; échec < 5 % ; restauration en minutes

Jalons par niveau#

ID	Jalon	Preuve vérifiable
PD-DOP-1.1	Une procédure de mise en production existe et est écrite.	Procédure datée, suivie lors du dernier déploiement.
PD-DOP-1.2	La liste des objets livrés est connue pour chaque livraison.	Note de livraison avec objets et version.
PD-DOP-1.3	Un environnement de test distinct de la production existe.	Environnement nommé, accessible, rafraîchi.
PD-DOP-1.4	Une sauvegarde est prise avant chaque déploiement.	Trace de sauvegarde datée avant le dernier déploiement.
PD-DOP-2.1	Les scripts de déploiement sont rejouables (idempotents) : les relancer ne casse rien.	Double exécution d'un script sur copie sans erreur ni doublon.
PD-DOP-2.2	Le déploiement s'effectue d'un seul geste (script, kit) sans retouche manuelle.	Observation d'un déploiement par une personne qui ne l'a pas écrit.
PD-DOP-2.3	Le numéro de version est tenu et visible dans la base ou le rapport.	Requête de version retournant le numéro du dernier déploiement.
PD-DOP-2.4	Le contenu livré est tracé aux demandes (tickets, changesets).	Chaque version liée à ses éléments de travail.
PD-DOP-3.1	Tout le code de données (SQL, modèle, configuration) est versionné dans un dépôt (GDS et SQL/BI).	Dépôt complet ; aucun objet modifié hors dépôt (comparaison base ↔ dépôt).
PD-DOP-3.2	Un pipeline exécute build et tests automatiques à chaque changement.	Historique de builds avec résultats de tests.
PD-DOP-3.3	Les environnements sont construits par le même mécanisme (pas de dérive entre test et production).	Comparaison de schéma entre environnements sans écart non expliqué.
PD-DOP-3.4	Les migrations de schéma conservent les données et sont testées sur un jeu représentatif.	Migration jouée sur copie avec contrôle de volumes et de totaux.
PD-DOP-4.1	La mise en production est automatisée et ne demande qu'une approbation.	Pipeline de déploiement avec étape d'approbation.
PD-DOP-4.2	Un retour arrière est prévu et a été répété (pas seulement décrit).	Exercice de restauration documenté, durée mesurée.
PD-DOP-4.3	Après déploiement, un contrôle d'effet (fraîcheur, volumes, totaux) valide la livraison.	Contrôles post-déploiement dans le pipeline, avec résultat archivé.
PD-DOP-4.4	Les indicateurs de livraison (délai, fréquence, échec, restauration) sont suivis.	Tableau DORA ou équivalent sur ≥ 3 mois.
PD-DOP-5.1	Les déploiements sont quotidiens ou à la demande, avec petits lots.	Fréquence mesurée ≥ 1 par jour ouvré sur un mois.
PD-DOP-5.2	Les changements risqués sont isolés (déploiement progressif, environnements éphémères, données masquées).	Cas réel d'environnement éphémère ou de bascule progressive.
PD-DOP-5.3	Les goulots du flux sont identifiés et traités de façon continue.	Cartographie du flux avec actions et gains mesurés.
PD-DOP-5.4	Les coûts d'environnement de test sont maîtrisés (extinction, taille réduite).	Mesure du coût des environnements de test (FIN).

Lecture détaillée par niveau#

🟢 Niveau 1 — Manuel#

Signes : « on déploie le jeudi soir avec Paul » ; la production comporte des objets inconnus du développement.
Gain : zéro investissement d'outillage.
Ne garantit pas : le déploiement identique d'une fois sur l'autre ; la continuité quand Paul est absent.
Difficulté : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Reproductible#

Signes : un kit d'installation unique ; scripts rejouables ; version consultable dans la base.
Gain : une livraison cesse de dépendre d'une personne ; les rejeux ne corrompent plus.
Ne garantit pas : l'absence d'erreur (aucun test automatique) ni la vitesse.
Difficulté : 2/5 · Effort : 3/5.

-- Idempotence : un ajout de colonne rejouable sans erreur
IF COL_LENGTH('[fact].[Releve]', 'REL_COMMENTAIRE') IS NULL
    ALTER TABLE [fact].[Releve] ADD [REL_COMMENTAIRE] NVARCHAR(400) NULL;

🟡 Niveau 3 — Versionné et testé#

Signes : tout est dans le dépôt ; un pipeline construit une base vide, joue les migrations, exécute les tests ; test et production ont le même schéma.
Gain : les régressions sont détectées avant la production ; le délai diminue parce que la peur diminue.
Ne garantit pas : le déploiement sans interruption ni le retour arrière.
Difficulté : 3/5 · Effort : 4/5.

🧪 Exemple

Un datamart livré par kits : avant, 5 jours entre la recette et la production, deux déploiements sur dix corrigés en urgence. Après un pipeline qui reconstruit la base vide, joue le chargement partiel puis compare les totaux à la référence, le délai tombe à 1 jour et les urgences à un déploiement sur vingt. Le gain principal vient de la recette automatique des totaux (REC), pas de l'outil de pipeline.

🟡 Niveau 4 — Continu et réversible#

Signes : approbation unique ; retour arrière répété ; contrôle d'effet post-déploiement ; indicateurs DORA lisibles.
Gain : les changements deviennent petits et fréquents, donc moins risqués.
Ne garantit pas : le retour arrière sans perte de données (une migration destructrice reste irréversible) ; planifiez la compatibilité arrière du schéma.
Difficulté : 4/5 · Effort : 4/5.

🔴 Niveau 5 — À la demande#

Signes : livraisons quotidiennes ; environnements éphémères avec données masquées ; flux optimisé en continu.
Gain : réactivité métier ; moindre coût par changement.
Ne garantit pas : la pertinence de ce qu'on livre ; la vitesse sans VAL produit seulement plus de rapports inutiles.
Difficulté : 5/5 · Effort : 5/5.

Atteinte partielle et notation#

Mesurez sur les dix derniers déploiements : un jalon vaut 1 si au moins neuf respectent la pratique, 0,5 si cinq à huit, 0 sinon. Pour les indicateurs (DOP-4.4), la mesure doit être calculée à partir d'événements (historique de pipeline), pas déclarée.

Un « 5 partiel » : livraisons hebdomadaires par pipeline avec retour arrière répété (4.x acquis), un environnement éphémère testé une fois (5.2 à 0,5), flux cartographié mais goulots non traités (5.3 à 0,5), coût de test non mesuré (5.4 à 0). Score ≈ 4,0 + 0,5 × 0,99.

⚠️ Piège

Aller vite sans tester : le pipeline automatise l'erreur. Symptôme : fréquence de déploiement en hausse, incidents aussi. Remède : ne dépassez pas le niveau de REC et QUA : DOP ne doit jamais avoir plus de deux niveaux d'avance sur eux.

⚠️ Piège

Rejouer un chargement qui n'est pas idempotent : doublons, totaux multipliés. Cause : insertion sans purge préalable ni clé de rejeu. Remède : un traitement se purge ou se MERGE sur sa clé ; testez le rejeu deux fois de suite.

Passer au niveau suivant#

Moyens possibles (facultatifs)

Passage	Leviers possibles
1 → 2	Un kit unique, des scripts idempotents, une table de version.
2 → 3	Tout dans un dépôt ; un pipeline qui construit une base depuis zéro ; un jeu de test représentatif (voir tests).
3 → 4	Automatiser le déploiement ; répéter la restauration ; ajouter des contrôles post-déploiement ; expand/contract pour les changements de schéma.
4 → 5	Réduire la taille des lots ; environnements éphémères masqués ; identifier le goulot par la cartographie de flux.

Pièges transverses : (1) Faux positif — pipeline vert qui ne teste rien d'important. (2) Goodhart — maximiser la fréquence de déploiement en découpant artificiellement ; surveillez aussi le taux d'échec. (3) État — traiter une base comme du code sans scripts de migration : on perd des données.

🤖 IA

Elle écrit des scripts de migration, des gabarits de pipeline et des jeux de test, et résume un journal d'échec. Elle ne mesure pas votre risque de production : tout script généré se rejoue sur copie avant production, et aucun secret ne figure dans un prompt.

Voir aussi#

Même matrice : 04 Contrats · 07 Recette · 10 Exploitation · 11 Coût et valeur · README
Autres matrices : DL — intégration et livraison continues · DL — déploiement et exploitation · DL — gestion de version et branches · BI — versionnement et industrialisation des rapports
Pratique : CI/CD pour la data · CI/CD · TFVC en profondeur · Azure DevOps / TFS · métriques de projet
Glossaire · Notation

✻ Rédigé par Claude Sonnet 5.5