Historique de la question : Dans le cadre des initiatives de modernisation des entreprises, les analystes commerciaux rencontrent souvent le déclin des connaissances—un phénomène où la logique commerciale critique survit uniquement dans du code hérité illisible. Cette question est née des migrations mainframe-vers-cloud où les architectes d'origine ont pris leur retraite il y a des décennies, laissant derrière eux des programmes COBOL qui s'exécutent parfaitement mais défient l'interprétation. Le contexte historique implique la transition du traitement par lot monolithique à des microservices distribués, où la gestion d'état implicite doit devenir des contrats API explicites.
Le problème tourne autour de l'opacité épistémique : le système fonctionne, mais personne ne sait pourquoi. La base de code COBOL contient des règles commerciales tacites—des cas particuliers, des correctifs réglementaires, et des surcharges manuelles—qui n'ont jamais été documentées parce que les développeurs d'origine les avaient en mémoire. Le personnel des opérations actuel comprend les entrées et les sorties mais pas la logique décisionnelle. Pendant ce temps, la nouvelle architecture cloud-native nécessite que ces règles soient découplées, documentées, et exposées via des points de terminaison REST pour une consommation en temps réel. La date limite réglementaire fixe empêche une fouille archéologique de plusieurs années, cependant, des erreurs dans l'extraction des règles pourraient violer les mandats de traitement des données GDPR ou l'exactitude des rapports financiers.
La solution emploie une approche de reverse-engineering triangulé. Tout d'abord, mener des ateliers de Event Storming avec le personnel des opérations pour cartographier les comportements commerciaux observables et identifier les processus "black box". Deuxièmement, utiliser des outils d'analyse de code statique pour générer des graphes de flux de contrôle des programmes COBOL, croisent les mutations de variables avec les résultats commerciaux. Troisièmement, mettre en œuvre un mode d'exécution parallèle, où les nouveaux processus de microservices reflètent les transactions contre le système hérité sans impact sur la production, signalant les écarts pour investigation. Cela crée une boucle de rétroaction où l'archéologie du code valide les souvenirs des parties prenantes, et le contexte des parties prenantes explique les anomalies de code.
Une compagnie d'assurance régionale avait besoin de remplacer un moteur de tarification de police COBOL datant des années 1980 par une suite de microservices Python/FastAPI pour permettre des devis mobiles en temps réel. La logique de calcul originale comprenait des pondérations de risque territoriales complexes, des facteurs d'ajustement saisonniers et des clauses de traité de réassurance qui avaient été corrigées en plus de quarante ans. Les trois derniers développeurs COBOL avaient pris leur retraite, et le personnel informatique actuel traitait le système comme une "boîte magique" qui produisait des primes correctes mais ne pouvait pas expliquer les dérivations mathématiques pour des cas particuliers spécifiques. L'autorité réglementaire a imposé l'achèvement de la migration dans les huit mois pour éviter des pénalités d'infrastructure non prises en charge.
Plusieurs approches ont été évaluées pour capturer les besoins. La première option proposait une transcription de code à spécifications, où les développeurs documenteraient manuellement chaque instruction IF et chaque opération MOVE dans le code source COBOL. Les avantages comprenaient une complétude théorique et la préservation de la logique exacte. Les inconvénients étaient sévères : la base de code contenait plus de deux millions de lignes de code spaghetti avec des variables globales non documentées, rendant cela un effort de plusieurs années qui manquerait la date limite et introduirait probablement des erreurs de transcription.
La deuxième option suggérait une dérivation des exigences black-box, observant les entrées (attributs de police) et les sorties (montants des primes) pour inférer des règles par régression statistique. Les avantages étaient la rapidité et l'accent mis sur la valeur commerciale actuelle plutôt que sur la dette technique. Les inconvénients incluaient l'incapacité à détecter des chemins de code dormants pour des scénarios de réclamations rares et le risque de codifier des bugs comme des fonctionnalités.
La troisième option, archéologie comportementale avec validation parallèle, impliquait d'extraire des données d'échantillon à partir de cinq ans de journaux de production, de construire des arbres de décision à partir de transactions réelles, et de valider ces derniers contre le code COBOL en utilisant des outils de comparaison automatisés.
L'équipe a sélectionné la troisième solution parce qu'elle équilibrait vitesse et précision tout en respectant le principe agile de logiciel fonctionnel plutôt que de documentation exhaustive. En se concentrant sur les chemins de code exécutés plutôt que sur des fonctionnalités mortes, ils ont réduit le périmètre de 60% tout en garantissant que les règles commerciales actives étaient correctement capturées. Ils ont établi un data lake contenant des transactions historiques anonymisées et ont fait passer celles-ci à la fois par les anciens travaux JCL et les nouveaux services FastAPI, signalant automatiquement les incohérences de calcul des primes supérieures à 0,01 %. Cela a révélé trois conditions critiques non documentées : une déduction corporelle pour les polices de Floride émises avant 1992, un calcul de commission spécial pour les agents retraités, et une erreur d'arrondi dans le reporting fiscal trimestriel qui avait été "corrigée" par des ajustements manuels dans des feuilles de calcul pendant des décennies. Les microservices ont été repensés pour gérer explicitement ces cas particuliers comme des règles commerciales configurables plutôt que comme des constantes codées en dur.
Lorsque vous faites de la rétro-ingénierie de code hérité, comment faites-vous la différence entre une contrainte commerciale critique et un contournement technique qui peut être éliminé en toute sécurité lors de la migration ?
Les candidats supposent souvent que toute logique existante sert un but commercial actuel, tombant dans la fallacie des coûts irrécupérables de la préservation de l'héritage. L'approche correcte implique une analyse de contexte temporel : examiner les dates des modifications de code pour établir un lien avec des changements réglementaires connus, des fusions ou des limitations technologiques qui n'existent plus. Par exemple, une routine de troncation de données en COBOL pourrait exister uniquement parce que le schéma DB2 d'origine utilisait des champs à largeur fixe, tandis que le PostgreSQL moderne prend en charge des chaînes de longueur variable—éliminant ainsi complètement le besoin de la règle de troncation. Les analystes commerciaux doivent mener des sessions de vérification d'intention avec les parties prenantes commerciales, présentant les contournements suspects sous la forme "Nous pouvons simplifier cela en supprimant X ; cela affecte-t-il votre conformité ?" plutôt que de demander "Devons-nous conserver X ?" Cela déplace le fardeau de la preuve vers la nécessité plutôt que vers la préservation.
Comment évitez-vous le modèle anti-pattern "culte des cargaisons" où le nouveau système réplique simplement des flux de travail de traitement par lot inefficaces simplement parce qu'ils existent dans le monolithe COBOL ?
De nombreux candidats se concentrent exclusivement sur la parité fonctionnelle sans réingénierie des processus. L'échec se produit lorsque les analystes commerciaux documentent l'état actuel (par exemple, "Le système exécute un traitement par lot nocturne à 2h00") comme une exigence pour l'état futur, ignorant que les architectures orientées événements utilisant Apache Kafka ou RabbitMQ peuvent permettre un traitement en temps réel. La solution nécessite une cartographie des capacités : séparer le "quoi" (le calcul du risque doit se produire) du "comment" (batch vs. streaming). Les analystes commerciaux devraient effectuer une cartographie du flux de valeur pour identifier les temps d'attente dans le calendrier par lot qui servaient la commodité opérationnelle plutôt que les règles commerciales. En démontrant que les points de terminaison REST peuvent fournir un retour immédiat aux souscripteurs—réduisant le temps de cotation à liaison de 24 heures à 30 secondes—ils justifient des changements architecturaux qui seraient autrement rejetés comme "trop différents du ancien système."
Quelle est votre méthodologie pour quantifier et communiquer le risque des "inconnues inconnues"—des règles tacites qui n'ont jamais été déclenchées durant votre période d'observation des données échantillonnées mais pourraient émerger catastrophiquement après la migration ?
Les candidats présentent fréquemment aux parties prenantes une fausse confiance basée sur des taux de test de 100 % réussis contre des données historiques. La réponse sophistiquée reconnaît le biais d'échantillonnage dans les données héritées et plaide pour des tests de résistance contre des scénarios synthétiques. Cela implique de générer des données d'entrée floues qui exercent des conditions limites non vues dans les journaux de production, puis de comparer les sorties COBOL et du nouveau système. De plus, les analystes commerciaux doivent établir un modèle de disjoncteur dans la nouvelle architecture : si le microservice rencontre une structure de transaction qu'il ne peut traiter (indiquant une règle potentiellement manquée), il doit se dégrader gracieusement en appelant le wrapper SOAP hérité (si disponible) ou signalant pour une révision humaine, plutôt que de faillir silencieusement ou de se réduire à des valeurs nulles. La stratégie de communication implique des matrices de risque probabilistes montrant que tandis que 95 % des règles sont validées, une incertitude résiduelle de 5 % nécessite une période de super vigilance de trois mois avec des vérifications de réconciliation manuelles doublées.