Documenter les règles métier d'un logiciel : les extraire avant qu'il ne soit trop tard

Ce qui a de la valeur dans votre logiciel, ce sont les années passées à décider comment les choses se passent chez vous. Ces décisions vivent dans deux têtes et dans du code que personne ne relit. Les mettre en français, et pourquoi ce document survit au code.

Documenter les règles métier d'un logiciel prend quelques jours et sauve des années de décisions. Sur Reddit (r/vibecoding, juillet 2026), le dirigeant d'une entreprise régionale de maintenance raconte quatre ans passés à affiner la logique de son outil interne, avec 95 % du code écrit par l'IA, jusqu'à ce qu'un grand groupe veuille l'utiliser. Il écrit que la valeur tient dans les quatre ans.

Où vivent vos règles aujourd'hui

Faites l'inventaire honnête. Une partie de vos règles est dans le logiciel, sous forme de conditions écrites il y a huit ans par quelqu'un qui a quitté l'entreprise. Une autre partie est dans la tête de deux personnes, celles à qui on demande toujours « on fait comment quand le client est en litige ? ». Une troisième vit dans un tableur que votre comptable maintient à côté, parce que l'outil n'a jamais eu la case. Aucune de ces trois n'est lisible par un nouveau venu, et aucune ne se transmet avec le fichier de code.

Ce qu'est une règle métier, en une phrase de français

Une règle métier tient en une phrase qu'un salarié comprend : une commande passée après jeudi midi part la semaine suivante, un devis refusé reste consultable un an, un client sous contrat annuel ne paie pas d'acompte. Elle a un déclencheur, une conséquence et presque toujours une exception. L'exception est la partie qui a de la valeur, parce qu'elle vient d'un problème réel que vous avez rencontré une fois et que vous ne voulez plus revoir. Un logiciel du marché aplatit ces exceptions ; c'est le sujet que nous avions pris par le métier pour les professions libérales.

Les extraire sans arrêter la production

Trois questions font sortir la matière, posées aux personnes qui font le travail. Dans quels cas contournez-vous le logiciel ? Qu'est-ce que vous corrigez à la main après coup ? Qu'est-ce qui a changé le jour où un client s'est fâché ? Chaque réponse donne une règle et une exception, en français, sans qu'un développeur soit dans la pièce. Comptez une heure par personne et un carnet. La méthode des questions qui fâchent sert la même intention avec un chronomètre. Un consultant en organisation fait ce travail mieux qu'une machine quand deux services se contredisent : la machine transcrit ce qu'on lui dit, elle n'arbitre pas entre le commerce et la production.

Une règle ne sort pas en réunion plénière. Elle sort au poste de travail, quand la personne vous montre son écran et dit « là, en principe je mets la date du lundi suivant, sauf pour eux ». Notez la phrase telle qu'elle la dit, avec le nom du client et la raison. Une règle réécrite en langage administratif perd son exception, et l'exception était le seul morceau qu'un logiciel du marché ne saura pas reproduire.

Le document est la mémoire du produit

Chez Maestro, ce document a un nom et une place : le cahier des charges, écrit en français par l'agent Victor à partir du cadrage mené par Margaux, relu par vous, validé par un « Ça me va » avant que la moindre ligne de code existe. Il sert deux fois. La première quand les agents construisent, parce qu'ils s'y réfèrent au lieu de deviner. La seconde des années plus tard : le code se régénère à partir du document, l'inverse ne marche pas. Une reprise d'un logiciel existant commence d'ailleurs par cette lecture, avant de migrer quoi que ce soit.

Ce que vous gagnez à l'avoir écrit

Un nouveau salarié apprend votre métier en le lisant plutôt qu'en posant vingt questions. Un prestataire chiffre sur un document au lieu d'une conversation, et vous pouvez comparer deux devis sur la même base. Le jour où un client important demande à utiliser votre outil, vous avez de quoi discuter d'un contrat plutôt que de fouiller votre propre code. Et si vous décidez un jour de tout refaire, le travail des années précédentes reste, alors que le code de 2019 ne servira à personne. Le dirigeant de r/vibecoding en est là : quatre ans de décisions accumulées dans un outil qu'un grand groupe veut utiliser, et une question de valeur qui porte sur ces décisions, pas sur les fichiers. Ce qu'il a construit se raconte, se vend et se refait ailleurs à condition d'être écrit.

Commencer par dix lignes cette semaine

Prenez une feuille et écrivez dix règles, une par ligne, en commençant par les exceptions que vous expliquez le plus souvent à vos équipes. Datez la feuille. Faites-la relire par la personne qui traite les commandes, elle en corrigera trois et en ajoutera deux. Vous aurez la première version de la mémoire de votre produit, et elle vaut déjà mieux que ce que contient votre logiciel actuel.