Parcours de modernisation

Migrer un parc COBOL batch vers TypeScript et Node.js.

Q: TypeScript est-il vraiment adapté à un COBOL transactionnel ?

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.

Q: Quel est l'avantage de Cloudflare Workers par rapport à Azure Functions ou AWS Lambda ?

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.

Q: Comment gérer l'arithmétique financière en TypeScript ?

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.

Q: Combien coûte une migration COBOL vers TypeScript ?

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.

Q: Qu'est-ce que le vibe coding et comment accélère-t-il la migration ?

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.

Modernisation d'applications COBOL batch vers TypeScript, architecture Node.js et cloud. Méthodologie ATLAS, parité fonctionnelle prouvée.

Chiffres clés

240 Md

lignes de COBOL encore en production dans le monde

Reuters / IBM 2022

10:1

ratio de réécriture COBOL vers TypeScript moderne

Par lots

livraison incrémentale, durée définie au cadrage

Méthodologie ATLAS appliquée

Du cadrage au déploiement, cinq phases structurées.

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.

01Phase 1
Cadrage
Étapes ATLAS
E1 Intake · E2 Discovery · E2b Spécification fonctionnelle
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.
Livrable de phase
Inventaire patrimoine + spec fonctionnelle + chiffrage
02Phase 2
Capture & dépendances
Étapes ATLAS
E2e Capture · E3 Mapping des dépendances
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.
Livrable de phase
Bench de jeux de données de référence + carto complète
03Phase 3
Architecture cible
Étapes ATLAS
E4 Architecture cible · E4b Tests pré-migration
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.
Livrable de phase
Architecture cible signée + suite de tests
04Phase 4
Migration & parité
Étapes ATLAS
E5 Migration · E6 Validation parité
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.
Livrable de phase
Code TypeScript + audit de parité par traitement
05Phase 5
Déploiement & transfert
Étapes ATLAS
E7 Livraison
Mise en service progressive avec strangler fig, runs parallèles legacy ↔ TypeScript, bascule des traitements par lot, transfert d'exploitation à l'équipe cliente.
Livrable de phase
Pipelines en production + équipe cliente autonome

Voir la méthodologie ATLAS complète →

Au cœur de la méthode ATLAS

L'IA pour comprendre le COBOL, pas pour le traduire.

Porter du COBOL vers TypeScript expose un écart que les convertisseurs ignorent : le COBOL calcule en décimal exact, JavaScript en flottant binaire. Une conversion littérale des arithmétiques financières introduit des écarts d'arrondi invisibles en test unitaire et visibles en clôture comptable. 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 d'origine, menées selon plusieurs angles. Ici, ce que nous relisons en priorité : les traitements batch séquentiels à repenser en services asynchrones, et toute arithmétique monétaire à isoler dans une bibliothèque décimale dédiée. L'IA intervient comme accélérateur de compréhension, pour déchiffrer des années 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 et pilote la migration pattern par pattern, sous audit de parité.

Cette compréhension exige encore des humains qui connaissent les technologies d'origine. C'est notre avantage : là où l'Europe et l'Amérique du Nord font face à une vague de départs en retraite sur ces compétences, la Tunisie conserve des développeurs COBOL expérimentés, couplés à des architectes Node.js. Ensemble, ils assurent la continuité entre l'intention métier d'origine et le système cible.

Qui est concerné

Contexte métier et enjeux de modernisation.

Pourquoi TypeScript pour moderniser du COBOL

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.

Les périmètres COBOL adaptés à TypeScript

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.

Notre retour d'expérience TypeScript

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.

Plateforme source

COBOL batch (mainframe, AS/400)

AS/400↗COBOL↗

Cible technologique

TypeScript, Node.js, PostgreSQL, conteneurs

TypeScript↗PostgreSQL↗Node.js↗

Alternatives technologiques

Comparer les trajectoires cibles.

TypeScript + Cloudflare Workers + D1

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.

