Combiner Delphi Desktop et portails Web : architecture, interfaces et modernisation sans rupture

Dans de nombreuses entreprises, la « console de commande » métier s’est développée au fil des ans en tant qu’application de bureau Delphi : VCL-Client, connaissances processus approfondies, saisie rapide des données, chaînes d’impression et de reporting, matériel spécialisé et souvent un accès direct à la base de données dans le LAN. Parallèlement, les attentes en matière de self-service et de collaboration externe augmentent : les clients souhaitent consulter l’état des commandes, échanger des documents ou enregistrer des réclamations – sans VPN, sans déploiement de client et sans installations locales.

Combiner Delphi Desktop et portails Web signifie en pratique réunir ces deux univers de façon à garder le pilotage, la sécurité et la cohérence des données maîtrisables. L’enjeu n’est pas de « reproduire » les écrans dans le navigateur, mais de concevoir une architecture qui sépare clairement processus, droits et flux de données et qui permet aux deux frontends de fonctionner selon des règles communes. Le bénéfice est une voie de modernisation sans Big-Bang : le Desktop reste productif pendant que le portail Web croît de manière contrôlée.

Ce billet s’adresse à la direction IT, aux administrateurs et aux responsables techniques de projet. L’accent est mis sur les impacts pour l’exploitation, l’administration, les interfaces, la sécurité, la persistance des données et la migration – moins sur les détails de framework. Vous trouverez des schémas applicables, des critères de décision et des pièges typiques avec leurs contre-mesures.

Pourquoi « Portal statt Desktop » est rarement réaliste

En environnement B2B, de nombreuses raisons rendent le client Desktop encore pertinent. Les administrateurs le constatent fréquemment : un portail est idéal pour des utilisateurs distribués, mais certaines tâches restent plus efficaces – ou uniquement réalisables – via le Desktop.

Forces du Desktop qui comptent dans la pratique

• Saisie de données complexe avec des écrans très denses, utilisation au clavier, vues tabulaires larges et changements rapides entre enregistrements.
• Périphériques et intégrations locales comme imprimantes d’étiquettes, scanners, appareils série ou composants Windows spécialisés.
• Performance en proximité LAN lorsque de gros volumes de données sont traités ou qu’un processus exige des latences extrêmement faibles.
• Workflows hérités avec de nombreux cas particuliers, pour lesquels un portage 1:1 dans un portail présente d’abord de forts risques.

Forces du portail qui répondent aux nouvelles exigences

• Accès externe pour clients, fournisseurs ou partenaires, sans déploiement de client.
• Contrôle central (versions, fonctionnalités, permissions) avec une frontière d’accès claire.
• Indépendance d’appareil (navigateur, usage mobile) pour les équipes terrain et le management.
• Ouvertures de processus ciblées telles que consultations d’état, uploads, validations ou circuits de tickets.

La valeur réside dans la combinaison : le Desktop demeure l’outil puissant pour des rôles internes, le portail devient l’accès contrôlé pour des groupes d’utilisateurs externes. Pour éviter l’apparition de deux « vérités », il faut un noyau unificateur.

Si vous combinez Delphi Desktop et portails Web : trois architectures cibles

La décision d’architecture porte principalement sur les responsabilités : où se trouvent les règles métier ? Qui peut modifier les données ? Quelle couche est la « Single Source of Truth » (c.-à-d. la source normative pour règles et états) ? Pour les décideurs techniques, la sélection a des conséquences directes sur l’exploitation, le diagnostic d’incidents, le release management et la sécurité.

Variante A : portail en complément via une API REST, le Desktop reste leader

Le portail couvre des cas d’usage choisis, typiquement en lecture et pour déclencher des actions : états, documents, validations, saisies simples. Pour cela on introduit une Delphi REST-API ou un serveur REST séparé. L’application Desktop peut continuer à accéder directement à la base de données dans un premier temps.

Avantage opérationnel : démarrage rapide, interventions limitées sur le Desktop, adapté pour obtenir une valeur initiale via le portail.

Point de risque : deux voies d’accès aux données coexistent (Desktop → DB direct, Portail → API). Si les règles métier restent uniquement dans le Desktop, des incohérences apparaîtront. Mesure corrective : démarrer les fonctions du portail là où les règles sont simples et reproduisibles côté serveur (p.ex. mise à disposition de documents, consultation d’état, actions de validation définies).

