Migration Delphi vers le web : moderniser, convertir ou réécrire votre application métier

Une application Delphi doit passer au web quand elle freine l'entreprise : accès à distance bricolé, postes Windows figés pour la faire tourner, composants que plus personne ne met à jour, ou un seul développeur qui connaît le code. Quatre voies existent : rester sur Delphi en le modernisant, garder Delphi côté serveur et ajouter une interface web, convertir le code vers C# avec un outil, ou réécrire sur des technologies web standards. Le bon choix dépend moins du langage que de l'état de votre application : sa version, sa couche de données et ses règles métier.

Ce guide s'adresse au dirigeant ou au responsable informatique qui doit trancher, pas au développeur qui fera la migration. La première page de Google sur ce sujet est tenue par des éditeurs d'outils de conversion, qui ont un produit à vendre. Nous avons aussi le nôtre, une réécriture sur mesure : raison de plus pour être précis sur les cas où elle ne vaut pas le coup.

Delphi n'est pas mort, et c'est une bonne nouvelle

Contrairement à Visual Basic 6, Delphi est toujours édité. Embarcadero annonçait sur sa page Delphi la disponibilité de RAD Studio 13.2 « Florence » (relevé du 07/11/2026). Le langage, le Pascal Objet, compile toujours des applications Windows natives, et l'éditeur propose des briques pour le mobile, Linux et les API.

Cela change la question. Une application écrite en Delphi 7 il y a vingt ans et une application maintenue dans une version récente n'ont rien à voir. La première accumule souvent :

• le BDE (Borland Database Engine), l'ancienne couche d'accès aux données, avec des tables Paradox ou dBase ;
• des composants tiers achetés à l'époque, dont l'éditeur a disparu ou ne publie plus de version compatible ;
• des chaînes de caractères non Unicode, qui posent problème dès que les données sortent du français ou passent par le web ;
• une compilation 32 bits et des DLL anciennes ;
• un accès à distance par bureau à distance (TSE, RDS) faute de mieux.

La seconde, si elle est saine, peut parfois rester sur Delphi et s'ouvrir au web par d'autres moyens.

Les signaux qui justifient une migration

• Vos équipes ont besoin du logiciel hors du bureau : commerciaux, techniciens, agences, télétravail. Le bureau à distance dépanne mais coûte en licences, en sécurité et en confort.
• Vous devez ouvrir le logiciel à l'extérieur : portail client, suivi de commande, échanges automatiques avec un fournisseur ou un ERP.
• Une seule personne connaît le code, souvent son auteur, proche de la retraite ou indisponible. Le vivier de développeurs Delphi existe, mais il est plus étroit que celui des langages web ou de C#.
• Des postes ne peuvent pas être mis à jour à cause de l'application. Windows 10 n'est plus pris en charge depuis le 14 octobre 2025, et un poste bloqué sur une version ancienne hérite de ses failles.
• Chaque évolution devient risquée : on n'ose plus toucher au code, les demandes du métier s'empilent. C'est le symptôme classique de la dette technique.

Quand il vaut mieux ne pas migrer

Une migration immobilise votre équipe et coûte cher. Elle ne se justifie pas si votre application :

• tourne sur une version de Delphi récente, sans BDE ;
• est maintenue par un développeur compétent et disponible, avec le code source sous votre contrôle ;
• sert des utilisateurs sédentaires, au bureau, sur des postes à jour ;
• évolue peu et ne doit pas s'ouvrir à des clients ou partenaires.

Dans ce cas, sécurisez plutôt l'existant : sauvegardes testées, code source versionné, documentation des règles principales, un second développeur qui connaît le projet. Vous garderez la migration pour le jour où un besoin réel apparaîtra.

Les quatre voies et le progiciel, comparés

Moderniser en restant sur Delphi

La voie la moins risquée à court terme : passer à une version récente, remplacer le BDE par FireDAC, convertir les chaînes en Unicode, compiler en 64 bits, remplacer les composants abandonnés. Elle se justifie quand l'application reste un outil de bureau et que vous disposez de développeurs Delphi. Elle ne règle ni la mobilité ni la dépendance à un vivier restreint.

Garder Delphi côté serveur et ajouter une interface web

On extrait la logique métier dans un serveur qui expose une API, puis on construit des écrans web par-dessus. Embarcadero propose pour cela RAD Server, et des frameworks tiers permettent même d'écrire l'interface web en Pascal. C'est une étape intermédiaire intéressante si le code métier est propre et bien séparé des fiches. Si la logique est mêlée aux écrans, ce qui est fréquent dans les applications anciennes, l'extraction coûte presque autant qu'une réécriture.

Convertir vers C# et .NET avec un outil

C'est la requête « migrate Delphi to C# ». Plusieurs éditeurs vendent des convertisseurs qui lisent les fichiers .pas et .dfm et produisent du C#. Leurs taux d'automatisation affichés sont des arguments commerciaux, à vérifier sur votre propre code. Ce qui se convertit bien : la logique de calcul, les classes, les procédures. Ce qui se convertit mal : les fiches VCL (une grille éditable Windows ne devient pas une page web), les états imprimés, les composants tiers, les appels à des DLL. Le résultat reste souvent une application de bureau .NET, à moins de refaire l'interface.

Réécrire en application web

Une application dans le navigateur, une base comme PostgreSQL, des interfaces de programmation documentées. C'est la voie qui ouvre le plus de possibilités : accès depuis un poste, une tablette ou un téléphone, portail client, intégrations, hébergement au choix. Le code Delphi n'est pas jeté pour autant : il sert de spécification. On y lit les règles de calcul, les contrôles de saisie, les cas particuliers accumulés en vingt ans. Pour choisir la pile technique, voir les technologies d'une application métier.

