Module L38 · Partie K · Ingénierie de l’IA

Bonnes pratiques : CRISP-ML(Q), MLOps, AIOps — le cycle de vie industrialisé.

Un modèle qui marche sur un portable n’est pas un produit. CRISP-ML(Q) est le processus (phases, tâches, assurance qualité à chaque étape) ; MLOps est l’ingénierie qui l’automatise (données, code, modèles versionnés ; pipelines reproductibles ; CI/CD/CT ; monitoring ; gouvernance) ; AIOps est l’application de l’IA à l’exploitation informatique elle-même (détection d’anomalies dans les journaux et métriques, corrélation d’incidents, prédiction de pannes). Ce chapitre donne les cadres, les niveaux de maturité, les pratiques concrètes avec du code, les mathématiques de l’assurance qualité (tests, contrôle statistique, risque), et les références.

Durée : 3 séances · Prérequis : L06, L32, L33, L35, L36. Objectifs : dérouler CRISP-ML(Q) sur un projet avec ses livrables et ses portes de qualité ; construire un pipeline MLOps minimal (données → entraînement → évaluation → registre → déploiement → monitoring) reproductible et testé ; situer une organisation sur les niveaux de maturité ; mettre en œuvre une détection d’anomalies AIOps sur des métriques d’exploitation ; documenter la gouvernance (cartes, lignage, conformité).

Ce que vous saurez faire à la fin

Écrire le plan qualité d’un projet IA : risques, tests, critères d’acceptation par phase.
Implémenter un pipeline reproductible avec versions liées (données, code, modèle) et tests automatiques.
Choisir le niveau d’automatisation (0 → 2) adapté à la fréquence de changement.
Appliquer l’IA à l’exploitation : anomalies, corrélation, prédiction, avec les métriques de leur utilité.

Fiche de cours · Définitions

Définitions

Définition (CRISP-DM, CRISP-ML(Q)). CRISP-DM (1999) : six phases itératives — compréhension métier, compréhension des données, préparation, modélisation, évaluation, déploiement. CRISP-ML(Q) (Studer et al. 2021) l’étend au ML avec une phase « surveillance et maintenance » et une assurance qualité systématique : pour chaque tâche, identifier les risques, définir des mesures et des critères, vérifier.

Définition (MLOps). Ensemble de pratiques (issues de DevOps) pour livrer et exploiter des systèmes ML de manière fiable et efficace : versionnage de tout (données, code, modèles, configuration, environnement), pipelines automatisés, intégration continue (CI : tests), livraison continue (CD : déploiement), entraînement continu (CT : ré-entraînement automatique), monitoring, gouvernance.

Définition (niveaux de maturité MLOps — Google). Niveau 0 : processus manuel, notebooks, déploiement de modèles à la main. Niveau 1 : pipeline d’entraînement automatisé, entraînement continu déclenché, validation des données et du modèle. Niveau 2 : CI/CD des pipelines eux-mêmes, expérimentation rapide, registre, déploiement automatisé avec tests, monitoring bouclé sur le ré-entraînement.

Définition (reproductibilité, lignage). Reproductibilité : relancer le pipeline avec les mêmes versions donne le même modèle (aux non-déterminismes GPU près). Lignage : pouvoir, depuis une prédiction en production, remonter au modèle, à ses données, au code, aux hyperparamètres, à l’auteur et à l’évaluation.

Définition (tests d’un système ML). Tests de données (schéma, distributions, fuites), tests de code (unitaires, intégration), tests de modèle (qualité minimale, tranches, invariances, comportements attendus — CheckList), tests d’infrastructure (reproductibilité, déploiement, rollback), tests en production (canary, shadow). Le « ML Test Score » (Breck 2017) les catalogue.

Définition (gouvernance). Rôles et responsabilités, documentation (cartes de modèle, datasheets), gestion des risques (AI Act : classification, exigences), accès et audit, conformité RGPD, comité d’éthique/revue, gestion des incidents.

Définition (AIOps). Application de l’analyse de données et du ML à l’exploitation informatique : ingestion de journaux/métriques/traces, détection d’anomalies, réduction du bruit d’alertes (regroupement, déduplication), corrélation d’événements et localisation de la cause, prédiction de pannes/capacité, remédiation automatique. Métriques : MTTD (temps de détection), MTTR (temps de résolution), taux d’alertes actionnables, précision/rappel des anomalies.

Définition (LLMOps). Spécialisation MLOps pour les LLM : gestion des prompts (versions, tests), évaluation par juges, traces des chaînes/agents, cache, coûts par token, garde-fous, boucle de retours humains.

Fiche de cours · Formules

Formules et grilles à connaître

Phase CRISP-ML(Q)	Tâches	Livrables	Assurance qualité (exemples de critères)
1. Compréhension métier et données	Objectif, KPI, faisabilité, données disponibles, contraintes (L34)	Cahier des charges, exigences mesurables, évaluation de faisabilité	KPI relié à une métrique ML ; données existantes et accessibles ; risques listés
2. Préparation des données	Collecte, nettoyage, annotation, séparation, documentation (L36)	Jeu versionné, datasheet, rapport de qualité	Schéma validé ; doublons/fuites contrôlés ; kappa ≥ seuil ; test scellé
3. Modélisation	Escalade (L37), expérimentation, sélection	Modèle candidat, journal d’expériences, carte de modèle	Baseline battue avec IC ; reproductibilité ; ressources dans le budget
4. Évaluation	Banc complet (L32) : qualité, robustesse, équité, coût, sécurité	Rapport d’évaluation, décision go/no-go	Seuils d’acceptation atteints par tranche ; revue par un tiers
5. Déploiement	Empaquetage, service (L33), shadow/canary, runbooks	Service en production, documentation d’exploitation	Tests d’infra passés ; rollback testé ; SLO respectés en canary
6. Surveillance et maintenance	Monitoring, dérive, ré-entraînement, incidents (L35)	Tableau de bord, politique de ré-entraînement, post-mortems	Alertes calibrées ; métriques avec étiquettes ; revue périodique

