Détection d'anomalies ML vs méthodes statistiques

La détection d’anomalies par ML justifie son coût par rapport aux méthodes statistiques plus simples uniquement dans des conditions spécifiques. Les arguments marketing pour la détection ML (« apprend automatiquement vos patterns de données », « pas de seuils manuels ») sont exacts mais pas universellement pertinents — pour beaucoup de projets dbt, la détection basée sur le Z-score est suffisante.

Comment fonctionne la détection statistique

Elementary OSS utilise la détection basée sur le Z-score. L’approche est conceptuellement simple : calculer la moyenne et l’écart type d’une métrique sur une période d’entraînement, puis signaler quand la valeur actuelle dépasse N écarts types par rapport à la moyenne.

tests:
  - elementary.volume_anomalies:
      time_bucket:
        period: day
        count: 1
      anomaly_sensitivity: 3  # alerter à 3 écarts types
      training_period:
        period: day
        count: 14  # apprendre sur 14 jours d'historique

Une sensibilité de 3 signifie alerter quand une métrique dépasse 3 écarts types par rapport à sa moyenne historique. Pour des données normalement distribuées, cela correspond à environ 0,3% de chances de faux positif pour n’importe quelle vérification. En pratique, les distributions de données sont rarement parfaitement normales, donc le taux de faux positifs varie.

Les forces de cette approche :

Transparente. On peut inspecter le calcul. Quand une alerte se déclenche, on peut regarder la moyenne historique, l’écart type et la valeur actuelle, et comprendre exactement pourquoi elle s’est déclenchée.
Configurable. Les paramètres anomaly_sensitivity et training_period donnent un contrôle direct sur le compromis entre sensibilité et bruit.
Pas de délai d’entraînement. Avec 14 jours d’historique, la détection Z-score commence à fonctionner. Les modèles ML ont souvent besoin de mois de données pour apprendre des patterns significatifs.
Faible coût de calcul. La moyenne et l’écart type sont peu coûteux à calculer, même sur de grandes tables.

Les faiblesses sont tout aussi claires :

Pas de conscience saisonnière. Si les données e-commerce ont un volume 3x supérieur le week-end, la détection Z-score traite la baisse du lundi comme une anomalie chaque semaine jusqu’à l’ajustement manuel de la fenêtre d’entraînement ou l’ajout de filtres.
Pas d’adaptation aux tendances. Une entreprise croissant de 10% mois-sur-mois finira par déclencher des alertes d’anomalie de volume car le comptage actuel dépasse la moyenne historique plus trois écarts types. La détection ne comprend pas la « croissance ».
Sensibilité symétrique. Un seuil à 3 sigma traite une baisse de 50% et un pic de 50% de façon identique. Pour beaucoup de métriques, une baisse de volume est une urgence tandis qu’un pic est attendu lors d’une campagne marketing.
Isolation par métrique unique. Les Z-scores évaluent chaque métrique indépendamment. Ils ne peuvent pas corréler une baisse de revenu avec une baisse de volume correspondante pour identifier une cause racine commune.

Comment fonctionne la détection ML

Monte Carlo, Anomalo et Bigeye utilisent du ML plus sophistiqué qui apprend des patterns historiques sur plusieurs dimensions simultanément.

Les approches varient selon le fournisseur, mais l’architecture générale implique :

Modèles de séries temporelles qui apprennent les patterns quotidiens, hebdomadaires et saisonniers. On s’attend à ce que le lundi soit différent du samedi. On s’attend à ce que décembre soit différent de juin.
Corrélation multi-métriques qui comprend les relations entre métriques. Si le volume et le revenu baissent tous les deux, c’est un seul incident, pas deux.
Baselines adaptatives qui s’ajustent aux changements progressifs sans traiter la croissance ou les variations saisonnières comme des anomalies.
Score de confiance qui différencie « c’est définitivement faux » de « c’est inhabituel mais peut-être attendu ».

Vimeo Engineering a rapporté une réduction des incidents à 10% de leur volume précédent après l’implémentation de Monte Carlo. C’est un chiffre convaincant, mais il nécessite du contexte : Vimeo est un environnement à grande échelle avec des patterns saisonniers complexes, de multiples sources de données et le type de complexité de données où le ML dispose de suffisamment de signal pour apprendre des patterns significatifs.

