Du problème métier à l’écran : comment nous transformons un besoin en solution

Quand un dirigeant nous dit « j’ai besoin de mieux contrôler le crédit », il ne demande pas un écran. Il décrit un problème métier : des clients qui ne paient pas, des livraisons qui partent sans garantie, un encours clients qui grossit. Notre travail consiste à transformer ce problème en quelque chose que le système peut faire, vérifier et mesurer.

Les quatre niveaux

1. Besoin métier (le « pourquoi »). L’objectif, dans le langage de l’entreprise. « Réduire les impayés échus sans freiner les ventes. »
2. Règles de gestion (le « ce qui est décidé »). Les politiques que fixe l’entreprise. « Nous ne livrons pas un client qui dépasse sa limite de crédit, sauf autorisation du service Crédit. »
3. Exigences fonctionnelles (le « ce que fait le système »). Des comportements concrets et vérifiables. « Lorsqu’une commande à crédit est confirmée, le système calcule l’exposition du client et, si elle dépasse la limite, met la commande en attente. »
4. Critères d’acceptation (le « comment savoir que ça marche »). Des cas de test écrits avant toute ligne de code.

Sauter un niveau est la raison la plus fréquente pour laquelle des projets « fonctionnent » sans rien résoudre.

Notre façon de faire

• Nous écoutons le problème, pas la solution. Si un utilisateur demande « un bouton pour bloquer les clients », nous demandons pourquoi. Il y a presque toujours une règle plus générale derrière.
• Nous écrivons la règle avec l’entreprise. C’est le métier qui décide des règles. Nous les rendons explicites, avec leurs exceptions et ceux qui les approuvent.
• Nous la décomposons en exigences fonctionnelles avec des exemples. Chaque exigence fonctionnelle s’accompagne d’exemples concrets avec des chiffres réels.
• Nous définissons l’acceptation avant de coder. Avec le développement piloté par les tests, chaque règle a son test automatisé dès le départ.
• Nous validons avec l’utilisateur clé pendant le sprint. Pas à la fin du projet : à chaque livraison de deux à quatre semaines.
• Nous mesurons. Le besoin métier avait un objectif ; après la mise en production, nous examinons l’indicateur clé.

Cas 1 : un grossiste qui vendait à crédit sans contrôle

Problème métier. Les commerciaux prenaient des commandes à crédit sans savoir combien le client devait ; les impayés échus ne cessaient d’augmenter et le service Crédit l’apprenait trop tard.

Règles de gestion.

• Chaque client a une limite de crédit.
• L’exposition correspond à ce que le client doit déjà, plus la commande en cours de confirmation.
• Si l’exposition dépasse la limite, la commande est mise en attente ; seule une personne habilitée peut la débloquer.
• Les acomptes du client sont imputés lors de la facturation de la commande.

Exigences fonctionnelles.

• À la confirmation d’une commande à crédit, calculer l’exposition et la comparer à la limite.
• En cas de dépassement, marquer la commande comme en attente et notifier le service Crédit.
• Une commande en attente ne peut être ni livrée ni facturée.
• À la facturation, imputer automatiquement l’acompte du client.

Critère d’acceptation (exemple). Étant donné un client avec une limite de 50 000 Bs et 42 000 Bs de dette, lorsque le commercial confirme une commande de 12 000 Bs, alors la commande est mise en attente, le service Crédit reçoit la notification et le bouton de livraison est verrouillé.

Cas 2 : un importateur qui ne connaissait pas son coût réel

Problème métier. Le prix de vente était calculé sur la valeur de la facture du fournisseur, sans fret, assurance, douane ni frais locaux. Certains produits étaient vendus à perte sans que personne ne s’en aperçoive.

Règles de gestion.

• Le coût d’un produit importé inclut tous les frais d’importation.
• Chaque frais est réparti entre les produits selon une base définie : valeur, poids, volume ou quantité.
• Le coût définitif est connu à la clôture du dossier d’importation.

Exigences fonctionnelles.

• Un dossier d’importation regroupe les factures du fournisseur et tous les frais associés.
• Pour chaque frais, on choisit sa base de répartition.
• À la liquidation, le système calcule le coût unitaire définitif de chaque produit et met à jour le coût des stocks.
• À partir du coût définitif, un prix de vente est proposé selon la marge cible.

Critère d’acceptation (exemple). Étant donné un envoi de deux produits de même valeur et de poids différent, lorsque le fret est réparti au poids, alors le produit le plus lourd absorbe davantage de fret et son coût unitaire le reflète.

Pourquoi c’est important

Un besoin correctement décomposé en termes fonctionnels peut être testé, maintenu et mesuré. Celui qui ne l’est pas finit en personnalisations que plus personne ne comprend un an plus tard.

Les deux cas de cet article sont devenus des flux de MKA ; vous pouvez parcourir le premier dans la démo des commandes et livraisons.