Risque = probabilité × impact ; priorité des tâches d’AQ par risque décroissant ; un critère d’acceptation par risque majeur

Contrôle statistique de processus (SPC) sur une métrique m suivie par lots : limites μ ± 3σ (règle des 3σ : 0,3 % de fausses alertes) ; règles de Western Electric (2 points sur 3 hors ±2σ, 8 points d’un même côté)

Score de test ML (Breck) : pour chacun des 28 tests, 0 (absent), 0,5 (manuel), 1 (automatisé) ; score = min(somme données, code, modèle, monitoring) ; < 1 : non prêt ; ≥ 5 : prêt pour la production

MTTD, MTTR ; disponibilité = MTBF/(MTBF + MTTR) ; budget d’erreur = 1 − SLO (99,9 % ⇒ 43 min/mois)

Anomalie par z-score robuste : |x − médiane|/(1,4826·MAD) > 3,5 ; par prévision : résidu = x_t − x̂_t hors intervalle de prédiction ; par isolation forest : score ∝ 2^{−E[h(x)]/c(n)}

Réduction du bruit d’alertes : regrouper par fenêtre temporelle et similarité (Jaccard des étiquettes, distance de texte) ; taux d’alertes actionnables = actionnables/total ; objectif > 50 %

Coût du délai : coût d’un incident ≈ (durée de détection + durée de résolution) × coût horaire d’indisponibilité + coût de réputation ⇒ la valeur d’AIOps est dans MTTD

Fiche de cours · Théorèmes et démonstrations

Ce qu’on peut démontrer sur le processus

Proposition 1 (le coût d’un défaut croît avec la phase où il est détecté). Si un défaut introduit en phase i coûte c_i à corriger et que le corriger en phase j > i exige de refaire les phases i..j, le coût est Σ_k=i^j c_k ≥ c_i ; pour des phases de coût croissant, il croît au moins linéairement, souvent géométriquement (défaut de données découvert en production : ré-annoter, ré-entraîner, ré-évaluer, redéployer).

Refaire la chaîne aval est nécessaire dès que le défaut invalide les artefacts produits (un jeu de données faux invalide le modèle, l’évaluation et le déploiement). Les études empiriques (Boehm en génie logiciel ; Sambasivan 2021 pour les « cascades de données » en ML) donnent des facteurs de 10 à 100 entre la détection en préparation et en production. C’est la justification de l’AQ par phase de CRISP-ML(Q) : des tests de données avant l’entraînement, une évaluation complète avant le déploiement, et des tests d’infrastructure avant le trafic réel.

Proposition 2 (l’automatisation est rentable au-delà d’une fréquence de changement). Si un cycle manuel coûte m par exécution et que l’automatisation coûte A une fois puis a par exécution (a ≪ m), avec f exécutions par mois, l’automatisation est rentable après A/((m − a)·f) mois.

Coût manuel cumulé à t mois : m·f·t ; automatisé : A + a·f·t ; égalité en t* = A/((m − a)f). Exemple : cycle manuel de 2 jours-ingénieur (m = 1 000 €), automatisation 20 jours (A = 10 000 €), a ≈ 50 €, f = 4/mois : t* = 10 000/(950 × 4) ≈ 2,6 mois. Pour f = 0,25/mois (un ré-entraînement par trimestre) : 42 mois — le niveau 0 est rationnel. La maturité MLOps se choisit selon la fréquence de changement des données et des modèles, pas selon la mode.

Proposition 3 (SPC : la règle des 3σ contrôle les fausses alertes, pas la puissance). Pour une métrique stable gaussienne, la probabilité qu’un point sorte de μ ± 3σ est 0,27 % ; un décalage de 1σ de la moyenne n’est détecté au premier point que dans 2,3 % des cas, et en moyenne après 44 points (ARL₁ ≈ 44) ; les cartes CUSUM/EWMA détectent les petits décalages bien plus vite.

P(|Z| > 3) = 0,0027. Après décalage de 1σ, P(Z + 1 > 3 ou Z + 1 < −3) = P(Z > 2) + P(Z < −4) ≈ 0,0228 ; le nombre de points avant détection est géométrique de moyenne 1/0,0228 ≈ 44. CUSUM accumule S_t = max(0, S_t−1 + (x_t − μ − k)) et alerte si S_t > h : pour k = 0,5σ, h = 5σ, l’ARL₀ (sans dérive) ≈ 465 et l’ARL₁ (décalage 1σ) ≈ 10. Leçon pour le monitoring (L35) : choisir le détecteur pour le type de dérive attendu — brusque (3σ) ou lente (CUSUM/EWMA).

Proposition 4 (le lignage est un graphe orienté acyclique, et l’impact d’un changement est sa fermeture descendante). Si les artefacts (données, code, modèles, déploiements) sont les nœuds d’un DAG de dépendances, l’ensemble des artefacts à re-valider après modification d’un nœud est l’ensemble de ses descendants — calculable par un parcours (L05).

Un artefact dépend de ses entrées ; un changement d’entrée invalide (potentiellement) toute sortie qui en dépend, transitivement : parcours en profondeur depuis le nœud modifié. Sans cycle (un modèle ne produit pas ses propres données d’entraînement — sinon boucle de retour, L35). Les outils (DVC, MLflow, orchestrateurs) matérialisent ce graphe ; c’est ce qui rend possible « qu’est-ce qui doit être relancé ? » et « d’où vient cette prédiction ? » en une requête.

01 / CRISP-ML(Q)

Le plan qualité d’un projet : risques → mesures → critères, phase par phase

