Architecte mainframe ↔ cloud serverless
Pont entre z/OS ou AS/400 et l'écosystème Node.js / serverless edge
Loading...
Loading...
Modernisation d'applications COBOL batch vers TypeScript, architecture Node.js et cloud. Méthodologie ATLAS, parité fonctionnelle prouvée.
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.
Comprendre le patrimoine COBOL batch existant : programmes, copybooks, JCL, chaînes de traitement de nuit. Reconstituer une analyse fonctionnelle. Définir périmètre, contraintes, critères de réussite.
Figer la référence : jeux de données d'entrée/sortie, états imprimés, fichiers d'échange. Cartographier les flux batch, fichiers VSAM/QSAM, bases DB2, ordonnancement.
Concevoir l'architecture TypeScript cible : Node.js ou Cloudflare Workers, base PostgreSQL/D1, orchestration des jobs, benchmark de coût cloud. Préparer la suite de tests de caractérisation.
Traduire COBOL → TypeScript pattern par pattern : COPY → modules typés, PERFORM → fonctions, PIC S9(n)V9(n) et COMP-3 → decimal.js. Parallélisation des batchs, audit de parité signé sur chaque lot.
Mise en service progressive avec strangler fig, runs parallèles legacy ↔ TypeScript, bascule des traitements par lot, transfert d'exploitation à l'équipe cliente.
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.
Migrer du COBOL vers TypeScript est une trajectoire de plus en plus choisie par les DSI qui cherchent à passer d'un mainframe monolithique à une architecture cloud-native serverless. TypeScript offre deux avantages décisifs sur Java ou .NET pour les périmètres adaptés : un coût d'exécution drastiquement réduit via des runtimes serverless (Cloudflare Workers, Azure Functions, AWS Lambda, Deno), et une vélocité d'évolution supérieure grâce à l'écosystème npm et au typage structurel plus souple que Java.
TypeScript convient particulièrement bien aux périmètres COBOL batch (traitements de nuit, reporting, ETL, extractions) et aux transactions à volume modéré (moins de mille transactions par seconde). Les secteurs typiques : fintech en croissance qui ne veut pas investir dans une infrastructure Java lourde, télécom et média orientés serverless, administrations digitalisées qui ont adopté les APIs cloud-first, banques de niche qui cherchent à sortir rapidement d'un mainframe coûteux. Pour des transactions à très haut volume (plus de dix mille TPS), regardez plutôt COBOL vers Java ou COBOL vers .NET Core.
Nos POC internes ont converti du COBOL vers TypeScript Cloudflare Workers sur trois cas représentatifs (CardDemo, Portfolio, CBSA). Le ratio observé est de 10:1 (10 lignes COBOL pour 1 ligne TypeScript) — supérieur au ratio Java (7:1) car TypeScript évite le boilerplate Spring. Le vibe coding assisté par IA (Claude Code, GitHub Copilot) accélère la conversion par 2 à 3 fois dans ce langage moderne. Voir la méthodologie ATLAS appliquée sur ces POC.
Architecture serverless, volumes modérés, coût d'exploitation minimal, distribution edge globale. Choix par défaut pour les fintech et télécoms agiles.
Architecture conteneurisée classique, besoin de contrôle fin sur l'infrastructure, compatible on-premise ou multi-cloud.
Ecosystem moderne, sécurité par défaut, TypeScript natif sans compilation. Adapté aux projets nouveaux ou aux migrations où on peut se permettre une stack émergente.
Volumes transactionnels très élevés, compétences Java internes fortes. Voir COBOL vers Java.
Écosystème Microsoft dominant. Voir COBOL vers .NET Core.
Une migration COBOL vers TypeScript se structure par lots fonctionnels successifs, dont la cadence est définie au cadrage selon le volume et la criticité. La cellule type combine un architecte cloud serverless, un tech lead TypeScript senior, des développeurs TypeScript idéalement avec un passé Java ou C#, un QA spécialisé en tests de caractérisation, et une direction de livraison. 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é. TypeScript permet généralement une cellule plus compacte que Java ou .NET.
Utiliser le type number JavaScript pour porter les PIC S9(n)V9(n) et COMP-3 COBOL. Les erreurs d'arrondi en virgule flottante sont garanties sur tout calcul financier.
Mapping systématique PIC et COMP-3 vers la bibliothèque decimal.js ou BigDecimal via BigInt. Les calculs financiers sont encapsulés dans une classe Money avec scale et rounding mode explicites. Tests de parité unitaires sur overflow, underflow, division par zéro, comparaison avec les sorties COBOL sur jeux représentatifs.
Reproduire les traitements batch COBOL séquentiels en TypeScript sans exploiter la parallélisation native Node.js. Le résultat est un batch lent qui ne profite pas des avantages du cloud.
Parallélisation explicite avec Promise.all, worker_threads ou job queue (BullMQ, Cloudflare Queues). Découpage des gros batchs en jobs idempotents orchestrés par un scheduler. Observabilité via logs structurés (Pino, Winston) et métriques (Prometheus, Cloudflare Analytics).
Négliger la différence de modèle de facturation cloud. COBOL batch facture à l'infra, serverless facture à l'exécution. Un batch mal optimisé peut devenir coûteux à l'échelle.
Benchmark de coût cloud intégré dans la phase d'architecture cible. Pour les batchs très volumineux, arbitrage entre Cloudflare Workers (edge, low latency) et Azure Container Apps ou AWS Fargate (long-running, coût prévisible). Estimation de coût mensuel validée avant déploiement.
Porter les fichiers séquentiels COBOL (VSAM, QSAM) en tables relationnelles naïves sans repenser le modèle. Les accès positionnés deviennent des full scan SQL, performances catastrophiques.
Modélisation relationnelle adaptée aux requêtes cibles. Les fichiers indexés VSAM deviennent des tables avec index composites adaptés aux patterns d'accès identifiés lors de la discovery. Les requêtes séquentielles COBOL sont portées en streams TypeScript avec pagination cursor-based pour éviter le chargement complet en mémoire.
Déclarer la migration terminée sans avoir validé les workflows de bout en bout en production avec les vrais volumes. Sur notre POC Portfolio, la première livraison était validée en tests API mais le dashboard navigateur ne fonctionnait pas car la base D1 distante n'était pas initialisée.
Principe E7 — validation navigateur et workflow obligatoire avant livraison. Checklist de déploiement comprenant : schema initialisé en environnement cible, seed data chargé, smoke tests API passés, smoke tests navigateur passés, workflow complet rejoué. Cette checklist a émergé de l'autocritique honnête de nos POC. 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 z/OS ou AS/400 et l'écosystème Node.js / serverless edge
TypeScript, Node.js, Cloudflare Workers ou conteneurs, patterns de migration COBOL→TS, traçabilité ligne à ligne
Idéalement avec un passé Java ou C# pour porter la logique métier accumulée
Migration des fichiers VSAM/QSAM, modélisation relationnelle, audit de parité données
Conteneurisation, CI/CD, observabilité, benchmark de coût cloud, parallélisation des batchs
Bench de tests de caractérisation, comparaison legacy/cible, validation des audits ATLAS
POC interne Access : migration COBOL CICS (AWS CardDemo, Apache 2.0) vers TypeScript Cloudflare Workers. Programmes COBOL, copybooks, tables D1, endpoints REST, dashboard HTML. Parité fonctionnelle validée sur 6/6 workflows navigateur, trois discordances détectées dont une métier (cascade overlimit/expiry).
POC interne Access : migration COBOL vers TypeScript Cloudflare Workers avec Hono et D1. Programmes et copybooks portés, endpoints REST, dashboard HTML, cinq discordances détectées dont deux métier (SELL cost_basis et position delete).
Oui, sous réserve du volume. TypeScript via Node.js ou Cloudflare Workers est parfaitement adapté aux transactions à volume modéré (jusqu'à mille TPS) avec latences sub-seconde. Pour des volumes supérieurs, regardez COBOL vers Java ou COBOL vers .NET Core. Le vrai sweet spot de TypeScript pour COBOL : les batchs et workloads événementiels où le modèle serverless brille.
Cloudflare Workers s'exécute sur 325 villes dans le monde en edge, avec une latence froide de quelques millisecondes (vs plusieurs centaines pour AWS Lambda). Il offre un modèle de pricing simple (tarif par requête) et une intégration native D1 (SQLite distribuée) pour le stockage relationnel. Azure Functions est préférable si votre SI est déjà dans l'écosystème Microsoft. AWS Lambda si l'écosystème AWS domine. Cloudflare Workers si vous partez de zéro et cherchez le meilleur rapport performance/coût pour du serverless edge.
Ne jamais utiliser le type `number` JavaScript pour des calculs financiers. Utiliser decimal.js (mature, largement adopté) ou BigDecimal via BigInt (plus performant mais moins ergonomique). Encapsuler toute opération financière dans une classe Money ou Decimal avec scale, currency et rounding mode explicites. Tests de parité unitaires sur chaque calcul avec comparaison aux sorties COBOL sur jeux représentatifs. decimal.js couvre 95 pour cent des cas.
Oui, généralement mieux même. Un batch COBOL séquentiel peut être porté en TypeScript avec parallélisation via worker_threads ou Promise.all, et exécuté sur un cluster (Kubernetes, Cloudflare Queues). Sur nos POC, les batchs migrés sont 2 à 5 fois plus rapides que leur équivalent COBOL grâce à la parallélisation et à la co-localisation avec la base de données. Exception : les batchs avec forte dépendance séquentielle (comptabilité avec totaux cumulés) où la linéarité est intrinsèque.
Pour trente mille lignes COBOL batch en co-delivery nearshore, comptez cinq cent mille à sept cent mille euros tests de parité et documentation inclus — moins cher que Java ou .NET grâce au ratio 10:1 qui réduit le volume de code cible. Pour cent mille lignes, budget un à deux millions d'euros. Voir les modèles de delivery pour les formats contractuels.
Le vibe coding désigne la conversion de code legacy assistée par IA (Claude Code, GitHub Copilot, Cursor) encadrée par notre méthodologie ATLAS. L'IA accélère la traduction pattern par pattern par 2 à 3 fois mais ne remplace pas la discovery ni les tests de caractérisation. Nous avons mesuré ces gains sur nos 10 POC, documentés dans notre article Vibe coding : consultants augmentés par IA.
Trois manières de démarrer — du diagnostic gratuit à la cellule complète. Notre approche COBOL → TypeScript serverless est documentée, chiffrée et applicable dès la première rencontre.