Architecte legacy ↔ Python
Pont entre COBOL batch/analytique et l'écosystème Python data, cartographie patterns COMP-3/PIC, design pipelines
Loading...
Loading...
Migration de traitements COBOL batch, calcul et analytique vers Python, pandas, NumPy et bibliothèques scientifiques. Méthodologie ATLAS, parité fonctionnelle prouvée, intégration à l'écosystème data moderne (Databricks, Jupyter).
Chaque phase regroupe une ou plusieurs des dix étapes ATLAS. Aucune phase ne démarre tant que la précédente n'a pas livré son artefact validé. La méthodologie ATLAS rend la migration AS/400 prévisible et auditable.
Inventaire des programmes COBOL candidats (batch analytique, calcul actuariel, scoring, reporting), exclusion des transactionnels (orientés Java/.NET). Choix de la cible Python (pandas+PostgreSQL, Databricks/PySpark, FastAPI). Reconstitution de la spec fonctionnelle des règles de calcul.
Capture des jeux de données production représentatifs (entrées, sorties attendues), figeage de la référence de vérité. Cartographie des dépendances : fichiers VSAM/QSAM, copybooks, ordonnancement JCL, intégrations bases DB2.
Design pipeline Python : decimal.Decimal pour calculs financiers, pandas pour transformations, modélisation relationnelle (PostgreSQL) ou colonne (Parquet/Delta Lake) selon volumes, orchestration Airflow ou Databricks Workflows, observabilité (logging, metrics). Préparation suite de tests de caractérisation.
Traduction pattern par pattern : PIC S9(n)V9(n) → decimal.Decimal, PERFORM séquentiels → opérations vectorisées pandas/NumPy (gain 5-20×), CALL → modules Python, fichiers VSAM → tables ou DataFrames. Runs parallèles COBOL/Python 4-8 semaines sur jeux production, comparaison automatique ligne à ligne.
Mise en service progressive avec coexistence COBOL ↔ Python pendant la transition. Intégration Databricks ou Jupyter pour exploration. Packaging (poetry/uv) et conteneurisation (Docker/Kubernetes ou serverless Cloud Run). Transfert d'exploitation à l'équipe cliente avec documentation et runbooks.
Les outils de conversion automatique de code legacy produisent du code qui compile, mais qui reste illisible et non maintenable : les patterns d'origine sont recopiés tels quels, sans idiomatisation, avec des dépendances à une runtime propriétaire. Mis en production sans re-caractérisation complète, ce code n'est ni fiable ni évolutif. La traduction automatique de bout en bout n'est pas une méthode de modernisation — c'est un transfert de dette.
Notre méthode est inverse. ATLAS repose sur plusieurs lectures du code legacy, menées selon plusieurs angles : flux de données, règles métier, dépendances, cas limites. L'IA intervient ici comme accélérateur de compréhension — pour déchiffrer des décennies de logique métier accumulée, rétro-documenter des branches non commentées, expliciter l'intention derrière le code. Elle ne décide pas et ne traduit pas : elle éclaire le travail de l'architecte, qui conçoit ensuite l'architecture cible (cloud, base de données, services) et pilote la migration pattern par pattern, sous audit de parité.
Cette compréhension exige encore des humains qui connaissent les langages legacy. C'est notre avantage : là où l'Europe et l'Amérique du Nord font face à une vague de départs en retraite des développeurs mainframe et legacy, la Tunisie conserve un vivier de développeurs expérimentés (COBOL, Delphi, PowerBuilder, RPG…). Couplés à des architectes et développeurs modernes formés à la méthode ATLAS, ils assurent la continuité entre l'intention métier d'origine et le système cible.
Le choix de Python comme cible de migration COBOL n'est pertinent que dans certains périmètres précis. Pour des traitements de calcul (actuariat, scoring de risque, simulations Monte Carlo, analyses statistiques), Python apporte un écosystème scientifique inégalé (NumPy, SciPy, pandas, scikit-learn). Pour des pipelines batch analytiques qui alimentent un data lake ou un lakehouse, Python s'intègre naturellement à Databricks, Airflow et Jupyter. Pour des transactionnels haute disponibilité ou des programmes financiers critiques, Java ou .NET Core restent préférables.
Les bons candidats à une migration vers Python : batchs analytiques d'assurance vie ou IARD (provisions, réassurance), scoring crédit des banques, calculs fiscaux des administrations, reporting réglementaire (Solvency II, BCBS 239), traitement de données scientifiques dans l'industrie ou la santé. Volume typique : 20 à 100 mille lignes COBOL par périmètre. Pour des volumes plus importants ou des transactionnels, regarder les autres parcours COBOL vers Java, .NET Core ou TypeScript.
Batchs analytiques classiques, intégration data lake, ordonnancement Airflow. Choix par défaut pour les pipelines analytiques.
Volumes massifs (TB), workloads distribués, intégration ML. Voir Pipelines data engineering.
Exposition de calculs sous forme d'API REST. Léger, rapide, facile à industrialiser.
Transactionnel haute disponibilité, performance critique, écosystème enterprise dominant. Voir COBOL vers Java ou COBOL vers .NET Core.
Une migration COBOL vers Python se structure par lots fonctionnels successifs, dont la cadence est définie au cadrage selon le volume et la complexité des calculs. Cellule type : un architecte legacy-Python, un tech lead Python, des développeurs Python (idéalement avec passé scientifique ou data engineering), un ingénieur QA spécialisé en tests de caractérisation, un référent métier (actuaire, data analyst, fiscal). La composition et l'effectif ne sont pas fixés à l'avance : ils sont déterminés à l'issue du POC et du cadrage, une fois le travail réel mesuré.
Utiliser le type float Python pour les calculs financiers. Les erreurs d'arrondi en virgule flottante sont garanties et les écarts de centimes finissent par dépasser les seuils acceptables des contrôles métier.
Mapping systématique PIC S9(n)V9(n) et COMP-3 vers la classe decimal.Decimal native Python avec context précision et rounding mode explicites. Tests de parité unitaires sur overflow, underflow, division avec arrondi déterministe. Comparaison automatique des sorties avec les jeux COBOL de référence.
Reproduire les boucles COBOL séquentielles en Python sans utiliser pandas ou NumPy. Le résultat est un Python lent qui ne profite pas des avantages du langage.
Vectorisation systématique avec pandas et NumPy pour les transformations de données. Les PERFORM COBOL deviennent des opérations vectorielles ou des `apply` pandas. Pour les volumes massifs : PySpark sur Databricks. Gain de performance typique : 5 à 20× vs traduction naïve.
Migrer un programme à la fois sans réviser le modèle de données. Le parc COBOL utilise typiquement des fichiers VSAM ou QSAM avec accès positionnés — naïvement portés en SQL relationnel, on perd les performances.
Modélisation relationnelle adaptée aux requêtes cibles avec index composites pertinents. Pour les analytiques massifs : stockage colonne (Parquet, Delta Lake) au lieu de PostgreSQL classique. Voir le parcours Pipelines data engineering pour les patterns lakehouse.
Déclarer la migration terminée après la conversion de calculs, sans valider sur jeux production complets. Les bords de domaine (overflow, valeurs aberrantes, dates antérieures à 1900) réservent des surprises.
Principe E7 — validation sur jeux production réels obligatoire avant livraison. Runs parallèles COBOL/Python pendant quatre à huit semaines sur jeux production complets, comparaison automatique des sorties à la ligne, registre des écarts classifiés. Voir la méthodologie ATLAS.
Plusieurs profils distincts, mobilisés sur la durée du programme. Reproduire cette cellule en interne est rarement réaliste — la pénurie des compétences legacy et la profondeur d'expertise ATLAS rendent l'externalisation structurellement plus rapide et moins risquée.
Pont entre COBOL batch/analytique et l'écosystème Python data, cartographie patterns COMP-3/PIC, design pipelines
Python 3, pandas, NumPy, decimal.Decimal, patterns de traduction COBOL→Python, traçabilité ligne à ligne
Idéalement avec passé scientifique ou data engineering (NumPy, SciPy, vectorisation, pandas avancé)
Actuaire, data analyst, fiscal — lever les ambiguïtés sur les règles de calcul accumulées, validation des écarts de parité
Migration des fichiers VSAM/QSAM vers PostgreSQL ou stockage colonne (Parquet, Delta Lake), audit parité données
Bench de tests de caractérisation, comparaison ligne à ligne legacy/cible sur jeux production, registre des discordances classifié
Capacité éprouvée sur la migration COBOL avec 10 POC internes couvrant Java et TypeScript (39 patterns COBOL couverts, 44 discordances tracées). Les patterns documentés sont applicables à une cible Python : decimal.Decimal pour COMP-3, pandas pour la vectorisation, Airflow ou Databricks pour l'orchestration. Capacité combinable avec notre expertise data engineering.
Non, dans la majorité des cas. Python convient parfaitement aux batchs analytiques et aux calculs scientifiques, mais pas aux transactionnels haute disponibilité (banque temps réel, paiements, transactions critiques). Pour ces périmètres, Java ou .NET Core restent préférables. Le sweet spot Python : actuariat, scoring, reporting réglementaire, ETL analytiques.
Trois leviers. decimal.Decimal systématique pour tous les calculs financiers (jamais float). Context précision et rounding mode explicites alignés avec le COBOL source (typiquement ROUND_HALF_EVEN ou ROUND_HALF_UP selon les conventions métier). Tests de caractérisation sur jeux production avec comparaison à la ligne, reconciliation des écarts classés en CRITIQUE / ADAPTATION / COSMÉTIQUE selon notre méthodologie ATLAS.
Pour 30 à 80 mille lignes COBOL de calcul/analytique en co-delivery nearshore, comptez 400 à 800 k€ tests de parité et documentation inclus. Coût typique inférieur à Java ou .NET grâce à la concision Python (ratio ~10:1) et à la cellule plus compacte (4 à 6 personnes). Voir les modèles de delivery.
Databricks : encapsulation des calculs migrés en notebooks PySpark, orchestration via Databricks Workflows ou Airflow. Versioning Git, CI/CD via Databricks Repos. Jupyter : pour l'exploration ad hoc et la documentation interactive des calculs métier. Production : packaging Python (poetry ou uv), exécution dans des conteneurs Docker orchestrés par Kubernetes ou serverless (Cloud Run, Lambda). Voir le parcours Pipelines data engineering.
Trois manières de démarrer — du POC sur votre code au programme complet. Python convient parfaitement aux batchs analytiques et aux calculs scientifiques ; nous excluons explicitement les transactionnels critiques (orientés Java/.NET).