Votre taux de conversion chute de 15 % mardi. Vous ne le remarquez que jeudi, en consultant votre tableau de bord. Deux jours de revenus perdus, et vous ne savez toujours pas pourquoi. Un système de détection d'anomalies vous aurait alerté mercredi matin : « Conversion en baisse de 15 % hier, paiement mobile touché. » Vous enquêtez aussitôt. Vous constatez qu'une mise en ligne a cassé les paiements mobiles. Vous corrigez l'après-midi même. La détection d'anomalies fait la différence entre trouver les problèmes des jours plus tard et les trouver quelques heures plus tard.
La détection d'anomalies est un système qui surveille vos indicateurs en continu et vous alerte quand quelque chose d'inhabituel se produit. Il n'attend pas que vous consultiez le tableau de bord. Il connaît votre référence (à quoi ressemble le « normal »), compare chaque jour à cette référence et signale les écarts. Un pic de trafic, une chute de conversion, un engagement qui recule : tout cela est repéré automatiquement et signalé avant de tourner à la catastrophe.
Que fait vraiment la détection d'anomalies ?
Prenez n'importe quel indicateur et vous verrez le même schéma : il fluctue naturellement. Le taux de conversion n'est jamais exactement le même chaque jour. Le trafic varie selon le jour de la semaine. Le mobile ne convertit pas comme l'ordinateur. Si vous réglez une alerte sur « conversion sous 2,5 % », vous aurez de fausses alertes, car la conversion descend naturellement à 2,4 % certains jours. La détection d'anomalies règle ce problème en apprenant à quoi ressemble la variation normale, puis en n'alertant que lorsque quelque chose sort de cette plage naturelle.
Le système apprend votre référence à partir de l'historique. Il répond à cette question : pour cet indicateur, ce jour de la semaine, avec ce volume de trafic, quelle est la plage attendue ? Les conversions du mercredi se situent en général entre 2,1 % et 2,9 %. La conversion mobile se situe en général entre 1,8 % et 2,4 %. Le trafic e-mail convertit en général entre 4 % et 6 %. Le système construit un modèle du comportement normal pour chaque combinaison de conditions.
Quand une nouvelle donnée arrive, le système la compare à la plage attendue. La conversion d'aujourd'hui est-elle dans la plage normale d'un mercredi ? Oui, elle est de 2,5 %, tout à fait normal. La conversion de demain est-elle dans la plage normale d'un jeudi ? Non, elle est de 1,2 %, c'est une anomalie. L'équipe est alertée. Elle enquête et découvre que le paiement mobile est cassé. Sans détection d'anomalies, elle l'apprend vendredi après-midi. Avec, elle le sait mercredi matin.
Différents types d'anomalies déclenchent différentes alertes. Un pic soudain (trafic 200 % au-dessus de la normale) est signalé. Une chute soudaine (conversion 50 % sous la normale) est signalée. Un déclin progressif (conversion qui baisse lentement sur une semaine) est signalé. Un schéma récurrent qui se brise d'un coup (le mobile convertit toujours 20 % mieux que l'ordinateur, mais cette semaine ils sont à égalité) est signalé. Le système surveille tout cela.
Pourquoi repérer les problèmes tôt compte-t-il autant ?
Observez comment la plupart des marques découvrent leurs problèmes et vous verrez le schéma : une découverte après coup. Un client écrit pour se plaindre que le paiement ne marche pas. Vous consultez votre tableau de bord et vous le confirmez. Ou bien vous remarquez jeudi que lundi était étrange et vous essayez de comprendre ce qui s'est passé. Ce sont des heures ou des jours d'occasions perdues.
À grande échelle, le coût du retard s'accumule. Une boutique en ligne qui réalise 1 million de dollars de chiffre d'affaires par jour et perd 15 % de conversion à cause d'un bug perd 150 000 $ par jour. Deux jours de retard coûtent 300 000 $. Si la détection d'anomalies le repère 6 heures plus tôt, vous économisez 37 500 $. Un service en ligne par abonnement de 5 000 utilisateurs qui subit 2 % de départs en plus perd 100 utilisateurs. Deux semaines de retard représentent 1 400 utilisateurs perdus. Un repérage immédiat en limite la perte à 100. La différence se chiffre en milliers de dollars de revenu récurrent annuel.
La rapidité touche aussi la réputation. Une équipe de service client veut connaître les problèmes avant que les clients ne les signalent. Avec la détection d'anomalies, vous pouvez écrire à vos clients : « Nous avons détecté un problème sur votre compte mercredi matin et l'avons corrigé dans l'après-midi. » Sans elle, les clients se plaignent vendredi, vous répondez « nous allons regarder », et ils sont déjà partis chez un concurrent. La psychologie du « nous l'avons repéré » face au « vous nous l'avez signalé » change la perception du client.
La rapidité permet aussi d'expérimenter. Si vous déployez un changement et voyez son effet en quelques heures, vous itérez plus vite. Sans détection d'anomalies, vous menez une expérience pendant une semaine, vous consultez les résultats, puis vous itérez. Avec elle, vous voyez en 24 heures si un changement a aidé ou nui. Cette vitesse s'accumule sur une année.
Quels types d'anomalies faut-il vraiment repérer ?
Toutes les anomalies ne valent pas la peine d'être repérées. Certaines variations sont attendues. Mais certaines comptent pour les décisions de l'entreprise. L'essentiel est de configurer la détection d'anomalies pour les indicateurs qui, s'ils changent de façon inattendue, exigent une action immédiate.
Les anomalies qui touchent le chiffre d'affaires sont la priorité numéro un. Un taux de conversion qui baisse, un panier moyen qui recule, un abandon de paiement qui explose : tout cela affecte directement les revenus. Mettez des alertes sur chacun. Si la conversion chute de 10 %, vous voulez le savoir tout de suite, pas après le week-end.
Les anomalies d'engagement des utilisateurs comptent parce qu'elles annoncent des problèmes. Une durée de session qui baisse, une adoption de fonctionnalités qui recule, une fréquence de connexion qui diminue : ce sont des signes avant-coureurs de départs. Une baisse d'engagement cette semaine annonce une baisse de rétention le mois prochain. Repérez-la maintenant et vous avez le temps d'intervenir.
Les anomalies de trafic comptent parce qu'elles révèlent des problèmes de portée ou d'acquisition. Un pic de trafic naturel signifie que votre SEO fonctionne (bon signe). Une baisse du trafic naturel signifie que quelque chose s'est cassé dans la recherche (mauvais signe). Un trafic payant en recul signifie que vos campagnes publicitaires sous-performent (mauvais signe). Soyez alerté quand les sources de trafic changent de façon inattendue.
Les anomalies de qualité comptent parce qu'elles sont des tueurs silencieux. Un taux de rebond qui augmente signifie que votre site devient moins pertinent. Un nombre de pages par session qui baisse signifie que les utilisateurs trouvent plus vite ce qu'ils cherchent (bon signe) ou ne trouvent pas ce qu'ils veulent (mauvais signe). Des erreurs de session qui explosent signifient que le site se dégrade. Tout cela reste invisible si vous ne surveillez pas de près.
Comment configurer la détection d'anomalies sans fausses alertes ?
Interrogez n'importe quelle équipe de statistiques sur les fausses alertes et vous entendrez la même plainte : la fatigue d'alerte. Si chaque petite fluctuation déclenche une alerte, l'équipe arrête de les lire. Elle s'y habitue. Les vrais problèmes se perdent dans le bruit. Pour bien détecter les anomalies, il faut fixer des seuils qui attrapent les vrais problèmes tout en ignorant la variation naturelle.
Commencez par les indicateurs qui comptent le plus pour votre activité. Tous les indicateurs n'ont pas besoin de détection d'anomalies. Concentrez-vous sur les indicateurs de revenus (conversion, valeur de commande, départs), de santé des utilisateurs (engagement, rétention, adoption de fonctionnalités) et de santé du système (erreurs, latence, disponibilité). Ce sont ceux qui exigent une action immédiate s'ils changent.
Réglez la sensibilité selon la volatilité. Certains indicateurs sont naturellement volatils. Le trafic rebondit d'un jour à l'autre. Fixez les seuils assez larges pour absorber cette variation naturelle. Pour le taux de conversion, un écart de 20 % peut être normal : ne signalez qu'à partir de 30 % d'écart ou plus. Pour le chiffre d'affaires, un écart de 5 % peut être normal. Pour l'engagement, un écart de 15 % peut être normal. Les seuils dépendent de votre historique.
Intégrez le contexte. Le jour de la semaine compte. Le samedi a en général d'autres tendances que le mercredi. Les jours fériés ont d'autres tendances que les jours ordinaires. La détection d'anomalies doit en tenir compte. « Conversion sous 1,5 % un dimanche » peut être normal. « Conversion sous 1,5 % un mercredi » est une anomalie. Les bons systèmes apprennent ces tendances automatiquement.
Commencez prudemment et resserrez avec le temps. Si vous hésitez sur les seuils, fixez-les larges. Mieux vaut rater quelques anomalies que submerger l'équipe de fausses alertes. À mesure que vous gagnez confiance dans le système et que l'équipe s'habitue à lire les alertes, resserrez les seuils et repérez des anomalies plus petites.
Quelles sont les limites de la détection d'anomalies ?
La détection d'anomalies trouve les écarts par rapport au normal. Mais le « normal » est ce que votre historique considère comme normal. Si vos données sont fausses ou biaisées, le système manquera de vrais problèmes ou signalera de faux positifs. Si un bug a gonflé artificiellement votre taux de conversion pendant trois mois, le système a appris ce taux gonflé comme « normal ». Quand vous corrigez le bug, la conversion retombe à son niveau réel, et le système la signale comme une anomalie.
La détection d'anomalies n'explique pas la cause. Elle vous dit que quelque chose a changé. Elle ne dit pas pourquoi. Si la conversion a chuté, il faut quand même enquêter. Est-ce un problème technique ? Un changement de marché ? Une action d'un concurrent ? L'arrivée d'un nouvel acteur ? La détection d'anomalies fait remonter le problème. Le diagnostic reste un travail humain.
La détection d'anomalies fonctionne mal à très petite échelle. Avec 100 visiteurs par jour, la variation aléatoire est énorme. Chaque jour paraît anormal par rapport aux autres. La détection d'anomalies marche mieux à plus grande échelle, là où les tendances sont stables. Un service par abonnement de 50 000 utilisateurs mensuels a des tendances propres et stables. Un service de 500 utilisateurs mensuels a trop de bruit.
Les changements progressifs peuvent échapper à la détection d'anomalies. Si la conversion recule lentement (0,5 % de moins par semaine), le système peut ne pas la signaler, car chaque semaine ne s'écarte que légèrement de la précédente. Vous risquez de ne le remarquer qu'après une baisse totale de 10 %. Pour repérer une dégradation progressive, il faut une analyse de tendance en plus de la détection d'anomalies à un instant donné.
Quelle différence entre détection d'anomalies et alertes ?
Les alertes sont des règles que vous fixez à la main (conversion sous 2 %, revenus sous X). La détection d'anomalies apprend automatiquement la référence (tout ce qui s'écarte de 3 écarts types du normal). Les alertes exigent que vous sachiez ce qui est normal et quand vous en soucier. La détection d'anomalies apprend le normal à partir de vos données. Elle convient mieux pour repérer des problèmes inattendus. Les alertes conviennent mieux pour surveiller des seuils connus.
Toutes les plateformes de statistiques ont-elles une détection d'anomalies ?
Non. Google Analytics propose quelques notifications d'anomalies de base. Les plateformes d'analyse produit ont une détection d'anomalies. Les outils de BI peuvent être configurés pour cela. Mais toutes les plateformes ne l'incluent pas. Avant de choisir un outil de statistiques, vérifiez si la détection d'anomalies est incluse, quelle est la sensibilité des seuils et si vous pouvez la personnaliser.
À combien de fausses alertes dois-je m'attendre ?
Si le réglage est bon, le taux de fausses alertes doit rester sous 5 % des alertes. La plupart doivent être de vrais écarts qui méritent d'être examinés. Si vous recevez plus de 20 fausses alertes par jour, les seuils sont trop sensibles. Si vous ne recevez aucune alerte en un mois, les seuils sont trop larges. Ajustez les seuils en suivant quelles alertes ont mené à de vraies découvertes et lesquelles n'étaient que du bruit.
La détection d'anomalies peut-elle repérer la fraude ?
En partie. Si la fraude crée des tendances inhabituelles (pic de remboursements, anomalies géographiques, moyens de paiement inhabituels), la détection d'anomalies peut la signaler. Mais la détection de fraude demande des règles spécialisées (même carte bancaire utilisée plusieurs fois, contrôles de vélocité, écarts de géolocalisation). Utilisez la détection d'anomalies pour repérer les tendances générales. Utilisez la détection de fraude pour les schémas propres à la fraude.
De combien d'historique ai-je besoin pour que la détection d'anomalies fonctionne ?
La plupart des systèmes ont besoin de 2 à 4 semaines de données de référence pour commencer à apprendre les tendances. Un mois, c'est mieux. Après un trimestre de données, le modèle est assez précis. Après un an, il est très précis (il comprend les tendances saisonnières). Si vous déployez la détection d'anomalies sur un site tout neuf, attendez-vous à un taux élevé de fausses alertes le premier mois, le temps que le système apprenne votre référence.
Dois-je agir sur chaque alerte d'anomalie ?
Pas forcément. Certaines anomalies sont attendues (grosse parution presse, nouveau concurrent, effet saisonnier, grande campagne marketing). Quand vous recevez une alerte, demandez-vous d'abord : quelque chose d'extérieur a-t-il changé ? Si oui, l'anomalie est attendue, ce n'est pas un problème. Sinon, enquêtez. Avec le temps, vous apprendrez quelles alertes sont du signal (de vrais problèmes) et lesquelles sont du bruit.