Observabilité des modèles d’IA

En ingénierie logicielle, l’observabilité repose sur trois piliers : les logs, les métriques et les traces. Pour les modèles de Machine Learning, ces trois piliers restent valides, mais ils sont insuffisants. Un service web peut fonctionner parfaitement (temps de réponse nominal, pas d’erreurs) pendant que le modèle qu’il embarque prend des décisions de plus en plus mauvaises.

C’est le problème fondamental de l’observabilité ML : un modèle peut être opérationnellement sain et scientifiquement dégradé en même temps.

Le data drift : quand le monde change sans vous prévenir

Le data drift se produit lorsque la distribution des données en production s’éloigne de la distribution des données d’entraînement. Quelques exemples concrets :

• Un modèle de détection de fraude entraîné en 2023 n’a jamais vu les patterns de fraude qui sont apparus en 2026
• Un modèle de recommandation entraîné sur des données pré-Covid ne reconnaît plus les comportements d’achat post-Covid
• Un modèle de crédit scoring entraîné sur une population urbaine est déployé dans des zones rurales

Pour détecter le data drift, on surveille les distributions statistiques des features en production par rapport à une baseline (les données d’entraînement) :

from evidently.metrics import DataDriftTable
from evidently.report import Report

drift_report = Report(metrics=[DataDriftTable()])
drift_report.run(
    reference_data=train_df,
    current_data=production_df_last_week
)

drift_report.save_html("drift_report.html")

Des outils comme Evidently, WhyLogs ou Arize permettent d’automatiser cette surveillance.

Le concept drift : quand les relations changent

Le concept drift est plus insidieux. La distribution des données peut rester stable, mais la relation entre les features et la target change. Un modèle qui prédit la probabilité d’achat basé sur l’âge et le revenu peut devenir inexact si le comportement des consommateurs évolue même si les distributions de l’âge et du revenu restent constantes.

Détecter le concept drift nécessite des labels différés : il faut attendre que les vérités terrain arrivent (est-ce que le client a finalement acheté ? est-ce que la transaction était bien frauduleuse ?) pour calculer les métriques réelles du modèle.

# Pipeline de feedback avec délai
def compute_delayed_metrics(predictions_df, ground_truth_df, delay_days=7):
    merged = predictions_df.merge(
        ground_truth_df,
        on="transaction_id",
        how="inner"
    )
    
    current_f1 = f1_score(merged["label"], (merged["score"] > 0.7).astype(int))
    return {"f1_score": current_f1, "n_samples": len(merged)}

Architecture de monitoring en production

Une architecture de monitoring ML robuste s’articule autour de plusieurs composants :

1. Collecte des prédictions

Chaque prédiction est loguée avec ses features, son score, et le contexte de la requête :

import structlog

logger = structlog.get_logger()

def predict(features: dict) -> float:
    score = model.predict_proba([list(features.values())])[0][1]
    
    logger.info(
        "prediction",
        score=score,
        features=features,
        model_version=MODEL_VERSION,
        request_id=request.headers.get("X-Request-ID")
    )
    
    return score

2. Métriques opérationnelles (Prometheus)

from prometheus_client import Histogram, Counter, Gauge

prediction_latency = Histogram("ml_prediction_latency_seconds", "Latency")
prediction_score = Histogram("ml_prediction_score", "Score distribution", buckets=[0.1, 0.3, 0.5, 0.7, 0.9])
model_accuracy = Gauge("ml_model_accuracy", "Rolling accuracy")

3. Alertes automatisées

Configurez des alertes à plusieurs niveaux :

# Prometheus alerting rules
groups:
- name: ml-model-alerts
  rules:
  - alert: ModelDriftDetected
    expr: ml_feature_drift_score{feature="montant"} > 0.3
    for: 1h
    labels:
      severity: warning
    annotations:
      summary: "Data drift detected on feature 'montant'"

  - alert: ModelAccuracyDegraded
    expr: ml_model_accuracy < 0.75
    for: 30m
    labels:
      severity: critical
    annotations:
      summary: "Model accuracy below threshold"

Monitoring sans labels : les métriques proxy

L’un des défis du monitoring ML est que les labels réels arrivent souvent avec un délai. En attendant, on surveille des métriques proxy qui corrèlent avec la qualité du modèle :

• Distribution des scores de prédiction : si le modèle commence à produire des scores très différents de la distribution habituelle, c’est un signal d’alarme
• Taux de refus : si un modèle de crédit refuse subitement 2× plus de demandes qu’habituellement sans changement métier connu
• Cohérence temporelle : les prédictions varient-elles de manière anormale selon l’heure, le jour de la semaine ?

La boucle de réentraînement automatique

L’observabilité n’a de valeur que si elle déclenche des actions. Une boucle complète ressemble à :

1. Détection : le monitoring détecte un drift ou une dégradation des métriques
2. Alerte : une notification est envoyée à l’équipe (Slack, PagerDuty)
3. Collecte : de nouvelles données étiquetées sont rassemblées
4. Réentraînement : un nouveau modèle est entraîné automatiquement
5. Validation : les métriques du nouveau modèle sont comparées à l’ancien
6. Promotion : si les métriques s’améliorent, le nouveau modèle est déployé automatiquement

Cette boucle peut être entièrement automatisée avec des outils comme Kubeflow Pipelines ou AWS SageMaker Pipelines, ou semi-automatisée avec une approbation humaine avant la promotion finale.

Conclusion

L’observabilité ML est une discipline à part entière. Elle ne remplace pas le monitoring opérationnel classique elle le complète avec une couche de surveillance scientifique qui permet de détecter, diagnostiquer et corriger les dérives avant qu’elles n’impactent vos utilisateurs et votre business. Dans un monde où les modèles prennent des décisions à haute valeur, ignorer cette couche n’est plus une option.