Avito a créé un bot d’analyse des métriques : l’IA rédige, le code classique calcule
L’équipe BI d’Avito a créé Big10 Pulse, un bot Mattermost qui vérifie chaque matin les principales métriques financières et envoie un PDF accompagné d’une courte note. Le principe : tout ce qui peut se traduire par une règle reste dans du code classique — disponibilité des données, seuils d’anomalie, contribution des segments. Le modèle de langage reçoit des faits déjà calculés et se contente de les transformer en commentaire, qui est ensuite vérifié pour repérer les affirmations inventées.
Traité par IA depuis Habr AI ; édité par Hamidun News
Chaque matin, un analyste ouvre le tableau de bord financier, vérifie que les données sont à jour, regarde le chiffre d’affaires et, si le montant a bougé, cherche où et pourquoi. Une demi-heure par jour, rien de magique, mais impossible de faire l’impasse sur ces vérifications. Aïgoul Akhmetova et Valeria Smirnova, développeuses BI chez Avito, ont décidé de confier cette routine à un bot. C’est ainsi qu’est né Big10 Pulse, dans le Mattermost de l’entreprise. Leur conclusion la plus intéressante porte sur ce qu’il ne faut pas confier à un modèle de langage.
Pourquoi une alerte ne suffit pas
Un graphique montre qu’une métrique a changé, mais n’explique pas pourquoi. Avant de formuler la moindre hypothèse, l’analyste doit vérifier que les données de la journée ont été entièrement chargées, que l’écart dépasse les fluctuations habituelles, que la base de comparaison est pertinente, et déterminer quel segment a le plus contribué à la variation. Passer directement à l’explication, c’est risquer de prendre une source partiellement chargée pour un recul de l’activité, ou un effet de jour férié pour un incident. Le graphique reste pourtant convaincant : c’est bien le problème.
L’équipe n’a donc pas créé de chat généraliste adossé à un rapport. Elle a limité la tâche à une première analyse : vérifier la disponibilité des données, séparer le signal du bruit, décomposer la variation en facteurs et indiquer où regarder ensuite.
Ce que fait le code, ce que fait le modèle
La première étape est très terre à terre : le bot vérifie la date de dernière mise à jour des sources. Tant que les données ne sont pas prêtes, le calcul ne démarre pas. Le modèle n’intervient pas ici. Il est capable de produire une explication fluide même à partir d’une erreur de chargement, alors que, dans cette situation, l’équipe a besoin qu’aucun texte ne soit produit. Chaque envoi est consigné dans un journal, et l’utilisateur ne reçoit pas de doublons.
Le bot recherche ensuite une anomalie. Il compare la valeur à celle de la semaine précédente et à la moyenne sur sept jours. Les seuils dépendent du type de journée et de l’historique de chaque métrique ; une règle distincte neutralise le rebond attendu après les jours fériés. Le code classique effectue tous ces calculs, car le système doit prendre la même décision à partir des mêmes données. L’équipe n’a pas demandé au modèle de « regarder le graphique et dire si cela ressemble à une anomalie ».
Le bot décompose ensuite l’écart global par activité et par type de chiffre d’affaires. Il les classe selon leur contribution, et non selon le pourcentage le plus élevé. Exemple : une baisse globale de 100 unités conventionnelles résulte de contributions de moins 80, moins 30 et plus 10. On voit alors clairement par où commencer. Une petite catégorie peut progresser de plusieurs dizaines de pour cent sans rien changer au résultat final.
Le modèle n’intervient qu’à la toute fin. Il reçoit un petit ensemble de faits établis : les variations relatives ont été calculées au préalable, et Python insère les valeurs absolues. L’équipe ne lui transmet pas l’intégralité du rapport : plus il voit de liens fortuits, plus il lui est facile d’inventer une explication plausible. Sa formule : moins le modèle a de liberté, plus sa réponse est utile.
Vérifier le texte avant l’envoi
Même avec des données d’entrée correctes, le modèle tend à amplifier les conclusions. Le calcul indique : l’activité A a apporté la principale contribution négative. Le texte devient : « le chiffre d’affaires a baissé à cause d’une erreur technique dans l’activité A ». Le modèle ne savait rien d’une quelconque erreur, mais il l’affirme avec assurance.
La note passe donc par deux contrôles. Le premier écarte les textes de remplacement, les réponses standardisées et les messages sans données. Le second compare le texte à l’ensemble de faits initial et recherche les chiffres et les affirmations qui n’y figuraient pas. Le point essentiel : le composant de vérification voit les mêmes faits que le générateur. Sinon, un modèle probabiliste se contente d’évaluer la force de conviction d’un autre, au lieu d’en vérifier la véracité.
Le bot distingue trois éléments : l’anomalie, quand la métrique dépasse les seuils ; la contribution, qui indique où la variation s’est produite ; et la cause, qui explique pourquoi. C’est généralement une personne qui confirme la cause, parfois à l’aide de sources supplémentaires. Si l’on mélange ces étapes, le système finira par présenter des hypothèses comme des faits établis.
Les autres problèmes à résoudre
L’abonnement enregistre le périmètre d’analyse, la langue et le type de rapport ; il se configure à l’aide de boutons dans Mattermost. Si plusieurs personnes s’abonnent au même périmètre, le calcul est réutilisé. Après la synthèse, l’utilisateur peut poser une question complémentaire, et la réponse est à nouveau vérifiée. Les droits d’accès ne changent pas : le bot ne montre rien que l’utilisateur ne pourrait voir dans le système d’origine. L’équipe suit l’utilisation et les incidents dans Grafana, et considère les retours des dirigeants et des managers comme une composante du produit.
Résultats et limites
Lors des tests, le bot comptait 9 abonnés, et l’équipe a estimé le gain à environ 99 heures-personnes par mois (9 personnes × 30 minutes × 22 jours ouvrés). Par la suite, 55 utilisateurs supplémentaires se sont abonnés de leur propre initiative. Il s’agit d’une estimation calculée, et non d’un chronométrage. Le changement d’usage est plus parlant : au lieu de consacrer 30–60 minutes à vérifier le rapport, une personne passe une à deux minutes à lire l’analyse déjà préparée.
Le bot ne remplace pas l’analyste et ne trouve pas la cause profonde de chaque variation. Il attend des données correctes, repère les écarts et guide l’utilisateur vers une première hypothèse vérifiable. L’article ne fournit aucun chiffre sur l’effet du bot sur la qualité des décisions ou sur l’exactitude des notes.
Les pratiques à retenir
Si vous développez un assistant IA similaire pour vos métriques, commencez par délimiter les responsabilités. La disponibilité des données, les seuils, la saisonnalité et la décomposition des contributions doivent relever du code déterministe. Confiez au modèle la rédaction à partir d’un petit ensemble de faits vérifiés. Donnez au validateur les mêmes faits qu’au générateur et prenez en compte les droits d’accès dès le premier jour. La décision la plus importante de l’équipe a été de savoir arrêter le modèle de langage à temps.
- 13 oct. 2026Avito dévoile comment il mesure la fiabilité et en quoi son budget d'erreurs diffère de celui de Google
- 23 juil. 2026Développement agentique vs vibe coding : comment Avito contrôle la qualité du code généré par l'IA
- 8 nov. 2026Le créateur de SalesAgent offre gratuitement son vendeur IA : le bot réussit 197 tests catalogue sur 200
- 30 avr. 2026Yandex montre à l'AI Dev Day comment l'IA transforme déjà le développement chez Avito, Ozon et T-Bank
Questions clés sur cet article
Pourquoi une alerte ne suffit pas?
Un graphique montre qu’une métrique a changé, mais n’explique pas pourquoi. Avant de formuler la moindre hypothèse, l’analyste doit vérifier que les données de la journée ont été entièrement chargées, que l’écart dépasse les fluctuations habituelles, que la base de comparaison est pertinente, et déterminer quel segment a le plus contribué à la variation.
Que sait-on sur Ce que fait le code, ce que fait le modèle ?
La première étape est très terre à terre : le bot vérifie la date de dernière mise à jour des sources. Tant que les données ne sont pas prêtes, le calcul ne démarre pas. Le modèle n’intervient pas ici. Il est capable de produire une explication fluide même à partir d’une erreur de chargement, alors que, dans cette situation, l’équipe a besoin qu’aucun texte ne soit produit. Chaque envoi est consigné dans un journal, et l’utilisateur ne reçoit pas de doublons. Le bot recherche ensuite une anomalie.
Que sait-on sur Vérifier le texte avant l’envoi ?
Même avec des données d’entrée correctes, le modèle tend à amplifier les conclusions. Le calcul indique : l’activité A a apporté la principale contribution négative. Le texte devient : « le chiffre d’affaires a baissé à cause d’une erreur technique dans l’activité A ». Le modèle ne savait rien d’une quelconque erreur, mais il l’affirme avec assurance. La note passe donc par deux contrôles. Le premier écarte les textes de remplacement, les réponses standardisées et les messages sans données.
Test Frontier LLMs & Autonomous Agents in One Workspace
Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.
L'essentiel de l'IA — une fois par semaine
Sept actus qui ont vraiment compté, choisies à la main. Sans bruit ni communiqués.
C'est fait ! Vérifiez votre boîte mail pour la confirmation.