Opérations
Questions en langage clair.
Aurélien
Le détaillant
Un détaillant streetwear de 9 magasins, deux acheteurs, trois mille cinq cents SKU.
Ce détaillant exploite 9 magasins en France sur le segment streetwear contemporain unisexe. L’équipe est réduite et focalisée : une équipe achat de 2 personnes qui gère environ 3 500 SKU en saison.
La stack est standard pour le secteur — Polaris comme socle de gestion retail, Shopify pour l’e-commerce, et Excel comme liant entre tous les autres outils. Cela fonctionne. Jusqu’au jour où ce n’est plus le cas.
« Chaque question que je posais nécessitait deux e-mails et trois jours pour obtenir une réponse. Quand la réponse arrivait, la question avait déjà changé. »
— Directrice merchandising
Contexte
Une directrice merchandising tenue à distance de ses données par un mur d’analystes.
2024. La directrice merchandising du détaillant streetwear pilotait la stratégie d’achat, le calendrier de marque et les relations fournisseurs. Chaque décision opérationnelle nécessitait de la donnée — tendances de sell-through, couverture de stock, performance magasin, ruptures de stock, surstocks, démarque, réassort — et chaque demande de donnée passait par son équipe d’analystes de deux personnes.
Les analystes étaient bons. Ils étaient aussi un analyste trop peu nombreux, et débordés. Les questions de la directrice s’accumulaient donc. Quand une réponse revenait, trois nouvelles questions avaient déjà émergé.
Elle avait les dashboards. Elle savait même les lire. Mais dès qu’elle avait une question spécifique — « pourquoi les ventes du week-end baissent-elles en magasin 4 ? » ou « quels articles capsule devons-nous réassortir pour SS ? » — elle devait faire appel à un analyste.
La problématique
Les données étaient là. Simplement pas pour vous.
Vous pouviez voir les dashboards. Vous pouviez même les lire. Mais dès que vous aviez une question précise — « Pourquoi les ventes du week-end baissent-elles dans le magasin 4 ? » ou « Quels articles capsule devons-nous relancer pour SS ? » — vous aviez besoin d’un analyste.
L’équipe analyste avait trente autres demandes. Vos questions restaient 1 à 3 jours en attente de réponse, puis nécessitaient souvent un suivi. Le cycle de décision s’allongeait. Les lundis étaient consacrés à l’envoi d’e-mails aux analystes, pas à la prise de décision.
Trois points de friction se cumulaient :
Les questions précises nécessitaient une capacité analyste qui n’existait pas.
Un délai de réponse de 1 à 3 jours ralentissait les décisions tactiques.
Les questions de suivi ajoutaient un cycle supplémentaire, multipliant le délai.
Vous aviez les données. Vous n’aviez tout simplement pas l’accès.
La solution
Des questions en langage naturel, des réponses structurées, les sources affichées.
Solya a récupéré le modèle retail de référence, les définitions des métriques de l’équipe et les règles métier encodées. Vos questions s’exécutaient directement sur le modèle — aucun analyste dans la boucle, pas de SQL.
Vous saisissiez vos questions naturellement : « Pourquoi les ventes du week-end baissent-elles dans le magasin 4 ? » ou « Quels articles capsule devons-nous relancer pour SS ? » L’agent a récupéré les données pertinentes, exécuté l’analyse et renvoyé une réponse structurée — avec le calcul affiché, les sources affichées et le niveau de confiance associé.
80 % des questions traitées en quelques secondes, avec une transparence totale.
Les cas limites restent orientés vers l’équipe analyste — mais avec une partie du travail déjà faite.
Chaque réponse est tracée jusqu’aux données, à la définition de la métrique et à la règle appliquée.
La file d’attente des analystes est passée de trente demandes à six. Tout le monde y gagne.
Comment nous l’avons fait
Dans la boucle.
L’agent analytique s’exécute sur la couche applicative, la couche des métriques fournissant les définitions et la couche de données fournissant le substrat. Voici comment le système fonctionne, de bout en bout.
01 — Se brancher au modèle canonique.
L’agent avait un accès direct au modèle retail canonique de Solya — chaque SKU, chaque magasin, chaque transaction — avec des entités retail natives et les définitions de métriques de l’équipe déjà encodées.
02 — Parser les questions en langage naturel.
La responsable merchandising saisissait ses questions naturellement. L’agent les traduisait en requêtes sur le modèle canonique — pas de SQL, pas d’intermédiaire analyste.
03 — Lancer l’analyse.
L’agent calculait la réponse à partir des définitions et des règles métier encodées par l’équipe. Pas de calcul ad hoc, pas de SQL de contournement.
04 — Afficher les sources et le raisonnement.
Chaque réponse était accompagnée des sources de données, du calcul et d’un niveau de confiance. La responsable merchandising pouvait vérifier, approfondir ou contester.
05 — Escalader les cas limites.
Quand le niveau de confiance de l’agent était faible, il transmettait la question à l’équipe analyste — avec le travail partiel déjà réalisé. Les analystes gagnaient du temps sur les cas simples.
La responsable merchandising a eu un accès direct. L’équipe analyste a récupéré sa file d’attente.
Les impacts
Des décisions qui n’attendent pas trois jours qu’un analyste soit disponible.
Après la mise en production de l’agent analytique, la responsable merchandising a traité elle-même ses questions — et l’équipe analyste s’est concentrée sur les analyses de fond qui avaient réellement besoin d’elle.
80% — Des questions traitées en quelques secondes.
30 → 6 — File d’attente des analystes à tout moment.
Sources affichées — Derrière chaque réponse.
Jours → secondes — De la question à l’action.
"J’ai arrêté de planifier mes questions. J’ai commencé à les poser."
— Responsable merchandising
Découvrez d'autres cas d'usage
Une seule plateforme. Chaque décision retail.
Stocks, allocation, tarification, planification, exécution — réunis dans une seule couche opérationnelle.
