Vos règles métier vivent dans un tableur que personne n'ose toucher

Il contient les prix, les seuils, les exceptions. Il fait autorité, il n'a plus vraiment d'auteur, et il n'existe qu'en un seul exemplaire — sauf les copies qui circulent par mail.

Ce que vous voyez

Le fichier a un nom qui finit par une date, et ce n'est pas la plus récente.
Une seule personne sait ce que fait le quatrième onglet, et elle n'était pas là quand il a été écrit.
Chaque mise à jour passe par un prestataire, parce que le fichier est devenu trop délicat pour être modifié en interne.
Personne ne peut dire quel tarif s'appliquait le mois dernier, ni à quel moment il a changé.
Pour décliner le barème auprès d'un nouveau partenaire, on duplique le fichier.

Ce qui se passe vraiment

Un tableur qui porte des règles n'est plus un tableur : c'est un logiciel, écrit dans un langage que personne n'assume. Il a une logique, des cas particuliers, des dépendances entre onglets — tout ce qu'a un programme, sauf l'historique, les tests, et quelqu'un pour en répondre.

Il est arrivé là par une suite de bonnes décisions. Au départ, c'était le moyen le plus rapide et le plus souple de tenir un barème, et il l'est resté longtemps. Puis il a grossi, et la souplesse s'est retournée : plus rien ne garantit qu'une modification en haut ne casse pas un calcul en bas. Alors on modifie avec précaution, puis on fait modifier, puis on ne modifie plus.

Le signe qui ne trompe pas, c'est le jour où la mise à jour d'un barème est confiée à celui qui développe l'application. Ce n'est pas son métier, c'est chronophage, et la valeur ajoutée est faible — mais c'est lui qui sait ouvrir le fichier sans le casser. Ce jour-là, une décision commerciale est devenue une tâche technique, et le métier a perdu la main sur ce qui lui appartient.

Ce que ça vous coûte

D'abord le délai : une décision prise en réunion attend une intervention technique pour exister. Ensuite le risque : rien ne vous dit qu'une valeur n'a pas été écrasée en cours de route, et vous ne l'apprendrez qu'à la réclamation d'un client. Enfin l'immobilité, qui est la plus chère de toutes — on renonce à des offres, à des remises, à des paliers, parce que les décliner dans le fichier fait peur. La règle n'est plus au service du commerce : c'est le commerce qui s'aligne sur ce que le fichier sait faire.

Comment on s'y prend

On ne remplace pas le tableur par un écran. On le remplace par deux choses distinctes, et cette distinction est tout le sujet : les valeurs d'un côté, la mécanique de l'autre.

Les valeurs — barèmes, seuils, taux, exceptions — restent des données, importables et versionnées : on garde la trace de ce qui s'appliquait à chaque date, et on peut revenir en arrière. La mécanique, elle, devient du code, testé, rejoué automatiquement avant chaque mise en production.

Le tableur ne disparaît pas forcément pour autant. Il peut redevenir ce qu'il aurait toujours dû être : un format d'échange, pas un moteur.

Ce que vous avez à la fin

Quelqu'un du métier modifie un barème, voit ce que cela change avant d'appliquer, et publie. Sans ticket, sans prestataire, sans attendre.

Et vous pouvez répondre à la question qui n'avait pas de réponse : quel tarif s'appliquait ce jour-là, et qui l'a décidé.

Où nous avons déjà vu ça

Réseau national de retail optique et audition

Le barème de référence était un classeur volumineux dont la mise à jour avait fini par revenir au prestataire de développement. L'en sortir, c'était rendre au métier une décision qui n'aurait jamais dû lui échapper.

Multi family office parisien

Un même socle devait servir plusieurs marques, avec des règles différentes. Séparer strictement le code métier du reste a permis d'en décliner plusieurs sans rien réécrire.

Les questions qu'on nous pose

Nous tenons à Excel. Nos équipes vont-elles le perdre ?

Non. Excel est excellent pour préparer, comparer, simuler, et nous continuons à l'accepter en entrée comme en sortie. Ce qu'il ne doit plus être, c'est l'endroit où la règle fait autorité.

Qui décide de ce qui devient un paramètre et de ce qui reste du code ?

Vous, au cahier des charges. La ligne se trace à une question simple : cette valeur peut-elle changer sans que rien d'autre change ? Si oui, c'est un paramètre. Sinon, c'est de la structure, et cela passe par le backlog.

Peut-on tout rendre paramétrable ?

Non, et il ne faut pas essayer. Un outil dont tout se règle devient un outil que plus personne ne sait régler. On rend paramétrable ce qui bouge réellement, et on laisse le reste dans le code, où il est plus sûr.

Et si nous nous trompons dans un barème ?

Vous en verrez l'effet avant de publier, et vous pourrez revenir à la version précédente. C'est tout l'intérêt des versions : l'erreur devient rattrapable au lieu d'être une découverte.

Les autres situations

Montrez-nous le fichier que personne n'ose ouvrir.

Trente minutes suffisent pour savoir si un outil sur mesure se justifie, ce qu'il coûterait, et en combien de temps il se rembourse. Si la réponse est non, nous vous le disons aussi.

Réserver 30 minutes (nouvel onglet)