La connaissance de l'ancien système après sa réécriture

Les personnes qui comprennent un ancien système ne sont pas un désagrément temporaire sur la route d'un code plus propre. Elles font partie de son modèle de fonctionnement actuel. Une réécriture qui ignore leur savoir peut reproduire chaque écran visible et échouer dès le premier remboursement inhabituel, ajustement de fin de trimestre ou redémarrage de traitement par lots.

Le bon objectif n'est pas de « télécharger » le cerveau de quelqu'un avant son départ à la retraite. Il faut transformer les affirmations sur le comportement en preuves qu'une autre personne peut examiner : exemples, tests, comptes rendus de décision, procédures d'exploitation et incertitudes nommées. Ce travail donne aussi aux experts un rôle crédible après la bascule. Considérez-les comme des témoins et des réviseurs, pas comme des obstacles ou des spécifications humaines.

L'ancien système comprend aussi ses utilisateurs

La connaissance d'un ancien système se trouve à plusieurs endroits. Une partie réside dans le code source et les définitions de jobs. Une autre apparaît dans les données de production, les manuels d'exploitation, l'historique des tickets et les feuilles de rapprochement. Le reste vit dans la tête de ceux qui savent que le statut client 7 change de sens avant la clôture mensuelle, ou qu'un lot en échec doit repartir du troisième point de contrôle parce que les deux premières étapes ne sont pas idempotentes.

Appeler tout cela « savoir tribal » est trop vague pour être utile. Je le sépare en quatre catégories, car chacune exige des preuves différentes :

• Règles métier : le résultat voulu par l'organisation dans un cas donné.
• Comportement observé : ce que fait réellement le système actuel, y compris les défauts dont dépendent certains appelants.
• Pratique opérationnelle : la façon dont les personnes planifient, rétablissent, rapprochent et contournent le système.
• Justification historique : la raison d'être d'une règle, d'une table ou d'un contournement, et ce qui pourrait casser en cas de suppression.

Ces catégories se contredisent souvent. Un expert métier peut décrire la règle approuvée alors que la production suit une ancienne exception. Un opérateur peut connaître une procédure de reprise sûre qu'aucun développeur ne connaît. Une responsable financière peut qualifier un écart d'arrondi de bug alors qu'un rapport en aval en dépend. L'équipe de réécriture doit conserver cette distinction assez longtemps pour obtenir une décision explicite.

Voilà pourquoi un organigramme cartographie mal la connaissance du système. La personne la mieux informée peut être un analyste du support capable de prédire quelle entrée bloquera le traitement nocturne, ou un ancien développeur désormais affecté à l'exploitation. Partez des événements du système, pas des titres : qui appelle-t-on quand la facturation échoue, qui valide le rapprochement, qui comprend les enregistrements rejetés, et qui sait pourquoi un export apparemment inutilisé tourne encore ?

Les personnes peuvent aussi se tromper. Leur expertise mérite le respect, mais un souvenir n'est pas une preuve. Les connaisseurs de l'ancien système fournissent des hypothèses, des exemples et du contexte. Les tests et les traces transforment ces contributions en éléments fiables pour la migration.

Les entretiens ont besoin de cas, pas de visites guidées

Le moyen le plus rapide de gaspiller le temps d'un expert consiste à demander : « Comment fonctionne le système ? » Vous obtiendrez une visite des menus et du parcours nominal. Aucun des deux ne révèle les conditions à l'origine des dix derniers incidents de production.

Organisez les entretiens autour de cas concrets. Demandez à la personne d'apporter une transaction terminée, une transaction rejetée, un ajustement manuel, un redémarrage et une sortie ayant nécessité un rapprochement. Faites-lui rejouer ce qu'elle a vu, ce qu'elle attendait, ce qu'elle a changé et comment elle a déterminé que le résultat était acceptable. Les enregistrements d'écran peuvent aider, mais le dossier écrit doit saisir les entrées et les décisions, pas seulement les clics.

Pendant ces séances, j'utilise un petit registre d'affirmations. Chaque ligne contient une affirmation, une source, un exemple représentatif, un contrôle proposé, un responsable et un niveau de confiance. Une ligne pourrait indiquer : « Un compte suspendu peut recevoir un crédit, mais pas un débit », avec le responsable du recouvrement comme source, deux identifiants de transaction et un test de limite proposé. Une autre : « Les opérateurs relancent JOB17 à STEP30 après un délai dépassé », avec l'opérateur de nuit comme source, le journal d'exécution correspondant et un test de reprise encore manquant.

