Migration Delphi vers application web — Sortir du Windows-only sans tout réécrire

#Le parc Delphi en France — Un héritage massif encore bien vivant

Delphi n'est pas mort. C'est l'erreur de perception la plus fréquente chez les DSI qui héritent d'une application Object Pascal en 2026 — ils supposent que le logiciel est hors de tout support et que personne d'autre ne fait face au même problème. La réalité est différente : selon les estimations IDC pour le marché européen, environ 15 000 applications Delphi restent en production active dans les entreprises françaises. Ce chiffre couvre aussi bien les petites applications de gestion interne (50 utilisateurs) que les ERP GPAO structurants de groupes industriels mid-size (3 000 utilisateurs).

#Distribution des versions en production

La distribution des versions donne la mesure du problème. Environ 30 % du parc tourne encore sur Delphi 7 (2002) ou Delphi 2007 — des versions antérieures à Unicode natif, antérieures aux génériques, et construites sur une architecture VCL 32 bits qui n'a jamais été pensée pour le web. Les versions Delphi XE (XE2 à XE8, 2011-2015) représentent environ 25 % du parc. Les versions Delphi 10.x (Seattle, Berlin, Tokyo, Rio, Sydney, Alexandria — 2015-2023) constituent le tiers restant, souvent dans des entreprises qui ont maintenu une mise à jour régulière de leur environnement Embarcadero sans pour autant repenser l'architecture fondamentale de leur application.

Embarcadero Technologies (racheté par Idera en 2015) maintient Delphi en vie avec des releases annuelles. La dernière version stable, Alexandria 11.3, apporte des améliorations substantielles — support LSP, compilateur ARM 64 bits pour mobile, intégration REST client. Mais aucune de ces évolutions ne résout le problème structurel pour les entreprises qui ont besoin d'une application accessible depuis un navigateur, d'un smartphone, ou intégrée dans une plateforme SaaS tiers via API REST.

#Secteurs les plus exposés

Quatre secteurs concentrent la majorité du parc Delphi encore actif en France :

• Industrie manufacturière : GPAO (Gestion de Production Assistée par Ordinateur), ordonnancement, gestion des nomenclatures. Delphi 7 et 2007 ont équipé une génération entière d'éditeurs de logiciels industriels français dans les années 2000. Ces ERP Delphi tournent parfois sur des Windows XP ou Windows 7 embarqués dans des postes de production — le couplage entre la version Windows et la version Delphi est lui-même un risque.
• Logistique : TMS (Transport Management System), gestion d'entrepôts, interfaces EDI avec les transporteurs. Les applications Delphi de TMS pré-API reposent souvent sur des échanges de fichiers plats (CSV, EDI X12/EDIFACT) au lieu d'API REST, ce qui les exclut des plateformes logistiques modernes (Shiptify, Transporeon, etc.).
• Immobilier : logiciels de gestion locative, de syndic, de transactions. De nombreux éditeurs français de ce secteur (ETI régionales) ont un codebase Delphi 2007 ou XE qui court depuis 15 ans avec des évolutions cosmétiques.
• Assurance : back-office de courtage, gestion des sinistres, outils de tarification. La contrainte ACPR sur les systèmes d'information assurance rend la modernisation à la fois plus complexe et plus urgente.

#Les problèmes structurels du statu quo Delphi

Maintenir une application Delphi en production en 2026 n'est pas impossible. Mais les coûts cachés du statu quo s'accumulent sur trois axes — technique, organisationnel et commercial — jusqu'à ce qu'un événement déclencheur force la décision de migration.

#Windows-only : l'exclusion mobile et web comme frein business

La VCL (Visual Component Library) est le framework d'interface graphique natif de Delphi. Elle génère du code Windows API natif — des fenêtres Win32, des contrôles communs Windows, des événements messages Windows. C'est sa force historique (performances, look-and-feel Windows natif) et son talon d'Achille structurel : une application VCL est et restera Windows-only. Il n'existe pas de chemin de migration de la VCL vers un navigateur. La FMX (FireMonkey), introduite par Embarcadero Delphi XE2, permet de créer des applications multiplateformes (macOS, iOS, Android) à partir du même code — mais ne résout pas l'accès depuis un navigateur web, et FMX représente une réécriture partielle significative de l'interface.

