Architecte Delphi ↔ .NET
Pont entre Object Pascal/VCL et l'écosystème .NET Core / WinForms ou Blazor
Loading...
Loading...
Migration d'applications Delphi Object Pascal vers .NET Core 8, reconstitution des interfaces natives, portage des bases embarquées. Méthodologie ATLAS.
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 l'application Delphi : formulaires VCL, composants tiers, BDE/FireDAC, code Object Pascal. Reconstituer une analyse fonctionnelle exploitable.
Figer la référence UI : captures d'écrans, parcours utilisateur, données de test. Cartographier composants tiers, bases embarquées, dépendances DLL/COM.
Concevoir l'architecture .NET Core cible : WinForms (parité visuelle), Blazor (web moderne) ou WPF (desktop riche). Choix de la base cible (SQL Server, PostgreSQL). Tests de caractérisation UI.
Porter Object Pascal → C# pattern par pattern, reconstituer les composants visuels VCL en WinForms ou Blazor. Migration incrémentale par formulaire, audit de parité UI signé.
Mise en service par lots fonctionnels, coexistence Delphi ↔ .NET dont la durée est définie au cadrage selon le profil de risque, bascule utilisateur progressive avec formation, transfert d'exploitation.
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.
Les applications Delphi sont massivement présentes dans les métiers d'ingénierie, les bureaux d'étude, les cabinets d'expertise, les ERP sectoriels, la logistique, l'industrie manufacturière, et certaines fonctions spécialisées des administrations. Delphi a dominé le développement d'applications Windows métier entre 1995 et 2010, et beaucoup de ces applications tournent encore aujourd'hui sans avoir été modernisées — fonctionnant parfaitement mais verrouillant l'évolution du SI.
Les raisons typiques de migrer un Delphi : l'éditeur a cessé de livrer des mises à jour majeures sur la version utilisée, les composants VCL tiers ne sont plus maintenus, l'application ne fonctionne qu'en architecture client lourd Windows alors que les utilisateurs demandent du web ou du mobile, ou le code est devenu difficile à faire évoluer faute d'expertise Delphi disponible. Notre méthodologie ATLAS encadre cette transition avec parité fonctionnelle prouvée sur chaque écran migré.
Le choix de .NET Core comme cible s'impose dans trois situations. Quand l'entreprise est déjà dans l'écosystème Microsoft (Azure, Dynamics 365, Power Platform, SQL Server dominant). Quand l'application doit continuer à exister en version desktop Windows pour des raisons métier (fonctionnement offline, intégration matérielle, performance native). Quand les équipes internes maîtrisent mieux C# que Java — la syntaxe Pascal se traduit quasi mot-à-mot en C#. Si votre cible est plutôt le web cloud-native, regardez Delphi vers TypeScript. Si votre SI cible est dominé par Java (Spring, JEE, intégrations Java existantes), regardez plutôt Delphi vers Java.
.NET Core 8, C#, WinForms ou Avalonia, SQL Server
Conserver une application desktop native avec portabilité Windows-Linux-macOS si Avalonia est choisi. Adapté aux métiers qui ont besoin d'un client lourd performant ou offline.
Passer d'un client lourd à une application web tout en restant dans l'écosystème .NET. Bon compromis quand les utilisateurs métier veulent accéder à l'application via navigateur sans réinstallation.
Moderniser totalement vers une architecture web cloud-native. Voir le parcours Delphi vers TypeScript. Choix adapté quand l'entreprise migre son SI vers des standards web.
Écosystème cible Java déjà dominant dans le SI. Nécessite une réécriture complète, la syntaxe Pascal et Java étant moins proches que Pascal et C#. Voir le parcours dédié Delphi vers Java.
Une migration Delphi vers .NET Core se planifie par lots fonctionnels successifs, dont la cadence est définie au cadrage selon le volume d'écrans et la complexité des intégrations. L'équipe type associe un architecte Delphi-.NET capable de faire le pont entre les deux écosystèmes, un tech lead .NET, des développeurs maîtrisant C# et idéalement avec un passé Pascal, un QA spécialisé en tests UI, un UX designer pour la recomposition ergonomique si elle est souhaitée. 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é.
Considérer la migration Delphi comme plus simple que COBOL et sous-estimer les pièges. La syntaxe Pascal est proche du C#, mais les composants VCL, la gestion manuelle de la mémoire et les DLL tierces recèlent des surprises.
Inventaire exhaustif des composants tiers dès la phase d'Intake. Chaque composant VCL non-standard est qualifié : équivalent .NET disponible, équivalent open source, ou réécriture nécessaire. Les applications Delphi ont généralement dix à trente pour cent de leur code dans des composants tiers — c'est là que se cachent les retards.
Migrer l'interface utilisateur pixel à pixel sans saisir l'occasion de moderniser l'ergonomie. Le résultat est une application .NET qui ressemble à du Delphi de 2005.
Séparation explicite entre migration technique (parité fonctionnelle) et refonte ergonomique (phase distincte). Sur notre expérience de refonte d'applications d'analyse structurale Delphi vers .NET Core, la phase ergonomique a été cadrée après la bascule fonctionnelle pour éviter de mélanger les deux chantiers.
Ignorer les spécificités Pascal — gestion des strings (AnsiString vs UnicodeString), types managés vs non managés, record vs class, property vs field.
Mapping systématique des types Pascal vers .NET documenté dans le registre de discordances. Les AnsiString deviennent des string .NET avec encoding explicite. Les records Pascal deviennent des struct C# pour préserver la sémantique de valeur. Chaque cas est tracé.
Oublier les bases de données embarquées (Paradox, dBase, Interbase) et leurs particularités (curseurs bidirectionnels, BLOBs, locking optimiste).
Portage progressif vers SQL Server ou PostgreSQL avec compatibility layer pour les cas où la sémantique est trop proche du moteur d'origine. Les BLOBs Delphi sont migrés vers des varbinary(max) ou bytea selon le moteur cible, avec tests de parité sur taille et intégrité.
Déclarer la parité UI en se basant uniquement sur des captures d'écran statiques. Les workflows complets en conditions réelles réservent toujours des surprises.
Principe E7 — validation navigateur et workflow obligatoire avant livraison. Chaque workflow métier est rejoué en conditions réelles, avec les jeux de données réels, et comparé à l'application Delphi en parallèle. Voir la méthodologie ATLAS complète.
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 .NET Core / WinForms ou Blazor
.NET Core 8, C#, refactoring de patterns Delphi vers C#, gestion des composants tiers
Idéalement avec passé Delphi ou C# pour porter le code et les composants visuels
Migration de Paradox, BDE, FireDAC vers SQL Server, audit de parité données
Refonte des écrans Delphi VCL vers WinForms ou Blazor, parité ergonomique auditée
Bench de tests UI, comparaison legacy/cible, validation des audits ATLAS
Capacité Access validée sur POC interne représentatif d'application Delphi métier critique. Patterns Delphi → .NET Core 8 + PostgreSQL éprouvés sur cas représentatif, parité fonctionnelle auditée.
POC Raptor Delphi converti pour valider la difficulté relative à une migration COBOL. Difficulté estimée à quatre sur dix pour Delphi contre sept sur dix pour COBOL.
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.
Trois manières de démarrer — du diagnostic gratuit à la cellule complète. Notre approche Delphi → .NET Core 8 préserve la parité fonctionnelle et la parité ergonomique des écrans.