Le champ de confiance empêche une conversation polie de devenir une fausse certitude. Utilisez des libellés simples : confirmé par le trafic, confirmé par un test reproductible, soutenu par deux personnes, souvenir unique et contesté. La confiance décrit les preuves, pas l'ancienneté.

Posez les questions gênantes. Que faites-vous hors du système ? À quels champs ne faites-vous jamais confiance ? Que vérifiez-vous avant d'approuver le résultat ? Quel message d'erreur signifie « réessayer » alors qu'il paraît fatal ? Que s'est-il passé lors de la dernière modification de cette règle ? Qui conteste votre version ? Ces questions font apparaître les feuilles de calcul parallèles, les accords téléphoniques et les contrôles compensatoires invisibles à l'analyse du code.

Gardez des séances assez courtes pour préserver la précision des experts. Renvoyez les affirmations pour correction sous un ou deux jours, tant que les exemples restent frais. Une transcription est une matière première, pas une documentation. Quelqu'un doit résoudre les noms, joindre les preuves et séparer les affirmations composites avant que la séance ne produise des éléments de migration.

Séparer l'intention de la compatibilité

Une réécriture doit distinguer la politique voulue du comportement de compatibilité, car préserver l'un ou l'autre par accident réserve des surprises coûteuses. Les équipes confondent régulièrement « le métier veut ceci » et « l'ancien programme fait ceci ». Ces phrases peuvent indiquer des directions opposées.

Pour chaque comportement important, consignez trois réponses : ce que fait l'ancien système, ce que l'organisation souhaite après la réécriture et ce qu'attendent les appelants ou rapports existants. Attribuez ensuite un sort. Conserver signifie que le nouveau système doit correspondre. Corriger signifie qu'il diffère volontairement et qu'une attente approuvée est nécessaire. Retirer signifie que le comportement et ses consommateurs disparaissent ensemble. Inconnu signifie que la bascule ne peut pas encore en dépendre sans risque.

Prenons un programme de facturation qui arrondit chaque ligne avant de calculer le total. La règle écrite demande d'additionner les lignes non arrondies, puis d'arrondir le total. Les clients ont peut-être reçu pendant des années des factures arrondies ligne par ligne, tandis qu'un import comptable attend les centimes qui en résultent. « Corriger » le calcul dans la réécriture peut casser le rapprochement, même si la nouvelle réponse est mathématiquement préférable.

La décision ne peut pas rester cachée dans la pull request d'un développeur. La finance doit choisir entre conserver le résultat, adapter l'interface comptable ou introduire la règle corrigée à une limite déclarée. La suite de parité encode ensuite le résultat choisi. La documentation explique pourquoi les anciens et nouveaux résultats diffèrent. Le support reçoit un exemple qu'il peut reconnaître.

Dans Working Effectively with Legacy Code, Michael Feathers utilise les tests pour placer le comportement existant sous contrôle avant de le modifier. Cette idée dépasse le code source. Un test de caractérisation indique ce qui se produit maintenant. Il ne déclare pas ce comportement correct. La gouvernance de la migration commence là où la caractérisation s'arrête : une personne habilitée décide ce qui devient un contrat.

Cette distinction évite aussi de faire porter une responsabilité injuste aux experts. La personne qui se souvient d'un contournement ne devrait pas décider seule s'il doit survivre. Son rôle consiste à exposer le comportement et ses conséquences. Les responsables métier et techniques désignés décident de son avenir par écrit.

Transformer les affirmations en exemples exécutables

Une connaissance devient durable lorsqu'une affirmation peut faire échouer un test. La prose reste utile, mais elle laisse deux lecteurs imaginer des conditions limites différentes.

Écrivez les exemples à la frontière du système chaque fois que possible. Saisissez la plus petite entrée qui déclenche la règle, l'état initial pertinent, les sorties attendues et les effets secondaires autorisés. Évitez les tests qui vérifient les séquences d'appels internes de l'ancienne implémentation. Ils préservent la structure au lieu du comportement et pénalisent toute modernisation sincère.

Un enregistrement de comportement peut rester assez simple pour qu'un expert le révise :

