Avito : l'équipe BI assemble des dashboards avec un agent en 8 à 10 jours au lieu de 20

De plus en plus souvent, des collègues apportent aux développeurs BI des dashboards assemblés avec l'aide de l'IA. Les graphiques sont nombreux et détaillés, mais on ne sait pas où regarder ni quelle conclusion en tirer. Ira Koulbiakina, de l'équipe Immobilier d'Avito, a analysé les raisons de ce phénomène et montré, à travers un exemple, comment amener un tel dashboard à un état exploitable. Selon les auteurs, avec un agent, un dashboard complexe s'assemble en 8 à 10 jours au lieu de 20.

Où l'agent aide, et où il n'aide pas

Le travail sur un dashboard se déroule en général ainsi. On commence par recueillir les besoins, puis on étudie les données : quelles tables sont à jour et comment calculer les métriques. Ensuite, on écrit le SQL et le code des visualisations, et on relie manuellement les filtres à chaque graphique. Ces étapes techniques, l'agent les prend en charge. Chez Avito, des serveurs MCP ont été créés pour Redash et pour l'entrepôt de données sur Trino. Par leur intermédiaire, l'agent cherche des tables, extrait les données, écrit des requêtes et construit des graphiques. Les sources et les calculs restent de toute façon vérifiés par des humains.

Les problèmes commencent lorsqu'on demande à l'agent d'assembler un dashboard complet à partir de graphiques. Pour le modèle, chaque graphique est une tâche distincte, avec sa propre requête, son type de visualisation et ses couleurs. Les erreurs au sein d'un même graphique (échelles différentes sur un même panneau, somme au lieu de moyenne, période précédente oubliée) sont faciles à détecter grâce à des règles. Les décisions à l'échelle de tout l'écran sont plus difficiles à prendre : quelle couleur est associée à quel indicateur, à quoi comparer chaque chiffre, ce qui est essentiel et ce qui ne doit pas figurer à l'écran.

L'expérience : le dashboard du centre d'appels

Une collègue a reconstitué le cahier des charges à partir d'un dashboard existant du centre d'appels, qui met en relation les acheteurs de logements neufs avec les promoteurs. Ensuite, l'autrice a assemblé un nouveau dashboard avec un autre agent, qui n'avait jamais vu la version d'origine. La question principale du client (« Pourquoi y a-t-il moins de transferts ciblés ? ») n'était pas mise en évidence dans le cahier des charges, pour que l'agent comprenne lui-même qu'elle était essentielle.

La première version semblait complète : sept cartes, évolution dans le temps, cascade, sources, villes, carte thermique, charge et tableau. Mais elle ne remplissait pas sa mission. Les corrections ont suivi :

• Évolution dans le temps. Un graphique qui montrait parts et volumes sur un même panneau a été scindé en cinq. La période précédente est affichée en pointillés, et les semaines incomplètes sont grisées, sinon la fin du mois ressemblerait à un effondrement.
• Carte thermique. En septembre, il y a cinq mardis et cinq mercredis, et quatre occurrences des autres jours : les sommes d'appels faussaient donc l'image. La somme a été remplacée par la moyenne, une légende a été ajoutée, et les chiffres ont été déplacés dans l'infobulle.
• Sources et villes. Transformées en tableaux avec une barre, une valeur et la variation par rapport à la période précédente, avec « Total » en première ligne.
• Employés. Regroupés par équipes, les petites lignes sont repliées dans « Autres », et tout le monde est coloré avec la même couleur, pour qu'aucune équipe ne paraisse à la traîne à cause du rouge.
• Indicateurs unifiés. Partout, c'est la part de transferts non ciblés qui a été retenue, plutôt que tantôt les ciblés, tantôt les non ciblés.

L'essentiel, l'agent ne l'a pas fait lui-même. La réponse à la question du client était fournie par la cascade, qui montre la contribution de chaque facteur à la variation des transferts ciblés. L'agent l'a construite, mais l'a placée sur le côté, sur la moitié de la largeur, sans comprendre que c'était précisément la réponse. Les humains ont dû déplacer la cascade sous les cartes, sur toute la largeur, et mettre en évidence l'unique contribution majeure : −63 transferts ciblés à cause de la hausse de la part de transferts non ciblés. Il y avait même plus de demandes, mais moins de transferts ciblés, précisément parce que la part des non ciblés avait augmenté.

Les règles à fixer

L'autrice a rassemblé ses conclusions dans une liste qui peut être transformée en skill pour l'agent :

• La comparaison doit être honnête : une seule échelle par graphique, les périodes incomplètes signalées, la moyenne plutôt que la somme lorsque le nombre de jours diffère selon les périodes.
• Un chiffre sans base de comparaison ne signifie rien. À côté de 82,3 %, il faut la période précédente.
• Ne pas dupliquer ce qui est déjà montré : si des chiffres figurent au-dessus des barres, l'échelle est inutile.
• Tout ce qui sert à la lecture est annoté : période, base de comparaison, unités.
• La couleur est associée à un sens sur tout l'écran. Le vert et le rouge servent uniquement à l'évaluation « mieux/moins bien », tandis que la hausse du volume d'appels est neutre et grise.

Ce qu'il faut en retenir

Il faut mentionner les limites à part. Tout l'article repose sur un seul dashboard avec des données synthétiques. Les chiffres définitifs du gain de temps ne sont pas révélés dans le fragment de texte disponible : « 8 à 10 jours au lieu de 20 » doit donc être pris comme une déclaration de l'équipe, et non comme une mesure indépendante. Les sources et les calculs, les auteurs les vérifient de toute façon manuellement.

La conclusion pratique est simple. On peut confier à l'agent la recherche de données, le SQL et la routine des filtres, mais la priorisation et la hiérarchie visuelle gagnent à être formulées explicitement. Si les règles du dashboard sont formalisées sous forme de skill, l'agent commettra moins d'erreurs classiques dès la première itération. Quant à la question « qu'est-ce qui est important ici, et pourquoi », c'est toujours à l'humain de la poser.