Remplacer Borland BDE par FireDAC : carte d'aide à la décision pour une migration sécurisée

Lundi matin, 08:15. Une mise à jour Windows fraîchement déployée, une nouvelle protection d’endpoint, plus un « petit » paquet de la distribution logicielle — et soudain un site est à l’arrêt. Une application métier critique Delphi démarre certes, mais au premier accès aux données survient « Alias non trouvé » ou « Chemin réseau invalide ». Dans le fil du ticket apparaissent des termes qui n’ont plus leur place dans de nombreuses équipes IT : administrateur BDE, NetDir, fichiers de configuration locaux qui se trouvent « quelque part » et semblent fonctionner « d’une manière ou d’une autre ».

Qui souhaite remplacer Borland BDE par BDE-remplacement avec connexion native, n’a généralement pas le luxe du « nous modernisons pour le plaisir », mais un véritable conflit d’objectifs. Objectif 1 : stabilité maximale en exploitation, pas de surprises dans les cycles de comptabilisation, les rapports ou les interfaces. Objectif 2 : sortir l’application du statut de cas Legacy — s’éloigner d’une configuration cliente fragile vers un accès aux données compatible avec 64‑Bit, Unicode, les Security-Baselines et une stratégie de base de données propre. Cette carte d’arbitrage situe bénéfices, efforts, risques et limites et montre pour qui quelle décision est plausible.

Conflit d’objectifs comme point de départ : maintenir la stabilité ou investir dans l’avenir ?

Objectif A : stabilité, parce que le processus en dépend

De nombreuses applications basées sur BDE sont opérationnellement rodées. Le support connaît les particularités, les services métier se sont habitués à des enchaînements d’écrans et à des listes spécifiques, et même les aspérités sont intégrées dans les procédures. C’est précisément pourquoi une modification de l’accès aux données est risquée : les erreurs ne se manifestent souvent pas par un plantage, mais par des écarts discrets — un tri différent, un arrondi différent, un traitement différent des valeurs NULL, un verrouillage anormalement long. Pour la direction IT et l’exploitation, cela signifie : la migration n’est acceptable que si l’équivalence des résultats et la possibilité de rollback sont réalistement garanties.

Objectif B : pérennité, parce que l’exploitation et la plateforme évoluent

Parallèlement, la Borland Database Engine (BDE) n’est pas « juste ancienne », elle est officiellement déclarée obsolète (deprecated). Embarcadero indique explicitement que la BDE ne sera plus développée et ne recevra par exemple jamais de prise en charge Unicode ; pour les applications existantes, une migration vers BDE-Ablosung mit nativer Anbindung est recommandée.^[Source] Conséquence pratique : plus vous durcissez les clients, déployez des logiciels, restreignez les droits et unifiez les plateformes, moins un accès aux données qui dépend de paramètres globaux historiques et d’un écosystème de pilotes obsolète convient. Cela concerne non seulement « l’esthétique IT », mais aussi le risque d’incident et la prévisibilité.

Ce qui change réellement lorsque vous remplacez Borland BDE par FireDAC

Dans de nombreux plans de projet, on lit en substance : TDatabase devient TFDConnection, TQuery devient TFDQuery, TTable devient TFDTable. C’est la partie visible. La partie pertinente se situe en dessous : BDE a porté pendant des années des hypothèses implicites (« conversions, tris par défaut, effets secondaires de transaction, emplacements de configuration »). FireDAC est en général plus strict, plus transparent et plus proche de la base de données concernée. Cela améliore la maintenabilité et le diagnostic — mais oblige à consigner et tester les hypothèses.

Quatre différences qui ont un impact quotidien sur l’exploitation et le métier

