C# et Delphi dans une architecture commune : intégration pragmatique plutôt que tout-ou-rien

Dans de nombreux services informatiques, la situation de départ est similaire : une application desktop Delphi stable et proche des processus supporte des opérations critiques, tandis que de nouvelles exigences poussent vers le Web, les portails, l’usage mobile et l’intégration avec des services cloud. Parallèlement, C# est adopté dans de nombreuses entreprises pour les services, les Web-API et l’intégration d’identités. La question centrale n’est donc plus « Delphi ou C# ? », mais : combiner C# et Delphi dans une architecture commune de façon à maîtriser l’exploitation, la maintenance, la gestion des données et la sécurité.

Cet article décrit des principes d’architecture pragmatiques qui font leurs preuves dans des environnements d’entreprise où tout ne peut ni ne doit être reconstruit. L’accent est mis sur des responsabilités clairement définies entre le client de bureau, les services, les données et les interfaces – et sur la manière de planifier des étapes de modernisation à faible risque, sans mettre en péril les processus en cours.

Pourquoi les stacks mixtes sont la norme en entreprise

Les solutions numériques d’entreprise issues d’une évolution historique naissent rarement sur une feuille blanche. Les applications Delphi ont souvent été étendues pendant de nombreuses années, proches des processus métier, avec une logique de données conséquente et un savoir-faire approfondi sur les cas particuliers. En parallèle, de nouvelles exigences sont apparues : portails en libre-service, échanges de données automatisés, connexion à DMS/CRM/ERP, capacité multi‑locataire, auditabilité renforcée ou Single Sign-on.

C# offre dans ce contexte des avantages pour les écosystèmes Web et services : large éventail d’hébergement, middleware standardisée, bonne intégration aux Identity Provider et patterns établis pour les Web-API. Delphi reste en revanche pertinent lorsque l’on vise des clients desktop Windows performants, des applications VCL maintenues sur le long terme ou des clients multiplateforme spécifiques (p. ex. via FMX).

Le mélange n’est donc pas un « cas particulier », mais une réponse réaliste à la protection des investissements et à la pression de modernisation. L’essentiel est que l’exploitation conjointe ne devienne pas un chantier permanent.

Principe d’architecture : couches claires plutôt que frontières linguistiques

Quand deux langages coexistent, la tentation est grande d’organiser la séparation selon la technologie (« Tout Delphi est Legacy, tout C# est neuf »). Techniquement, cela peut fonctionner à court terme, mais conduit à long terme à des frictions : règles métier dupliquées, responsabilités floues et erreurs difficiles à reproduire.

En pratique, une stratification fonctionnelle s’est avérée efficace, souvent mise en œuvre comme une architecture Layer-3 : présentation (UI), domaine (logique métier) et infrastructure (accès aux données, systèmes externes). L’important n’est pas le modèle théorique, mais l’effet concret au quotidien : les décisions concernant les données, les validations et les workflows sont prises en un seul endroit et exposées via des interfaces stables.

Dans une architecture mixte, cela signifie concrètement : Delphi peut continuer à fournir une partie UI (ou certains workflows), tandis que C# services encapsulent une couche de domaine métier – ou inversement. Il est crucial que la frontière entre les couches soit techniquement propre et testable.

C# et Delphi dans une architecture commune : trois modèles d’intégration éprouvés

Pour le couplage de Delphi et C# il n’existe pas « le » bon chemin unique. Les bonnes décisions se fondent sur l’exploitation, les exigences de sécurité, la latence, le volume de données et les cycles de release. En pratique, trois schémas se sont dégagés.

1) Approche orientée services sur HTTP/REST comme couplage standard

La solution souvent la plus robuste pour l’exploitation et l’évolution est une intégration via des APIs REST (interfaces basées sur HTTP). Les clients Delphi appellent des services C# ou Delphi ; les portails C# utilisent les mêmes endpoints. Cette découplage rend les releases plus prévisibles : une mise à jour du client n’est pas forcément nécessaire si l’API reste rétrocompatible.

Il est important d’appliquer cela de façon professionnelle : timeouts, réessais, idempotence (requêtes répétables sans effets secondaires), codes d’erreur clairs et une stratégie de gestion des versions. Pour l’administration et l’exploitation, comptent également : des logs homogènes, des Request-IDs traçables et des temps de réponse bien mesurables.

2) Base de données partagée : seulement avec des règles claires

