Delphi moderniser sans perdre la logique métier

Delphi-Anwendungen laufen in vielen Unternehmen seit Jahren stabil – und bilden genau die Fachlogik ab, die Umsatz, Servicequalität und Compliance sichert. Bei einer Modernisierung geht es daher selten um „neue Oberfläche“, sondern um eine kontrollierte Weiterentwicklung, bei der Regeln, Sonderfälle und historisches Prozesswissen erhalten bleiben.

Dans cet article, nous présentons une approche éprouvée pour moderniser progressivement Delphi : de l’inventaire à la découplage de l’UI/accès aux données jusqu’à la modernisation technique (Unicode/64 bits, remplacement de BDE, API/Services) – y compris la sécurisation par des tests, le monitoring et le fonctionnement en parallèle. L’objectif est une architecture modernisable, sans réécriture en Big Bang et sans perte de logique.

Modernisierungen scheitern in der Praxis selten am Compiler oder an einem Framework, sondern an falschen Annahmen über das Systemverhalten. Über Jahre gewachsene Delphi-Anwendungen enthalten typischerweise Fachregeln in GUI-Events, SQL in Formularlogik, Varianten pro Kunde/Mandant, historisch bedingte Sonderfälle sowie Integrationen, die nur „im Betrieb“ dokumentiert sind.

Dans la pratique, les modernisations échouent rarement à cause du compilateur ou d’un framework, mais à cause d’hypothèses erronées sur le comportement du système. Les applications Delphi développées sur plusieurs années contiennent typiquement des règles métier dans des événements GUI, du SQL dans la logique de formulaire, des variantes par client/mandant, des cas particuliers hérités ainsi que des intégrations qui ne sont documentées que « en production ».

Ein Big-Bang-Rewrite zwingt dazu, dieses Wissen neu zu rekonstruieren – inklusive der Fehler, die das Altsystem längst nicht mehr macht. Der bessere Ansatz ist, die Fachlogik als Vermögenswert zu behandeln: isolieren, absichern, dann Schritt für Schritt modernisieren.

Une réécriture en Big Bang force à reconstruire ce savoir – y compris les erreurs que l’ancien système ne commet plus depuis longtemps. L’approche préférable consiste à considérer la logique métier comme un actif : isoler, sécuriser, puis moderniser pas à pas.

Ein tragfähiges Zielbild für prozesskritische B2B-Systeme ist nicht „alles neu“, sondern eine Architektur, die Veränderungen ermöglicht – ohne den laufenden Betrieb zu gefährden:

• séparation claire de l’UI, de la logique de domaine, de l’accès aux données et des intégrations
• testabilité et mesurabilité (régression, logging, monitoring, builds reproductibles)
• remplaçabilité progressive (moderniser l’UI sans migration immédiate de la base de données – ou inversement)
• capacité API (z. B. REST), pour connecter portails, mobiles ou intégrations systèmes
• déploiements exploitables avec option de rollback

Delphi s’y prête bien, car les unités et classes de domaine existantes peuvent être réutilisées pendant que le périmètre extérieur est modernisé.

Bevor Code angepasst wird, braucht es eine belastbare Entscheidungsgrundlage – keine Voll-Dokumentation. Bewährt haben sich diese drei Ergebnisse:

• Fachlogik-Landkarte: cas d’utilisation critiques, règles/calculs, variantes (Mandanten/Länder/Kunden), Schnittstellen, Jobs/Batch-Läufe.
• Risikoprofil: besonders fehlerkritische Bereiche, Datenqualität, regulatorische Anforderungen, Engpässe im Betrieb (Performance, Stabilität, Wartbarkeit).
• Modernisierungs-Backlog: priorisierte Pakete nach Business-Wert und Risiko (was muss stabil bleiben, was darf sich ändern, was später).

Damit lässt sich Modernisierung planbar machen: mit klaren Inkrementen statt einem einzigen „Alles-oder-nichts“-Projekt.

Damit Fachlogik nicht „versehentlich“ verändert wird, braucht es eine Absicherung, die unabhängig vom UI-Refactoring funktioniert. Typische Bausteine:

• Characterization/Golden-Master-Tests: vorhandenes Verhalten wird über repräsentative Eingaben/Ausgaben eingefroren (Reports, Berechnungen, Prozessschritte).
• Regressionstests auf Use-Case-Ebene: die geschäftskritischen Abläufe werden automatisiert oder halbautomatisiert nachgestellt.
• Télémétrie: Journalisierung, Metriken und Fehlerbilder werden vor/nach einer Änderung vergleichbar gemacht.
• Parallelbetrieb & kontrollierte Umstellung: neue Module laufen neben dem Bestand (Feature Toggles, Pilotgruppen), mit klarer Rollback-Strategie.

Ce n’est que lorsque ces filets de sécurité sont en place que la modernisation technique proprement dite vaut la peine — car les risques et le retravail diminuent drastiquement.