{
  "case": "credit_on_suspended_account",
  "starting_state": {"status": "suspended", "balance": 12500},
  "input": {"type": "credit", "amount": 2500},
  "expected": {
    "accepted": true,
    "balance": 10000,
    "audit_code": "CR-SUSP"
  },
  "source": "collections_review_14"
}

Les valeurs ont besoin d'une unité et d'un sens. Si 12500 désigne des unités monétaires mineures, précisez-le dans la convention des fixtures. Si les dates utilisent le jour ouvré local plutôt que UTC, encodez cette condition. Beaucoup de prétendus échecs de parité sont en réalité des fixtures ambiguës.

Construisez des familles de tests autour des limites, pas un unique exemple de référence. Pour la règle du compte suspendu, testez un crédit, un débit, zéro, le montant maximal accepté, un changement de statut pendant le traitement et la répétition de la même requête. L'expert connaît souvent les cas qui ont déjà causé des problèmes. L'ingénieur sait où les limites de l'implémentation peuvent fuir. Les deux points de vue appartiennent à la suite.

Consignez séparément l'ancien résultat et le résultat approuvé lorsqu'ils diffèrent. Un bon banc de test peut signaler MATCH, APPROVED_DIFFERENCE, UNEXPLAINED_DIFFERENCE ou NOT_COMPARABLE. Un verdict binaire incite les équipes à approuver des changements inexpliqués pour faire passer un tableau de bord au vert.

CodeHero utilise un banc de parité sur du trafic de production enregistré tout en modernisant l'architecture au lieu de transposer l'ancien code. La même discipline doit encadrer le savoir des experts : chaque souvenir important exige un cas rejouable, une décision approuvée ou un statut non résolu visible.

Le trafic de production a des angles morts

Le trafic de production enregistré constitue la meilleure source sur les comportements fréquents, mais il ne contient pas toutes les règles que la réécriture doit préserver. Il montre ce qui s'est produit pendant la période de capture. Il dit peu des rares parcours de fin d'année, de la reprise après sinistre, des fonctions d'urgence inutilisées, des entrées rejetées en amont ou des événements réparés manuellement avant leur enregistrement.

Considérez le trafic et le témoignage des experts comme complémentaires. Rejouez d'abord les requêtes capturées dans les anciens et nouveaux systèmes, puis comparez les résultats visibles de l'extérieur. Regroupez les différences par point d'accès, type de transaction, champ de sortie et classe d'erreur. Montrez ensuite des groupes représentatifs aux personnes qui exploitent ou possèdent ces flux. Elles repèrent un écart d'horodatage bénin, un défaut connu ou une règle absente bien plus vite qu'une équipe lisant des différences brutes.

Le trafic a besoin de contexte pour devenir un corpus de test stable. Masquez ou tokenisez les valeurs sensibles tout en préservant leurs relations. Figez les données de référence qui changeraient entre deux exécutions. Consignez les hypothèses d'horloge, la locale, les règles d'ordre et les réponses fournies par les dépendances. Gardez l'identifiant de capture d'origine afin qu'un enquêteur puisse suivre un cas en échec sans copier de données de production dans un ticket.

Méfiez-vous de l'échantillonnage. Un point d'accès très actif peut submerger le corpus, tandis qu'une transaction rare aux fortes conséquences n'apparaît qu'une fois. Mesurez la couverture par événement métier et par risque, pas seulement par nombre de requêtes. Demandez aux experts quels événements doivent apparaître même si aucune capture récente ne les contient. Construisez ensuite des cas synthétiques à partir d'un exemple approuvé et exécutez-les sur l'ancien système lorsque cela reste sûr.

Le rejeu du trafic ne dispense pas de décider quelles sorties comptent. Une comparaison octet par octet signalera les identifiants générés, horodatages, ordres et différences de format sans conséquence. Une normalisation excessive peut masquer une écriture comptable manquante. Nommez les champs observables et les tolérances de chaque classe de transaction. Un expert doit pouvoir expliquer pourquoi une différence est ignorée.

Enfin, conservez une quarantaine pour les cas encore impossibles à comparer. Un message peut appeler un partenaire indisponible, dépendre de données de référence expirées ou déclencher une action irréversible. Chaque cas en quarantaine exige un responsable et une raison. Si l'équipe les retire simplement du corpus, l'incertitude disparaît du rapport, pas du système.

La documentation doit expliquer les décisions