Variante B : noyau de services comme couche de processus partagée (recommandée en exploitation parallèle)

On déplace progressivement la logique métier hors du Desktop vers des services. Desktop et portail consomment les mêmes endpoints. Le Desktop devient davantage un Rich Client (UI, intégrations locales), tandis que règles et validations s’exécutent côté serveur.

Avantage opérationnel : un point central pour droits, audit, logique d’état et validations ; comportement cohérent sur tous les frontends.

Effort : plus élevé au départ, car il faut définir normes d’API, formats d’erreur, versionning, monitoring et déploiement. En contrepartie, l’effort diminue nettement par la suite, car il y a moins de chemins exceptionnels.

Variante C : le portail en tête, le Desktop conserve un rôle de client spécialisé

Cette variante est pertinente si le navigateur doit devenir l’accès standard (p.ex. organisation fortement distribuée), mais que le Desktop reste nécessaire pour des rôles spécifiques avec matériel spécialisé ou saisie haute performance. Le noyau de services doit alors être particulièrement stable et scalable.

Architecture Layer-3 comme fil conducteur compréhensible

Indépendamment de la variante, une architecture Layer-3 aide : (1) présentation (Desktop/Portail), (2) couche application et domaine (use cases, règles), (3) infrastructure (base de données, stockage de fichiers, messaging, systèmes externes). Pour les administrateurs c’est important car les limites d’exploitation deviennent claires : qu’est‑ce qui est un « problème frontend », qu’est‑ce qui relève d’un « problème de service », ou se situe en base de données ou dans le storage ? Cette séparation raccourcit la recherche d’incidents et réduit les effets secondaires lors des déploiements.

Mise en pratique : comment Desktop et portail partagent le même processus

La plus grande difficulté n’est souvent pas de « construire le portail », mais de définir : comment Desktop et portail se partagent-ils les responsabilités au sein d’un même processus, sans doubler les règles ? Trois patterns sont particulièrement pertinents en pratique.

1) Use-Case-APIs plutôt que APIs tables ou CRUD

Un écueil fréquent est une API qui expose simplement les tables de la base (« Create/Read/Update/Delete »). Alors le portail doit réimplémenter les règles, et le Desktop continue d’appliquer les siennes. Mieux vaut des Use-Case-APIs : des endpoints décrivant des actions métier comme « créer une réclamation », « valider une commande », « téléverser un document », « confirmer un statut de livraison ».

Effet en exploitation : les validations s’exécutent côté serveur, les messages d’erreur sont reproductibles et les deux clients (Desktop et Portail) déclenchent le même déroulé via la même logique.

2) Rendre gérables les conflits et les répétitions

L’ajout d’un portail augmente la probabilité de modifications parallèles et de requêtes répétées (p.ex. timeouts, retries ou double-clics utilisateur). Trois concepts aident sans recourir à des « verrous permanents » :

• Idempotence : les actions critiques sont conçues pour qu’une répétition produise le même effet sans double exécution. En pratique, cela se fait souvent via un identifiant de requête unique (Idempotency Key).
• Optimistic Concurrency : un enregistrement porte une information de version (p.ex. « Row Version »). Le service vérifie la version lors des modifications et renvoie proprement les conflits.
• Transactions courtes : au lieu de « tout verrouiller », les opérations d’écriture restent brèves. Les travaux longs (p.ex. exports, packs de rapports) sont traités de façon asynchrone.

Pour les décideurs techniques : ces mécanismes réduisent la charge du support, car les cas « c’est arrivé deux fois », « ma modification a disparu » se produisent beaucoup moins souvent.

3) Modéliser proprement états et transferts

Si le Desktop traite des cas complexes et que le portail ne fournit que des demandes ou des pré-étapes, il faut des transitions d’état définies. Un découpage pragmatique : le portail crée ou enrichit des dossiers dans des zones d’état clairement limitées (p.ex. « soumis »), le Desktop gère les cas spécialisés, et le noyau de services décide et journalise les changements d’état. Ainsi on évite que le client portail puisse, par des actions indirectes, « mettre en défaut » un processus.

Données et documents : la zone d’intégration souvent sous-estimée