Concrètement, pour une ETI dont les commerciaux travaillent avec des tablettes ou des smartphones : aucun accès à l'ERP Delphi hors du réseau local (sauf VPN, avec toute la friction associée). Pour une plateforme SaaS B2B souhaitant proposer un portail client web : impossible sans reconstruire l'interface de zéro. Pour une application de gestion de production devant s'intégrer à un MES moderne via API REST : les connexions BDE/Firebird ne parlent pas REST nativement.

#BDE et Firebird : des couches d'accès aux données bloquantes

Le BDE (Borland Database Engine) est la couche d'accès aux données historique de Delphi — introduite dans les années 90, officiellement dépréciée par Embarcadero depuis 2009, elle équipe encore une proportion significative du parc Delphi en production. Le BDE supporte nativement Paradox, dBASE, InterBase et Firebird via des pilotes ODBC propriétaires. Il est installé en local sur chaque poste client, crée des problèmes de déploiement sur Windows 10 et 11 (compatibilité 64 bits bridée), et ne supporte pas les connexions aux bases de données modernes (PostgreSQL, MySQL/MariaDB, SQL Server avec protocoles récents).

Firebird — fork open source d'InterBase, la base de données historiquement liée à Borland/Embarcadero — est une base de données robuste et performante. Le problème n'est pas Firebird en tant que tel, mais l'architecture qui l'entoure dans les applications Delphi legacy : accès direct aux tables sans couche ORM, logique métier embarquée dans des triggers et procédures stockées difficiles à documenter et à faire évoluer, schéma de données évoluant "à la main" sans migration versionnée (Flyway, Liquibase), absence de réplication et de haute disponibilité pour les configurations de production critiques.

#La crise de recrutement des développeurs Delphi

C'est souvent l'événement déclencheur de la décision de migration. La population de développeurs Delphi actifs en France vieillit structurellement — l'âge moyen est estimé à 50+ ans, selon les analyses de la communauté DelphiPraxis et les enquêtes Stack Overflow Developer Survey (Delphi/Object Pascal représentait 1,8 % des langages utilisés mondialement en 2024, en baisse continue). Les développeurs Delphi expérimentés capables de maintenir des applications VCL/BDE se raréfient sur le marché, pratiquent des tarifs élevés (TJM à partir de 592 € HT pour un freelance qualifié), et sont souvent occupés à maintenir leur propre portefeuille de clients legacy.

Par contraste, l'écosystème React/TypeScript/Next.js compte plusieurs centaines de milliers de développeurs actifs en France. Le ratio de disponibilité est d'environ 1 pour 50 en faveur des stacks web modernes. Une ETI qui perd son développeur Delphi interne — par départ en retraite, démission, ou longue maladie — se retrouve en situation de crise opérationnelle immédiate : le code tourne mais ne peut plus être modifié, corrigé, ni évoluer.

#Stagnation de l'écosystème et impossibilité du CI/CD

L'écosystème de packages Delphi (GetIt Package Manager chez Embarcadero, Delphinus Community, JVCL) est sans commune mesure avec npm/yarn côté JavaScript — ni en volumétrie (quelques centaines de packages actifs vs plusieurs millions de packages npm), ni en cadence de mise à jour. Les librairies tierces pour Delphi (composants de reporting, intégration PDF, charteurs, gestionnaires de protocoles) sont souvent maintenues par des individus ou de petites structures, avec des cycles de mise à jour de 12 à 24 mois.

