Porter une application Delphi vers .NET Core 8 avec parité UI.

Oui, Embarcadero continue de livrer des versions majeures de Delphi (dernière version 12 Athens en 2024) avec un écosystème actif. La migration n'est donc pas une nécessité technique absolue. Elle devient pertinente quand l'application devient difficile à faire évoluer faute d'expertise, quand les composants tiers utilisés ne sont plus maintenus, ou quand l'entreprise standardise son SI sur un autre stack. Le calendrier est rarement dicté par l'éditeur.

La migration peut être progressive si l'application est modulaire. La méthodologie ATLAS applique le pattern strangler fig — on migre un module à la fois, en maintenant une intégration entre code Delphi existant et code .NET nouveau via une couche de service. Cette approche est particulièrement adaptée aux applications Delphi structurées en modules métier. Pour les applications monolithiques avec un code très couplé, une refonte d'un seul tenant est parfois plus réaliste.

Cela dépend du choix de cible. Si vous migrez vers .NET WinForms avec une parité UI pixel à pixel, les utilisateurs formés à l'ancienne application retrouvent leurs repères immédiatement. Si vous passez à Blazor ou à une application web, il y a une phase d'accompagnement indispensable. Nous recommandons une communication claire en amont sur les changements volontaires (fonctionnalités ajoutées, ergonomie modernisée) et une parité stricte sur les éléments conservés.

Les rapports QuickReport ou FastReport sont migrés vers des composants .NET comme DevExpress Reports, FastReport .NET, Stimulsoft, ou vers des solutions web comme Crystal Reports ou des générateurs PDF à la volée. Le choix dépend du volume de rapports, de la complexité des mises en page et du mode de consommation (impression papier, PDF, export Excel). Pour un parc de plusieurs dizaines de rapports, nous mettons en place un template de migration appliqué rapport par rapport avec validation visuelle.

Cas fréquent sur les applications Delphi anciennes. Trois options : remplacer par un composant .NET équivalent (meilleure option si disponible), réécrire le composant en .NET avec parité fonctionnelle (effort modéré à important), ou externaliser la fonctionnalité dans un service séparé appelé par l'application. Le choix se fait au cas par cas en fonction de la criticité du composant, du temps d'ingénierie nécessaire et des licences nouvelles envisagées.

Un développeur Delphi expérimenté maîtrise l'essentiel de C# et .NET Core en deux à quatre semaines, grâce à la proximité syntaxique Pascal-C#. La bonne pratique est de construire l'équipe de migration en mixant deux à trois développeurs .NET seniors avec deux à trois développeurs Delphi formés progressivement au stack cible. Cette mixité permet aux développeurs Delphi de porter la connaissance métier et aux développeurs .NET d'apporter les bonnes pratiques du framework cible.

Delphi n'est pas techniquement obsolète — Embarcadero publie régulièrement des mises à jour RAD Studio et Delphi 12 est sorti en 2023 avec un compilateur modernisé. Le vrai sujet, c'est l'écosystème et les compétences : le vivier de développeurs se réduit, les éditeurs tiers (DevExpress, TMS) dépriorisent Delphi progressivement, et l'intégration aux stacks cloud, IA et web modernes demande des contournements croissants. Pour des applications qui tournent et n'évoluent peu, garder Delphi reste rationnel. Pour des applications qui doivent s'ouvrir en API, supporter du mobile ou intégrer de l'IA, la modernisation vers .NET Core, TypeScript ou Java est le chemin. La méthodologie ATLAS encadre cette migration avec parité fonctionnelle prouvée. Voir le parcours Delphi vers .NET Core.