Une bonne documentation de migration indique au prochain ingénieur ce que promet le système, où cette promesse est vérifiée et pourquoi une exception existe. Un catalogue d'écrans et de tables vieillit avant la bascule, car il décrit l'ancienne forme plutôt que le nouveau contrat.

Donnez à chaque comportement important un dossier compact. Incluez l'événement métier, les préconditions, les résultats acceptés et rejetés, le responsable officiel, les identifiants des tests, la réponse opérationnelle et l'historique des décisions. Des liens internes au dépôt ou à la documentation peuvent relier ces éléments, mais le contenu doit rester lisible sans ouvrir cinq autres pages.

Les comptes rendus de décision comptent surtout lorsque la parité a été rompue volontairement. Indiquez l'ancien comportement, le comportement retenu, les consommateurs touchés, les approbateurs, la condition de déploiement et le signal de retour. Évitez les entrées vagues telles que « correction du problème de calcul ». Écrivez l'écart exact : « La nouvelle facture arrondit le total une fois ; l'adaptateur comptable ajoute une ligne d'équilibrage aux factures créées avant la date de la règle. »

Les procédures d'exploitation exigent le même soin. Une instruction comme « redémarrer le lot s'il se bloque » est dangereuse. Définissez comment l'opérateur détecte le blocage, quel point de contrôle est sûr, quels effets secondaires dupliqués vérifier, quel rapprochement prouve la fin et quand escalader. Transformez les préconditions sûres en contrôles automatiques quand c'est possible. Gardez les décisions humaines explicites lorsque l'automatisation ne ferait que simuler la certitude.

La propriété de la documentation doit suivre le système. Pendant la migration, l'expert de l'ancien système peut vérifier une règle pendant qu'un ingénieur du nouveau écrit le dossier et le test. Après la bascule, le responsable du service possède les deux. Cette rédaction en binôme évite que l'expert reste le secrétaire permanent d'une plateforme qu'il n'exploite plus.

La recherche compte, mais une immense base de connaissances unique n'est pas la réponse. Gardez le comportement près des tests exécutables, les procédures près du service, et les décisions de politique là où les responsables les examinent. Utilisez des identifiants de cas cohérents dans ces espaces. L'identifiant forme le fil conducteur ; la consolidation forcée crée souvent un cimetière.

Révisez la documentation en tentant une tâche. Donnez un cas en échec à un ingénieur qui n'a pas suivi la migration et demandez-lui d'expliquer le résultat attendu, de localiser le test et de trouver la procédure de reprise. Sa confusion est un défaut documentaire accompagné d'un exemple reproductible.

Les experts ne doivent pas devenir une file d'attente

Les experts de l'ancien système doivent avoir une vraie autorité dans la réécriture, mais attendre une seule personne pour chaque décision transforme le savoir caché en goulot d'étranglement visible. Un protocole de revue doit consacrer leur attention à l'ambiguïté et au risque.

Attribuez à chacun un rôle borné. Il peut posséder les affirmations d'un domaine métier, approuver les exemples représentatifs, classer les écarts de parité ou vérifier une procédure. Précisez quelles décisions il peut prendre et lesquelles exigent un responsable métier, sécurité ou service. Une matrice RACI est facultative ; une voie d'escalade explicite ne l'est pas.

Préparez les éléments avant de demander une revue. N'invitez pas un opérateur à regarder défiler des milliers de résultats. Regroupez les différences, supprimez le bruit connu, choisissez des exemples et formulez la question comme une décision : conserver, corriger, retirer ou enquêter ? Joignez le cas source et la conséquence en aval. Dix minutes de jugement expert remplacent alors des heures d'errance dans les journaux.

Prévoyez deux personnes pour les domaines lourds de conséquences. Associez l'expert de longue date à quelqu'un qui restera responsable après la bascule. La deuxième personne écrit le test ou la procédure, le démontre et traite la prochaine question connexe. L'expert corrige le travail au lieu de dicter chaque phrase. Le transfert de connaissances devient ainsi observable.

Protégez formellement le temps. Une revue de migration ajoutée à une charge opérationnelle complète perdra face au prochain incident, à juste titre. Les managers doivent retirer d'autres tâches, planifier des créneaux de décision et suivre les affirmations sans réponse comme des risques de livraison. Ne mesurez pas la participation au nombre de réunions. Mesurez les affirmations résolues, les exemples approuvés, les différences inexpliquées fermées et les procédures de reprise démontrées.