Un accès partagé à la base de données entre Delphi et C# est séduisant car il est rapide au départ. À long terme, il devient risqué si les deux mondes écrivent directement sur les mêmes tables. La raison : les règles métier migrent vers des triggers, des stored procedures ou « quelque part dans le client ». Cela complique l’analyse des erreurs et les audits.

Si une base commune est inévitable (par ex. en phases de transition), des règles claires aident :

• Centraliser les accès en écriture : un système est « System of Record » pour certaines entités.
• Définir des contrats : des vues ou des APIs comme couche de lecture stable plutôt que des accès directs aux tables.
• Planifier des fenêtres de migration : déployer les modifications de base de données toujours de manière rétrocompatible (par ex. nouvelles colonnes d’abord optionnelles).

Techniquement, la base de données devient alors un composant d’infrastructure, et non le bus d’intégration.

3) Messaging/Events pour processus asynchrones

Pour des enchaînements découplés (par ex. imports, notifications, post-traitements, jobs d’interface), un modèle asynchrone est pertinent : un système publie des événements, un autre les consomme. Cela réduit les dépendances directes et stabilise les pics de charge.

Pour la direction IT et les administrateurs, sont importants : le monitoring (longueurs des queues), les concepts de dead-letter (messages échoués), le comportement de reprise au redémarrage et une idempotence fonctionnelle clairement définie. Les events ne remplacent pas une gouvernance propre des données de référence, mais constituent un bon outil pour des chaînes de processus robustes.

Contrats de données et compatibilité : le noyau sous-estimé

Indépendamment du pattern d’intégration, la qualité des contrats de données détermine la stabilité. Un contrat de données est la description contraignante des champs, des types, de l’obligatoire/optionnel et de la sémantique. Dans les APIs REST il s’agit typiquement de JSON ; l’important n’est pas « le JSON en soi », mais la discipline dans la gestion des changements.

Règles éprouvées qui simplifient sensiblement l’exploitation :

• Étendre plutôt que casser : ajouter de nouveaux champs, continuer d’envoyer les anciens dans un premier temps.
• Documenter la sémantique des champs : pas seulement « string », mais p. ex. date ISO, fuseau horaire, états autorisés.
• Traiter de manière tolérante les valeurs d’énumération : les clients doivent survivre à des valeurs inconnues (compatibilité ascendante).
• Appliquer la gestion des versions d’API de manière consciente : chaque release n’exige pas une nouvelle version ; mais les breaking changes doivent être clairement encapsulés.

Ces points sont particulièrement importants lorsque des clients desktop Delphi ne peuvent pas être mis à jour aussi fréquemment que des services web.

Authentification et autorisation : un modèle de sécurité commun

Les architectures mixtes échouent rarement à cause de la « technique », plus souvent en raison d’une sécurité incohérente. Pour l’entreprise, l’essentiel est : qui est autorisé à faire quoi ? Comment cela est-il vérifié ? Comment est-ce audité ? Un modèle commun évite la gestion d’utilisateurs en double et des rôles contradictoires.

En pratique, cela conduit à une couche d’identité centrale : par exemple via SAML 2.0 (authentification unique fédérée, fréquent en environnement entreprise) ou OpenID Connect (basé sur OAuth2, souvent utilisé pour des API Web modernes). C#-services peuvent généralement être connectés directement à un Identity Provider ; les clients Delphi peuvent obtenir des tokens et les joindre aux appels API. Il est important que les applications de bureau n’obtiennent pas non plus de « droits spéciaux » via un accès direct à la base de données.

Pour les administrateurs, éléments centraux :

• Durées de vie des tokens et stratégie de refresh (pour que les clients restent stables tout en étant sécurisés)
• Authentification service-to-service pour la communication interne (p. ex. mTLS ou tokens signés)
• Least Privilege : ne pas définir les rôles et autorisations de façon trop large
• Logs d’audit : consigner de manière traçable les actions pertinentes pour la sécurité

Concepts d’exploitation: Windows- und Linux-Services, IIS und Prozesse im Alltag

Une architecture n’est « bonne » dans l’entreprise que si elle est exploitable : mises à jour planifiables, localisation des erreurs, maîtrise de la charge. Dans des paysages mixtes, les variantes d’exploitation les plus courantes sont :