• Configuration et déploiement : Les configurations BDE fonctionnent historiquement avec des configurations globales d’alias/NetDir et des fichiers qui peuvent varier par machine ou par profil. FireDAC se configure de manière proche de la connexion et se pilote mieux par environnement, mais nécessite selon la base de données des bibliothèques clientes appropriées et une stratégie claire de mise à jour et de distribution.
• Types de données, paramètres, conversion implicite : FireDAC est souvent plus précis. Le SQL qui fonctionnait « par hasard » (date en tant que chaîne, nombre en tant que texte) se voit plus facilement. C’est positif — à condition que vous détectiez ces erreurs en test, et non lors de la clôture mensuelle.
• Unicode et collation (règles de tri/jeu de caractères) : Si l’application utilise historiquement une logique ANSI, une modernisation peut révéler des problèmes de caractères et de comparaisons : tri, casse, caractères accentués, formats d’export. C’est résoluble, mais pas automatiquement « identique ».
• Transactions et comportement de verrouillage : Beaucoup de schémas legacy comptent sur des effets secondaires pilotés par le dataset. FireDAC offre un contrôle de transaction propre — mais exige que vous précisiez où commencent et se terminent les transactions.

Carte de décision : bénéfices, effort, risques et limites

Quand la migration est particulièrement pertinente

Lorsque le déploiement et le durcissement de la sécurité entrent régulièrement en conflit

Plus votre parc client est standardisé (distribution logicielle, droits restreints, réseaux segmentés, protection des endpoints), plus tout ce qui est configuré « par machine » ou « par profil utilisateur » se voit, et n’est réparable en cas d’erreur que par une reproduction manuelle. FireDAC ne vous oblige pas automatiquement à adopter un bon modèle de configuration, mais il s’accorde mieux avec une approche où les paramètres de connexion sont définis, versionnés et documentés par environnement.

Lorsque la planification 64 bits ou du nouveau matériel est prévue

Beaucoup d’entreprises ne changent pas à cause d’une version d’IDE, mais parce que des serveurs de terminaux sont renouvelés, de nouvelles versions de système d’exploitation arrivent ou les politiques de sécurité sont renforcées. Alors l’accès aux données devient un point de dépendance critique. Qui le modernise découple les projets suivants : la prochaine initiative plateforme ou infrastructure n’aura pas à résoudre en même temps le problème d’accès aux données.

Lorsque la gestion des données doit de toute façon devenir mature

Dans les scénarios basés sur des fichiers (classique Paradox/dBase), le principal risque est rarement l’interface utilisateur. Il s’agit du verrouillage, de la réalité des sauvegardes, de l’intégrité des données, des droits et du fonctionnement multi‑utilisateur. FireDAC est principalement conçu pour les bases de données SQL et les modèles de transaction clairs. Si une stratégie de base de données serveur est de toute façon envisagée, la BDE-remplacement est souvent le moment de planifier les deux ensemble — avec toutes les conséquences pour l’exploitation (sauvegardes, monitoring, fenêtres de maintenance, concept de rôles/permissions).

Trois parcours de migration — aux profils de risque très différents

Parcours 1 : recompiler mécaniquement (seulement comme objectif intermédiaire)

Embarcadero décrit dans l’Upgrade/Migration Center une migration typique FireDAC comme un processus en plusieurs étapes et mentionne aussi « reFind » comme outil aidant pour la partie mécanique : remplacer des composants, mettre à jour les clauses uses, effectuer des modifications de base pour pouvoir recompiler.^[Quelle] Comme étape intermédiaire, c’est utile. Comme solution finale, c’est insuffisant, car compiler n’apporte aucune garantie sur l’équivalence fonctionnelle, la performance sous charge ou la concurrence.

Parcours 2 : encapsuler l’accès aux données, puis basculer (souvent le meilleur compromis)

Au lieu de remodeler chaque écran individuellement, centralisez l’accès aux données dans quelques points responsables : création des connexions, gestion centrale des erreurs, logging/tracing, règles contraignantes pour les paramètres et les transactions. Ensuite, migrez module par module. Cela réduit la surface de migration et rend l’acceptation et l’exploitation plus prévisibles, car le comportement peut être observé et corrigé en un seul endroit.

Pfad 3: FireDAC + Datenbankwechsel (hoher Nutzen, aber höhere Governance)

Si de toute façon un passage d’un modèle basé sur des fichiers à un modèle serveur est prévu, il peut être efficace de combiner les deux. Le gain est important (transactions, droits, monitoring, meilleurs processus d’exploitation). Le prix à payer est que vous décidez de bien plus que de la « technique » : migration des données, conception du schéma, basculement, exploitation parallèle, stratégie de retour en arrière. Sans format d’acceptation clair et accords d’exploitation, cette voie devient rapidement un projet interminable.

