Vous devez remplacer un système hérité et personne ne sait comment il fonctionne. Comment abordez-vous ça ?

Reconstituez le comportement à partir de trois sources : les données qu'il produit, les gens qui l'utilisent, et le code ou le paramétrage si quelqu'un sait encore les lire. Travaillez à rebours depuis les sorties, parce que ce sont les sorties qui constituent les vraies exigences. Attendez-vous à des règles non documentées, consignez chacune de celles que vous trouvez, et prévoyez une période de fonctionnement en parallèle pour attraper celles que vous avez ratées.

Je travaille à rebours depuis les sorties, parce que ce qu'il produit est ce dont le métier dépend vraiment, et la logique interne n'est intéressante que là où elle change une sortie. Je récupère donc des échantillons de tout ce qu'il émet, rapports, fichiers, interfaces, et je remonte ce qui doit être vrai pour chacun. En parallèle je parle à ceux qui l'utilisent depuis le plus longtemps et je les interroge spécifiquement sur les cas bizarres, parce que c'est là que vivent les règles cachées. Si quelqu'un sait encore lire le code ou le paramétrage, c'est la troisième source et elle tranche les disputes. Sur un remplacement, on a trouvé une règle d'arrondi enfouie dans une procédure stockée dont personne de vivant n'avait connaissance, et elle affectait environ un cinquième des transactions d'un petit montant que la finance rapprochait à la main depuis des années. Ce sur quoi j'insiste, c'est le fonctionnement en parallèle, parce qu'on ne trouve jamais toutes les règles, et le rapprochement avec l'ancien système est la façon de trouver celles qu'on a ratées avant que les clients ne le fassent.