Parcours de modernisation

Transformer une application Delphi client-serveur en application web TypeScript.

Q: Est-ce possible de garder l'aspect desktop même en migrant vers le web ?

Oui, via Electron ou Tauri qui empaquettent une application web dans un runtime desktop (Windows, macOS, Linux). L'utilisateur voit une application desktop, le code est du TypeScript web. Cette approche cumule les avantages : code web moderne (maintenance, écosystème) plus expérience desktop (installation, raccourcis, icônes système). Tauri est préféré aujourd'hui pour sa légèreté face à Electron (applications plus petites, démarrage plus rapide).

Q: React ou Angular pour une migration Delphi ?

React si votre priorité est la vélocité et l'écosystème (composants, bibliothèques, recrutement). Angular si votre priorité est la structure et la proximité avec la philosophie Delphi (framework complet, opinion forte, TypeScript natif dès le départ). Les deux sont valides, notre préférence penche légèrement sur React pour la disponibilité des composants data-heavy (AG Grid, Material UI). Si vos équipes ont déjà du C#/Angular, restez sur Angular.

Q: Comment gérer l'authentification et les rôles Delphi en web ?

Les rôles Delphi sont migrés vers un système d'authentification JWT plus RBAC (Role-Based Access Control). Les tables utilisateurs Delphi deviennent une base d'utilisateurs cible, exposée via Auth0, Keycloak, Azure AD, ou Cognito selon contexte. Les permissions Delphi (lecture, écriture, supervision) deviennent des scopes JWT vérifiés côté API. Tests de parité sur chaque rôle avec jeux de données de référence.

Q: Peut-on migrer par module pour réduire le risque ?

