Architecte web
Conception de l'architecture cible SPA + API REST + base relationnelle, pont entre Object Pascal et l'écosystème web
Loading...
Loading...
Migration d'applications Delphi vers une architecture web moderne : TypeScript, React ou Angular, API REST. 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 client-serveur : formulaires VCL, composants tiers, accès 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, intégrations COM/DCOM.
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.
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é.
Mise en service par lots fonctionnels, double run Delphi ↔ web avec utilisateurs pilotes, bascule 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 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 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.
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.
TypeScript, React ou Angular, 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.
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).
Courbe d'apprentissage plus douce, équipe junior, volonté de framework plus léger. Adapté à des applications de taille modérée.
Écosystème Microsoft préservé, équipes Delphi-.NET en transition. Voir Delphi vers .NET Core.
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é.
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.
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é).
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é.
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.
Ignorer les bases embarquées Delphi (Paradox, dBase, Interbase, SQL Lite). Les conversions vers PostgreSQL ont des subtilités (encoding, types dates, BLOBs, locking).
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.
Oublier les composants Delphi tiers (DevExpress, TMS, Woll2Woll) et leurs équivalents web introuvables. Certains composants Delphi n'ont pas d'équivalent web direct.
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.
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.
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.
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.
Conception de l'architecture cible SPA + API REST + base relationnelle, pont entre Object Pascal et l'écosystème web
TypeScript, React ou Angular, conception d'API, patterns de migration Delphi→web, traçabilité
React ou Angular, reconstitution des écrans VCL en composants web (AG Grid, Material UI)
API REST, portage de la logique métier Object Pascal, authentification JWT/RBAC
Refonte ergonomique du client lourd vers une SPA, maquettes Figma, tests d'utilisabilité
Migration de Paradox, Interbase, FireDAC vers PostgreSQL, audit de parité données
Tests end-to-end (Playwright, Cypress), comparaison legacy/cible, validation des audits ATLAS
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.
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#.
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 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.
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.
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.
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.
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.
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.