La mise en place d'un pipeline CI/CD sur une application Delphi traditionnelle est difficile, bien que pas impossible avec RAD Studio en ligne de commande. La compilation Delphi est Windows-only (le compilateur ne tourne pas sur Linux, ce qui exclut les runners GitLab CI ou GitHub Actions standard), les tests unitaires via DUnit/DUnitX sont peu utilisés dans les codebases legacy, et le déploiement d'une application VCL reste typiquement un processus manuel (copie des binaires EXE + DLL, gestion des dépendances d'exécution Delphi runtime). Les équipes DevOps modernes qui rejoignent des entreprises avec un parc Delphi se retrouvent face à une chaîne de livraison qui n'évolue pas.

#Trois options de migration Delphi — Laquelle choisir

Il n'y a pas une seule bonne réponse à la question "comment migrer mon application Delphi". Le choix dépend de la profondeur de la dette technique, du budget disponible, des contraintes de continuité de service et des objectifs à moyen terme. Nehos qualifie ces critères lors de l'audit initial avant toute recommandation.

#Option A — Réécriture complète (Greenfield)

La réécriture de zéro consiste à concevoir et développer une nouvelle application web en partant d'une page blanche, en s'appuyant sur les spécifications fonctionnelles de l'application Delphi existante comme cahier des charges métier.

Quand c'est recommandé. Le codebase Delphi est un "spaghetti" irrémédiable : logique métier éparpillée entre triggers Firebird, formulaires VCL et unités Pascal sans structure, zéro couverture DUnit, aucune documentation. La complexité d'extraction de la logique métier par couches est supérieure à la complexité de la réécriture. La base d'utilisateurs est petite (moins de 50 utilisateurs actifs), ce qui réduit le risque de la bascule finale. L'application a une périmètre fonctionnel stable et bien documenté — les spécifications sont connues et ne vont pas changer pendant la réécriture.

Quand c'est déconseillé. L'application est structurante pour des centaines ou milliers d'utilisateurs en production. La logique métier est partiellement implicite — des comportements émergent de la combinaison de triggers, d'événements VCL et de procédures stockées que personne ne documente exhaustivement. Le budget est contraint (la réécriture est toujours l'option la plus coûteuse, et elle prend systématiquement 2 à 3 fois plus de temps qu'estimé — syndrome du second système, cf. Fred Brooks). Nehos recommande l'option A dans moins de 20 % des projets Delphi.

#Option B — Strangler Fig Application (recommandée pour 60-70 % des projets)

Le pattern Strangler Fig (Martin Fowler, 2004) est la voie de migration progressive par excellence pour les applications en production. Le principe : on ne remplace pas l'application Delphi d'un coup, on la "étrangle" progressivement — en exposant sa logique métier via une API REST, puis en reconstruisant l'interface utilisateur écran par écran en React/Next.js, jusqu'à ce que l'application Delphi soit complètement supplantée et puisse être décommissionnée.

Etape 1 — Exposition REST de la logique Delphi. Embarcadero fournit deux solutions natives pour exposer du code Delphi en REST : RAD Server (anciennement EMS — Enterprise Mobility Services), un serveur HTTP intégré à Delphi qui permet de créer des endpoints REST à partir d'unités Pascal existantes, et WebBroker, le framework web historique de Delphi (disponible depuis Delphi 4, toujours maintenu). Pour les versions Delphi plus anciennes (Delphi 7, 2007) sans accès à RAD Server, une alternative est d'exposer la logique métier via un service Windows qui écoute sur un port TCP et communique en JSON — une approche minimaliste mais opérationnelle qui évite de toucher au code Delphi original. Cette couche API Delphi coexiste avec l'application VCL pendant toute la durée de la migration.

Etape 2 — Reconstruction progressive du front React/Next.js. Chaque écran VCL est analysé, traduit en composants React, connecté à l'API Delphi. On commence par les écrans les moins critiques et les moins couplés (formulaires de consultation, tableaux de bord reporting) pour gagner de la pratique avant de migrer les écrans transactionnels (saisie de commandes, validation de gammes, enregistrement de sinistres). Un feature flag contrôle quel écran est servi depuis l'interface web ou depuis le client Delphi — les deux coexistent pendant la migration.

Etape 3 — Migration base de données BDE/Firebird → PostgreSQL. En parallèle de la migration des écrans, la base de données est migrée de Firebird (ou Paradox/BDE) vers PostgreSQL 16. Firebird-to-PostgreSQL est un chemin balisé : la syntaxe SQL est très proche, les procédures stockées PL/pgSQL couvrent les mêmes cas d'usage que les triggers Firebird, et des outils comme pgloader automatisent la migration des données. La migration DB se fait en mode double-write (écriture simultanée sur Firebird et PostgreSQL pendant la phase de transition) pour garantir la cohérence jusqu'à la bascule finale.

Durée typique option B : 6 à 18 mois selon le nombre d'écrans et la complexité de la logique métier. Budget : à partir de 51 k€ HT.

#Option C — Transcoding semi-automatisé via RemObjects Oxygene

RemObjects Oxygene (anciennement Chrome) est un compilateur Object Pascal multi-cible qui compile du code Pascal vers .NET (C#/IL), Java, JavaScript/WebAssembly et Go. L'idée est d'utiliser Oxygene comme étape intermédiaire : le code Pascal Delphi existant est transcodé semi-automatiquement vers C# ou JavaScript, puis la migration vers la stack cible (NestJS, Next.js) se poursuit ce transcodage.

En pratique. Le transcoding Delphi → C# via Oxygene fonctionne bien pour la logique métier pure (unités Pascal sans dépendances VCL). La VCL elle-même — et donc tous les formulaires, événements et composants visuels — ne se transpose pas automatiquement : il faut de toute façon reconstruire l'interface de zéro. La valeur d'Oxygene est donc limitée à accélérer la migration de la logique métier des couches non-UI (calculs, règles de gestion, accès données abstraits). Nehos l'utilise ponctuellement en option C pour les projets avec une logique métier volumineuse et bien isolée des couches VCL, comme étape intermédiaire vers NestJS (TypeScript). Ce n'est pas une panacée — le code transcodé nécessite un nettoyage manuel significatif — mais ça peut réduire la durée de la phase de migration back-end de 20 à 30 % sur les projets adaptés.

Recommandation Nehos : Option B (Strangler Fig) ou C (Oxygene + Strangler Fig) selon le ratio logique métier / UI dans le codebase Delphi et selon le budget. L'audit technique initial permet de qualifier ce choix sur la base de métriques concrètes.

#Stack cible — Next.js 15 + React 18 + NestJS/FastAPI + PostgreSQL 16

La stack cible recommandée par Nehos pour les migrations Delphi est construite autour de quatre blocs techniques.

#Frontend — Next.js 15 + React 18 + TypeScript

Next.js 15 avec App Router (React Server Components) remplace les formulaires VCL. Le choix de Next.js s'explique par trois avantages concrets pour des applications B2B issues de migrations Delphi :

• SSR et performance : les pages de tableau de bord, de reporting et de consultation sont rendues côté serveur (React Server Components) — TTFB sous 200 ms contre 2 à 5 secondes de démarrage pour une application Delphi lourde. Les formulaires de saisie complexes utilisent les Client Components React 18 avec Concurrent Features pour une réactivité optimale.
• Composants de formulaires riches : les applications Delphi sont typiquement des environnements riches en formulaires de saisie (grilles, lookups, validations complexes). L'écosystème React 18 — React Hook Form, Zod pour la validation, TanStack Table pour les grilles, shadcn/ui pour les composants — couvre ces cas d'usage sans compromis.
• TypeScript bout en bout : le typage statique TypeScript prévient une classe entière de bugs qui sont courants dans les migrations (mauvais typage des champs de formulaires, erreurs d'appel API) et facilite le recrutement de développeurs sur la stack.

Pour l'état UI local (l'équivalent des événements VCL — OnChange, OnClick, état des formulaires), Nehos utilise Zustand ou Jotai selon la complexité du state management. Ces librairies légères remplacent naturellement le modèle événementiel VCL sans l'overhead d'un Redux complet.

#Backend — NestJS (Node.js) ou FastAPI (Python)

Le choix entre NestJS et FastAPI dépend principalement des compétences disponibles dans l'équipe interne et des besoins d'intégration :

NestJS (TypeScript/Node.js) est recommandé quand le projet vise une stack TypeScript homogène bout en bout (Next.js frontend + NestJS backend), quand l'application Delphi d'origine expose beaucoup de logique métier orientée objet qui se traduit naturellement en modules/services NestJS, et quand des intégrations IA (LangChain.js, agents Claude) sont prévues dans la feuille de route.

FastAPI (Python) est recommandé quand l'application Delphi d'origine comporte des algorithmes de calcul complexes (ordonnancement GPAO, optimisation logistique, tarification assurance) qui se portent naturellement en Python, quand l'équipe interne a des profils Python data/IA, et quand des modèles de machine learning doivent être intégrés au back-end applicatif.

Pour l'ORM et la couche d'accès aux données PostgreSQL : Prisma (typage automatique du schéma DB en TypeScript, migrations versionnées, client type-safe) avec NestJS, SQLAlchemy 2.0 avec FastAPI. La gestion des migrations de schéma se fait via Flyway ou les migrations intégrées Prisma, assurant la traçabilité de chaque évolution du schéma — en rupture totale avec l'approche "ALTER TABLE à la main" des bases Firebird/BDE legacy.

Pour l'authentification : NextAuth v5 pour les applications avec authentification gérée côté Next.js (SSO simple, OAuth2), ou Keycloak déployé sur OVHcloud pour les projets enterprise avec SSO LDAP/Active Directory existant — une migration naturelle depuis les systèmes d'authentification Windows AD souvent associés aux environnements Delphi.

#Base de données — PostgreSQL 16 (hébergement OVHcloud souverain)

PostgreSQL 16 remplace Firebird, Paradox et BDE. Les avantages sont mesurables : réplication native (streaming replication + logical replication), partitionnement de tables pour les grandes tables historiques (ordres de fabrication, historiques de transport, journaux de sinistres), JSONB pour les colonnes semi-structurées (paramétrage flexible des gammes ou des contrats), pgvector pour les futurs usages IA (recherche sémantique dans les documents techniques). L'hébergement est systématiquement sur OVHcloud (infra souveraine française, RGPD natif, certifications HDS disponibles pour les données de santé).

→ Vous évaluez vos options ? Utilisez notre estimateur de budget en ligne pour obtenir une fourchette en 2 minutes, ou consultez nos tarifs détaillés.

#Méthodologie Nehos — Les 4 phases d'une migration Delphi

#Phase 1 — Inventaire et cartographie (3 à 6 semaines)

L'audit technique est la condition préalable à tout projet de migration. Sans inventaire précis, toute estimation de coût ou de durée est sans fondement. Nehos structure cet audit autour de quatre axes :

Analyse AST du code Pascal. Un parser AST (Abstract Syntax Tree) appliqué au codebase Delphi identifie automatiquement les unités Pascal (.pas), les formulaires VCL (.dfm), les dépendances entre unités, les appels aux composants VCL, les accès BDE/TDataSet, et les procédures et fonctions publiques — autant de "business rules" candidates à l'exposition REST en Phase 2. Des outils comme DelphiAST (open source) et une analyse statique via Castalia (pour les versions récentes Delphi) fournissent cette cartographie en quelques heures sur des codebases de taille moyenne.

Cartographie du schéma de base de données. Le schéma Firebird (ou Paradox, ou InterBase) est exporté, analysé et documenté : nombre de tables, colonnes, clés étrangères explicites et implicites (intégrité référentielle gérée applicativement), procédures stockées et triggers, volume de données par table, index manquants détectés via EXPLAIN PLAN sur les requêtes les plus fréquentes. Cette cartographie conditionne le plan de migration DB vers PostgreSQL et l'identification des tables critiques (les tables avec des millions de lignes nécessitant une stratégie de migration par batch).

Identification des règles métier implicites. Les applications Delphi legacy concentrent souvent des règles métier dans des endroits inattendus : calculs dans des événements OnChange de formulaires VCL, validations dans des triggers Firebird, transformations de données dans des procédures stockées. L'inventaire AST combiné à une lecture systématique des unités métier et à des entretiens avec les utilisateurs experts permet de documenter ces règles avant qu'elles ne soient perdues lors de la migration.

Comptage et priorisation des écrans. Chaque formulaire VCL (.dfm) est inventorié, décrit fonctionnellement ("formulaire de saisie bon de commande", "tableau de bord stock", "module calcul prix de revient") et évalué selon deux critères : complexité de migration (nombre de composants VCL, logique événementielle, appels DB) et valeur business (fréquence d'utilisation, criticité pour les processus métier). Cette matrice complexité × valeur détermine l'ordre de migration dans les phases suivantes.

Output de l'audit : rapport de 20 à 40 pages, cartographie des modules, recommandation de voie de migration (A, B ou C), plan de migration phase par phase avec estimation de charge, budget et timeline.

#Phase 2 — API-first — Exposition REST/GraphQL des fonctions métier critiques

Sur la base de la cartographie Phase 1, on identifie les fonctions métier Delphi les plus sollicitées (top 20 % par fréquence d'appel) et on les expose via une couche API REST. Techniquement, deux approches selon la version Delphi :

• Delphi 10.x (Seattle et suivants) : utilisation de RAD Server (serveur HTTP intégré Embarcadero) ou du composant TRESTResponseDataSetAdapter. RAD Server permet de créer des endpoints REST annotés directement dans le code Pascal et expose automatiquement un Swagger/OpenAPI. C'est la voie la plus rapide pour les versions récentes.
• Delphi 7 / 2007 / XE : utilisation de WebBroker (framework HTTP natif Delphi, disponible depuis D4) ou création d'un service Windows WinAPI qui écoute sur un port HTTP et répond en JSON pur. Cette approche est plus manuelle mais compatible avec toutes les versions Delphi.

L'API Delphi ainsi créée est documentée via OpenAPI 3.1 (soit générée automatiquement par RAD Server, soit écrite manuellement pour les versions plus anciennes). Elle constitue le contrat d'interface entre la couche Delphi et le nouveau frontend React — et restera en production pendant toute la durée de la migration front-end.

#Phase 3 — Frontend progressif — Reconstruction des écrans en React

Les écrans VCL sont reconstruits en composants React/Next.js, en commençant par les écrans de consultation et de reporting (lecture seule, moins risqués) et en finissant par les écrans de saisie transactionnels (écriture, validations métier critiques). Chaque écran migré passe par :

1. Analyse du formulaire VCL : extraction des champs, règles de validation, comportements événementiels, appels DB.
2. Maquette UI React : redesign de l'écran avec les composants shadcn/ui, Tailwind CSS — l'occasion de moderniser l'UX en même temps que la migration technique.
3. Connexion à l'API Delphi : le composant React appelle les endpoints REST créés en Phase 2. TanStack Query gère le cache et la synchronisation côté client.
4. Tests Playwright : les parcours utilisateurs critiques de l'écran migré sont couverts par des tests E2E automatisés.
5. Feature flag et déploiement progressif : l'écran est mis en production derrière un feature flag. 10 % des utilisateurs sont basculés sur la version React, on surveille les métriques (erreurs JS, temps de réponse, comportements utilisateurs via Hotjar/PostHog), puis on monte progressivement à 100 %.

#Phase 4 — Cutover et décommissionnement de l'application Delphi

Une fois 100 % des écrans migrés vers React et 100 % du trafic utilisateur routé vers la nouvelle interface web, la migration de la base de données est finalisée (bascule complète Firebird → PostgreSQL avec vérification d'intégrité). L'application Delphi est archivée (tag Git, snapshot binaire) et les postes Windows dédiés peuvent être redéployés. La couche API Delphi (RAD Server ou WebBroker) est décommissionnée ou maintenue temporairement si des processus batch ou des intégrations tierces l'utilisent encore.

Formation de l'équipe interne à la nouvelle stack (Next.js + NestJS/FastAPI + PostgreSQL). Documentation technique (ADR — Architecture Decision Records, README, diagrammes de flux métier). Forfait MCO mensuel optionnel pour les clients sans équipe technique interne suffisante.

Durée totale selon périmètre :

#Métriques de réussite — Ce qui change concrètement après migration

Une migration Delphi réussie se mesure sur des KPIs tangibles, pas sur des déclarations d'intention technologique.

Accessibilité. 100 % accessible depuis un navigateur web standard (Chrome, Firefox, Safari, Edge) — sans installation d'un client Windows, sans VPN obligatoire pour les accès mobiles. Les tablettes et smartphones accèdent directement à l'application via HTTPS.

Performance. TTFB (Time to First Byte) inférieur à 200 ms pour les pages de consultation (Next.js SSR/ISR sur OVHcloud), contre 2 à 5 secondes de démarrage à froid pour une application Delphi lourde. Les grilles de données — souvent le point de douleur performance des applications Delphi avec des TDBGrid non virtualisés — affichent 10 000+ lignes sans freeze grâce à la virtualisation de TanStack Table.

Déploiement continu. Release en 15 à 30 minutes via pipeline GitLab CI/GitHub Actions, sans fenêtre de maintenance ni déploiement manuel. Zero-downtime deployments avec rolling update sur OVHcloud Kubernetes. Contra les releases manuelles des applications Delphi (copie EXE + notification aux utilisateurs de relancer le client).

Recrutement. Le pool de développeurs React/TypeScript/Next.js est 50 fois plus large que le pool de développeurs Delphi actifs en France. Time-to-hire divisé par 3 à 5 en pratique. Coût salarial des profils React 30 à 40 % inférieur aux rares profils Delphi expérimentés disponibles en 2026.

Dette technique. Score SonarQube sur le nouveau code (TypeScript + NestJS/FastAPI) : objectif A sur toutes les métriques (maintenabilité, fiabilité, sécurité) dès la mise en production. Couverture de tests : 70-80 % sur le code backend (Jest + NestJS), parcours E2E critiques couverts par Playwright.

#Cas pratiques — 3 migrations Delphi par secteur

#ERP GPAO industriel — Delphi 7 → Next.js (3 000 utilisateurs, 18 mois)

Un équipementier automobile mid-size (1 200 salariés, 3 sites de production) exploitait depuis 2004 un ERP GPAO maison développé en Delphi 7 — 120 formulaires VCL, base de données Firebird 2.5, 3 000 utilisateurs internes sur les sites de production. Le code Delphi avait été maintenu par une équipe de 2 développeurs internes dont l'un partait en retraite en 2025. La priorité absolue : ne pas bloquer la production pendant la migration.

Mission Nehos : audit technique (4 semaines, cartographie de 8 modules métier, 120 formulaires VCL, 340 tables Firebird, 180 procédures stockées), migration Strangler Fig en Option B sur 18 mois, exposition REST via RAD Server sur les modules critiques (ordonnancement, gammes, nomenclatures), reconstruction progressive des écrans en Next.js 15 + React 18 + NestJS, migration Firebird 2.5 → PostgreSQL 16 en double-write pendant 8 mois. 0 interruption de production sur toute la durée. Résultats : 100 % des 3 000 utilisateurs accessibles depuis navigateur (tablettes en atelier incluses), temps de chargement des grilles de nomenclature divisé par 4, recrutement de 2 développeurs React junior en 3 semaines (vs 0 candidat Delphi en 6 mois de recherche).

#TMS logistique — Delphi XE → React + FastAPI (intégration API transporteurs)

Un commissionnaire de transport français (400 salariés) utilisait un TMS développé en Delphi XE2 depuis 2012, avec des échanges EDI fichiers plats avec ses transporteurs partenaires (DHL, Geodis, DB Schenker). La plateforme Transporeon exigeait des intégrations API REST que le TMS Delphi ne supportait pas nativement. La migration vers une stack API-first était devenue une condition d'accès à plusieurs appels d'offres logistiques.

Mission Nehos : audit (3 semaines, codebase Delphi XE2 de 65 000 lignes, 55 formulaires VCL, base InterBase), migration Option B sur 11 mois, exposition REST des fonctions TMS critiques via WebBroker Delphi XE2, reconstruction frontend React + Next.js 15, backend FastAPI Python (migration des algorithmes d'optimisation tournées vers Python), intégration API REST Transporeon + DHL Express + Geodis. Migration InterBase → PostgreSQL 16 en 4 mois. Résultats : intégration Transporeon opérationnelle en M+8, accès mobile pour les conducteurs (application PWA Next.js), traitement EDI remplacé par des webhooks REST temps réel, réduction des erreurs de saisie manuelle de 67 %.

#Back-office assurance — Delphi 2007 → NestJS + React (conformité ACPR)

Un courtier en assurance de niche (IARD, 85 collaborateurs) gérait ses contrats et sinistres via un back-office Delphi 2007 développé entre 2007 et 2015. L'application tournait sur un réseau local Windows uniquement — aucun accès distant pour les gestionnaires en télétravail post-COVID. L'ACPR avait par ailleurs exprimé des réserves lors d'un contrôle sur la traçabilité des accès au système de gestion des sinistres (pas de logs d'accès structurés sur la base Firebird).

Mission Nehos : audit (5 semaines, codebase Delphi 2007 60 000 lignes, 70 formulaires VCL, base Firebird 3.0, 0 couverture DUnit), migration Option B sur 14 mois, exposition REST via WebBroker + wrapper JSON maison (Delphi 2007 sans RAD Server), reconstruction React + NestJS + PostgreSQL 16 avec pgaudit pour les logs d'accès ACPR, authentification Keycloak SSO avec SSO Azure AD (harmonisation avec l'environnement Microsoft 365 du cabinet). Conformité ACPR rétablie dès M+10 (logs d'accès structurés sur PostgreSQL + pgaudit). Télétravail 100 % opérationnel en M+14. Résultats : 0 remarque ACPR lors du contrôle suivant (M+18), adoption par les gestionnaires 94 % (NPS +22 vs l'ancienne interface Delphi), coût d'infra réduit de 35 % (plus de serveur terminal Windows Server dédié).

#Pricing — 212 k€ HT selon périmètre

La tarification d'une migration Delphi dépend directement de trois variables : le nombre d'écrans VCL à migrer, la profondeur de la dette technique mesurée lors de l'audit (version Delphi, complexité de la logique métier, état du schéma de base de données), et la voie de migration choisie.

Fourchette 212 k€ HT — Applications Delphi simples. 10 à 25 formulaires VCL, 1 à 2 modules métier, base Firebird de moins de 50 tables, Delphi XE ou 10.x récent. Option B (Strangler Fig partiel) ou Option C (Oxygene + Strangler Fig). Durée 4 à 7 mois. Profil typique : outil de gestion interne mono-département, application satellite d'un ERP principal.

Fourchette 171 k€ HT — Applications Delphi moyennes. 25 à 60 formulaires VCL, 3 à 5 modules métier, base Firebird 50-150 tables, Delphi 7/2007 ou XE. Option B (Strangler Fig complet). Durée 7 à 13 mois. Profil typique : TMS logistique, back-office assurance, outil GPAO mono-site.

Fourchette 712 k€ HT — ERP Delphi structurants. 60 à 150 formulaires VCL, 6 à 12 modules métier, base Firebird 150-400 tables, Delphi 7/2007/XE multi-sites, logique métier complexe (algorithmes de calcul, intégrations EDI, procédures stockées volumineuses). Option B (Strangler Fig long cours). Durée 13 à 18 mois. Profil typique : ERP GPAO multi-sites, TMS grand compte, back-office assurance multi-ramos.

L'audit technique initial (à partir de 1 618 € HT, 3 à 6 semaines) est facturé séparément. Son résultat est le seul moyen d'obtenir une estimation fiable — une fourchette de prix sans audit est une fiction non engageante.