Surveillez les simulacres d'approbation. Si les réviseurs reçoivent cent pages le vendredi et une demande de signature le lundi, la signature ne prouve rien. De petites revues fondées sur des cas créent une trace utile et font apparaître les désaccords tôt.

Rémunérez les personnes pour le rôle nécessaire au projet et rendez concret leur parcours après la bascule. Certaines deviendront responsables de domaine, analystes produit, opérateurs de service, concepteurs de tests ou responsables de modernisation. D'autres choisiront peut-être de partir. Le respect ne garantit pas leur maintien, mais le mépris garantit presque que les avertissements les plus utiles arriveront tard ou jamais.

Un désaccord signale un risque

Lorsque deux experts décrivent différemment la même règle, ne faites pas la moyenne et ne donnez pas raison au titre le plus élevé. Le désaccord indique souvent une condition cachée : groupes de clients, dates, régions, canaux d'entrée ou états de reprise différents.

Inscrivez les deux affirmations dans le registre et demandez à chacun un cas où sa version s'applique. Comparez ces cas avec les chemins du code, la configuration, l'historique des données, les tickets et le trafic. Il faut trouver le prédicat qui rend les deux récits cohérents, ou prouver que le système se comporte de façon incohérente.

Supposons qu'un opérateur affirme qu'un paiement rejeté peut être rejoué sans danger, tandis qu'un autre annonce des doublons. Leurs procédures peuvent différer parce qu'une file attribue un jeton d'idempotence et qu'un canal plus ancien ne le fait pas. Un test générique « les nouvelles tentatives sont sûres » cacherait précisément la limite que la réécriture doit imposer.

Certains désaccords portent sur la politique, pas sur les faits. Le produit veut une dérogation favorable au client, la conformité un rejet ferme, et l'exploitation applique un compromis manuel. Le code ne résoudra pas ce conflit. Nommez le responsable, montrez les conséquences concrètes et consignez la décision auprès des tests qu'elle modifie.

Le silence constitue aussi une preuve. Une zone sans responsable sûr, trafic récent ni exemple reproductible mérite davantage d'examen. Les équipes la déclarent souvent inutilisée parce que sa suppression simplifie le plan. Vérifiez les planificateurs, journaux d'accès, fichiers générés, imports en aval et procédures calendaires avant de la retirer. Si les preuves restent faibles, isolez la fonction derrière un contrôle de bascule et surveillez sa demande au lieu de feindre la certitude.

Suivez les désaccords non résolus dans les critères de mise en service. Chacun exige un responsable, un périmètre touché, une solution de repli sûre et une échéance. Une migration peut avancer avec une incertitude connue si son rayon d'effet est borné et le retour réel. Elle ne doit pas avancer parce que l'incertitude a disparu de l'ordre du jour.

L'aspect humain compte. Les experts qui craignent d'être tenus responsables de chaque écart aplaniront les contradictions. Examinez le système, pas la mémoire de la personne. Récompensez celui qui apporte un contre-exemple gênant, car cet exemple coûte moins cher avant la bascule qu'après.

L'absence d'expert change la méthode

Si la personne qui connaissait le système est déjà partie, la réécriture reste possible, mais l'équipe doit remplacer les souvenirs par une recherche de preuves plus méthodique. Ne nommez pas l'employé le plus proche expert universel. Vous obtiendrez des réponses assurées de quelqu'un qui n'a vu qu'une partie du système.

Commencez par les traces de décisions. Les tickets d'incident montrent quels échecs comptaient et qui y a participé. Les demandes de changement expliquent l'origine d'une condition. Les journaux de lots et calendriers de planification révèlent le travail lié au temps. Les fichiers de rapprochement indiquent ce qu'un autre service jugeait officiel. Les modèles du support révèlent les messages récurrents. L'historique du code peut identifier les réviseurs d'un module même si son auteur est parti.

Construisez une carte des témoins à partir de ces traces. Un témoin peut connaître une limite étroite : le comptable qui reçoit un export, l'équipe partenaire qui envoie un fichier, l'analyste du support qui reconnaît les doublons, ou l'ingénieur d'infrastructure qui a restauré le dernier lot en échec. Interrogez chacun uniquement sur les événements qu'il a traités directement. Plusieurs récits étroits valent mieux qu'un grand récit emprunté.