Presque tout portail implique des opérations sur des fichiers : téléversements, justificatifs, bons de livraison, images, sorties PDF. Pour les administrateurs c’est un point central car cela impacte les sauvegardes, les permissions, le contrôle antivirus, les coûts de stockage et la performance.

Où stocker les fichiers : base de données, partage de fichiers ou objet-storage ?

Trois options courantes conduisent chacune à une réalité opérationnelle différente :

• Base de données (BLOB) : adapté si les transactions doivent être strictement couplées et si backup/restore doivent rester dans un seul package. Inconvénients : bases plus volumineuses et fenêtres de sauvegarde plus longues.
• Filesystem/Share : typique On-Prem, bien intégrable aux concepts de sauvegarde existants. Important : permissions claires et une couche API qui contrôle l’accès.
• Objet-Storage : pertinent en cas de montée en charge, règles de cycle de vie ou si les accès externes doivent être techniquement bien isolés. Nécessite un modèle explicite de clés et de permissions.

Quel que soit le lieu de stockage : le portail ne devrait pas « charger directement » des fichiers depuis un share. Mieux vaut un téléchargement contrôlé via des endpoints de service avec vérification des droits, journalisation et, si besoin, URL de téléchargement temporisée.

PDFs et rapports : côté serveur plutôt que doubles implémentations

Les applications Delphi Desktop ont souvent des chaînes d’impression et de reporting héritées. Les portails réclament fréquemment les mêmes contenus en PDF. Au lieu d’entretenir deux implémentations, il est judicieux de centraliser la génération documentaire dans le noyau de services : modèles, versionning et formats de sortie côté serveur ; Desktop et portail consomment le résultat. Côté exploitation, cela apporte des avantages nets : sorties traçables, archivage unifié et moins de dépendance aux installations Desktop.

REST-Server et services : Delphi, C# ou architecture mixte

Le choix « Delphi ou C# » dépend moins d’une posture idéologique que de la capacité des équipes, du contexte d’exploitation et de la maintenabilité. Dans de nombreux environnements, une architecture mixte est réaliste tant que les responsabilités sont bien délimitées.

Delphi comme plateforme de services : pertinent quand la logique métier existe déjà

Si la logique métier et l’accès aux données sont déjà solidement implantés dans Delphi, un serveur REST basé sur Delphi peut être efficace. Pour les administrateurs et les décideurs, important : l’exploitation d’un service n’est pas « du Desktop en continu ». Un service productif exige une configuration claire, des timeouts maîtrisés, des logs structurés, des health-checks et un déploiement reproductible.

L’accès aux données doit aussi être modernisé si des anciens pilotes ou la BDE sont encore utilisés. Une remplacement de BDE et la migration vers des accès de données modernes réduisent les incidents en exploitation et facilitent le déploiement, car moins de composants legacy doivent être installés et maintenus.

Services C# dans l’écosystème portail : fréquent pour l’hébergement et l’identity

Si le portail naît dans un paysage dominé par .NET, des services C# seront souvent privilégiés – notamment pour l’intégration d’Identity, les standards d’exploitation existants et l’hébergement derrière Microsoft IIS ou sur des plateformes containerisées. L’essentiel est d’éviter la double implémentation : soit la logique métier centrale reste dans des services Delphi et C# gère les aspects Edge (p.ex. orchestration spécifique au portail), soit vous planifiez une migration contrôlée de la logique vers .NET, avec des frontières métier clairement définies.

API-Gateway : élément d’ordre, mais pas obligatoire

Un API-Gateway peut regrouper des fonctions centrales (routing, rate-limits, logging, authentification). Pour des architectures de démarrage, une API cohérente avec des standards uniformes suffit souvent. Dès lors que plusieurs services et groupes d’utilisateurs coexistent, un gateway aide néanmoins à stabiliser la frontière extérieure et à appliquer des politiques de façon centralisée.

Authentification et droits : du Desktop interne au monde externe du portail

L’arrivée d’un portail modifie le paysage utilisateur : aux utilisateurs internes s’ajoutent comptes externes, rôles et tenants. Cela crée des exigences d’identity, d’autorisations et d’auditabilité. Pour les administrateurs, c’est critique car les systèmes d’identity et les modèles de rôles sont difficiles à refondre ultérieurement.