La couche de données, vrai chantier de la migration

Les applications Delphi ont connu plusieurs générations d'accès aux données, et la vôtre peut en mêler plusieurs :

• BDE avec Paradox ou dBase : des fichiers sur un disque partagé. La documentation d'Embarcadero le présente comme déprécié, sans prise en charge d'Unicode ni du 64 bits. Ces fichiers se corrompent volontiers après une coupure réseau.
• InterBase ou Firebird : de vraies bases serveur, assez simples à reprendre, mais souvent riches en procédures stockées et déclencheurs.
• SQL Server ou Oracle via ADO, dbExpress ou FireDAC : la base peut parfois rester en place pendant la transition, ce qui simplifie beaucoup la cohabitation.

Trois pièges reviennent dans presque chaque reprise :

• la logique cachée dans la base : procédures stockées et déclencheurs qui calculent des stocks ou des soldes, que personne ne pense à inventorier ;
• la logique cachée dans les fiches : des contrôles et des calculs écrits dans les événements des boutons, invisibles depuis la base ;
• les données sales : doublons, dates saisies en texte, enregistrements orphelins, encodages qui ont varié.

La méthode complète, avec migrations de test et validation par le métier, est décrite dans la reprise de données lors d'une migration de logiciel.

Ce qu'un devis de migration oublie souvent

• Les états imprimés : QuickReport, FastReport, Rave Reports. Une application ancienne en compte souvent des dizaines, à refaire un par un.
• Les périphériques : imprimantes d'étiquettes, douchettes, balances, ports série. Chacun demande une solution dans le navigateur ou un petit relais installé sur le poste.
• Les échanges de fichiers : imports et exports avec la comptabilité, la banque, un transporteur, souvent dans des formats maison.
• Le hors ligne : un dépôt ou un atelier mal couvert a besoin d'un mode dégradé.
• La formation et la bascule : des utilisateurs habitués depuis vingt ans à leurs raccourcis clavier ne changent pas d'outil en un jour.
• Le code source et les droits : vérifiez que vous disposez du code complet, composants tiers compris, et que vous avez le droit de l'exploiter. Voir la propriété du code source, avec des droits définis au cas par cas dans le contrat.

Migrer par étapes plutôt que d'un bloc

Remplacer d'un coup une application Delphi centrale, c'est tout jouer sur une seule date. La méthode la plus sûre consiste à construire la nouvelle application à côté de l'ancienne :

1. Inventaire : les fiches et les états réellement utilisés, par qui, à quelle fréquence. Une partie ne sert plus.
2. Extraction des règles : lecture du code et entretiens avec les utilisateurs clés, pour écrire ce que le logiciel fait vraiment.
3. Premier module choisi pour sa valeur : souvent ce qui manque le plus, comme un accès mobile ou un portail client.
4. Prototype validé par les utilisateurs avant tout développement.
5. Cohabitation : le module web lit et écrit dans la même base, ou échange avec elle, pendant que Delphi assure le reste.
6. Bascule module par module, avec retour arrière prévu, jusqu'à l'extinction de l'application Delphi.

Cette méthode est détaillée dans la refonte d'une application métier par étapes. Elle vaut aussi pour les autres environnements des années 1990 et 2000 : voir la migration WinDev vers le web et la migration VB6.

Combien coûte une migration Delphi

Le langage d'origine pèse peu dans le prix. Ce qui le fait varier : le nombre de fiches et d'états réellement utilisés, la complexité des règles métier, l'état des données, le nombre d'intégrations et de périphériques. Ce qui alourdit le plus une migration Delphi, ce sont la logique dispersée dans les fiches et la base, et l'absence de documentation. Nos repères et la décomposition des postes de coût sont dans le prix de la refonte d'un logiciel métier.

Le mode de paiement compte autant que le montant. Un forfait à prix fixe par module, une édition en SaaS si votre métier en partage les besoins, ou un abonnement qui évite de payer le développement d'avance : chaque formule répartit le risque différemment.

Les erreurs fréquentes

• Signer pour une conversion automatique sans essai sur votre code réel.
• Reproduire chaque écran à l'identique au lieu de repenser le travail : une page web n'est pas une fiche Windows, et vingt ans d'usages ont souvent produit des détours inutiles.
• Oublier les procédures stockées et découvrir en recette que les soldes ne tombent plus juste.
• Basculer tout le monde le même jour, sans retour arrière.
• Laisser partir le développeur historique avant d'avoir extrait ce qu'il sait.

La check-list du dirigeant

• Quelle version de Delphi ouvre aujourd'hui le code source, et l'avez-vous ?
• L'application utilise-t-elle encore le BDE, Paradox ou dBase ?
• Quels composants tiers sont indispensables, et sont-ils encore maintenus ?
• Quelles fiches et quels états sont utilisés chaque semaine ?
• Quel besoin justifie la migration : mobilité, ouverture, dépendance, sécurité ?
• Qui, dans l'équipe, connaît les règles métier et peut valider la nouvelle application ?

Par où commencer

Rassemblez des captures des écrans les plus utilisés, la liste des états imprimés et, si possible, une copie de la base. Avec cela, un premier échange suffit à dire quelle voie vous convient, y compris si la bonne réponse est de rester sur Delphi.

Chez LPR Studio, cet échange débouche sur un prototype visuel gratuit du premier module web, présenté en visio sous 5 jours ouvrés : vos équipes voient leur futur écran avant toute décision. La démarche est expliquée dans voir son logiciel avant de le payer.