Opérations
Workflows qui agissent sur les signaux.
Aurélien
Le détaillant
Un détaillant de prêt-à-porter casual de 10 magasins où l'équipe était devenue le workflow.
Notre détaillant exploite 10 magasins en France sur le segment prêt-à-porter casual / athleisure. L'équipe est structurée : une équipe achat de 2 personnes plus un responsable des opérations, qui gère environ 4 500 SKU en saison en magasin et via une petite extension e-commerce.
La stack est standard pour le secteur — Fastmag comme cœur de la gestion retail, Shopify pour l'e-commerce, et Excel comme lien entre tout le reste. Ça fonctionne. Jusqu'au jour où non.
"Quatre personnes, quatre tableurs, quatre lundis. Nous étions le workflow."
— Responsable des opérations
Contexte
Quatre rituels hebdomadaires qui consumaient le lundi et le mardi de l'équipe.
2024. Le détaillant de prêt-à-porter casual fonctionnait sur une série de rituels hebdomadaires : revue des ruptures de stock (lundi matin), revue des alertes de démarque (lundi après-midi), planification des transferts inter-magasins (mardi matin), validation du réassort fournisseur (mardi après-midi). Chaque rituel impliquait une personne, un Excel et un jeu de décisions.
L'équipe était passée à 10 magasins. Les Excels étaient devenus plus complexes. Deux jours par semaine partaient dans les rituels — ne laissant que trois jours pour le vrai travail d'amélioration opérationnelle.
L'équipe ne manquait pas de discipline. Elle manquait de levier.
Le problème
Les mêmes boucles, chaque semaine, à la main.
Chaque rituel suivait un schéma clair : extraire les données, appliquer les règles, générer les décisions, déployer les actions. Le schéma était identique. L’exécution était manuelle.
L’équipe répétait : cela devrait être automatisé. Mais chaque tentative d’automatisation exigeait une capacité IT qu’elle n’avait pas. Les rituels continuaient donc. Chaque lundi, chaque mardi, la même boucle.
Trois points de friction s’additionnaient :
Le même schéma répété quatre fois par semaine, entièrement à la main.
Chaque rituel mobilisait une personne pendant une demi-journée.
Les outils de workflow no-code ne parlaient pas retail ; l’automatisation codée nécessitait l’IT.
L’équipe était le workflow. Elle devait cesser d’être le workflow.
La solution
Un workflow builder visuel, natif des signaux retail.
La couche d’orchestration de Solya permettait au responsable des opérations de construire les quatre rituels sous forme de visual workflows. Chacun suivait la même logique : trigger (un signal), constraints (règles métier), action (déploiement vers un système ou notification à une équipe).
La revue des ruptures de stock devenait : trigger 'stockout signal' → check 'within reorder budget' → action 'create draft PO in Fastmag, notify buyer.' L’ensemble s’exécutait en quelques secondes, à chaque déclenchement du trigger. Pas de code, pas de ticket IT. Construit un mardi après-midi.
Trigger — signaux retail natifs de la couche d’intelligence de Solya : ruptures de stock, surstocks, démarque, réassort.
Constraints — règles métier définies une seule fois, appliquées automatiquement.
Action — blocs préconfigurés : création de PO, notification magasin, ouverture de ticket.
L’équipe a cessé d’exécuter le workflow. Elle s’est mise à le superviser.
moq ≥ 6
notify(buyer)
Comment nous l’avons fait
Dans la boucle.
Chaque rituel a été reconstruit comme un workflow sur la couche d’orchestration de Solya. Le responsable des opérations les a construits visuellement, en quelques heures, sans IT. Voici comment le système fonctionne, de bout en bout.
01 — Cartographier chaque rituel.
Le responsable des opérations a cartographié chaque rituel hebdomadaire : déclencheur, décisions, actions, exceptions. Le schéma est apparu sous la forme de quatre workflows similaires.
02 — Construire le déclencheur.
Chaque déclencheur provenait de la couche de signaux de Solya : signal de rupture de stock, signal de surstocks, signal de transfert nécessaire, signal de réassort. Aucun code personnalisé.
03 — Appliquer les contraintes.
Les règles métier de la couche de contraintes (planchers de marge, MOQ, niveaux de magasins) ont été intégrées visuellement. Le workflow les respectait par conception.
04 — Définir l’action.
Les actions allaient de « créer un brouillon de BC dans Fastmag » à « notifier l’acheteur dans Slack » à « ouvrir un ticket de transfert dans le système d’entrepôt ». Chaque action était un bloc préconstruit.
05 — Exécuter et ajuster.
Les workflows tournaient en continu. L’équipe revoyait les exceptions chaque semaine. Les ajustements étaient faits visuellement, en quelques minutes, sans mobiliser l’IT.
L’équipe a cessé de faire tourner le workflow. Elle a commencé à le superviser.
Les impacts
Deux jours récupérés. Quatre boucles automatisées.
Une fois les quatre workflows déployés, l’équipe opérations a récupéré deux jours par semaine et est passée de l’exécution à la gestion des exceptions.
4 → 1 — rituels hebdomadaires automatisés.
2 jours — récupérés par semaine et par membre de l’équipe.
0 IT — tickets ouverts pendant la construction.
En production — boucles du signal à l’action.
"Nous avons cessé d’être le workflow. Nous avons commencé à piloter l’opération."
— Responsable des opérations
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.