SSO avec SAML 2.0 ou OIDC : moins d’effort admin, meilleur contrôle

En B2B, SAML 2.0 (Single Sign-On via un Identity Provider) est répandu car les entreprises veulent réutiliser des identités existantes. OIDC (OpenID Connect) est également courant, surtout sur des plateformes plus modernes. Les logins classiques par utilisateur/mot de passe restent possibles, mais impliquent un effort supplémentaire pour politique de mot de passe, MFA, processus de réinitialisation et support.

Architecturalement important : authentification (qui êtes‑vous ?) et autorisation (que pouvez‑vous faire ?) doivent être vérifiées côté serveur – pas dans le frontend du portail.

Multi‑tenancy et modèle de rôles : ne pas « ajouter plus tard »

Un portail client requiert quasiment toujours une séparation des tenants : un client ne voit que ses données. Cela doit être implémenté dans le noyau de services, idéalement via :

• Claims dans le token (p.ex. Tenant‑ID, rôles, référence contractuelle), afin que les services puissent prendre des décisions.
• Vérifications au niveau des enregistrements (Row‑Level‑Checks dans la logique métier), pas seulement « masquer des menus ».
• Traçabilité (Audit‑Trails) pour les actions importantes (qui, quoi, quand), plus corrélation via une Request‑ID pour l’analyse d’incidents.

Le Desktop peut – si souhaité – également utiliser des tokens contre le même stack d’identity. Cela réduit les chemins spécifiques et facilite la traçabilité des modifications, surtout lorsque portail et Desktop opèrent sur le même enregistrement.

Moderniser l’accès aux données : FireDAC, PostgreSQL et flux de données contrôlés

Beaucoup de solutions Desktop Delphi ont grandi avec un accès direct à la base. Dès qu’un portail entre en jeu, cela devient un enjeu d’architecture : les flux de données doivent être contrôlables, les validations centralisées et la performance stable même sous charge parallèle.

FireDAC comme base d’un accès aux données maintenable

Remplacement de BDE avec liaison native est un standard répandu dans les environnements Delphi pour accéder aux bases modernes. L’important n’est pas tant le composant que l’uniformisation : requêtes paramétrées, frontières de transaction claires, gestion d’erreur uniforme et temps d’exécution mesurables. En exploitation, ce qui compte est que les timeouts et la consommation de ressources deviennent prévisibles et que les problèmes soient traçables dans les logs et le monitoring.

PostgreSQL avec Delphi : maîtrisable avec un bon typage et un concept de migration

PostgreSQL avec Delphi est robuste si le mapping de types (p.ex. UUID, timestamps, champs JSON), les index et les migrations de schéma sont traités proprement. Les portails génèrent souvent de nombreuses requêtes listées avec filtres. Il convient de mettre en œuvre filtres, paging et tri côté serveur pour éviter le transfert inutile de gros volumes. Cela réduit la charge et améliore l’expérience utilisateur sans ralentir le Desktop.

Exploitation, déploiement et monitoring : rendre les backends Delphi matures pour le portail

Un portail est généralement disponible en continu et nécessite donc plus d’efforts d’exploitation qu’une simple application Desktop. Pour les administrateurs, c’est le domaine où une bonne architecture rapporte immédiatement : déploiements traçables, observabilité claire (logs/métriques) et créneaux de maintenance définis.

Service Windows ou service Linux : le modèle d’exploitation compte

Un service Delphi peut être exploité comme des services Windows et Linux ou comme un démon Linux. Plus important que le système d’exploitation sont les standards qui stabilisent l’exploitation :

• Health‑Checks pour le monitoring et le load balancer (p.ex. « service vivant » et « base de données accessible »).
• Logging structuré (incl. Request‑ID, utilisateur/tenant, durée, codes d’état) pour rendre les cas support reproductibles.
• Configuration sans rebuild (p.ex. variables d’environnement, fichiers de config centralisés) pour automatiser proprement les déploiements.
• Capacité de rollback via des versions distinctes et des migrations de base de données sûres.

Profils de charge : le portail = « beaucoup de courtes requêtes » plutôt que « quelques longues sessions »

L’utilisation Desktop génère souvent des phases de travail longues par utilisateur, tandis que les portails produisent de nombreuses requêtes courtes et parallèles. Mesures techniques typiques :