• Windows- et Linux-services : adapté aux jobs d’arrière-plan, aux traitements d’interfaces et aux workers ; bien intégrable dans des modèles d’exploitation de serveurs Windows classiques.
• Windows- et Linux-services/daemon : pertinent pour des modèles d’exploitation containerisés ou basés sur VM ; souvent stable en fonctionnement continu, bonne automatisation via systemd.
• Microsoft IIS : hébergement établi pour applications Web et scénarios de reverse-proxy dans des environnements centrés sur Windows.

Il est important que les composants Delphi et C# respectent des standards d’exploitation similaires : endpoints de santé cohérents (signes de vie), timeouts définis, consommation de ressources limitée, ainsi qu’une procédure claire de déploiement et de rollback. Cela réduit les traitements exceptionnels « spécifiques à une technologie ».

Logging, tracing et métriques : un niveau d’observabilité commun

Particulièrement avec deux stacks technologiques, des chaînes de diagnostic continues sont essentielles. Un problème typique : le client Delphi signale « erreur lors de l’enregistrement », le service C# rencontre un timeout, la base de données signale des verrous — sans lien commun.

Les pratiques éprouvées sont :

• IDs de corrélation par requête (Client → API → DB), pour permettre la consolidation des logs.
• Logging structuré (clé/valeur plutôt que de simples lignes de texte), pour pouvoir filtrer ensuite.
• Métriques pour la latence, les taux d’erreur, les longueurs de file d’attente et l’utilisation des ressources.
• Classification des erreurs : erreurs métier (validation) séparées des erreurs techniques (timeout, réseau).

Ces principes de base font gagner en pratique plus de temps que n’importe quelle discussion sur « le bon langage ».

Accès aux données et migration : BDE-remplacement, FireDAC et bases de données modernes

Dans les environnements Delphi, l’accès aux données a historiquement joué un rôle important. Lorsqu’encore d’anciens chemins d’accès comme la Borland Database Engine (BDE) sont en service, une pression supplémentaire apparaît : mises à jour du système d’exploitation, migrations 64 bits, disponibilité des pilotes, exigences de sécurité. Une BDE-remplacement n’est alors pas seulement une modernisation, mais une réduction du risque.

Typiquement, la migration consiste en un BDE-remplacement avec nativer Anbindung (couche d’accès aux données moderne en Delphi), combinée à une base de données opérationnellement facile à gérer (p. ex. PostgreSQL, SQL Server, MariaDB). Pour une architecture commune Delphi/C#, deux aspects sont importants :

• Limites de transaction : qui initie/committe les transactions, et comment les accès en écriture parallèles sont-ils gérés ?
• Stratégie de verrouillage et d’isolation : afin que les workflows de bureau et les services ne se bloquent pas mutuellement.

Lors des migrations, une planification en étapes s’avère judicieuse : moderniser d’abord la couche pilote et d’accès, puis consolider le modèle de données, ensuite stabiliser les interfaces d’intégration. Ainsi les sources d’erreurs deviennent isolables et les rollbacks réalistes.

Release-Management : concilier des cycles de mise à jour différents

Un point de tension récurrent est la fréquence des mises à jour : les services web peuvent être déployés plus fréquemment, les clients de bureau souvent moins (fenêtres de déploiement, communication aux utilisateurs, packaging). Une architecture commune doit tenir compte de cette asymétrie.

Conséquences pratiques :

• Rétrocompatibilité des API est une obligation, pas un luxe.
• Feature Flags (commutateurs fonctionnels) aident à activer de nouvelles fonctionnalités de manière contrôlée côté serveur.
• Migrations de schéma doivent s’effectuer en phases : étendre la base de données d’abord, ensuite permettre au service de l’utiliser, puis mettre à jour le client.
• Dépréciation claire : supprimer d’anciens endpoints ou champs seulement après une période définie.

Particulièrement dans des environnements régulés, il est important d’officialiser ces règles par écrit comme garde-fous architecturaux, afin que les décisions ne soient pas réinventées au cas par cas.

Pièges typiques et comment les éviter de manière systématique

Du point de vue de l’exploitation, les problèmes les plus fréquents dans les environnements mixtes Delphi/C# sont prévisibles. Si on les adresse tôt, les coûts à long terme diminuent sensiblement.

Piège 1 : logique métier dupliquée

