Les règles métier implicites en PME : pourquoi elles sabotent un projet SI sur deux

Ce qu'on appelle une règle métier implicite

Une règle métier implicite est une règle de gestion que les équipes appliquent sans l'avoir jamais formalisée. Elle existe dans les têtes, se transmet à l'oral lors de l'intégration des nouveaux collaborateurs, et fonctionne tant que les bonnes personnes sont présentes. Personne ne l'a écrite parce que tout le monde la connaît. Du moins, c'est ce qu'on croit.

Ces règles prennent des formes très diverses. Un seuil de validation non écrit : les devis au-dessus d'un certain montant passent toujours par le directeur commercial, même si ce circuit n'est formalisé dans aucun outil. Une exception métier connue de tous : les commandes de tel client bénéficient d'un délai de paiement étendu « depuis toujours », sans qu'un contrat le stipule. Une règle de priorité implicite : quand deux commandes entrent le même jour, l'équipe logistique sait laquelle traiter en premier selon des critères que personne ne saurait énoncer clairement.

Dans une PME qui fonctionne depuis dix ou quinze ans, il y a plusieurs centaines de ces règles. Sur un périmètre de deux ou trois processus coeurs, on en compte facilement trente à cinquante. Certaines sont critiques pour le service client, d'autres pour la fiabilité de la facturation, d'autres encore pour la conformité réglementaire.

Quand les règles implicites explosent en cours de développement

Le développement logiciel force une formalisation que le quotidien ne demande pas. Tant que les équipes gèrent les processus à la main, les règles implicites fonctionnent grâce à la mémoire collective et à la transmission orale. Un développeur qui code une règle de gestion doit, lui, la traduire en logique déterministe. Il ne peut pas s'appuyer sur l'intuition d'un collaborateur expérimenté.

La confrontation entre la règle implicite et la logique du code est le point de friction qui génère le plus de reprises en cours de projet. Le scénario classique : le développeur code le processus nominal. L'équipe terrain teste et découvre que le logiciel ne gère pas « le cas du client X ». Reprise. Puis découverte du « cas Y ». Reprise. Puis du « cas Z ». À chaque itération, la confiance se dégrade et le budget s'érode.

Ce n'est pas un problème de compétence des développeurs. C'est un problème de documentation en amont. Les règles étaient dans les têtes, pas dans les specs.Personne ne peut coder ce qui n'a pas été verbalisé.

Le cas particulier des secteurs à règles techniques denses

Dans certains secteurs, les règles implicites ne sont pas seulement organisationnelles. Elles sont techniques et réglementaires. L'énergie, la santé, l'assurance, le transport réglementé : chaque secteur a son vocabulaire propre, ses règles de calcul, ses obligations de traçabilité. Ces règles s'accumulent dans les équipes terrain au fil des années. Elles ne se voient pas de l'extérieur.

Un développeur ou un chef de projet externe qui arrive sans investir du temps à comprendre ce vocabulaire va produire une architecture qui ne corresponds pas aux objets métier réels. Le produit livré sera techniquement correct mais fonctionnellement inadapté. C'est l'une des causes les plus fréquentes de projets qui « ne collent pas » sans que les équipes arrivent à expliquer pourquoi.

« On parle d'énergie, de soutirage, d'injection, d'Énédis, de TURPE, plein de vocabulaires techniques qui impliquent des règles métier techniques. La force, ça a été de se projeter dans leur métier tout en gardant un regard extérieur pour poser les bonnes questions. »

Pourquoi les prestataires classiques passent à côté

Un prestataire qui démarre directement par le développement, sans phase de terrain structurée, ne peut pas sortir les règles implicites. Il code ce qu'on lui demande, sur la base des specs fournies. Si les specs ne documentent pas les exceptions, les cas limites et les règles de priorité implicites, le code ne les gérera pas.

Ce n'est pas de la mauvaise volonté. C'est une conséquence mécanique du mode de travail. Un corpus de freelances travaillant en parallèle, chacun sur son périmètre, va produire des briques qui fonctionnent individuellement mais qui ne s'articulent pas sur les cas d'interface. Les règles implicites, justement, vivent aux interfaces entre processus.

Chez BKW Énergie France, une ETI filiale d'un groupe suisse, une tentative avec des freelances en 2025 avait laissé les projets partir dans toutes les directions. Pas parce que les développeurs étaient incompétents. Parce que personne n'avait pris le temps de cartographier les règles métier implicites du secteur de l'énergie avant de coder. Les scénarios non nominaux, nombreux dans ce métier (soutirage/injection, règles Énédis, TURPE), ont généré des reprises continuelles. Le projet a stagné.

Pour aller plus loin sur la distinction entre diagnostic et simple audit : pourquoi le diagnostic SI est un livrable à part entière, pas une prestation gratuite.

Sortir les règles : une phase à part entière

Documenter les règles métier implicites est une phase de projet à part entière.Ce n'est pas une réunion de lancement, ce n'est pas une série de formulaires à remplir. C'est un travail de terrain structuré, avec des méthodes spécifiques pour faire émerger ce que les équipes savent sans le savoir.

Ce travail se déroule en trois temps distincts. D'abord, les entretiens terrain : on interviewe les opérationnels dans leur quotidien, pas dans une réunion de spécification. On leur demande de décrire leur journée type, les cas qui « coinçent », les exceptions qu'ils gèrent « de tête ». On observe les outils utilisés, y compris les workarounds.

Ensuite, la modélisation : les règles collectées sont formalisées en BPMN (notation de modélisation de processus métier) ou sous forme de tableaux de décision, selon leur nature. L'objectif est un livrable que les développeurs peuvent exploiter directement, sans interprétation.

Enfin, la validation : chaque règle formalisée est relue par les équipes terrain qui l'appliquent. C'est à cette étape que les règles manquantes émergent, par réaction à ce qui est écrit. Les équipes ne voient pas toujours ce qu'elles savent, mais elles voient immédiatement ce qui manque ou ce qui est inexact.

Ce que ça change dans la pratique

Quand les règles métier implicites ont été documentées avant le développement, le projet change de nature. Les allers-retours ne portent plus sur « vous avez oublié de gérer le cas X », ils portent sur des arbitrages fonctionnels qui méritent une décision. C'est un dialogue différent, plus productif, qui consomme moins de budget.

Chez BKW Énergie France, après la phase de documentation des règles et la modélisation BPMN des processus cibles, le développement a pu avancer sans les allers-retours chroniques de l'année précédente. L'audit interne du groupe suisse conduit en 2026 a validé la qualité du travail : en net progrès sur l'audit précédent, les équipes du cabinet ont salué la documentation et la méthode. Pour un projet SI qui impacte la production quotidienne d'une ETI, c'est un résultat qui se mesure en risques évités.

La documentation des règles métier est aussi un actif en soi. Elle réduit la dépendance aux personnes-clés, facilite l'intégration des nouveaux collaborateurs et prépare les évolutions futures du SI. C'est rarement présenté comme un livrable facturé à part, et c'est là que réside l'erreur de beaucoup de projets.

Si vous anticipez une évolution de votre SI dans les douze mois, commencez par identifier les trois processus les plus critiques de votre organisation et demandez à chaque responsable concerné d'écrire les cinq exceptions qu'il gère chaque semaine sans que cela soit formalisé. Vous verrez ce qui ressort.

Pour comprendre les enjeux d'une migration SI sans rupture de service : migrer son ERP en PME sans big bang, la méthode progressive.