• paging systématique, filtres côté serveur et tailles de réponse limitées
• caching pour données de référence et requêtes rares
• jobs asynchrones pour tâches longues (exports, bundles de rapports)
• rate‑limits et protections contre les usages abusifs

Pour les décideurs : la performance n’est pas un simple « réglage final », mais une partie de la définition de l’API (tailles de réponse, timeouts, traitement en arrière‑plan).

Modernisation sans Big‑Bang : une voie robuste en cinq étapes

Un refonte complète est rarement nécessaire et souvent risquée car le savoir‑faire processus est encapsulé dans le client Delphi. Une approche éprouvée consiste en des paliers, chacun étant exploitable en production sans mettre l’exploitation en péril.

1) Inventaire : processus, souveraineté des données, intégrations

Ne commencez pas par les écrans, mais par les use cases : quels flux doivent aller au portail ? Quelles données un utilisateur externe peut‑il voir ou modifier ? Quelles interfaces existent vers ERP, DMS ou CRM ? De là émerge une liste d’APIs priorisées qui apportent une valeur réelle.

2) Définir les fondamentaux de services : Auth, format d’erreur, logging, versioning

Cette base conditionne la maintenabilité ultérieure. Convenir tôt de standards pour authentification/autorisation, d’un format d’erreur cohérent, de corrélation de requêtes, du versionning d’API et de la télémétrie. Cela réduit les frictions entre l’équipe portail, l’équipe backend et l’exploitation.

3) Livrer une première piste portail de bout en bout

Choisissez un processus à périmètre clair (p.ex. zone documentaire ou consultation d’état). L’important est que la chaîne soit complète : login, contrôle des droits, API, UI, logging, monitoring, exploitation. L’organisation identifie ainsi tôt les standards qui fonctionnent en production.

4) Connecter le Desktop de façon ciblée : chemins d’écriture critiques via des services

Dès que les services sont stables, rapatriez des fonctions Desktop choisies : en particulier changements d’état, validations ou validations centrales. Le Desktop reste performant, mais les règles deviennent plus cohérentes et l’accès direct en écriture à la DB est réduit progressivement.

5) Consolider : éliminer règles doublons et chemins spéciaux

Sans cela, on obtient deux systèmes. Prévoyez des consolidations régulières : quelles règles existent en double ? Où le portail peut‑il consommer les services Desktop ? Quels rapports doivent être générés centralement ? L’objectif est une plateforme maîtrisable, pas un dogme.

Pièges typiques du point de vue exploitation – et comment les éviter

Les règles sont réimplémentées dans le portail

Cela provoque des écarts et des tickets support. Contromesure : Use‑Case‑APIs avec validations côté serveur, retours d’erreur explicites et, si possible, scénarios métiers de test partagés.

Propriété des données floue entre Desktop et portail

Si les deux clients peuvent tout modifier, des conflits surgiront. Contremesure : modèle d’états, responsabilités définies et Optimistic Concurrency pour les modifications concurrentes.

La sécurité traitée comme un ajout ultérieur

Pour un portail client, SSO, contrôles multi‑tenant, téléchargements de fichiers sécurisés et audits sont nécessaires dès le départ. Les ajouter après coûte plus cher et augmente le risque de failles.

Manque de transparence en exploitation

Sans Request‑IDs, logs structurés et health‑checks, la recherche d’incidents devient une enquête. Contremesure : l’observabilité est un composant obligatoire des premières releases de service.

Conclusion : un noyau de services relie la puissance du Desktop à la portée du portail

La combinaison d’un Desktop Delphi et d’un portail Web est, dans de nombreuses entreprises, la voie la plus réaliste pour préserver les processus cœur tout en permettant la collaboration externe. Crucial : ne pas exploiter deux mondes séparés, mais créer un noyau de services unificateur : Use‑Case‑APIs, droits clairs, états traçables, flux de données contrôlés et un modèle d’exploitation avec logging, monitoring et déploiements planifiables.

Ainsi se construit une modernisation par paliers : le Desktop reste productif, le portail apporte rapidement de la valeur et l’architecture devient progressivement plus cohérente et maintenable.

Dans le contexte métier, la modernisation Delphi joue aussi un rôle important lorsque les intégrations, les flux de données et l’évolution doivent bien s’articuler.

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