Architecte Delphi ↔ Java
Pont entre Object Pascal/VCL et l'écosystème Java moderne, capable de cartographier les patterns Delphi et de définir les équivalents Java
Loading...
Loading...
Migration d'applications Delphi (Object Pascal, VCL, FireDAC) vers Java 21 et Spring Boot, sous méthodologie ATLAS. Capture du legacy, tests de caractérisation, migration pattern par pattern, audit de parité, exposition API REST pour intégration cloud et workflows agentiques.
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 Delphi : projets, formes DFM, DataModule, BPL, composants tiers, intégrations Windows natives. Reconstituer une analyse fonctionnelle à partir du code. Définir périmètre, contraintes, critères de réussite, choix d'architecture cible (web SPA, Vaadin, JavaFX).
Figer la référence de vérité : écrans VCL capturés, jeux de données, états imprimés, transactions clés. Cartographier les sous-systèmes, les composants tiers (DevExpress, TMS, FastReport) et leurs équivalents Java, les schémas FireDAC ou dbExpress, les intégrations Windows COM/OLE à remplacer.
Concevoir l'architecture Java cible : Spring Boot, JPA, PostgreSQL managé, conteneurisation Docker, exposition API REST documentée OpenAPI, frontend SPA séparé ou Vaadin. Définir la stratégie cloud (Azure App Service, AWS Elastic Beanstalk, GCP Cloud Run, Kubernetes self-managed) et l'observabilité. Préparer la suite de tests de caractérisation.
Traduire Pascal → Java pattern par pattern : properties → Lombok getter/setter, FireDAC → Spring Data JPA, VCL Form → REST endpoint + composant frontend, TObject lifecycle → garbage collection Java. Migration incrémentale par sous-système, runs parallèles, audit de parité signé sur chaque lot. Tests de bord (overflow, nullité, encodage) ajoutés à la suite de caractérisation.
Mise en service progressive avec coexistence Delphi ↔ Java pendant la transition (durée définie au cadrage selon profil de risque), bascule transactionnelle par lot, exposition des API REST aux workflows cloud et aux intégrations tierces, transfert d'exploitation à l'équipe cliente avec documentation et pair-programming.
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.
Delphi (Object Pascal sur VCL puis FireMonkey) reste présent dans les PME industrielles, les banques régionales et mutualistes, les assurances, les éditeurs de logiciels métier (ERP sectoriels, applications de gestion, logiciels scientifiques et techniques) développés entre 1995 et 2015. Sa force historique : la productivité du RAD (Rapid Application Development) — un développeur unique pouvait livrer une application desktop complète avec base de données embarquée, formulaires riches et états imprimés en quelques semaines. Sa faiblesse aujourd'hui : éditeur Embarcadero peu actif, vivier de développeurs Delphi en raréfaction rapide, architecture client-serveur incompatible avec mobile, web moderne et cloud-native. Famille 4GL adjacente : PowerBuilder suit les mêmes patterns de migration.
Trois forces poussent à la migration. Premièrement, la disparition progressive des développeurs Delphi : les profils formés dans les années 2000 partent en retraite ou se reconvertissent, et la relève est quasi inexistante en école. Deuxièmement, la dette technique accumulée sur des composants tiers (DevExpress, TMS, FastReport) dont certaines versions ne sont plus supportées et empêchent les évolutions OS Windows. Troisièmement, et c'est souvent le déclic, l'impossibilité d'ouvrir l'application à des canaux modernes : mobile, web, API tierces, workflows cloud, agents IA. Notre méthodologie ATLAS cadre cette transition de façon prévisible, sans rupture de service.
Le choix de Java comme cible Delphi est pertinent quand le SI cible est dominé par Java (intégration avec applications Spring existantes, ERP Java, middleware Java EE), quand l'organisation a une forte expertise interne Java mais aucune expertise C#, ou quand la portabilité multi-OS est requise (Linux serveur privilégié). Mais le vrai gain dépasse le port code-pour-code : Spring Boot expose nativement la logique métier en API REST, ce qui transforme une application desktop fermée en services composables consommables par des workflows cloud (Azure Logic Apps, AWS Step Functions, n8n, Power Automate, Make), des agents IA et des intégrations tierces. La donnée prisonnière de la base Paradox devient une source d'API gouvernée, observable, monétisable. Si Microsoft domine le SI, regardez Delphi vers .NET Core. Si le besoin est une vraie modernisation web cloud-native, regardez Delphi vers TypeScript.
Delphi (Object Pascal, VCL, FireDAC, dbExpress, composants tiers)
Java 21, Spring Boot, JPA, PostgreSQL, REST API, frontend SPA ou JavaFX
Choix par défaut : modernisation web, exposition API REST native, intégration aux workflows cloud et aux agents IA. Frontend React ou Angular séparé pour une vraie UX moderne.
Besoin desktop confirmé (mode déconnecté, intégration matérielle, performance native, contraintes utilisateurs internes Windows). JavaFX seulement si Java est imposé par le SI cible — sinon .NET Core WinForms est plus simple.
Équipe à dominante backend Java sans expertise frontend SPA, applications internes à faible trafic, priorité au time-to-market sur l'UX. Vaadin masque le frontend mais limite la richesse interactive.
Écosystème Microsoft → Delphi vers .NET Core (proximité syntaxique Pascal-C#). Modernisation web cloud-native pure → Delphi vers TypeScript (effort de réécriture plus important mais cible la plus ouverte).
Une migration Delphi vers Java se planifie par lots fonctionnels successifs, dont la cadence est définie au cadrage selon le volume, le nombre d'écrans VCL et l'interface cible (SPA web, Vaadin, ou JavaFX desktop). La cellule type combine un architecte Delphi-Java, un tech lead Java senior, des développeurs Java (idéalement avec passé Pascal ou C++ pour comprendre le typage strict et le modèle objet), un développeur Delphi senior pour la connaissance métier (essentiel en début de programme), un UX designer si refonte web, un QA spécialisé tests de caractérisation, et 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é. La distance syntaxique Pascal-Java est plus marquée que Pascal-C# : prévoir une formation Java approfondie pour les développeurs Delphi en transition.
Sous-estimer la distance syntaxique Pascal-Java. Contrairement à C#, Java n'a pas de properties natives, pas de delegates, pas de records avant Java 16, une gestion mémoire automatique par GC (vs cycle de vie TObject explicite en Delphi), pas de sets type natif, pas de variants.
Patterns de traduction documentés et testés : properties Pascal → getter/setter Java avec Lombok ou Java records, delegates → interfaces fonctionnelles Java 8+, sets Pascal → EnumSet Java, variants → Object générique ou sealed classes Java 21. Tests de parité unitaires sur chaque pattern. Principe P1 — tests d'abord, migration ensuite appliqué systématiquement.
Choisir JavaFX desktop par défaut sans réévaluer le besoin métier. JavaFX est moins maintenu que Swing, moins riche que React/Angular pour le web, et oblige l'utilisateur final à installer le runtime Java. Pour la plupart des applications Delphi, c'est un faux choix de continuité.
Réévaluation systématique du besoin desktop vs web pendant la phase E4 Architecture cible. Si les utilisateurs sont en interne sur Windows, .NET Core WinForms peut être plus simple. Si une vraie modernisation est souhaitée, frontend SPA séparé (React, Angular) avec backend Spring Boot. JavaFX uniquement si Java est imposé et besoin déconnecté avéré.
Ne pas anticiper la gestion des composants tiers Delphi (DevExpress VCL, TMS, FastReport, EhLib). Ces composants n'ont pas d'équivalent direct Java — il faut souvent réécrire les écrans concernés en utilisant les briques natives du framework cible (AG Grid pour les grids, JasperReports ou Apache POI pour les rapports, ApexCharts pour les graphes).
Cartographie exhaustive des composants tiers dès la phase E2 Discovery. Pour chaque composant identifié, mapping explicite vers son équivalent Java moderne et estimation de l'effort de réécriture. Inclure cet effort dans le chiffrage initial — c'est souvent 30 à 50 % de l'effort UI total sur une application Delphi mature.
Migrer code-pour-code sans repenser l'exposition de la logique métier. On rate alors l'opportunité de transformer l'application desktop en services consommables par des workflows cloud, des agents IA ou des intégrations tierces — et on livre un Java moderne mais aussi fermé que le Delphi d'origine.
Architecture cible orientée API REST dès la phase E4 : Spring Boot expose la logique métier en endpoints REST documentés (OpenAPI), avec authentification standard (OAuth2, JWT), versioning, observabilité (Micrometer + Prometheus). L'UI consomme l'API comme n'importe quel autre client — cloud workflow, n8n, Power Automate, agent IA. C'est ce qui justifie la migration au-delà de la simple dette technique.
Déclarer la migration terminée après la conversion de code, sans valider les workflows utilisateurs réels ni la parité fonctionnelle sur les jeux de données du client. Les écrans peuvent compiler et afficher correctement tout en cassant un calcul métier hérité d'une RTL Delphi spécifique.
Principe E7 — validation navigateur et workflow métier obligatoire avant livraison. Runs parallèles Delphi / Java sur les transactions clés, comparaison automatique des résultats, audit de parité avec registre interne de discordances classées selon une grille CRITIQUE / ADAPTATION / COSMÉTIQUE. Aucune bascule sans parité prouvée sur les workflows critiques.
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 Object Pascal/VCL et l'écosystème Java moderne, capable de cartographier les patterns Delphi et de définir les équivalents Java
Java 21, Spring Boot, JPA, REST API design, patterns de migration Pascal→Java, traçabilité ligne à ligne
Idéalement avec passé Pascal ou C++ pour comprendre le typage strict et le modèle objet ; formation Java dédiée pour développeurs Delphi en transition
Connaissance métier accumulée, lecture du code legacy, lever les ambiguïtés d'interprétation en début de programme (essentiel)
Refonte ergonomique web (React, Angular ou Vaadin), responsive, accessibilité — uniquement si cible web (non requis pour JavaFX)
Migration des bases embarquées (Paradox, Firebird, dBase, SQL Server local) ou SGBD historiques vers PostgreSQL, audit de parité données
Bench de tests de caractérisation, comparaison legacy/cible, validation des audits ATLAS
Trois cas justifient Java : (1) le SI cible est dominé par Java (Spring, JEE, intégrations existantes), (2) l'organisation a une expertise interne Java forte sans expertise C#, (3) la portabilité multi-OS est requise et Linux serveur est privilégié. Sinon, .NET Core est plus naturel (proximité syntaxique Pascal-C#) ou TypeScript si l'objectif est web cloud-native pur. La méthodologie ATLAS s'applique aux trois cibles avec la même rigueur.
C'est l'opportunité la plus sous-estimée de cette modernisation. La donnée historiquement prisonnière de bases embarquées (Paradox, Firebird, dBase, SQL Server local) est migrée vers PostgreSQL managé (Azure Database for PostgreSQL, AWS RDS, GCP Cloud SQL ou on-premise selon stratégie). La logique métier est exposée en API REST documentées OpenAPI par Spring Boot. Concrètement, cela permet : (1) consommation par des workflows cloud (Azure Logic Apps, n8n, Power Automate, Make, AWS Step Functions), (2) intégration avec des agents IA qui peuvent interroger ou alimenter le système, (3) ouverture à des canaux modernes (mobile, portail client, intégrations partenaires) sans refonte additionnelle. L'application sort du desktop pour devenir un service composable.
Ces composants n'ont pas d'équivalent direct Java — il faut réécrire les écrans concernés en utilisant les briques natives du framework cible. Mapping typique : grids DevExpress → AG Grid (côté web) ou JavaFX TableView (côté desktop) ; TMS Aurelius → Spring Data JPA ; FastReport → JasperReports, Apache POI ou Stimulsoft Java ; EhLib → composants tableurs web (Handsontable, SpreadJS) ou JavaFX TableView étendu. Cet effort de réécriture représente typiquement 30 à 50 % de l'effort UI total sur une application Delphi mature — il doit être inclus dans le chiffrage initial, pas découvert en cours de programme.
SPA séparée (React ou Angular) : choix par défaut pour toute vraie modernisation web. UX moderne, mobile-friendly, ouverture cloud maximale, talent pool large. Plus d'effort initial mais investissement durable. Vaadin server-side : pour les équipes backend Java sans frontend, applications internes faible trafic, time-to-market prioritaire. Limite la richesse interactive. JavaFX desktop : seulement si besoin desktop confirmé (mode déconnecté, intégration matérielle, performance native) ET si Java est imposé par le SI cible. Sinon, .NET Core WinForms est plus simple pour rester desktop Windows. La décision se prend en phase E4 Architecture cible, pas par défaut.
Pour une application Delphi de 50 à 100 mille lignes en co-delivery nearshore avec frontend web cible, comptez 600 k€ à 1 M€ incluant UX, développement, tests, audit de parité et documentation. Pour des applications plus volumineuses (200 k+ lignes, multi-modules, composants tiers nombreux), comptez 1,2 à 2 M€ sur 12 à 18 mois. Coût équivalent à .NET Core sur volumes comparables, légèrement supérieur si formation Java approfondie pour l'équipe Delphi en transition. Nous cadrons le chiffrage lors de la phase d'Intake avec une fourchette assumée. Voir les modèles de delivery.
Oui, mais pas seule. L'IA accélère deux choses : la lecture du code Delphi (cartographier les intentions des formes DFM, extraire la logique métier des événements VCL, identifier le code mort) et l'écriture du code Java cible pattern par pattern avec traçabilité. Nous mesurons une productivité multipliée par 2 à 3 sur les chantiers de migration legacy quand l'IA est encadrée par une méthodologie structurée et une revue humaine systématique. Ce que l'IA ne remplace pas : la phase de Discovery (comprendre les composants tiers utilisés, les intégrations Windows natives, les RTL spécifiques), les tests de caractérisation écrits avant de toucher au code cible, et l'audit de parité sur jeux de données réels. Notre position : l'IA est le mode opératoire par défaut (vibe coding) à l'intérieur de la méthodologie ATLAS — jamais un remplaçant.
Oui, pendant la phase de coexistence Delphi/Java. Ces profils restent précieux pour deux raisons : lever les ambiguïtés d'interprétation sur des règles métier non documentées dans le code Delphi original, et accompagner les tests de parité sur les cas limites rarement couverts par la documentation. Une fois cette connaissance métier suffisamment intégrée côté Java, ces profils évoluent vers de l'architecture, de la gouvernance ou un nouveau périmètre. Conserver un développeur Delphi senior pendant la phase de coexistence Delphi/Java est non négociable — c'est le filet de sécurité qui évite les régressions silencieuses.
Cela dépend du volume, du nombre d'écrans VCL et de l'ambition de modernisation. ATLAS livre par lots fonctionnels successifs plutôt que sur un plan monolithique : chaque lot est défini avec vous au cadrage, livré avec parité validée, avant d'attaquer le suivant. La variable qui pèse le plus n'est pas le volume — c'est l'état du legacy (composants tiers obsolètes, dépendances Windows natives, dette accumulée) et le choix de l'interface cible (refonte web = effort UX additionnel). Un POC de 4 à 6 semaines sur le code réel du client mesure la productivité effective et chiffre le programme complet de façon fiable.
Quatre disciplines combinées. (1) Tests de caractérisation écrits en amont sur le legacy Delphi : la suite caractérise le comportement avant qu'on touche au code Java. (2) Migration pattern par pattern avec traçabilité ligne à ligne — chaque transformation Pascal→Java est documentée et testée unitairement. (3) Runs parallèles Delphi / Java sur jeux de données client avec comparaison automatique des résultats — objectif > 99 % d'équivalence sur les chemins critiques avant cutover. (4) Registre interne de discordances classées selon une grille CRITIQUE / ADAPTATION / COSMÉTIQUE : chaque écart identifié est documenté, pondéré, arbitré entre Access et le client, classé en interne. C'est ce qui rend le livrable opposable : Access ne s'auto-valide pas. Voir la méthodologie ATLAS complète.
Trois manières de démarrer — du diagnostic court à la cellule complète. Notre approche Delphi → Java 21 est documentée, chiffrée et applicable dès la première rencontre, avec un POC de 4 à 6 semaines pour mesurer la productivité réelle sur votre code.