# Plan qualité CRISP-ML(Q) pour un détecteur d'obstacles embarqué (exemple) : chaque risque a une mesure, un critère et une phase de vérification
plan = [
 ("1 métier",     "KPI non relié à une métrique ML",            "table KPI ↔ métrique (rappel humain ≥ 0,99 ↔ taux d'arrêts inutiles)",      "revue avec le métier, signée",                 "élevé"),
 ("2 données",    "images non représentatives (sites, éclairages)","couverture par tranche (site × heure × météo) vs plan d'échantillonnage",  "chaque tranche ≥ 200 images",                  "élevé"),
 ("2 données",    "fuites train/test (mêmes sessions)",          "séparation par robot et période ; doublons croisés (pHash)",                "0 doublon croisé ; test scellé (hash)",        "élevé"),
 ("2 données",    "étiquettes bruitées",                          "kappa sur 10 % en double ; ré-annotation des suspects",                      "kappa ≥ 0,8 ; suspects < 2 %",                  "moyen"),
 ("3 modélisation","sur-apprentissage / mauvais réglage",         "courbes train/val ; 3 graines ; baseline",                                   "val ≥ baseline + IC ; écart train/val < 5 pts", "moyen"),
 ("4 évaluation", "performance insuffisante sur 'humain'",       "rappel par classe et par tranche avec IC ; robustesse (bruit, flou, nuit)",  "rappel humain ≥ 0,99 (borne basse) ; ≥ 0,97 la nuit", "critique"),
 ("4 évaluation", "latence hors budget temps réel",              "WCET sur cible (L18) ; p99 sur 10 000 images",                               "p99 < 40 ms sur Jetson",                        "critique"),
 ("5 déploiement","modèle ≠ modèle évalué (conversion int8)",    "exactitude après quantification/export sur le jeu de test",                  "écart < 0,5 pt ; hash du modèle déployé = registre", "élevé"),
 ("5 déploiement","rollback impossible",                          "exercice de retour arrière en préproduction",                                "< 10 min, testé chaque mois",                   "moyen"),
 ("6 surveillance","dérive (nouveau site, saison)",               "PSI sur plongements, rappel sur échantillon annoté hebdo (L35)",             "alerte PSI > 0,2 ; rappel hebdo ≥ 0,98",         "élevé"),
]
print(f"{'phase':15s} {'risque':46s} {'critère d acceptation':50s} {'niveau':8s}")
for ph, r, mesure, crit, niv in plan: print(f"{ph:15s} {r:46s} {crit:50s} {niv:8s}")
critiques = [p for p in plan if p[4] == "critique"]; print(f"\n{len(plan)} risques, {len(critiques)} critiques → portes de qualité bloquantes : {[p[1] for p in critiques]}")
print("Chaque ligne devient un TEST (automatisé si possible) dans le pipeline : le plan qualité est le cahier des charges de la CI.")

02 / MLOps

Un pipeline reproductible en 60 lignes : versions liées, tests de données et de modèle, registre

import numpy as np, hashlib, json, time
rng = np.random.default_rng(0)
# --- Artefacts et lignage : chaque étape prend des entrées hachées et produit une sortie hachée ; le "registre" est un dict ---
registre = {}; lignage = {}
def h(obj): return hashlib.sha256(json.dumps(obj, sort_keys=True, default=str).encode()).hexdigest()[:12]
def etape(nom, entrees, f, **params):
    cle = h({"nom": nom, "entrees": [e["hash"] for e in entrees], "params": params})
    if cle in registre: print(f"  {nom:14s} → cache ({cle})"); return registre[cle]           # même entrées + même params ⇒ même sortie : pas de recalcul
    t0 = time.time(); sortie = f(*[e["objet"] for e in entrees], **params)
    art = {"hash": cle, "objet": sortie, "nom": nom, "params": params, "duree": round(time.time() - t0, 3)}
    registre[cle] = art; lignage[cle] = [e["hash"] for e in entrees]; print(f"  {nom:14s} → {cle} ({art['duree']} s)"); return art
# --- Étapes : données → validation → séparation → entraînement → évaluation → (promotion si critères) ---
def charger(seed): r = np.random.default_rng(seed); X = r.normal(0, 1, (2000, 5)); y = ((X @ np.array([1, -1, 0.5, 0, 0]) + 0.5 * r.normal(0, 1, 2000)) > 0).astype(int); return {"X": X.tolist(), "y": y.tolist()}
def valider(d):
    X, y = np.array(d["X"]), np.array(d["y"]); erreurs = []
    if X.shape[1] != 5: erreurs.append("schéma : 5 colonnes attendues")
    if np.isnan(X).any(): erreurs.append("valeurs manquantes")
    if not 0.3 < y.mean() < 0.7: erreurs.append(f"déséquilibre : {y.mean():.2f}")
    if len({tuple(r) for r in np.round(X, 6)}) < len(X): erreurs.append("doublons")
    assert not erreurs, erreurs; return d
def separer(d, frac): X, y = np.array(d["X"]), np.array(d["y"]); n = int(len(y) * (1 - frac)); return {"Xtr": X[:n].tolist(), "ytr": y[:n].tolist(), "Xte": X[n:].tolist(), "yte": y[n:].tolist(), "test_hash": h(X[n:].tolist())}
def entrainer(s, lr, iters):
    X, y = np.array(s["Xtr"]), np.array(s["ytr"]); w = np.zeros(5); b = 0.0
    for _ in range(iters): p = 1 / (1 + np.exp(-(X @ w + b))); w -= lr * X.T @ (p - y) / len(y); b -= lr * (p - y).mean()
    return {"w": w.tolist(), "b": b}
def evaluer(m, s):
    X, y = np.array(s["Xte"]), np.array(s["yte"]); p = 1 / (1 + np.exp(-(X @ np.array(m["w"]) + m["b"]))); acc = float(np.mean((p > 0.5) == y))
    ic = 1.96 * np.sqrt(acc * (1 - acc) / len(y)); return {"exactitude": acc, "ic_bas": acc - ic, "n": len(y), "test_hash": s["test_hash"]}