La cause la plus fréquente de perte de logique est le mélange de l’UI, de l’accès aux données et des règles métier. La modernisation commence donc par le découplage — pas par le remplacement du framework d’UI.

Un objectif pragmatique est une structure en 3 couches :

• Presentation: VCL/FMX, Presenter/ViewModel, nur UI-nahe Validierung (Format, Pflichtfelder)
• Business: modèles de domaine, services, règles, logique d’état, calculs
• Data/Integration: repositories, accès BD, adaptateurs vers ERP/DMS/CRM, REST-Clients, messaging

Règle pratique : les règles métier migrent des OnClick/OnExit vers des services de domaine. Le SQL migrera des Forms vers des repositories. Ainsi la logique devient testable et réutilisable ensuite via l’UI, les services et les jobs.

Avec le Strangulation Pattern, du neuf est créé intentionnellement « à côté » de l’existant : les nouvelles fonctionnalités sont déjà implémentées dans la structure découplée pendant que le système hérité continue de fonctionner. Pas à pas, la nouvelle couche assume davantage de responsabilités, jusqu’à ce que des parties anciennes disparaissent.

Exemple (typique B2B) :

• Vous extrayez la logique des commandes dans un service de domaine.
• L’UI VCL existante utilise d’abord le même service (pas de rupture de processus).
• Parallèlement, un REST-endpoint est créé pour un portail client ou une intégration.
• Après stabilisation, certains anciens Forms sont remplacés – sans qu’il soit nécessaire de reconstruire la logique centrale.

Ainsi vous réduisez le risque projet, maintenez la capacité d’exploitation et obtenez rapidement des bénéfices mesurables (p. ex. API, performance, maintenabilité).

Selon la situation de départ, ces blocs sont souvent pertinents — l’essentiel est de prioriser selon le risque et la valeur métier :

• BDE/Remplacement de l’accès DB legacy : pilotes/fournisseurs modernes, frontières transactionnelles nettes, déploiements reproductibles.
• Unicode : gestion des chaînes, base de données/interfaces, composants tiers.
• 64‑Bit : dépendances, mémoire/performance, bibliothèques externes.
• Couche API et de services : REST, Windows-/Linux-services, intégrations.
• Build & Release : CI/CD, gestion des artefacts, installateurs signés, rollback.

Important : ces points sont idéalement mis en œuvre après découplage et sécurisation — ainsi les changements peuvent être vérifiés en toute sécurité.

Une réécriture complète peut être pertinente dans certains cas — souvent toutefois c’est la voie la plus coûteuse pour obtenir de la « technologie moderne ». Ces questions aident à l’évaluation :

• La logique métier est-elle entièrement comprise et testable — ou beaucoup de savoir est-il implicitement détenu par l’exploitation ?
• Existe-t-il des échéances strictes (p. ex. fin de plateforme, conformité) qui excluent un fonctionnement en parallèle ?
• Quelle est l’ampleur de la diversité des variantes (logique client/mandant) ?
• Quelle est la criticité de la disponibilité, et quelle est la tolérance aux changements de processus ?
• Quelles parties sont réellement « responsables » (UI, accès aux données, intégrations, déploiement) — et lesquelles sont stables ?

Dans de nombreux scénarios B2B, une approche progressive conduit plus rapidement à des résultats mesurables, car elle contrôle les risques et protège la logique métier.

Delphi-audit de modernisation (pour les applications critiques pour le processus) : nous analysons l’architecture, les dépendances, les zones à risque et fournissons une feuille de route priorisée pour moderniser sans perdre la logique métier.

• Entrée : base de code (lecture seule), configuration du build, 2–3 cas d’utilisation clés, environnement système (BD, intégrations).
• Résultat : carte de la logique métier/des modules, analyse des risques et des dépendances, architecture cible recommandée, plan de mise en œuvre par incréments incluant la sécurisation (tests/exploitation en parallèle).
• Optionnel : Proof of Concept pour le découplage + premier test Golden-Master.

Vous obtenez ainsi une base de décision fiable avant d’engager budget et temps dans une réécriture risquée.

Peut-on moderniser Delphi sans réécrire l’application ?
Oui. Dans de nombreux cas, on découple d’abord la logique métier et l’accès aux données, puis on modernise techniquement. Cela réduit le risque et maintient la stabilité de l’exploitation.

Comment empêcher que la logique métier soit « silencieusement » modifiée ?
Par des tests Golden-Master et de régression, de la télémétrie ainsi qu’une exploitation parallèle contrôlée avec une stratégie de rollback claire.

Quelles étapes apportent souvent le bénéfice le plus rapide ?
Transparence (Assessment), découplage de l’UI/SQL, remplacement de BDE et une couche API/service pour les intégrations – chacune sécurisée par des tests.

Combien de temps prend une modernisation ?
Cela dépend des cas d’usage critiques, de la diversité des variantes et des dépendances. Un Audit fournit typiquement en peu de temps une feuille de route fiable et des incréments priorisés.