Où le ML justifie son coût

La détection par ML justifie son tarif premium dans des conditions spécifiques, pas universellement.

Patterns saisonniers marqués. Si les données ont des cycles prévisibles hebdomadaires, mensuels ou annuels, le ML apprend ces patterns et ajuste les baselines en conséquence. Une entreprise de retail avec des pics Black Friday, des creux estivaux et des pics de week-end tire une valeur significative d’un modèle qui comprend ces rythmes. Avec la détection Z-score, il faudrait configurer manuellement des seuils différents pour différentes périodes — ou accepter un flot de faux positifs lors des variations attendues.

Nombre élevé de tables. Quand il y a 500+ tables à surveiller, la configuration manuelle des seuils devient impossible. Le ML qui apprend automatiquement les baselines appropriées pour chaque table offre une couverture qu’aucune équipe ne peut répliquer manuellement.

Relations inter-métriques complexes. Quand une seule cause racine se manifeste comme des anomalies sur plusieurs métriques et tables simultanément, le ML capable de corréler ces signaux et d’identifier la cause commune économise des heures d’investigation manuelle. Un changement de schéma dans une table source qui provoque des augmentations du taux de null dans dix modèles en aval est un seul incident, mais la détection Z-score déclenche dix alertes indépendantes.

Détection de dérive progressive. Si le nombre d’utilisateurs quotidiens passe de 10 000 à 8 000 sur deux semaines, un test row_count_between fixé à 5 000-15 000 ne le signalera pas. Les modèles ML qui suivent la direction et la vélocité des tendances peuvent détecter ce type de dégradation lente.

Où les méthodes statistiques sont suffisantes

Pour beaucoup de projets dbt avec des patterns de données relativement stables, l’approche Z-score d’Elementary est genuinement suffisante. Les conditions où les méthodes statistiques fonctionnent bien :

Données stables et prévisibles. Si les sources se mettent à jour selon un calendrier régulier, les volumes sont relativement constants (ou croissent linéairement) et il n’y a pas de patterns saisonniers marqués, la détection Z-score attrape les anomalies qui importent sans la surcharge du ML.

Faible nombre de tables. En dessous de 100 tables, les paramètres de sensibilité et les périodes d’entraînement peuvent être ajustés manuellement. L’investissement en temps est gérable, et le contrôle total sur le comportement des alertes est maintenu.

Modes d’échec clairs. Si les problèmes de qualité de données les plus courants sont « la source a arrêté d’envoyer des données » (volume tombe à zéro) ou « le schéma a changé » (colonne ajoutée ou supprimée), ce sont des échecs binaires que la détection Z-score attrape trivialement. Il n’est pas besoin de ML pour détecter qu’une table qui compte normalement 10 000 lignes en a soudainement zéro.

Contraintes budgétaires. À 0€ de coût de licence, Elementary OSS fournit une détection d’anomalies qui attrape la majorité des vrais problèmes. Le calcul du TCO favorise souvent l’OSS pour les équipes où l’alternative est l’absence de détection d’anomalies, pas un choix entre Z-scores et ML.

Évaluation

La détection par ML est meilleure pour gérer les patterns complexes, mais « meilleure » et « nécessaire » sont des questions différentes. Pour une équipe opérant un seul entrepôt avec 50-200 modèles et des patterns de données relativement stables, investir 5 000-15 000€/mois dans la détection par ML résout un problème que la détection Z-score gère adéquatement. L’approche d’Elementary attrape les anomalies haute sévérité (les données ont arrêté d’arriver, le volume a chuté de 80%, le taux de null a explosé) qui représentent la majorité des incidents réels.

La détection ML se justifie dans les environnements à grand volume et grande complexité où la gestion manuelle des seuils devient impraticable et où le nombre de patterns d’échec potentiels dépasse ce que n’importe quelle équipe peut anticiper. En dessous de ce seuil, le coût est mieux appliqué à l’élargissement de la couverture de tests et à l’établissement du stack d’observabilité minimum viable.

Les outils d’observabilité non ajustés se dégradent avec le temps ; les approches plus simples qui reçoivent une attention régulière tendent à mieux performer en pratique.