Ein praxistauglicher Ablauf in 7 Schritten (ohne Big Bang)

1. Inventur als Risikokarte: Quelles sources de données, quels modes d’accès (axé sur TTable vs. SQL), quels rapports critiques, quels traitements batch, quelles interfaces d’import/export dépendent du comportement de l’ensemble de données ?
2. Zielmodus entscheiden: « FireDAC sur la même base de données » ou « FireDAC plus modernisation de la base de données ». Il s’agit d’une décision de portefeuille et d’exploitation, pas d’une simple question de développement.
3. Foundation definieren: Configuration centrale des connexions, timeouts, gestion des erreurs, tracing/logging commutable en option. Objectif : reproductible en Dev/Test/Prod.
4. Pilotprozess wählen: Pas le plus petit écran, mais un processus fonctionnellement bien délimité avec lecture et écriture (transactions, verrouillages, validation) et des critères d’acceptation clairs.
5. Ergebnisgleichheit nachweisen: Comparaison des resultsets, des rapports et des indicateurs clés sur des données de test définies. Focus : NULL, logique des dates, arrondis, jeu de caractères, tri.
6. Migration in Wellen: Par modules / cas d’utilisation, avec un release-ring (groupe pilote, fenêtre de support, paquet de rollback, communication). L’exploitation parallèle est autorisée, mais techniquement proprement séparée.
7. BDE im Deployment zurückbauen: Supprimer l’installateur, la documentation, les RESTes de configuration. Tant que BDE RESTe installé « au cas où », une partie du risque opérationnel subsistera.

Typische Risikozonen – und wie man sie administrativ in den Griff bekommt

1) Datentypen, NULL und „historische“ Konvertierungen

De nombreuses applications Delphi héritées contiennent des cas limites restés longtemps intacts : chaînes vides au lieu de NULL, nombres dans des champs texte, date stockée en chaîne, «0» utilisé comme False. FireDAC ne casse pas automatiquement ces endroits, mais les rend plus visibles. Pour l’exploitation et le métier, c’est un avantage, car les erreurs deviennent plus reproductibles — à condition de définir des règles : quelles colonnes peuvent être NULL ? Quelles valeurs par défaut s’appliquent sur le plan fonctionnel ? Comment les booléens sont-ils stockés ? Quelle résolution temporelle est pertinente (date vs. timestamp) ?

2) Transactions, verrous et concurrence

Dans les structures héritées BDE, les transactions naissent souvent de façon informelle : dataset ouvert, l’utilisateur clique, puis le post intervient à un moment indéterminé. Sur des bases de données serveur, cela peut conduire à des transactions longues et à des verrous inutiles. Lors d’une migration FireDAC, un principe simple est profitable : les transactions doivent englober le cas d’utilisation, pas l’interface utilisateur. Cela peut signifier que les opérations d’enregistrement sont regroupées, que les validations sont déplacées en amont et que la gestion des erreurs est centralisée.

3) Dialecte SQL, mots réservés, tri déterministe

Une partie du travail relève moins de «FireDAC» que de l’hygiène SQL. Historiquement, BDE a toléré plusieurs choses : alias ambigus, jointures implicites, tri non déterministe. FireDAC n’est pas l’adversaire ici, mais l’amplificateur : les problèmes deviennent visibles. La solution robuste consiste presque toujours à expliciter le SQL. C’est aussi utile pour les administrateurs, car les requêtes deviennent plus analysables (besoin d’index, plans d’exécution, tests de charge).

4) Reporting, exports, analyses pertinentes pour l’audit

Lorsque des rapports servent à la clôture mensuelle, à la facturation ou à des analyses pertinentes pour l’audit, les écarts «silencieux» constituent le risque principal. Traitez donc les rapports critiques comme des composants produits à part entière : jeux de test définis, totaux/nombre de lignes attendus, logique de filtrage documentée, validation par le métier. Dans la mesure du possible, stabilisez la base de données (par ex. via des requêtes ou vues clairement définies) plutôt que d’accepter des chaînes de filtres côté UI comme source de vérité.

Conséquences architecturales : ce que FireDAC permet — et ce qui ne naît pas automatiquement

