IT/Données
Règles métier, rédigées une seule fois.
Aurélien
L’enseigne
Une enseigne sport de 16 magasins, trois acheteurs, sept mille SKU.
Notre enseigne opère 16 magasins en France sur le segment sport multimarque spécialisé — running, fitness, textile technique. L’équipe achat est structurée : une équipe de 3 acheteurs, plus un allocator dédié, qui pilote environ 7 000 SKU en saison.
La stack est standard dans le secteur — Ginkoia comme cœur de la gestion retail, Shopify pour l’e-commerce, et Excel comme couche de liaison entre le reste. Cela fonctionne. Jusqu’au moment où ce n’est plus le cas.
"Nos vraies règles vivaient dans trois têtes de senior et un PDF obsolète. Le modèle ne les connaissait jamais."
— Responsable Achats
Contexte
Une enseigne de 16 magasins pilotée par des règles que personne n’avait consignées.
2024. L’enseigne sport fonctionnait avec un ensemble riche de contraintes métier : marge minimale par catégorie, MOQ fournisseurs, priorité des magasins par niveau sur les produits chauds, variations de lead time selon les fournisseurs. Ces règles s’étaient construites en quinze ans d’exploitation — et elles vivaient dans la tête de trois acheteurs seniors, plus un PDF de 2019 déjà obsolète.
Quand ils ont fait appel à leur premier fournisseur d’IA, les recommandations violaient régulièrement leurs règles. L’équipe en a contourné 70 %. Ils n’ont pas perdu confiance dans l’IA — ils ont compris que l’IA ne savait pas ce qui comptait vraiment pour eux.
Le modèle était techniquement solide. Simplement, les règles ne lui parvenaient jamais.
La problématique
Le modèle recommandait. L’équipe contournait. Personne n’y gagnait.
Les recommandations du précédent fournisseur d’IA étaient techniquement solides — elles optimisaient le chiffre d’affaires, le sell-through, ou quel que soit l’objectif défini. Mais elles ne connaissaient pas les vraies règles de l’équipe : « Les produits de la marque X vont toujours d’abord dans les magasins de niveau A », « Le plancher de marge sur le textile technique est de 38 % », « Le fournisseur Y a des délais de 6 semaines en hiver ».
À chaque recommandation s’ajoutait donc un coût caché : l’équipe devait la vérifier manuellement au regard des règles non écrites, contourner ce qui ne convenait pas et expliquer pourquoi. Au bout de trois mois, elle faisait moins confiance au modèle qu’à son intuition.
Trois problèmes se cumulaient :
Les vraies règles métier vivaient dans la tête des seniors, et dans aucun système.
Les recommandations cassaient régulièrement les planchers de marge ou les contraintes fournisseurs.
Un taux d’override de 70 % érodait la confiance dans l’IA plus vite qu’elle ne se construisait.
Le modèle n’a pas échoué. Les règles ne lui sont tout simplement jamais parvenues.
La solution
Chaque règle codifiée une seule fois, dans Solya, respectée par chaque recommandation.
La couche de contraintes métier de Solya est devenue le point de référence unique pour chaque règle opérationnelle. L’équipe les a formalisées une seule fois : marge minimale par catégorie, quantités minimales de commande (MOQ) et délais d’approvisionnement fournisseurs, priorités par niveau de magasin, plafonds budgétaires, politiques de transfert, réassort, ruptures de stock, surstocks et démarque. Chaque règle était encodée dans un générateur visuel — pas de code, pas de ticket d’ingénierie.
À partir de là, chaque recommandation générée par Solya respectait les règles par construction. Le taux d’override a baissé. La confiance a augmenté. L’équipe disposait enfin d’une IA qui comprenait son activité.
Générateur visuel pour chaque règle — les acheteurs les rédigeaient eux-mêmes, sans ingénierie.
Application par construction — les recommandations sont vérifiées par rapport aux règles avant d’être affichées.
Découverte pilotée par les overrides — lorsqu’une règle manquait, les patterns d’override la faisaient émerger.
Les règles ont cessé de vivre dans les têtes. Elles ont commencé à vivre dans le système.
Comment nous l’avons fait
Dans la boucle.
La couche de règles métier fonctionnait sur l’Intelligence Layer, l’équipe achat rédigeant les règles et Solya les appliquant. Voici le fonctionnement du système, de bout en bout.
01 — Cartographier les règles.
L’équipe achat a organisé deux ateliers pour faire émerger chaque règle opérationnelle importante. Quarante-deux règles ont été identifiées autour de la marge, des fournisseurs, des niveaux de magasin et du budget.
02 — Les encoder dans le builder visuel.
Chaque règle a été rédigée dans le builder de Solya : condition, seuil, périmètre, exception. Pas de code. L’équipe achat l’a fait elle-même.
03 — Appliquer à chaque recommandation.
Chaque sortie produite par Solya — prévisions, allocations, réassorts, démarques — était vérifiée au regard des règles avant d’être affichée. Les violations étaient signalées ou bloquées.
04 — Suivre les overrides.
Lorsque l’équipe contournait une recommandation, Solya en consignait la raison. Les patterns de dérogations ont fait ressortir des règles manquantes ou obsolètes.
05 — Piloter dans la durée.
Les règles étaient versionnées. Lorsqu’une règle changeait, Solya consignait qui, quand et pourquoi. L’historique était consultable, auditable et lisible.
Les règles ne restaient plus dans les têtes. Elles vivaient désormais dans le système.
Les impacts
Des recommandations alignées sur le business qu’elles servent.
Après trois mois d’exploitation avec les règles encodées, le taux de dérogation a fortement baissé, la confiance dans les recommandations a augmenté, et le savoir tacite de l’équipe est devenu un actif partagé.
1 seul endroit — Pour chaque règle métier.
Versionnées — Chaque changement tracé.
0 violation — Dans les recommandations à venir.
70% → 18% — Taux de dérogation sur les recommandations.
"L’IA a enfin compris ce qui compte vraiment pour nous."
— Responsable des achats
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.
