Une règle déterminante peut se cacher dans une formule Excel, l’objet d’un email, la couleur d’une cellule ou l’ordre dans lequel une collaboratrice ouvre trois écrans. Lorsqu’elle part en congé, les dossiers restent soudainement bloqués sans qu’aucune spécification ne semble manquer.
Le problème n’est pas seulement documentaire. Le risque est de reconstruire le workflow officiel, puis de découvrir en recette que les cas rentables, sensibles ou urgents suivaient une décision différente. Le projet accumule alors reprises manuelles, exceptions tardives et perte de confiance.
Vous allez comprendre comment collecter des indices limités, formuler une règle réfutable, chercher ses contre-exemples, arbitrer son autorité et la convertir en table de décision testable. La méthode distingue une politique légitime d’un contournement hérité ou d’une préférence individuelle.
Une équipe de développement web sur mesure doit protéger cette connaissance avant de choisir l’architecture. La page application métier sur mesure porte le résultat : des états, droits, validations et reprises qui correspondent aux décisions réellement assumées.
Comprendre pourquoi les règles métier restent tacites
Le système officiel ne couvre pas toute la décision
Un ERP ou un CRM stocke les statuts, mais pas toujours le raisonnement qui a produit le statut. L’utilisateur complète ce manque par une recherche dans un fichier, une question à un collègue ou une comparaison avec un dossier ancien.
Ce savoir devient tacite lorsqu’il fonctionne assez souvent pour ne plus être expliqué. Les nouveaux arrivants apprennent par imitation ; la procédure décrit le résultat attendu, tandis que les critères de choix restent portés par l’équipe.
Les changements empilent des couches
Une règle réglementaire peut être remplacée sans supprimer le contrôle historique. Une remise commerciale temporaire peut devenir permanente dans un tableur. Une limitation technique du legacy peut être interprétée comme une politique métier alors que sa cause a disparu.
L’archéologie ne cherche donc pas à reproduire tout ce qui existe. Elle reconstitue origine, intention, périmètre et autorité afin de décider ce qui doit être conservé, corrigé, simplifié ou explicitement abandonné.
Classer une règle, un usage, une préférence et un contournement
| Type d’indice | Question de qualification | Traitement avant développement |
|---|---|---|
| Règle obligatoire | Quelle politique, obligation ou décision de direction l’impose ? | Formaliser, tester et tracer son application. |
| Règle de gestion | Quel résultat économique ou opérationnel protège-t-elle ? | Mesurer son effet et nommer son owner. |
| Usage efficace | Produit-il un gain sans contredire la politique ? | Évaluer son intégration dans le futur outil. |
| Préférence locale | Le résultat changerait-il avec une autre personne ? | Ne pas la coder sans arbitrage collectif. |
| Contournement | Compense-t-il une limite technique ou organisationnelle ? | Supprimer la cause ou encadrer la reprise. |
Le même geste peut changer de catégorie selon le contexte. Demander un second accord peut être une obligation au-delà d’un montant, une prudence personnelle ou la réponse à un contrôle défaillant. Seule la preuve de l’intention permet de trancher.
Chaque indice conserve un statut provisoire. « Observé » signifie que le comportement existe ; « approuvé » signifie qu’une autorité l’assume pour le futur. Entre les deux, le développement ne doit pas transformer l’habitude en automatisme.
Choisir les sources de preuve sans confondre fréquence et légitimité
Les sources comprennent dossiers terminés, exports, versions de fichiers, modèles d’emails, tickets, journaux applicatifs, règles du legacy, procédures, entretiens et observation du poste. Chaque source montre une facette ; aucune ne reçoit seule le statut de vérité.
Une formule répétée dans mille lignes prouve une pratique fréquente, pas son autorité. À l’inverse, une clause contractuelle rarement activée peut gouverner un cas critique. Le registre distingue fréquence, gravité et force normative.
Établir une chaîne de preuve
Chaque indice reçoit source_id, case_id, date, action, acteur, état avant, état après et référence consultable selon les droits. Une citation ou une capture reste liée au dossier pseudonymisé et à la question qu’elle étaye.
Le propriétaire de collecte documente entrées, sorties, dépendances, durée de conservation et qualité. Un fichier déplacé ou une exportation partielle déclenche une alerte ; il ne laisse pas l’analyste conclure sur un échantillon devenu incomplet.
Échantillonner des dossiers contradictoires plutôt que moyens
Un échantillon utile juxtapose dossiers acceptés, refusés, bloqués, corrigés, urgents, rentables, déficitaires et réouverts. Il couvre périodes, équipes, segments clients et personnes afin de révéler les variations qui disparaissent dans le chemin nominal.
La taille n’est pas fixée par une promesse statistique générique. Elle augmente jusqu’à ce que les nouveaux dossiers n’ajoutent plus de branche significative ou qu’une population rare exige un traitement dédié.
Partir du résultat puis remonter la décision
Pour chaque dossier, l’équipe demande quel événement a changé le statut, quelles données étaient connues, quelle personne pouvait agir, quel critère a été appliqué et quelle preuve a permis de clore. Cette reconstruction limite les souvenirs reconstruits après coup.
Deux dossiers presque identiques mais décidés différemment sont prioritaires. Ils révèlent une variable cachée, un changement de règle, une erreur ou une latitude humaine que le futur outil devra représenter explicitement.
Observer les décisions plutôt que recueillir seulement les discours
L’entretien commence par un cas réel : « montrez la dernière fois où vous avez hésité ». La personne ouvre ses écrans, explique les recherches, les appels et les vérifications. L’analyste note les décisions et leurs entrées, pas seulement la séquence de clics.
Les formulations « normalement », « sauf si », « on demande à », « je vérifie toujours » et « cela dépend » signalent une branche possible. Elles deviennent des questions à éprouver sur d’autres dossiers, jamais des exigences prêtes à coder.
Repérer les artefacts qui font office d’interface
Une colonne déplacée en tête d’un tableur peut porter la priorité. Une couleur peut signifier que le dossier a déjà été contesté. Un objet d’email peut router le travail. L’usage de l’artefact compte davantage que son format.
Le signal faible est une vérification que la personne effectue sans la mentionner, puis recommence sur chaque dossier sensible. Avant que ce geste ne se perde, l’observateur demande ce qui arriverait s’il était omis et cherche un cas où il a changé la décision.
Minimiser les données consultées pendant l’enquête
Explorer des emails ou des dossiers peut exposer identités, opinions, données financières ou informations sensibles sans rapport avec la règle. La finalité, le périmètre, la base d’accès, les personnes autorisées et la durée doivent être définis avant la collecte.
La CNIL rappelle le principe de minimisation : seules les données adéquates, pertinentes et nécessaires à la finalité doivent être traitées. L’archéologie ne justifie donc pas une aspiration générale des messageries.
Collecter la décision, pas la conversation entière
L’équipe privilégie un échantillon fourni par les personnes habilitées, puis extrait date, type de cas, déclencheur, décision et justification en pseudonymisant les acteurs. Le message brut reste dans sa source avec des droits existants.
Un registre précise qui peut voir la preuve, quand elle sera supprimée et comment une synthèse sera conservée. La procédure de purge est journalisée ; les copies locales et captures non nécessaires sont interdites.
Construire une fiche de règle réfutable
La fiche formule une phrase conditionnelle : si les entrées vérifiables sont réunies, alors une décision produit un résultat et une trace. Elle nomme le périmètre, les exclusions, l’owner, la date d’effet, la source d’autorité et le niveau de confiance.
Elle associe au moins un cas positif, un cas négatif et une frontière. Les exemples sont référencés par case_id pseudonymisé ; ils permettent aux métiers, à la QA et au backend de discuter de la même règle.
Séparer fait, hypothèse et décision
« Douze dossiers ont reçu un second accord » est un fait observé. « Le montant déclenche ce contrôle » est une hypothèse. « À partir de la prochaine version, le montant et le risque déclenchent ce contrôle » est une règle approuvée.
Le registre conserve ces trois colonnes et leur auteur. Une hypothèse non arbitrée ne rejoint ni les critères d’acceptation, ni la base de données, ni le code Symfony. Elle reste dans la file de questions avec une date de revue.
Chercher les contre-exemples avant de généraliser
Pour réfuter une règle, l’équipe cherche un dossier qui satisfait la condition sans produire la décision, puis l’inverse. Elle varie une donnée à la fois : montant, segment, territoire, ancienneté, urgence, rôle ou période.
Le contre-exemple peut révéler une entrée manquante, une exception, un changement de politique ou une erreur humaine. Il ne doit pas être absorbé immédiatement par une clause supplémentaire, sous peine de recréer toute l’histoire dans une règle illisible.
Utiliser des questions de frontière
L’atelier demande ce qui se passe juste sous et juste au-dessus d’un seuil, lorsque la donnée manque ou lorsque deux conditions se contredisent. Il vérifie aussi qui peut forcer la décision et quelle justification devient obligatoire.
Contre-intuitivement, une règle qui couvre moins de cas peut être meilleure si elle rend la frontière explicable. Les exceptions restantes passent dans une file humaine tracée plutôt que dans une formule opaque qui prétend tout décider.
Arbitrer des règles contradictoires avec l’autorité compétente
Deux équipes peuvent appliquer des seuils différents parce qu’elles optimisent marge, risque ou délai. L’analyste ne choisit pas la version la plus fréquente ; il expose l’effet de chaque règle et convoque l’owner capable d’assumer l’arbitrage.
La matrice rapproche règle A, règle B, population touchée, coût, risque, source d’autorité et date. Le verdict peut conserver deux politiques si les segments diffèrent réellement, ou imposer une règle commune avec transition.
Versionner les périodes de validité
Une décision ancienne peut être correcte pour son époque. La règle possède valid_from et valid_to ; les dossiers historiques restent expliqués par la version applicable, tandis que le futur workflow utilise la version active.
Le journal d’arbitrage conserve participants, options refusées, impacts et condition de réouverture. Si une règle dégrade le délai ou la qualité au-delà du seuil retenu, alors le rollback réactive la version précédente pendant une nouvelle revue.
Passer de l’hypothèse à une table de décision
La table aligne entrées, valeurs, priorités, résultat et règle de couverture. Elle montre les combinaisons absentes et les chevauchements. Chaque ligne renvoie aux cas qui la prouvent et au propriétaire qui l’a approuvée.
La notation DMN de l’Object Management Group fournit une base lisible pour spécifier décisions et règles métier. Elle peut compléter BPMN ou CMMN sans obliger toute organisation à rendre immédiatement la table exécutable.
Choisir le bon niveau d’exécution
Une politique stable et déterministe peut rejoindre un service de décision. Une appréciation rare, sensible ou encore disputée reste assistée par l’outil métier avec justification et droits de dérogation.
Le frontend affiche les entrées et l’explication ; le backend applique la version de règle, journalise résultat et override, puis expose les événements nécessaires à l’observabilité. L’architecture garde ainsi la décision testable sans la cacher dans l’interface.
Relier chaque règle au workflow, aux droits et aux preuves
Une règle intervient avant une transition, après un événement ou pendant une validation. Elle doit nommer l’état source, l’état cible, l’acteur autorisé, les données requises, les effets secondaires et la preuve créée.
Les droits distinguent calculer, consulter, confirmer, déroger et annuler. Un manager peut autoriser une exception sans pouvoir modifier la table ; un administrateur technique peut déployer la configuration sans recevoir le droit métier de valider un dossier.
Prévoir attente, erreur et reprise
Si une dépendance ERP ou API manque, le workflow passe en attente avec cause et délai, pas en refus implicite. Le worker peut rejouer l’intégration avec idempotence, tandis que l’utilisateur voit l’état et la prochaine action attendue.
Le runbook couvre dépendance indisponible, donnée incohérente, table non chargée et erreur de version. Il précise owner, alerte, correction, journalisation et repli afin qu’une règle correcte ne crée pas un blocage opérationnel.
Transformer les cas réels en tests de non-régression
Les dossiers pseudonymisés deviennent des fixtures couvrant règle nominale, frontières, valeur manquante, conflit et dérogation. Le résultat attendu inclut décision, version, justification, transition et événements émis.
Les tests unitaires vérifient la table ; les tests d’intégration contrôlent base, API et workflow ; la QA rejoue les parcours complets avec droits. Une migration de règle échoue si elle change un cas protégé sans approbation explicite.
Mesurer les écarts après déploiement
L’observabilité compare décisions automatiques, dérogations, retours arrière et dossiers bloqués par version. Une hausse des overrides peut révéler une population absente du cadrage, une règle trop stricte ou une formation incomplète.
Le monitoring n’évalue pas la personne qui déroge ; il évalue la qualité de la règle et de l’outil. Les données sont agrégées selon les droits et la finalité définis, avec une durée de conservation bornée.
Résoudre un cas concret de validation commerciale
Exemple concret : la remise qui semblait dépendre du montant
La procédure indique qu’une remise supérieure à dix pour cent exige une validation de direction. Le fichier montre pourtant des remises à douze pour cent validées par les responsables de compte, et l’équipe affirme que « certains clients sont autonomes ».
L’échantillon contradictoire révèle trois variables : marge résiduelle, segment contractuel et présence d’un engagement annuel. Le pourcentage seul n’était qu’un raccourci visible ; la décision protégeait en réalité une marge minimale selon le contrat.
Arbitrer, tester et déployer par palier
La direction approuve une table avec segment, marge après remise, engagement et rôle. Les anciens comptes sans segment passent en revue humaine. Quatre dossiers frontières deviennent des tests et chaque dérogation exige un motif.
Par exemple, si plus de 8 % des devis du pilote demandent une dérogation après deux semaines, alors le déploiement reste limité et l’équipe analyse les motifs. Si le taux reste sous 3 % sans baisse de marge ni délai supplémentaire, elle élargit ; sinon le rollback réactive l’ancien circuit.
Pour qui et dans quels cas mener cette archéologie
La démarche réunit responsables métier, produit, développeurs, QA, data, sécurité et personnes qui traitent réellement les dossiers. Elle est prioritaire avant une application métier, une migration legacy, une automatisation, le départ d’un sachant ou une fusion d’équipes.
Elle convient aux processus de validation, tarification, éligibilité, conformité, allocation, support et reprise. Elle est moins utile lorsqu’une règle simple, récente, écrite et testée possède déjà une autorité clairement identifiée.
Il faut agir lorsque les mêmes dossiers produisent des décisions différentes, que les équipes consultent des fichiers latéraux ou que la recette découvre sans cesse de nouvelles exceptions. Il faut différer l’automatisation si personne ne peut arbitrer la règle future.
Une petite équipe peut commencer par dix dossiers contradictoires et cinq fiches. La valeur vient de la réfutation et de l’autorité, pas d’un inventaire massif de toutes les habitudes de travail.
Éviter les erreurs fréquentes de l’extraction métier
Croire la personne la plus expérimentée sans éprouver
Erreur fréquente : transformer le récit du sachant en spécification. Son expérience est essentielle, mais elle peut mélanger plusieurs versions, exceptions et préférences que seuls les cas réels permettent de séparer.
Autre erreur : coder tout contournement observé sans vérifier sa cause. Certains compensent une limite technique qui disparaîtra ; les reproduire transfère la dette fonctionnelle et ses coûts de support dans le nouveau socle.
Collecter trop de données et décider trop tard
Erreur de méthode : aspirer fichiers et emails avant de définir les questions. L’équipe augmente le risque de confidentialité, le bruit et le coût d’analyse sans améliorer la preuve.
Erreur de gouvernance : accumuler des hypothèses sans owner ni échéance. Le développement commence alors avec des ambiguïtés maquillées en tickets, puis les arbitrages arrivent lorsque le code coûte déjà cher à modifier.
Plan d’action : expliciter les règles en quatre semaines
Semaine 1 : cadrer et échantillonner
Produit et métier choisissent deux décisions critiques, la finalité, les sources autorisées et les owners. Ils sélectionnent dossiers normaux, contradictoires, bloqués et dérogés, puis pseudonymisent les références de travail.
L’équipe définit registre d’indices, droits d’accès, durée de conservation et critères de sortie. Le projet ne collecte aucune messagerie complète ; il demande les cas utiles à la question formulée.
Semaine 2 : observer et réfuter
Les ateliers rejouent les dossiers et remplissent les fiches de règle. Chaque hypothèse reçoit cas positif, cas négatif, frontière, origine, confiance et question ouverte.
Une seconde personne cherche les contre-exemples. Les contradictions rejoignent une matrice avec impact, autorité et options ; elles ne sont pas résolues par une moyenne des pratiques.
Semaine 3 : arbitrer et modéliser
Les owners approuvent, modifient ou abandonnent les hypothèses. Les règles stables deviennent tables de décision ; les jugements restants deviennent files humaines avec droits, justification et seuil de revue.
Développeurs et QA relient chaque ligne à état, API, données, effets secondaires, fixture et observabilité. Les erreurs et dépendances reçoivent un comportement de reprise avant le premier déploiement.
Semaine 4 : piloter et mesurer
Un périmètre limité utilise la nouvelle règle. L’équipe compare décisions, dérogations, temps de traitement et qualité, puis examine tout écart avec la preuve et la version applicables.
La revue décide élargissement, correction ou rollback selon les seuils convenus. Les indices personnels inutiles sont supprimés ; seuls registre, décisions approuvées, cas pseudonymisés et journal d’arbitrage restent conservés.
- À faire d’abord : choisir les décisions qui changent réellement coût, risque, délai ou qualité, puis borner les sources nécessaires à leur compréhension.
- Ensuite : confronter discours et dossiers contradictoires afin de séparer faits observés, hypothèses, préférences et règles officiellement assumées.
- Puis : attribuer chaque contradiction à un owner et convertir seulement les décisions arbitrées en tables, workflows, droits et tests.
- À valider enfin : déployer par palier avec seuils de dérogation, observabilité, procédure de repli et suppression des données de travail inutiles.
Guides complémentaires sur le processus métier réel
Les règles tacites prennent place dans une carte du processus, un inventaire d’exceptions et une décision explicite sur les contournements qui méritent ou non de survivre au changement d’outil.
Cartographier les événements et les états
La cartographie du processus avant application métier relie événements, états, décisions, attentes, preuves, responsabilités et coût complet pour chaque population de dossiers étudiée pendant le cadrage.
Elle fournit le contexte dans lequel chaque fiche de règle peut être positionnée sans confondre décision, transition, tâche, délai d’attente, reprise et effet secondaire technique produit dans le système.
Chiffrer les exceptions avant automatisation
L’inventaire des exceptions métier mesure fréquence, gravité, preuve, délai et coût complet afin de choisir suppression, assistance, automatisation ou contrôle humain selon un arbitrage documenté.
Il évite qu’un contre-exemple rare mais grave soit noyé dans le taux de couverture d’une règle nominale apparemment performante et protège les populations qui exigent un traitement spécifique.
Décider du sort des contournements
La méthode pour traiter les contournements humains avant migration aide à supprimer, encadrer ou transformer les pratiques latérales observées avant qu’elles contaminent la conception du nouveau produit.
Elle complète l’archéologie lorsque tableurs, validations orales et reprises manuelles compensent les limites de l’outil actuel plutôt qu’une règle métier durable, légitime et assumée par sa direction.
- À conserver : une règle prouvée, arbitrée, versionnée, expliquée et associée à un owner qui assume ses effets.
- À assister : une décision rare ou sensible dont les entrées peuvent être préparées sans retirer le jugement humain.
- À refuser : toute habitude reproduite dans le code uniquement parce qu’elle est fréquente ou portée par la personne la plus expérimentée.
Conclusion : coder une décision prouvée plutôt qu’une habitude
Les fichiers, emails et gestes d’équipe contiennent des indices précieux, mais ils ne constituent pas automatiquement la règle future. Leur fréquence prouve un usage ; seule l’autorité compétente peut en assumer la légitimité.
L’archéologie transforme ces indices en hypothèses réfutables, cherche les dossiers qui les contredisent et conserve l’origine de chaque arbitrage. Elle réduit ainsi les surprises de recette sans sanctuariser la dette historique.
Une règle approuvée devient table, droits, workflow, tests et observabilité. Une appréciation encore fragile reste humaine, visible et révisable au lieu d’être cachée dans une condition backend.
Dawap vous accompagne pour cadrer ces décisions et construire une application web sur mesure dont le code reste relié aux preuves métier, aux owners et aux tests qui autorisent chaque évolution future.