Oui. La méthodologie ATLAS applique le pattern strangler fig pour Delphi aussi : on migre un module à la fois (par exemple, d'abord la gestion des utilisateurs, puis la gestion des données, puis les workflows métier), en maintenant l'application Delphi en production pour les modules non migrés. Une passerelle API permet aux deux applications de communiquer pendant la transition. Cette approche étale le risque mais rallonge la durée totale, définie au cadrage selon le périmètre.

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

Pour une application de cinquante mille lignes Delphi avec quarante écrans en co-delivery nearshore, comptez six cent mille à neuf cent mille euros incluant UX, développement, tests et accompagnement utilisateurs. Pour cent cinquante mille lignes, budget un million deux cent mille à deux millions d'euros. Les coûts incluent la refonte UX obligatoire pour une bonne expérience web. Voir les modèles de delivery pour les formats contractuels.

Q: Comment gérer l'intégration avec les applications Delphi restantes en entreprise ?

Les applications Delphi restantes exposent souvent des services via COM, DCOM, ou base de données partagée. En web TypeScript, ces intégrations sont encapsulées via des adaptateurs API (Azure Functions, Node.js ponts). Pour les bases partagées, on évite idéalement l'accès direct en favorisant une API intermédiaire qui serve à la fois Delphi et web. Pour les vieux COM/DCOM, on les encapsule dans un service .NET ou Node.js côté serveur qui expose des endpoints REST utilisables depuis les deux mondes.

Migration d'applications Delphi vers une architecture web moderne : TypeScript, React ou Angular, API REST. Méthodologie ATLAS.

Chiffres clés

30 ans

Delphi/Object Pascal présent en production depuis 1995

4/10

difficulté relative d'une migration Delphi, contre 7/10 pour COBOL

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 l'application Delphi client-serveur : formulaires VCL, composants tiers, accès FireDAC, code Object Pascal. Reconstituer une analyse fonctionnelle exploitable.
Livrable de phase
Inventaire des écrans + spec fonctionnelle + chiffrage
02Phase 2
Capture & dépendances
Étapes ATLAS
E2e Capture · E3 Mapping des dépendances
Figer la référence UI : captures d'écrans, parcours utilisateur, données de test. Cartographier composants tiers, bases embarquées, intégrations COM/DCOM.
Livrable de phase
Bench UI de référence + carto des dépendances
03Phase 3
Architecture cible
Étapes ATLAS
E4 Architecture cible · E4b Tests pré-migration
Concevoir l'architecture web cible : SPA React ou Angular, API REST avec contrat OpenAPI, base PostgreSQL. Cadrer la refonte UX et préparer les tests end-to-end.
Livrable de phase
Architecture cible signée + maquettes + suite de tests E2E
04Phase 4
Migration & parité
Étapes ATLAS
E5 Migration · E6 Validation parité
Porter Object Pascal → TypeScript pattern par pattern, reconstituer les écrans VCL en composants web React ou Angular. Migration itérative par module, audit de parité fonctionnelle signé.
Livrable de phase
Application web + audit de parité par module
05Phase 5
Déploiement & transfert
Étapes ATLAS
E7 Livraison
Mise en service par lots fonctionnels, double run Delphi ↔ web avec utilisateurs pilotes, bascule progressive avec formation, transfert d'exploitation.
Livrable de phase
Application 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 Delphi, pas pour le traduire.

Passer d'un client lourd Delphi à une application web n'est pas une traduction de langage mais un changement de modèle d'exécution. Un convertisseur reproduit une logique synchrone, à état local et fortement couplée à l'écran, dans un environnement asynchrone et sans état. Les symptômes n'apparaissent qu'en charge. 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é : l'état applicatif porté par les fiches VCL, à redistribuer entre client et serveur, et les traitements longs à repenser en appels asynchrones. 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 Delphi expérimentés, couplés à des architectes TypeScript. 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 passer du Delphi desktop au web TypeScript

Les applications Delphi client-serveur dominantes entre 1995 et 2010 ont un défaut structurel : elles exigent une installation locale Windows sur chaque poste utilisateur. Cela complique le déploiement, interdit l'accès mobile, et rend le télétravail compliqué sans VPN. Migrer vers TypeScript plus React ou Angular transforme l'application en web SPA accessible depuis tout navigateur, sans installation, avec un code maintenable par des équipes web modernes. C'est l'option retenue quand l'application doit s'ouvrir aux utilisateurs distants ou aux partenaires externes.

Les secteurs concernés

Les candidats typiques à une migration Delphi vers TypeScript : bureaux d'étude et cabinets d'expertise qui veulent ouvrir leurs outils aux clients externes, ERP sectoriels Delphi (logistique, transport, industrie) qui cherchent à sortir du client lourd, applications métier développées en interne dans les années 2000 qui doivent moderniser leur UX, éditeurs de logiciels qui repackagent leurs produits Delphi en SaaS web. Pour un public interne uniquement qui accepte Windows, regardez plutôt Delphi vers .NET Core.

La proposition de valeur TypeScript

TypeScript apporte trois avantages décisifs pour porter un Delphi. Le typage statique facilite la traduction depuis Object Pascal — les types Pascal ont des équivalents directs en TypeScript. L'écosystème npm offre des composants riches qui remplacent les VCL et DevExpress Delphi (Material UI, Ant Design, AG Grid, Handsontable). Enfin, la vélocité de développement et le coût d'exploitation cloud permettent de rentabiliser rapidement l'investissement de migration. Voir la méthodologie ATLAS appliquée à ces migrations.

Plateforme source

Delphi (client-serveur, VCL)

Delphi↗

Cible technologique

TypeScript, React ou Angular, Node.js, PostgreSQL

TypeScript↗PostgreSQL↗Node.js↗Angular↗React↗

Alternatives technologiques

Comparer les trajectoires cibles.

TypeScript + React + Node.js + PostgreSQL

Choix par défaut pour une application web moderne maintenable. React domine largement le marché et dispose de l'écosystème de composants le plus riche.

TypeScript + Angular + NestJS + PostgreSQL

Préférence pour un framework structuré end-to-end, équipes internes déjà orientées Angular ou .NET. Angular est plus proche de la philosophie Delphi (framework complet).

TypeScript + Vue.js + Hono + PostgreSQL

Courbe d'apprentissage plus douce, équipe junior, volonté de framework plus léger. Adapté à des applications de taille modérée.

.NET Core avec Blazor

Écosystème Microsoft préservé, équipes Delphi-.NET en transition. Voir Delphi vers .NET Core.

Repère de cadrage

Durée et équipe type pour ce parcours.

Une migration Delphi vers TypeScript se planifie par lots fonctionnels successifs, dont la cadence est définie au cadrage selon le nombre d'écrans et la complexité des interactions. L'équipe combine un architecte web capable de concevoir l'architecture cible (SPA plus API plus base), un tech lead TypeScript, des développeurs front-end (React ou Angular), des développeurs back-end Node.js, un UX designer pour la recomposition ergonomique inévitable sur une SPA, un QA spécialisé en tests end-to-end (Playwright, Cypress), un DBA pour la migration des bases embarquées. 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é.

Défis

Transformer une interface client-serveur en application web SPA sans perte fonctionnelle.
Migrer la logique métier Pascal vers TypeScript.
Reconstruire les workflows interactifs avec des patterns React ou Angular.

Approche ATLAS

Capture de l'existant et cartographie des interfaces.
Reconstitution de l'architecture cible : front SPA, API REST, base relationnelle.
Migration itérative avec audit de parité fonctionnelle.

Résultats attendus

Application web moderne, responsive, déployable en cloud.
API REST documentée et testée.

Pièges identifiés et réponse ATLAS

Ce que nous avons appris sur ce chemin de migration.

Piège 01

Reproduire l'interface Delphi pixel à pixel en web. Le client lourd Delphi a des patterns UX qui fonctionnent mal en web : fenêtres modales imbriquées, menus contextuels denses, dialogues de saisie rapides.

Réponse ATLAS

Refonte UX obligatoire sur une SPA. Les menus contextuels Delphi deviennent des panels latéraux ou des modales web, les dialogues rapides deviennent des formulaires inline, les fenêtres multiples deviennent des onglets ou des vues. Cette refonte UX est cadrée avant la migration technique, avec validation utilisateur (maquettes Figma, tests d'utilisabilité).

Piège 02

Migrer sans repenser le modèle de données. Delphi client-serveur utilise souvent des accès SQL directs avec curseurs Firedac ; une API REST bien conçue exige un modèle de données structuré.

Réponse ATLAS

Conception d'API REST en amont (ou GraphQL selon contexte) avec définition OpenAPI formelle. Les tables Delphi sont normalisées et exposées via des DTO typés. Les accès directs client-serveur deviennent des endpoints REST avec authentification JWT, rate limiting, versioning. Tests de non-régression sur les comportements métier.

Piège 03

Ignorer les bases embarquées Delphi (Paradox, dBase, Interbase, SQL Lite). Les conversions vers PostgreSQL ont des subtilités (encoding, types dates, BLOBs, locking).

Réponse ATLAS

Phase dédiée migration données avec outils spécialisés (pgloader, Azure DMS selon source). Les BLOBs deviennent des bytea PostgreSQL avec tests de parité sur taille et intégrité. Les dates sont migrées vers TIMESTAMP WITH TIME ZONE avec fuseau horaire explicite. Les curseurs optimistes deviennent du RowVersion PostgreSQL.

Piège 04

Oublier les composants Delphi tiers (DevExpress, TMS, Woll2Woll) et leurs équivalents web introuvables. Certains composants Delphi n'ont pas d'équivalent web direct.

Réponse ATLAS

Inventaire exhaustif des composants tiers dès l'Intake. Chaque composant est qualifié : équivalent React/Angular disponible (AG Grid remplace TDBGrid, Material UI remplace VCL), équivalent open source, ou réécriture nécessaire. Les éditeurs propriétaires (DevExpress) ont souvent leur version React — coût de licence à anticiper.

Piège 05

Déclarer la parité fonctionnelle sans valider les workflows métier complets en conditions réelles. Les utilisateurs formés à l'application Delphi ont des habitudes précises qui doivent être reproduites ou explicitement repensées.

Réponse ATLAS

Principe E7 — validation navigateur obligatoire avec tests end-to-end automatisés (Playwright) sur chaque workflow métier critique. Période de double run Delphi-web de quatre à huit semaines avec utilisateurs pilotes. Retours d'expérience intégrés itérativement avant bascule générale. 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 le nombre d'écrans et la complexité des interactions

Volume

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

Profils

Architecte web

Conception de l'architecture cible SPA + API REST + base relationnelle, pont entre Object Pascal et l'écosystème web

Tech Lead TypeScript

TypeScript, React ou Angular, conception d'API, patterns de migration Delphi→web, traçabilité

Développeurs front-end

React ou Angular, reconstitution des écrans VCL en composants web (AG Grid, Material UI)

Développeurs back-end Node.js

API REST, portage de la logique métier Object Pascal, authentification JWT/RBAC

UX & UI designer

Refonte ergonomique du client lourd vers une SPA, maquettes Figma, tests d'utilisabilité

DBA bases embarquées → PostgreSQL

Migration de Paradox, Interbase, FireDAC vers PostgreSQL, audit de parité données

QA & parité fonctionnelle

Tests end-to-end (Playwright, Cypress), comparaison legacy/cible, validation des audits ATLAS

Retour d'expérience Access

Ce parcours en conditions réelles.

Capacité Access — POC interne

Capacité Access validée sur POC interne représentatif d'application Delphi métier critique, portée vers une architecture moderne avec parité fonctionnelle auditée sur cas représentatif.

Parité fonctionnelle auditée · POC capacité

Lire le cas complet →

POC Access — ingénierie logicielle

POC Raptor Delphi évalué pour valider la difficulté relative. Delphi est estimé à 4 sur 10 contre 7 sur 10 pour COBOL, notamment grâce à la proximité syntaxique Pascal-TypeScript/C#.

Difficulté 4/10 vs 7/10 COBOL

Questions fréquentes

Ce que les décideurs demandent sur ce parcours.

Est-ce possible de garder l'aspect desktop même en migrant vers le web ?+

Oui, via Electron ou Tauri qui empaquettent une application web dans un runtime desktop (Windows, macOS, Linux). L'utilisateur voit une application desktop, le code est du TypeScript web. Cette approche cumule les avantages : code web moderne (maintenance, écosystème) plus expérience desktop (installation, raccourcis, icônes système). Tauri est préféré aujourd'hui pour sa légèreté face à Electron (applications plus petites, démarrage plus rapide).

React ou Angular pour une migration Delphi ?+

React si votre priorité est la vélocité et l'écosystème (composants, bibliothèques, recrutement). Angular si votre priorité est la structure et la proximité avec la philosophie Delphi (framework complet, opinion forte, TypeScript natif dès le départ). Les deux sont valides, notre préférence penche légèrement sur React pour la disponibilité des composants data-heavy (AG Grid, Material UI). Si vos équipes ont déjà du C#/Angular, restez sur Angular.

Comment gérer l'authentification et les rôles Delphi en web ?+

Les rôles Delphi sont migrés vers un système d'authentification JWT plus RBAC (Role-Based Access Control). Les tables utilisateurs Delphi deviennent une base d'utilisateurs cible, exposée via Auth0, Keycloak, Azure AD, ou Cognito selon contexte. Les permissions Delphi (lecture, écriture, supervision) deviennent des scopes JWT vérifiés côté API. Tests de parité sur chaque rôle avec jeux de données de référence.

Peut-on migrer par module pour réduire le risque ?+

Oui. La méthodologie ATLAS applique le pattern strangler fig pour Delphi aussi : on migre un module à la fois (par exemple, d'abord la gestion des utilisateurs, puis la gestion des données, puis les workflows métier), en maintenant l'application Delphi en production pour les modules non migrés. Une passerelle API permet aux deux applications de communiquer pendant la transition. Cette approche étale le risque mais rallonge la durée totale, définie au cadrage selon le périmètre.

Combien coûte une migration Delphi vers TypeScript ?+

Pour une application de cinquante mille lignes Delphi avec quarante écrans en co-delivery nearshore, comptez six cent mille à neuf cent mille euros incluant UX, développement, tests et accompagnement utilisateurs. Pour cent cinquante mille lignes, budget un million deux cent mille à deux millions d'euros. Les coûts incluent la refonte UX obligatoire pour une bonne expérience web. Voir les modèles de delivery pour les formats contractuels.

Comment gérer l'intégration avec les applications Delphi restantes en entreprise ?+

Les applications Delphi restantes exposent souvent des services via COM, DCOM, ou base de données partagée. En web TypeScript, ces intégrations sont encapsulées via des adaptateurs API (Azure Functions, Node.js ponts). Pour les bases partagées, on évite idéalement l'accès direct en favorisant une API intermédiaire qui serve à la fois Delphi et web. Pour les vieux COM/DCOM, on les encapsule dans un service .NET ou Node.js côté serveur qui expose des endpoints REST utilisables depuis les deux mondes.

Vous transformez une application Delphi en web ?

Trois manières de démarrer — du diagnostic gratuit à la cellule complète. Notre approche Delphi → TypeScript reconstruit une SPA web moderne sans perte fonctionnelle.

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

Réalisations