Bonne base pour les services, jobs et interfaces

Beaucoup d’entreprises étendent des systèmes de bureau avec des services REST, du traitement en arrière-plan ou des portails. Un accès aux données moderne convient à cela si le cycle de vie des connexions, la gestion des erreurs et les transactions sont correctement encapsulés. Sans cette encapsulation, on obtient seulement «un nouveau pilote dans une ancienne structure» — et chaque projet suivant réinvente ses règles.

FireDAC ne remplace pas le découplage de l’UI et de la logique métier

Si aujourd’hui des formulaires construisent des requêtes SQL, que des règles métier sont dans des gestionnaires d’événements et que des états globaux dominent, cela restera d’abord le cas après la migration. FireDAC n’est pas une mesure architecturale, mais une bonne occasion d’implémenter une structure minimale : gestion centralisée des connexions, peu de classes d’accès par module métier, règles définies pour les erreurs et les transactions. Cela suffit souvent à rendre la maintenance et l’exploitation nettement plus prévisibles.

Limites et cas particuliers à aborder ouvertement tôt

Systèmes fortement pilotés par TTable/Paradox

Si l’existant est fortement basé sur des fichiers, la vraie question n’est pas «BDE ou FireDAC», mais «quelle modalité de stockage des données». FireDAC n’est pas destiné à conserver une architecture basée sur des fichiers telle quelle. Ceux qui doivent moderniser des données Paradox doivent planifier soigneusement les efforts de migration des données, de conception du schéma, des droits, des tests de sauvegarde/RESTauration et du basculement — y compris le fonctionnement en parallèle et le rapprochement des données si une coupure franche n’est pas possible sur le plan fonctionnel.

Le fonctionnement en parallèle est un outil, pas un état final

Oui, BDE et FireDAC peuvent fonctionner en parallèle. Le prix à payer est la complexité : configurations doublées, diagnostics d’erreur doublés, dépendances accrues. Fixez donc tôt une date de fin pour le démantèlement de BDE et définissez la ligne de séparation (modules, cas d’utilisation, couches techniques). Un statu quo à moitié-moitié sans vision cible coûte en exploitation généralement plus cher qu’une refonte décidée, réalisée en vagues.

Décisions que la direction IT et l’exploitation doivent définir tôt

• Stratégie d’environnement: Comment gérez-vous les configurations Dev/Test/Prod ? Qui peut modifier les paramètres de connexion ? Comment gérez-vous les secrets ?
• Politique de pilotes et de mises à jour: Comment les bibliothèques clientes sont-elles versionnées et distribuées ? Existe-t-il des paliers de publication et une option de repli ?
• Observabilité: Quels logs l’exploitation nécessite-t-elle en cas d’incident ? Quels contextes SQL peuvent être consignés pour des raisons de protection des données ou d’exigences de sécurité ?
• Format d’acceptation: Quels processus clés doivent être couverts en tests de régression (listes, écritures, exports, rapports) ?
• Plan de rollback: Quelle est la stratégie de repli par vague – technique (paquets), organisationnelle (communication) et liée aux données (aucune perte de données) ?

Le levier déterminant du succès: la confiance par la démonstration

La plupart des migrations échouent non pas à cause de «l’intégration», mais à cause du manque de confiance. La confiance naît lorsque vous pouvez démontrer que les processus critiques RESTent identiques sur le plan fonctionnel — ou lorsque les écarts sont décidés en connaissance de cause et clairement communiqués. C’est précisément là que réside l’opportunité de la migration : elle impose des règles explicites (tri, types de données, transactions) et établit une base qui RESTera maintenable et exploitable dans deux ans. FireDAC n’est alors pas l’objectif, mais le moyen de ramener l’exploitation et l’évolution dans un état normal planifiable.

Si vous souhaitez préparer la substitution de manière structurée (carte des risques, pilote, plan de tests et de déploiement), vous pouvez lancer l’initiative proprement ici : discuter du projet ou du programme de modernisation avec Net-Base.

Pour ce sujet, Delphi Modernisation et la migration FireDAC sont également importantes. L’article situe ces aspects de manière claire et montre ce qui compte au quotidien.

Discuter d’un projet ou d’une démarche de modernisation avec Net-Base.