def pipeline(seed, lr, iters):
    d = etape("charger", [], charger, seed=seed); v = etape("valider", [d], valider); s = etape("separer", [v], separer, frac=0.25)
    m = etape("entrainer", [s], entrainer, lr=lr, iters=iters); e = etape("evaluer", [m, s], evaluer); return m, e
print("exécution 1 :"); m1, e1 = pipeline(seed=1, lr=0.5, iters=200)
print("exécution 2 (identique) :"); m2, e2 = pipeline(seed=1, lr=0.5, iters=200)
print("exécution 3 (nouveau lr) :"); m3, e3 = pipeline(seed=1, lr=0.1, iters=200)
# Porte de qualité et promotion au registre "production" : critère sur la borne basse, test scellé identique
def promouvoir(m, e, seuil=0.85):
    ok = e["objet"]["ic_bas"] >= seuil; print(f"\nmodèle {m['hash']} : exactitude {e['objet']['exactitude']:.3f} (borne basse {e['objet']['ic_bas']:.3f}) sur test {e['objet']['test_hash']} → {'PROMU' if ok else 'refusé'}")
    return ok
promouvoir(m1, e1); promouvoir(m3, e3)
print("\nlignage du modèle 1 :", m1["hash"], "←", lignage[m1["hash"]], "← …  (chaque hash remonte jusqu'aux données et aux paramètres)")

Ce que font DVC, MLflow, Kubeflow, Dagster : exactement ce mécanisme — hachage des entrées, cache, lignage, registre — à l’échelle et avec une interface. Le principe tient en 60 lignes ; l’important est qu’il soit toujours appliqué.

02 / MLOps

Tests d’un système ML : données, code, modèle, infra — le ML Test Score en pratique

import numpy as np
rng = np.random.default_rng(1)
# Les quatre familles de tests (Breck et al. 2017), avec un exemple exécutable de chaque
X = rng.normal(0, 1, (500, 5)); y = ((X @ np.array([1, -1, 0.5, 0, 0])) > 0).astype(int); w = np.array([0.9, -1.1, 0.4, 0.02, -0.01]); pred = lambda X: (X @ w > 0).astype(int)
tests = []
# 1) Données : schéma, distributions, importance des variables, fuites
tests.append(("données : schéma (5 colonnes float)", X.shape[1] == 5 and X.dtype.kind == "f"))
tests.append(("données : pas de variable quasi constante", bool(np.all(X.std(0) > 0.1))))
tests.append(("données : pas de variable proxy de la cible (corr < 0,95)", bool(np.all(np.abs([np.corrcoef(X[:, j], y)[0, 1] for j in range(5)]) < 0.95))))
# 2) Modèle : qualité minimale, tranches, invariances (CheckList), comportement directionnel, comparaison à la baseline
acc = np.mean(pred(X) == y); tests.append(("modèle : exactitude ≥ 0,85", acc >= 0.85))
tests.append(("modèle : exactitude par tranche (x0 > 0 vs ≤ 0) écart < 10 pts", abs(np.mean(pred(X[X[:, 0] > 0]) == y[X[:, 0] > 0]) - np.mean(pred(X[X[:, 0] <= 0]) == y[X[:, 0] <= 0])) < 0.10))
Xp = X.copy(); Xp[:, 3] += 5; tests.append(("modèle : invariance à la variable 3 (non pertinente)", np.mean(pred(Xp) == pred(X)) > 0.98))
Xd = X.copy(); Xd[:, 0] += 2; tests.append(("modèle : direction (x0 ↑ ⇒ p(1) ne baisse pas)", bool(np.all(pred(Xd) >= pred(X)))))
tests.append(("modèle : bat la baseline majoritaire + 20 pts", acc > max(y.mean(), 1 - y.mean()) + 0.20))
# 3) Code / infra : reproductibilité, sérialisation, latence
import json, time; w2 = np.array(json.loads(json.dumps(w.tolist()))); tests.append(("infra : sérialisation/désérialisation identique", np.allclose(w, w2)))
t0 = time.perf_counter(); [pred(X[:1]) for _ in range(200)]; tests.append(("infra : latence p50 < 1 ms", (time.perf_counter() - t0) / 200 < 1e-3))
# 4) Monitoring : les métriques existent et sont calculables sur un lot de production simulé
lot = rng.normal(0.3, 1, (100, 5)); tests.append(("monitoring : PSI calculable sur un lot", isinstance(float(np.abs(lot.mean(0) - X.mean(0)).max()), float)))
for nom, ok in tests: print(f"{'✔' if ok else '✘'} {nom}")
score = {"données": 3, "modèle": 5, "infra": 2, "monitoring": 1}; print(f"\nML Test Score = min par famille = {min(score.values())} (automatisés : 1 point chacun) — la famille la plus faible fixe le score : monitoring à renforcer")

Les tests de comportement (invariance, direction, cas minimaux — CheckList, Ribeiro 2020) attrapent des défauts que l’exactitude globale cache ; pour un LLM, ce sont des cas de banc d’essai (L28) : « la réponse ne change pas si l’on reformule », « refuse hors périmètre », « cite ».

02 / MLOps

Niveaux de maturité, outils, et l’organisation : qui fait quoi

Niveau	Déclencheur de ré-entraînement	Pipeline	Déploiement	Monitoring	Quand c’est suffisant
0 — manuel	À la main, rarement	Notebooks, scripts	Manuel (copie de fichier, API)	Peu ou pas	Prototype, modèle stable, ré-entraînement < 1/trimestre (Proposition 2)
1 — pipeline automatisé	Planifié ou sur dérive/nouvelles données	Orchestré, versionné, validation des données et du modèle, registre	Semi-automatique avec validation	Dérive, qualité sur étiquettes	Données changeantes, plusieurs modèles, équipe de 2–5
2 — CI/CD/CT	Automatique avec portes de qualité	Pipelines testés en CI, déployés par CD ; expérimentation rapide (feature store, métadonnées)	Automatisé : shadow → canary → complet, rollback auto	Complet, bouclé sur le ré-entraînement	Dizaines de modèles, changements quotidiens, criticité