Lorsque le client Delphi et le service C# implémentent différemment les mêmes règles, des « erreurs fantômes » apparaissent : un processus fonctionne dans l’UI mais échoue lors de l’import API. Contre-mesures : centraliser les règles dans la couche domaine (service) ou les attribuer clairement sur le plan fonctionnel, y compris des réponses de validation explicites.

Piège 2 : contournements côté UI au lieu d’interfaces propres

« Écrire rapidement un champ de base de données » peut sembler anodin au cas par cas, mais crée des interfaces fantômes sans journalisation, authentification ni gestion de versions. Mieux : passer systématiquement par des endpoints définis, même si cela exige d’abord plus de discipline.

Piège 3 : responsabilités d’exploitation peu claires

Si l’on ne sait pas quelle équipe est responsable de quel service, de quel log et de quels paramètres d’exploitation, la recherche d’incidents tourne au ping-pong. Concrètement, une cartographie des services (quel service, quelles dépendances, quels ports, quels SLA internes) et des runbooks uniformes pour les incidents fréquents aident.

Stolperstein 4: fehlende Sicherheitskonsistenz

Un portail avec SSO mais un client desktop avec des comptes administrateur locaux pose problème dans de nombreux audits. Un modèle d’identité et de rôles commun réduit les risques et la charge de support.

Entscheidungshilfe: Was bleibt in Delphi, was geht in C#?

La répartition pertinente dépend moins d’une idéologie que de la proximité avec les processus et des exigences d’exploitation. À titre d’orientation du point de vue de l’architecture et de l’exploitation :

• Delphi ist häufig gut für : des clients desktop existants Windows (VCL), des flux UI très réactifs, des scénarios proches de l’offline, la maintenance à long terme d’interfaces héritées.
• C# ist häufig gut für : des API centrales REST, des services d’intégration vers ERP/DMS/CRM, des composants proches de l’identité, des portails et des processus backend à forte fréquence de changements.
• Bewusst entscheiden : la logique de données et la validation ne doivent pas rester « dans le client » lorsque plusieurs frontends existent (desktop, portail, jobs d’import).

Important : l’objectif n’est pas « tout vers C# », mais une architecture globale robuste dans laquelle les étapes de modernisation sont planifiables et les processus métiers restent stables.

Modernisierungspfad: Schrittweise von der Anwendung zum System

Dans la pratique, une architecture commune est souvent une transition, mais une transition longue. Un parcours de modernisation réaliste évite les grands projets à haut risque et mise sur des objectifs intermédiaires mesurables :

1. Stabiliser les interfaces : introduire l’API REST comme frontière fonctionnelle, même si tout n’est pas encore « propre » en interne.
2. Moderniser l’accès aux données : remplacement de BDE, pilotes, prise en charge 64 bits, transactions claires.
3. Centraliser l’identité : SSO et modèle de rôles pour toutes les voies d’accès.
4. Uniformiser l’exploitation : Logging/Monitoring/Health, déploiements clairs, environnements reproductibles.
5. Découpler les modules fonctionnels : déplacer les parties particulièrement sujettes aux changements vers des services, alléger progressivement l’UI.

Cette séquence n’est pas dogmatique, mais elle minimise typiquement les dépendances : sans interfaces stables et concept d’exploitation, chaque changement ultérieur revient plus cher.

Fazit: Integration ist eine Architekturaufgabe, keine Sprachenfrage

Une combinaison viable entre Delphi et C# ne naît pas de « bibliothèques passerelles », mais de frontières fonctionnelles claires, de contrats de données propres et d’un concept d’exploitation qui prend au sérieux le monitoring, la sécurité et le release‑management. Lorsque C# et Delphi dans une architecture commune jouent consciemment selon les responsabilités, les entreprises obtiennent avant tout une chose : une modernisation sans rupture de processus. Delphi peut continuer à supporter de manière fiable des workflows desktop stables, tandis que les services C# fournissent l’intégration, les Web‑APIs et les portails comme fonctions centrales de plateforme.

Si vous souhaitez moderniser progressivement un paysage Delphi existant ou connecter proprement des services C#, une revue d’architecture axée sur les interfaces, les données, l’exploitation et la sécurité est le moyen le plus rapide d’aboutir à des décisions fiables. Plus d’informations dans un échange direct :

Dans le contexte métier, la Delphi modernisation et l’REST-API pour les logiciels existants jouent un rôle important lorsque les intégrations, les flux de données et l’évolution doivent s’articuler proprement.

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