TypeScript + Node.js + PostgreSQL + Kubernetes

Architecture conteneurisée classique, besoin de contrôle fin sur l'infrastructure, compatible on-premise ou multi-cloud.

TypeScript + Deno + Deno KV

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.

Java 21 + Spring Boot

Volumes transactionnels très élevés, compétences Java internes fortes. Voir COBOL vers Java.

.NET Core 8 + Azure

Écosystème Microsoft dominant. Voir COBOL vers .NET Core.

Repère de cadrage

Durée et équipe type pour ce parcours.

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.

Défis

Porter l'arithmétique décimale COBOL en TypeScript avec bibliothèques adaptées (decimal.js).
Transformer les traitements batch séquentiels en pipelines Node.js observables.
Migrer les fichiers séquentiels vers des bases relationnelles ou des streams Kafka.

Approche ATLAS

Capture de l'existant et cartographie des flux batch.
Tests de caractérisation sur jeux de données représentatifs.
Migration pattern par pattern avec runs parallèles et audit de parité.

Résultats attendus

Pipelines TypeScript observables, déployables en conteneurs.
Tests de non-régression automatisés.
Documentation technique et registre interne de discordances classées.

Pièges identifiés et réponse ATLAS

Ce que nous avons appris sur ce chemin de migration.

Piège 01

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.

Réponse ATLAS

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.

Piège 02

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.

Réponse ATLAS

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).

Piège 03

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.

Réponse ATLAS

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.

Piège 04

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.

Réponse ATLAS

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.

Piège 05

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.

Réponse ATLAS

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.

Expertise associée

Legacy to Cloud

Voir les modules, services et cas d'usage.

Méthodologie propriétaire

Méthodologie ATLAS

10 étapes, 9 principes, parité prouvée.

Composition de la cellule

Une cellule spécialisée pour ce parcours de modernisation.

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.

Durée

Définie au cadrage selon volume et criticité

Volume

Déterminé à l'issue du POC et du cadrage

Profils

Architecte mainframe ↔ cloud serverless

Pont entre z/OS ou AS/400 et l'écosystème Node.js / serverless edge

Tech Lead TypeScript

TypeScript, Node.js, Cloudflare Workers ou conteneurs, patterns de migration COBOL→TS, traçabilité ligne à ligne

Développeurs TypeScript

Idéalement avec un passé Java ou C# pour porter la logique métier accumulée

DBA fichiers séquentiels → PostgreSQL/D1

Migration des fichiers VSAM/QSAM, modélisation relationnelle, audit de parité données

Ingénieur cloud & DevOps serverless

Conteneurisation, CI/CD, observabilité, benchmark de coût cloud, parallélisation des batchs

QA & parité fonctionnelle

Bench de tests de caractérisation, comparaison legacy/cible, validation des audits ATLAS

Retour d'expérience Access

Ce parcours en conditions réelles.

POC CardDemo (AWS Mainframe Sample)

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).

Ratio 7,4:1 · 3 discordances · 6/6 workflows validés

POC Portfolio Management

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).

Ratio 10:1 · 5 discordances · architecture serverless

Questions fréquentes

Ce que les décideurs demandent sur ce parcours.

TypeScript est-il vraiment adapté à un COBOL transactionnel ?+

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.

Quel est l'avantage de Cloudflare Workers par rapport à Azure Functions ou AWS Lambda ?+

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.

Comment gérer l'arithmétique financière en TypeScript ?+

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.

Peut-on maintenir la performance d'un batch COBOL en TypeScript ?+

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.

Combien coûte une migration COBOL vers TypeScript ?+

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.

Qu'est-ce que le vibe coding et comment accélère-t-il la migration ?+

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.

Vous évaluez une migration COBOL vers TypeScript ?

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.

Audit COBOL (4-6 semaines) →Expertise Legacy to Cloud →Modèle Build-Operate-Transfer →

Réalisations