Rôle	Responsabilité	Livrables
Responsable produit / métier	Objectif, KPI, critères d’acceptation, priorités, risques métier	Cahier des charges, décision go/no-go
Ingénieur données	Ingestion, qualité, pipelines de données, catalogue	Jeux versionnés, tests de données
Data scientist / ingénieur ML	Escalade, expérimentation, évaluation, cartes de modèle	Modèles candidats, rapports d’évaluation
Ingénieur MLOps / plateforme	Pipelines, registre, service, monitoring, infra (L33)	Plateforme, runbooks, tableaux de bord
Sécurité / conformité / juridique	Données personnelles, licences, AI Act, audits	Analyses d’impact, registre des traitements
Exploitation (SRE)	Disponibilité, incidents, astreinte, post-mortems	SLO, budget d’erreur, post-mortems

Outils par fonction (libres) : versionnage — Git, DVC, LakeFS ; orchestration — Airflow, Dagster, Kubeflow, Prefect ; expériences/registre — MLflow, W&B ; validation de données — Great Expectations, pandera, TFDV ; service — vLLM, Triton, BentoML, KServe ; monitoring — Evidently, Prometheus/Grafana, Langfuse (LLM) ; feature store — Feast ; annotation — Label Studio, Argilla.

03 / AIOps

L’IA au service de l’exploitation : détection d’anomalies, corrélation, prédiction — implémentées