Utilisez l'ancien système comme sujet expérimental lorsque la sécurité le permet. Clonez un état proche de la production dans un environnement isolé, changez une entrée à la fois et consignez sorties et effets secondaires. Partez des cas récupérés dans les journaux, puis sondez les limites visibles dans les branches, tables de validation et traitements d'erreur. Ne lancez jamais de transactions exploratoires sur des flux financiers, industriels ou clients actifs simplement parce que la documentation manque.

L'analyse statique peut repérer des règles candidates, mais ne dit pas si une branche correspond à la politique actuelle, à du code mort ou à un ancien défaut attendu par un appelant. Marquez ces règles comme non confirmées jusqu'à ce que le trafic, une exécution reproductible ou un responsable les soutienne. L'absence d'une personne rend les niveaux de confiance plus nécessaires, pas moins.

Adaptez les contrôles de bascule à l'incertitude restante. Un rapport mal compris peut tourner en parallèle pour un ensemble défini d'événements métier. Une transaction rare et irréversible peut exiger une approbation manuelle et une voie de retour. Un export apparemment inutilisé peut rester isolé et surveillé jusqu'au passage de son déclencheur calendaire. Ces contrôles coûtent du temps, mais ils montrent honnêtement le coût.

Parfois, les preuves ne deviennent jamais assez solides. La réponse responsable est une exception bornée avec un propriétaire, une méthode de détection et une procédure de reprise. Inventer la certitude produit un rapport plus propre et un incident plus sale. Un expert absent augmente la charge de la preuve, il ne la supprime pas.

Définissez avant les tests le minimum de preuves requis pour chaque classe de risque afin que la pression des délais n'abaisse pas discrètement le seuil.

La bascule change le poste, pas le besoin de jugement

Après la réécriture, les experts de l'ancien système ne devraient plus être les seuls capables de maintenir l'activité. Leur jugement compte encore, mais il doit passer par des tests, décisions et procédures attribués plutôt que par des appels d'urgence.

Définissez la transition avant la bascule. Listez chaque responsabilité récurrente : approuver les exceptions, rapprocher les sorties, mettre à jour les références, relancer le travail, expliquer les rapports et trier les défauts. Nommez le nouveau responsable, l'élément d'appui, une date de démonstration et la condition de sortie de l'ancien expert. « Connaissances transférées » n'est pas une condition. « Le nouveau responsable a effectué deux rapprochements représentatifs et récupéré un lot en échec pendant une répétition » en est une.

Répétez l'exploitation avec des défaillances réalistes. Coupez une dépendance, injectez un message dupliqué, faites expirer les références et forcez un lot partiel. Les nouveaux responsables doivent diagnostiquer et rétablir le service avec les nouveaux outils d'observation et procédures pendant que l'ancien expert regarde. Chaque indication soufflée devient ensuite un contrôle ou une instruction manquante.

Gardez les experts dans une boucle de revue limitée au début de l'exploitation, avec des voies claires et une date de fin. Ils doivent examiner les nouveaux échecs de parité et les questions de politique, pas approuver éternellement les changements ordinaires. Si chaque incident leur arrive encore, la migration a déplacé le code sans déplacer la propriété.

Conservez l'ancien environnement et ses preuves selon les règles juridiques, opérationnelles et relatives aux données. L'équipe peut devoir reproduire une sortie contestée ou expliquer une transaction historique. Cela ne signifie pas laisser un système sans maintenance connecté sans limite. Définissez l'accès, l'isolation, la conservation des données et l'autorité pour l'exécuter.

Le test final est l'absence. Les nouveaux responsables peuvent-ils gérer une clôture, récupérer une panne, répondre au support et modifier une règle documentée pendant que l'ancien expert reste indisponible ? Sinon, identifiez les preuves manquantes et recommencez la répétition.

Une réécriture réussit quand l'organisation peut expliquer son comportement sans folklore et le modifier sans convoquer une personne précise. Ceux qui ont porté l'ancien système méritent mieux qu'un entretien de cérémonie. Donnez-leur des cas précis à juger, consignez les désaccords qu'ils trouvent et rendez leur savoir exécutable. La nouvelle équipe reçoit alors des preuves plutôt que des histoires, et les experts laissent mieux qu'une astreinte permanente.