Porter une application Delphi vers Java et exposer la donnée aux workflows cloud.

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.

Trois variables déterminent le coût d'une migration Delphi vers Java. La part de logique métier enfouie dans les événements VCL, qui doit être extraite avant tout portage. Le nombre de composants tiers sans équivalent Java, à réimplémenter un par un. Et le choix de la cible d'interface : frontend web séparé ou client riche JavaFX. L'Intake mesure les trois avant chiffrage. Cadrage initial gratuit, de 30 minutes à 2 heures.

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.