import numpy as np
rng = np.random.default_rng(2)
# Métriques d'exploitation simulées : latence p95 (ms) d'un service pendant 14 jours, à la minute (saisonnalité journalière + bruit + incidents)
T = 14 * 24 * 60; t = np.arange(T); jour = 24 * 60
base = 180 + 60 * np.sin(2 * np.pi * (t % jour) / jour - 1.2) + 20 * (t // jour % 7 >= 5)             # plus lent la nuit ? non : pic en journée ; week-end différent
lat = base + rng.gamma(4, 5, T)
lat[6 * jour + 600: 6 * jour + 660] += 400                                                              # incident brusque (1 h)
lat[10 * jour:] += np.linspace(0, 120, T - 10 * jour)                                                   # dérive lente (fuite mémoire)
# 1) Détecteur naïf : seuil fixe → fausses alertes aux heures de pointe, aveugle à la dérive lente
seuil_fixe = 300; alertes_fixe = lat > seuil_fixe
# 2) Détecteur saisonnier robuste : résidu par rapport à la médiane du même créneau les jours précédents, z-score robuste (MAD)
def anomalies_saisonnieres(x, jour, fen_jours=5, z=4.0):
    res = np.zeros_like(x); flags = np.zeros(len(x), bool)
    for i in range(fen_jours * jour, len(x)):
        hist = x[i - fen_jours * jour: i: jour] if False else np.array([x[i - k * jour] for k in range(1, fen_jours + 1)])
        med = np.median(hist); mad = 1.4826 * np.median(np.abs(hist - med)) + 1e-6; res[i] = (x[i] - med) / mad; flags[i] = abs(res[i]) > z
    return flags, res
flags_sais, res = anomalies_saisonnieres(lat, jour)
# 3) CUSUM sur le résidu pour la dérive lente (Proposition 3)
def cusum(r, k=0.5, h=8.0):
    S = 0.0; out = np.zeros(len(r), bool)
    for i, v in enumerate(r): S = max(0.0, S + v - k); out[i] = S > h
    return out
flags_cusum = cusum(np.clip(res, -10, 10))
def resume(flags, nom):
    j = np.where(flags)[0]; print(f"{nom:28s} : {len(j):5d} minutes en alerte ; première alerte incident (j6 10h) : {'oui' if flags[6*jour+600:6*jour+660].any() else 'non'} ; première alerte dérive : jour {j[j > 10*jour][0] / jour if (j > 10*jour).any() else float('nan'):.1f} ; fausses alertes (jours 5–9 hors incident) : {flags[5*jour:10*jour].sum() - flags[6*jour+600:6*jour+660].sum()}")
resume(alertes_fixe, "seuil fixe 300 ms"); resume(flags_sais, "saisonnier robuste (z > 4)"); resume(flags_cusum, "CUSUM sur résidu")
print("\nLe seuil fixe hurle chaque après-midi et rate la dérive ; le saisonnier voit l'incident sans bruit ; CUSUM voit la dérive lente 2 jours après son début.")
# 4) Regroupement d'alertes : 60 minutes d'alertes consécutives = UN incident (déduplication temporelle) ; corrélation avec un déploiement
def regrouper(flags, gap=30):
    j = np.where(flags)[0]; groupes = []; deb = None; prev = None
    for i in j:
        if deb is None: deb = i
        elif i - prev > gap: groupes.append((deb, prev)); deb = i
        prev = i
    if deb is not None: groupes.append((deb, prev)); return groupes
inc = regrouper(flags_sais); print(f"\n{flags_sais.sum()} alertes brutes → {len(inc)} incident(s) regroupé(s) : {[(round(a/jour, 2), round((b-a)/60, 1)) for a, b in inc][:5]} (jour, durée h)")
deploiements = [6 * jour + 590]; print("corrélation : l'incident commence 10 min après un déploiement →", "cause probable : le déploiement (rollback proposé)")

03 / AIOps

Prédire les pannes et la capacité, et mesurer l’utilité d’AIOps

import numpy as np
rng = np.random.default_rng(3)
# 1) Prédiction de capacité : quand le disque sera-t-il plein ? Régression linéaire robuste sur les 14 derniers jours + intervalle
jours = np.arange(14); usage = 62 + 1.8 * jours + rng.normal(0, 1.5, 14); usage[9] += 8               # une valeur aberrante (sauvegarde)
def theil_sen(x, y):                                                                                 # pente = médiane des pentes par paires (robuste)
    pentes = [(y[j] - y[i]) / (x[j] - x[i]) for i in range(len(x)) for j in range(i + 1, len(x))]; a = np.median(pentes); return a, np.median(y - a * x)
a, b = theil_sen(jours, usage); a_ls, b_ls = np.polyfit(jours, usage, 1)
print(f"pente robuste {a:.2f} %/jour (moindres carrés {a_ls:.2f}) → disque plein (100 %) dans {(100 - b) / a - 13:.0f} jours ; alerte à 30 jours → créer le ticket maintenant")
# 2) Prédiction de panne : à partir de signaux précurseurs (température, erreurs disque, redémarrages), classifieur → la métrique utile est le rappel à préavis suffisant
n = 4000; X = rng.normal(0, 1, (n, 4)); panne = (X[:, 0] * 0.8 + X[:, 1] * 0.5 + rng.normal(0, 1, n) > 1.8).astype(int)
w = np.array([0.8, 0.5, 0, 0]); score = X @ w; o = np.argsort(-score)
for k in (0.02, 0.05, 0.10):
    top = o[: int(k * n)]; rappel = panne[top].sum() / panne.sum(); precision = panne[top].mean()
    print(f"maintenance préventive sur les {k:.0%} de machines les plus à risque : rappel des pannes {rappel:.2f}, précision {precision:.2f} → {int(k*n)} interventions pour {panne[top].sum()} pannes évitées sur {panne.sum()}")
# 3) Mesurer AIOps : MTTD, MTTR, alertes actionnables — avant/après
avant = dict(MTTD_min=95, MTTR_min=140, alertes_jour=340, actionnables=0.08); apres = dict(MTTD_min=12, MTTR_min=75, alertes_jour=22, actionnables=0.64)
cout_h = 4000                                                                                         # € par heure d'indisponibilité
for nom, d in (("avant", avant), ("après", apres)): print(f"{nom:6s} MTTD {d['MTTD_min']:3d} min, MTTR {d['MTTR_min']:3d} min, {d['alertes_jour']:3d} alertes/jour dont {d['actionnables']:.0%} actionnables → coût par incident ≈ {(d['MTTD_min'] + d['MTTR_min']) / 60 * cout_h:.0f} €")
print("→ la valeur d'AIOps est dans la détection rapide et le silence des fausses alertes ; la remédiation automatique vient après, avec des garde-fous (jamais de rollback automatique sans critère prouvé).")

04 / Gouvernance

Gouvernance, conformité, éthique : ce qui doit exister avant la mise en production

Élément	Contenu	Quand	Référence
Registre des systèmes IA	Liste des modèles en production : propriétaire, usage, données, risque, version, date de revue	Dès le premier déploiement	AI Act (obligation pour les systèmes à haut risque), ISO/IEC 42001
Classification du risque	Interdit / haut risque (santé, emploi, crédit, sécurité des machines, biométrie) / transparence (chatbots, contenu généré) / minimal	Phase 1	AI Act, annexe III
Documentation	Carte de modèle, datasheet, rapport d’évaluation, ADR, plan qualité	Chaque phase	L34, L36, L32
Données personnelles	Base légale, minimisation, DPIA si risque élevé, droits (accès, effacement — y compris dans les jeux d’entraînement ?), durée de conservation	Phase 2	RGPD, CNIL
Équité et non-discrimination	Métriques par groupe (L32), choix documenté du critère, tests avant déploiement et en production	Phases 4 et 6	Impossibilité de Chouldechova ; lignes directrices
Sécurité	Menaces (injection, empoisonnement des données, extraction du modèle, attaques adverses), contrôles, tests adverses	Phases 3–6	OWASP ML/LLM Top 10, MITRE ATLAS
Supervision humaine	Qui peut annuler, comment, avec quelle information ; humain dans la boucle pour les décisions à impact	Phase 5	AI Act art. 14
Transparence	Informer que l’on interagit avec une IA ; marquer le contenu généré ; expliquer les décisions (dans la mesure du possible)	Phase 5	AI Act art. 50/52
Revue et audit	Comité de revue (technique + métier + juridique), audits périodiques, journal des décisions	Avant déploiement, puis annuel	ISO 42001, NIST AI RMF
Gestion des incidents	Procédure, notification (autorités si haut risque), post-mortems (L35)	Phase 6	AI Act art. 73

05 / Articles

Les références à lire

Référence	Contribution	À retenir
Studer et al., Towards CRISP-ML(Q): A Machine Learning Process Model with Quality Assurance Methodology, 2021 — 2003.05155	Le processus et l’AQ par phase	Le tableau des phases ; risques → mesures → critères
Chapman et al., CRISP-DM 1.0, 1999	L’ancêtre	Toujours le vocabulaire commun
Sculley et al., Hidden Technical Debt in ML Systems, NeurIPS 2015	Dettes spécifiques au ML	Le modèle est une petite partie du système
Breck et al., The ML Test Score, IEEE Big Data 2017	28 tests, score de maturité	La liste de la partie 02
Google Cloud, MLOps: Continuous delivery and automation pipelines in machine learning, 2020	Niveaux 0/1/2	Choisir le niveau selon la fréquence de changement (Proposition 2)
Kreuzberger, Kühl & Hirschl, Machine Learning Operations (MLOps): Overview, Definition, and Architecture, IEEE Access 2023 — 2205.02302	Principes, composants, rôles, architecture	Une carte complète du domaine
Ribeiro et al., Beyond Accuracy: Behavioral Testing of NLP Models with CheckList, ACL 2020 — 2005.04118	Tests de comportement (invariance, direction, cas minimaux)	Des tests unitaires pour les modèles
Polyzotis et al., Data Validation for Machine Learning, SysML 2019	Validation de données en production (TFDV)	Schémas, dérives, anomalies de données
Paleyes, Urma & Lawrence, Challenges in Deploying Machine Learning: A Survey of Case Studies, ACM CSUR 2022 — 2011.09926	Ce qui échoue en déploiement, par phase	Les mêmes problèmes reviennent partout
Dang, Lin & Huang, AIOps: Real-World Challenges and Research Innovations, ICSE 2019	AIOps : détection, prédiction, causes	Le bruit d’alertes est le premier problème
Notaro, Cardoso & Gerndt, A Survey of AIOps Methods for Failure Management, ACM TIST 2021	Taxonomie des méthodes AIOps	Détection, prédiction, localisation, remédiation
Page, Continuous Inspection Schemes (CUSUM), Biometrika 1954 ; Montgomery, Introduction to Statistical Quality Control	SPC, CUSUM, EWMA	Proposition 3
NIST, AI Risk Management Framework, 2023 ; ISO/IEC 42001:2023 ; Règlement (UE) 2024/1689	Gestion des risques, système de management, obligations	La gouvernance n’est pas optionnelle

TP guidé

TP — Un pipeline MLOps niveau 1, testé, avec monitoring AIOps (8 h)

Plan qualité. Pour votre projet (L34–L37), le tableau risques → mesures → critères, avec 3 portes bloquantes.
Pipeline. DVC (données, étapes, cache) + MLflow (expériences, registre) ou Dagster ; étapes : ingestion → validation (Great Expectations/pandera) → séparation → entraînement → évaluation (L32, IC) → promotion conditionnelle. Reproductibilité : deux exécutions identiques donnent le même hash de modèle.
Tests en CI. GitHub Actions : tests de données, tests unitaires, tests de comportement (CheckList ou vos cas), test de non-régression du banc d’essai, test de sérialisation et de latence. Une régression bloque la fusion.
Déploiement. Conteneur + service (FastAPI/BentoML/vLLM) ; shadow puis canary simulé ; rollback scripté et testé.
Monitoring et AIOps. Journalisation des prédictions ; Evidently ou vos détecteurs (L35) ; métriques système dans Prometheus ; détecteur saisonnier + CUSUM sur la latence ; regroupement d’alertes ; un runbook par alerte ; simulation d’un incident et post-mortem.
Gouvernance. Carte de modèle, datasheet, entrée au registre des systèmes IA, classification de risque AI Act, checklist RGPD.
Livrable. Dépôt complet, rapport de ML Test Score avant/après, tableau de bord, post-mortem, dossier de gouvernance.

Exercices

Exercices auto-corrigés

Exercice 1 — ML Test Score

Écrivez ml_test_score(tests) : tests = liste de (famille, nom, statut) avec statut ∈ {"absent", "manuel", "auto"} (0 / 0,5 / 1 point) ; renvoie (score = min des sommes par famille parmi les 4 familles données/modèle/infra/monitoring, dict des sommes) et famille_faible(tests).

Correction

POINTS = {"absent": 0.0, "manuel": 0.5, "auto": 1.0}
def ml_test_score(tests):
    sommes = {f: 0.0 for f in ("données", "modèle", "infra", "monitoring")}
    for f, _, s in tests: sommes[f] += POINTS[s]
    return min(sommes.values()), sommes
def famille_faible(tests): _, s = ml_test_score(tests); return min(s, key=s.get)

Exercice 2 — Seuil de rentabilité de l’automatisation (Proposition 2)

Écrivez mois_rentabilite(A, m, a, f) (None si m ≤ a) et niveau_recommande(f_par_mois) : 0 si f < 0,5, 1 si 0,5 ≤ f < 10, 2 sinon (heuristique du cours).

Correction

def mois_rentabilite(A, m, a, f): return None if m <= a else A / ((m - a) * f)
def niveau_recommande(f): return 0 if f < 0.5 else (1 if f < 10 else 2)

Exercices

Exercices auto-corrigés (suite)

Exercice 3 — CUSUM et longueur moyenne de détection (Proposition 3)

Implémentez cusum_alerte(x, mu, sigma, k, h) (indice de la première alerte ou None, CUSUM bilatéral sur (x − μ)/σ) et arl(mu_decalage, k, h, essais, rng) (longueur moyenne avant alerte sur des données N(décalage, 1)). Vérifiez ARL₀ (décalage 0) ≫ ARL₁ (décalage 1), et que la règle des 3σ a un ARL₁ ≈ 44.

Correction

def cusum_alerte(x, mu, sigma, k=0.5, h=5.0):
    Sp = Sm = 0.0
    for i, v in enumerate(x):
        z = (v - mu) / sigma; Sp = max(0.0, Sp + z - k); Sm = max(0.0, Sm - z - k)
        if Sp > h or Sm > h: return i
    return None
def arl(decalage, k=0.5, h=5.0, essais=300, rng=None, n_max=3000):
    rng = rng or np.random.default_rng(0); L = []
    for _ in range(essais):
        i = cusum_alerte(rng.normal(decalage, 1, n_max), 0, 1, k, h); L.append(n_max if i is None else i + 1)
    return float(np.mean(L))

Exercice 4 — Impact d’un changement dans le graphe de lignage (Proposition 4)

Écrivez a_revalider(deps, noeud) : deps = dict artefact → liste de ses entrées ; renvoie l’ensemble des descendants (artefacts qui dépendent, transitivement, du nœud modifié). Vérifiez sur un graphe données → features → modèle → évaluation → déploiement, avec une branche indépendante.

Correction

def a_revalider(deps, noeud):
    enfants = {}
    for a, ins in deps.items():
        for i in ins: enfants.setdefault(i, []).append(a)
    vus, pile = set(), [noeud]
    while pile:
        n = pile.pop()
        for c in enfants.get(n, []):
            if c not in vus: vus.add(c); pile.append(c)
    return vus

Fiche de cours · Exercices corrigés

Exercices corrigés (rédaction)

Exercice 1. Une équipe de 3 personnes maintient un modèle de prévision de demande ré-entraîné chaque mois, et un chatbot dont les prompts changent chaque semaine. Quel niveau MLOps pour chacun, et quels sont les 5 premiers investissements ?

Correction. Prévision (f ≈ 1/mois) : niveau 1 suffit (Proposition 2 : automatiser un cycle mensuel de 2 jours se rentabilise en ~1 an — utile mais pas urgent) ; l’essentiel est la reproductibilité et le monitoring de dérive. Chatbot (prompts hebdomadaires, données changeantes) : niveau 1 vers 2 sur la partie LLMOps — banc d’essai de prompts en CI (L28), versions, évaluation par juge, traces. Cinq investissements : (1) versionnage lié données/code/modèle/prompt (Git + DVC + MLflow) ; (2) banc d’essai automatisé avec portes de qualité, exécuté à chaque changement (le plus rentable) ; (3) journalisation des prédictions et tableau de bord de dérive/qualité (L35) ; (4) déploiement scripté avec rollback testé ; (5) plan qualité et registre des systèmes IA (gouvernance minimale). Pas de Kubernetes ni de feature store à ce stade.

Exercice 2. Un modèle de scoring de crédit, classé « haut risque » par l’AI Act, est prêt techniquement. Lister ce que la gouvernance exige avant la mise en production.

Correction. (1) Système de gestion des risques documenté sur tout le cycle de vie (identification, mesures, tests) ; (2) gouvernance des données : représentativité, biais examinés, qualité, lignage ; (3) documentation technique complète (carte de modèle, datasheet, rapport d’évaluation avec métriques par groupe, robustesse, sécurité) ; (4) journalisation automatique permettant l’audit et le suivi (traçabilité des décisions) ; (5) transparence et information des utilisateurs (notice, explication des décisions, droit à une intervention humaine) ; (6) supervision humaine effective : qui peut contester ou annuler, avec quelle interface ; (7) exactitude, robustesse, cybersécurité démontrées et surveillées ; (8) évaluation de conformité, déclaration, enregistrement dans la base de l’UE ; (9) DPIA RGPD, base légale, minimisation ; (10) procédure d’incidents graves avec notification. Techniquement : un test d’équité par groupe avec critère choisi et documenté (L32), et un plan de surveillance post-marché (L35).

Exercice 3. Le système d’alertes d’exploitation génère 400 alertes par jour dont 5 % sont actionnables ; les astreintes n’y répondent plus. Concevoir une démarche AIOps en quatre étapes mesurées.

Correction. (1) Mesurer : classer 2 semaines d’alertes (actionnable / bruit / doublon), calculer MTTD et MTTR par type d’incident, identifier les 10 règles qui produisent 80 % du bruit. (2) Réduire : remplacer les seuils fixes par des détecteurs saisonniers robustes (résidu/MAD) et CUSUM pour les dérives ; regrouper les alertes par fenêtre et similarité ; supprimer les règles non actionnables ; objectif : < 50 alertes/jour, > 50 % actionnables — mesuré chaque semaine. (3) Corréler : enrichir chaque alerte avec le contexte (déploiements récents, changements de configuration, dépendances de service) pour proposer une cause probable et un runbook ; mesurer la fraction d’incidents dont la cause proposée est confirmée. (4) Prédire et automatiser prudemment : capacité (disque, mémoire) par régression robuste avec alertes à 30 jours ; remédiation automatique seulement pour des actions réversibles et éprouvées (redémarrage d’un pod, montée en charge) avec journal et limite de fréquence ; jamais de rollback automatique sans critère validé. Chaque étape est évaluée par MTTD, MTTR, taux d’actionnables et satisfaction des astreintes ; les faux positifs d’un détecteur ML sont eux-mêmes une dérive à surveiller.

Vérification

Quel critère principal décide du niveau de maturité MLOps à viser ?

Deux questions supplémentaires

1. Que mesure le ML Test Score ? Le minimum, sur quatre familles (données, modèle, infra, monitoring), des points de tests automatisés : la famille la plus faible fixe la note.

2. Pourquoi CUSUM plutôt que la règle des 3σ pour une dérive lente ? La règle des 3σ met ~44 points à voir un décalage de 1σ ; CUSUM accumule les petits écarts et alerte en ~10 points.

Référence

Les mots à retenir

Mot	Définition
CRISP-ML(Q)	Six phases + assurance qualité par risque/mesure/critère.
MLOps niveaux 0/1/2	Manuel / pipeline automatisé / CI-CD-CT ; choisir par fréquence de changement.
Lignage	DAG des artefacts ; impact d’un changement = descendants.
ML Test Score	Tests données/modèle/infra/monitoring ; min par famille.
Tests de comportement	Invariance, direction, cas minimaux (CheckList).
SPC, CUSUM, EWMA	Contrôle statistique ; ARL₀ / ARL₁.
AIOps	Anomalies saisonnières, regroupement, corrélation, prédiction ; MTTD/MTTR.
Gouvernance	Registre, classification de risque, documentation, supervision humaine, incidents.

Suite

Dernier chapitre : piloter tout cela — le projet, l’équipe, le budget, les parties prenantes.

Gérer et administrer des projets IA : cadrage, estimation sous incertitude, organisation, suivi, communication des résultats, arrêt d’un projet, portefeuille de modèles.

← L37 Sommaire L39 : gestion de projets IA →