Problématique - Pour les équipes offres
Elles savaient imaginer de nouveaux tarifs, mais pas toujours les traduire en règles fiables.
- Horaires variables
- Seuils de consommation
- Périodes d'application
Un éditeur de règles tarifaires sans dépendre de l'IT
Pour tester une nouvelle offre tarifaire, les équipes métier devaient passer par l’IT, même pour les cas les plus courants.
J’ai conçu un éditeur de règles où le métier pouvait créer une offre, voir quand elle s’applique et vérifier son effet sur la facture, sans dépendre d’un développeur.
Contexte
J’ai piloté
Framing no-codeArchitecture UXModèle d’interactionLogique de règlesValidation métierPrototypage
Équipe
Product - Engineering - Backend - Equipe métier client - Sales
Challenge
Rendre la création d'offres assez simple pour le métier, sans perdre la précision nécessaire à la facturation.
Année
2019
Planning
12 mois
Outils
Figma, Notion, Zeplin
Comprendre le problème
Exploration et solution
Un formulaire par offre
Créer un écran dédié pour chaque logique tarifaire, avec des champs simples pour les cas standards.
Promesse
Très facile à lire / Rapide sur cas simples
Raisons d’abandon
Peu flexible / Trop de variantes
Un éditeur avancé unique
Exposer une logique proche du moteur de règles pour couvrir les scénarios tarifaires les plus complexes.
Promesse
Très flexible / Couvre les cas rares
Raisons d’abandon
Trop technique / Risque d'erreurs
Un mode guidé, avancé et temporel
Combiner des briques métier lisibles, un mode avancé pour les règles complexes et une timeline pour voir quand chaque règle s'applique.
Promesse
Accessible au métier / Périodes visibles
Risque accepté
Plus dur à concevoir / Modèle à expliquer
Décisions clés
Rendre les règles configurables
Parce que chaque nouvelle offre ne pouvait pas rester dépendante d'un développement spécifique.
Coût évité
Coder chaque nouvelle offre
Coût évité
Dépendre constamment des développeurs
Cadrer les règles configurables
Coût accepté
Limiter certains cas spécifiques
Coût accepté
Séparer guidé et avancé
Parce qu'un outil seulement simple aurait été trop limité, et un outil seulement puissant trop difficile à utiliser.
Coût évité
Un outil trop technique
Coût évité
Un formulaire trop rigide
Deux modes à relier
Coût accepté
Un modèle à expliquer
Coût accepté
Mettre le temps au centre
Parce qu'une règle d'offre n'avait de sens que si l'équipe voyait clairement quand elle s'appliquait.
Coût évité
Des périodes invisibles
Coût évité
Des conflits difficiles à repérer
Une visualisation plus complexe
Coût accepté
Des chevauchements à gérer
Coût accepté
Vérifier avant facturation
Parce qu'une erreur de règle devenait coûteuse si elle n'était découverte qu'au moment de la facture.
Coût évité
Découvrir les erreurs trop tard
Coût évité
Envoyer des résultats non vérifiés
Concevoir des vues de validation
Coût accepté
Expliquer les résultats générés
Coût accepté
Les impacts
L'outil a rendu les offres plus rapides à créer, plus faciles à tester et vérifiables avant facturation.
Les équipes offres gagnaient en autonomie
les cas courants devenaient configurables sans développement spécifique
Les variantes devenaient plus rapides à tester
moins d'allers-retours avec l'IT pour ajuster une règle
Les effets sur facture devenaient vérifiables
les règles pouvaient être contrôlées avant d'arriver dans la facturation
Temps pour réaliser les tâches clés
Les mêmes tâches devenaient plus rapides une fois configurables dans l'outil
8/12
Scénarios configurables sans IT
Scénarios courants désormais couverts en autonomie par les équipes métier, sans développement spécifique
Rétrospective
Créer un écran pour chaque cas
Concevoir un système qui absorbe les variantes
Cacher toute la complexité
La rendre lisible et manipulable
Valider seulement l'interface
Vérifier ce que l'interface produit réellement
