Architecture serveur REST avec Delphi pour les entreprises

Beaucoup d’entreprises se trouvent aujourd’hui dans une situation similaire : une application métier mûre (souvent Delphi/VCL) couvre des processus centraux, mais doit subitement desservir de nouveaux canaux. Un portail client a besoin de données et d’opérations, des utilisateurs mobiles attendent des accès sécurisés, des systèmes tiers (ERP, DMS, CRM, BI) exigent des intégrations. Dans ce contexte, une API REST semble être l’étape logique. En pratique, les initiatives d’API échouent rarement à cause de HTTP ou JSON, mais à cause d’une répartition des responsabilités floue entre client, serveur et couche de données.

Une architecture de serveur REST viable avec Delphi ne naît pas en « posant quelques endpoints » sur des tables de base de données existantes. Elle naît quand l’entreprise considère conjointement les règles métier, les exigences de sécurité, la souveraineté des données, les frontières transactionnelles et les concepts d’exploitation. Le serveur REST devient alors la couche contractuelle stable entre la logique métier et les consommateurs : client desktop, portail, services, partenaires d’interface. C’est précisément là que Delphi montre ses atouts : développement rapide, runtime robuste, code natif performant, bonne intégration aux bases de données (p. ex. via remplacement de BDE avec connexion native) et possibilité d’encapsuler la logique métier de manière contrôlée dans des bibliothèques ou des modules serveur.

Ce billet décrit comment les entreprises peuvent planifier des serveurs REST avec Delphi afin de rester cohérentes sur le plan métier, de s’intégrer dans des paysages applicatifs existants et de ne pas devenir une source d’erreurs en production. L’accent est mis sur les principes d’architecture, les pièges typiques des projets de modernisation et les composants concrets pour la sécurité, l’accès aux données, la gestion des versions et l’observabilité.

Pourquoi une API REST est une décision d’architecture pour l’entreprise

Dans un monde classique client‑serveur, de nombreuses règles étaient implicitement réparties dans le client desktop : validations, changements d’état, calculs, parfois même les autorisations. Tant qu’un seul client existait, cela n’était pas critique — sur le plan métier discutable, mais gérable. Dès que plusieurs consommateurs accèdent aux mêmes objets métier, ce modèle bascule :

• Un portail ne peut pas « réutiliser » les validations du client.
• Les applications mobiles doivent pouvoir fonctionner en mode déconnecté, mais ne doivent pas dupliquer les règles métier.
• Les intégrations exigent des contrats stables, versionnés, et une sémantique d’erreur claire.
• La conformité requiert des accès traçables, des modèles de rôles et des capacités d’audit.

L’API devient le lieu où converge logique métier, droits et accès aux données. Son architecture détermine donc si votre système restera extensible à long terme — ou si vous ne ferez que générer de la dette technique supplémentaire.

Delphi comme plateforme pour des serveurs REST : forces et scénarios typiques

Delphi est souvent associé en entreprise aux applications desktop. Pour des serveurs REST, Delphi est toutefois très adapté, notamment lorsqu’il s’agit de réutiliser de la logique métier existante ou de fournir des services performants. Scénarios typiques en environnement B2B :

• Couche API pour logiciel existant : l’application métier Delphi reste l’UI, le serveur REST encapsule les accès aux données et les règles pour les nouveaux consommateurs.
• Backend pour portail/espace client : le portail web consomme des endpoints REST qui utilisent le même noyau de règles que les processus internes.
• Serveur d’intégration et d’interfaces : raccordement ERP/DMS/CRM, import/export, traitement d’événements, jobs planifiés.
• Services Linux ou services Windows : processus longue durée, workers sur file, scheduler, workflows documentaires.

Ce qui compte moins, c’est le label du framework, et plus la discipline sur le découpage en couches, la gestion de la concurrence, le traitement des erreurs et le déploiement. Delphi permet les deux : des itérations rapides et, en même temps, une architecture modulaire et propre — à condition de planifier consciemment.

Modèle en couches : l’architecture Layer-3 comme fondation pour des API durables

Pour le logiciel d’entreprise, un modèle en couches clair et léger s’est avéré efficace. Dans l’écosystème Delphi, cela est souvent décrit comme l’architecture Layer-3. Les termes varient, mais les responsabilités doivent être nettes :

1) Couche API/Transport (HTTP, sérialisation, routage)

Cette couche gère HTTP, l’authentification au niveau protocole, les formats request/response, le routage, les codes d’état, le Content-Type, la compression. Aucune règle métier n’y a sa place. Objectif : interchangeabilité et testabilité. Si vous étendez ultérieurement votre API REST par d’autres protocoles (p. ex. WebSocket, patterns de type gRPC, Server‑Sent Events), le noyau métier doit rester stable.

2) Couche Domaine/Service (logique métier, cas d’usage, droits, transactions)

La vérité métier réside ici : machines d’état, calculs, plausibilités, règles multi‑tenants, vérifications de droits sur les actions métiers. Cette couche doit être indépendante de l’UI et travailler idéalement sans connaissance de HTTP. Idéalement, implémentez des cas d’usage tels que «libérer commande», «clore ticket», «générer facture» plutôt que du simple CRUD sur des tables.

3) Couche d’accès aux données (repositories, SQL, FireDAC, mapping)

Cette couche encapsule la persistance : SQL, procédures stockées, contrôle transactionnel, stratégies de verrouillage, connection‑pooling, particularités DB. Dans Delphi, BDE-Ablosung mit nativer Anbindung est souvent un choix pragmatique, surtout lors de migrations (remplacement de BDE) et dans des environnements à bases hétérogènes (SQL Server, PostgreSQL, MariaDB, Firebird). Il est essentiel que la couche Data‑Access ignore HTTP et n’implique pas de décisions métier.

Ce modèle réduit le couplage : les changements du modèle de données n’exigent pas de réécriture de l’API, et les nouveaux clients héritent automatiquement de la même logique. C’est particulièrement la base de la modernisation Delphi, permettant de découpler progressivement des applications desktop existantes sans interrompre l’exploitation.

Conception d’API pour logiciel d’entreprise : pas du CRUD mais des contrats métier

Beaucoup d’APIs démarrent avec des endpoints comme /customers, /orders, /documents et implémentent du CRUD. C’est parfois suffisant pour des outils internes, mais en logiciel d’entreprise c’est vite trop superficiel. Les processus métier consistent en changements d’état, règles, effets secondaires et autorisations.

Modéliser clairement ressources, actions et états

Un meilleur schéma combine ressources et actions explicites, par exemple :

• Lire la ressource : GET /orders/{id}
• Déclencher une action : POST /orders/{id}/release
• Générer un document : POST /orders/{id}/documents/invoice
• Vérifier le statut : GET /orders/{id}/status

Cela rend visible dans le contrat API que «libérer» n’est pas un simple update de champ. Le serveur peut appliquer centralement validations, droits, transactions, audit et processus annexes.

Sémantique d’erreur et validation : rendre les erreurs planifiables pour les clients

Les clients d’entreprise doivent pouvoir distinguer les types d’erreurs : erreurs de validation (400), permission manquante (403), conflit dû à une modification parallèle (409), refus métier (souvent 409 ou 422), problèmes backend temporaires (503). Une structure d’erreur cohérente est importante, par exemple avec un code d’erreur, un message, des indications de champ optionnelles et une correlation‑ID. Ainsi un portail peut afficher des messages compréhensibles et le support/les opérations peuvent tracer efficacement les incidents.

Sécurité : authentification ≠ autorisation

Dans le contexte B2B, la sécurité échoue rarement à cause du chiffrement, mais plutôt à cause d’un manque de séparation entre identité, rôles et autorisations métier. Une architecture serveur REST doit donc distinguer deux niveaux :

Authentification (qui est-ce ?)

Les approches courantes sont token‑based (p. ex. JWT ou tokens opaques), combinées à TLS et une stratégie de session claire. Points décisifs : durée de vie des tokens, mécanisme de refresh, invalidation lors de changements de rôle, et la question de savoir si vous utilisez des Identity‑Providers distincts pour portails et systèmes internes. Les serveurs Delphi peuvent agir en Resource‑Server et, selon le setup, émettre des tokens. Dans de nombreuses entreprises, l’intégration aux systèmes d’identité existants (p. ex. AD/LDAP, solutions SSO) est un point central.

Autorisation (a‑t‑il le droit ?)

L’autorisation appartient à la couche Domaine/Service. Les rôles et droits sont rarement purement techniques ; ils dépendent du tenant, du site, de l’unité organisationnelle, du statut contractuel ou de la phase du processus. Bonnes pratiques :

• Modèle de rôles (p. ex. Admin, Gestionnaire, Auditeur) comme base
• Politiques métier («peut générer la facture seulement en statut X», «peut voir uniquement ses propres tickets»)
• Multi‑tenancy par défaut : chaque requête requiert un contexte tenant
• Audit : qui a déclenché quelle action et quand

L’API ne doit pas se contenter de renvoyer «accès autorisé/refusé», mais empêcher systématiquement qu’une manipulation de paramètres rende visibles des données d’un autre tenant. Cela paraît évident, mais dans des systèmes hérités c’est l’un des défauts d’architecture les plus fréquents quand on «pose des tables sur HTTP» trop rapidement.

Accès aux données avec FireDAC : transactions, pooling et stratégie base de données

Dans les applications d’entreprise, l’accès aux données est le facteur de stabilité : pics de charge, deadlocks, rapports longs, mises à jour parallèles, imports en masse. FireDAC est un composant éprouvé dans l’écosystème Delphi pour accéder de manière unifiée à différentes bases. Pour une architecture serveur REST, les points suivants sont cruciaux :

Bornes transactionnelles par cas d’usage

Une API REST est typiquement basée sur des requêtes. Cela se prête bien au concept «transaction par cas d’usage» : ouvrir une transaction dans la portée d’une requête, effectuer les opérations métier, puis commit/rollback. Important : ne pas mettre automatiquement chaque endpoint en transaction, mais être cohérent pour les opérations en écriture. Les endpoints de lecture peuvent aussi nécessiter des transactions selon le niveau d’isolation requis pour des vues cohérentes.

Stratégie de connexions et parallélisme

La parallélité serveur signifie : beaucoup de requêtes simultanées, chacune avec accès DB. Prévoyez donc :

• tailles de pool limitées et surveillées
• timeouts pour les requêtes et connexions
• règles claires pour les opérations longues (externaliser en jobs/workers)

Une erreur fréquente est de faire tourner des rapports coûteux ou des exports massifs de manière synchrone sur la même instance API qui sert les requêtes interactives du portail. Mieux vaut séparer : interactif vs batch/async.

Modernisation de la base comme partie de la planification API

Si l’existant contient encore des accès anciens (p. ex. BDE), l’API devient un catalyseur : elle impose des frontières d’accès claires. Un remplacement contrôlé vers FireDAC réduit les risques et augmente la portabilité (PostgreSQL, MariaDB, SQL Server). Ne planifiez pas cela en «Big Bang», mais par étapes : les nouveaux cas serveur utilisent déjà la nouvelle couche Data‑Access, tandis que les composants hérités migrent progressivement.

Versioning et compatibilité descendante : protéger les contrats API

Les entreprises sous‑estimeraient souvent le coût des breaking changes. Dès qu’un portail client, un système partenaire ou un service Windows dépend de votre API, vous ne pouvez plus «renommer un champ en vitesse». Une stratégie de versioning propre est donc obligatoire.

Règles pragmatiques pour le versioning

• Pas de breaking changes sans version : ne renommez/supprimez pas des champs, n’interprétez pas différemment des endpoints.
• Étendre plutôt que changer : ajouter des champs, marquer les anciens comme dépréciés.
• Valeurs par défaut compatibles : éviter de nouvelles propriétés obligatoires ou les dériver côté serveur.
• Versionnement explicite : p. ex. /v1/… ou via header ; la méthode importe moins que la constance.

Pour les équipes Delphi, cela implique aussi : stabiliser les DTO (Data Transfer Objects) et concevoir le mapping consciemment, plutôt que de sérialiser objets domaine 1:1. Cela augmente le travail initial, mais réduit les coûts de support à long terme.

Observability : logs, métriques et traces dès le départ

En exploitation, «ça marche chez moi» ne suffit pas si les erreurs sont impossibles à reproduire. Les serveurs REST qui desservent de nombreux consommateurs exigent un minimum d’observabilité :

Logging structuré avec correlation‑ID

Chaque requête doit porter une correlation‑ID (reprise si fournie ou générée) et apparaître dans les logs. Les entrées de log doivent être structurées (p. ex. logs JSON) pour ingestion dans des systèmes centraux. Au minimum, collectez :

• méthode request, route, code de statut, durée
• contexte user/tenant (pseudonymisé / conforme)
• durée DB et classe d’erreur
• correlation‑ID pour le support

Métriques pour capacité et tendances d’erreurs

Pour la montée en charge et la stabilité, on a besoin de métriques : requêtes par minute, latences p95/p99, taux d’erreur par endpoint, utilisation du pool DB, longueurs de queue. Ce n’est pas nécessairement du «Cloud‑Native overkill», mais sans chiffres les discussions de performance restent subjectives.

Traitement des erreurs et exceptions comme élément d’architecture

Les exceptions Delphi ne doivent pas fuiter de manière incontrôlée vers l’extérieur. Un middleware d’exception central (ou un handler global) doit traduire les exceptions en réponses d’erreur cohérentes, incluant un ID de support et des codes HTTP pertinents. Les stacktraces appartiennent aux logs sécurisés, pas aux réponses clients.

Synchrone vs asynchrone : extraire les processus longs de la réponse REST

Beaucoup de processus métier ne tiennent pas dans un cycle request/response de 200 ms : génération de PDF, import de données, traitements d’interfaces, rapprochements, modifications massives, archivage. Ces charges ne doivent généralement pas être exposées par un endpoint REST synchrone, car elles occupent des threads, provoquent des timeouts et bloquent les utilisateurs.

Pattern job

Pratique courante : un endpoint démarre un job et le serveur retourne immédiatement un Job‑ID. Un autre endpoint fournit le statut/résultat. Un callback/webhook peut notifier. En Delphi, cela se met en œuvre avec des services worker, une table de jobs et une machine d’état claire. Avantage : stabilité et scalabilité prévisible.

Queues et services

Selon le contexte, une file de messages peut être pertinente, mais ce n’est pas toujours nécessaire. L’essentiel est le principe : les APIs interactives restent réactives, les processus batch s’exécutent de manière contrôlée, répétable et observable — en tant que services Windows ou Linux, selon le mode de déploiement.

Déploiement en entreprise : Windows, Linux, conteneurs, on‑prem

Une architecture serveur REST est «opérationnelle» seulement si elle est exploitée. Les entreprises diffèrent fortement : serveurs Windows classiques, hôtes virtualisés Linux, plateformes conteneurisées, zones réseau strictes, règles de proxy et de certificats. Delphi est flexible dans ces contextes, à condition de maîtriser les dépendances.

Configuration et secrets

La configuration doit être dépendante de l’environnement (Dev/Test/Prod). Les identifiants n’ont pas leur place dans l’EXE ou le dépôt. Utilisez un stockage sécurisé (p. ex. le gestionnaire de secrets de la plateforme) et séparez les valeurs de configuration des releases de code. Prévoyez également des rotations (mot de passe DB, API‑Keys) sans recompilation du système.

Stratégies de release et rollback

Lorsque plusieurs consommateurs dépendent d’une API, vous avez besoin de releases contrôlées : scripts de migration pour les changements DB, feature‑toggles pour activation progressive, chemins de rollback clairs. En particulier, les changements structurants de base de données doivent rester compatibles en arrière‑pour permettre un rollback de la version serveur.

Intégration avec l’existant : modernisation progressive plutôt que Big Bang

Dans de nombreux environnements Delphi, le noyau métier est précieux mais techniquement «collé» : accès aux données couplés à l’UI, états globaux, responsabilités mélangées. Une API REST peut représenter à la fois un risque et une opportunité. L’objectif est une trajectoire produisant des améliorations mesurables avec un effort raisonnable.

Approche Strangler pour les APIs

Plutôt que de tout refondre, définissez des points d’intégration métier apportant une valeur réelle : par ex. «statut de commande et documents pour le portail client», «lookup de données de base pour utilisateurs mobiles», «interface pour écritures comptables ERP». Ces cas d’usage sont implémentés comme nouvelles fonctions API, avec couche Domaine et Data‑Access. Le client historique peut basculer progressivement sur les mêmes cas serveur, sans nécessiter une refonte immédiate de l’UI.

Logique métier partagée : utile, mais contrôlée

Delphi permet de partager des bibliothèques métier entre le serveur et les applications existantes. Cela peut être un pont, mais comporte des risques : si des dépendances UI s’infiltrent dans la logique partagée, vous perdez l’indépendance. Règle simple : partager uniquement la logique sans UI, sans états globaux, avec des interfaces claires et des unités testables. Le reste reste séparé.

Erreurs typiques dans les projets de serveurs REST — et comment les éviter

«Nous publions simplement des tables»

Lorsque des endpoints reflètent directement des tables, le système devient instable : chaque refactoring DB provoque un breaking change de l’API, les règles métier sont dupliquées dans les clients, et les vecteurs d’injection/sécurité via des paramètres non contrôlés augmentent. Mieux : définir des Use‑Cases métier et des DTO qui stabilisent le contrat.

Autorisations métier uniquement côté client

Les clients sont remplaçables et manipulables. L’autorisation doit résider côté serveur et prendre en compte les règles métier, pas seulement des rôles techniques.

Absence de stratégie claire pour la concurrence

Les mises à jour parallèles arrivent : deux gestionnaires, portail et client interne, ou un job d’import. Sans Optimistic Locking (p. ex. RowVersion/Timestamp), codes de conflit (409) et règles de merge, vous obtiendrez des pertes de données ou des effets «dernier write gagne».

Les processus longs bloquent les endpoints interactifs

La génération synchrone de PDF ou d’exports provoque des timeouts et des expériences «verrouillées». Le pattern job avec endpoints de statut est préférable.

L’observabilité est ajoutée a posteriori

Sans correlation‑ID, logs structurés et métriques, chaque incident exige de longues enquêtes. L’observabilité n’est pas un luxe, c’est une condition d’exploitation.

Checklist concrète pour votre architecture de serveur REST avec Delphi

• Séparer clairement les couches : transport (HTTP), domaine (Use Cases), accès aux données (FireDAC/SQL).
• Considérer l’API comme un contrat : stabiliser les DTO, planifier le versioning, éviter les breaking changes.
• Sécurité en deux étapes : authentification (tokens) plus autorisation (politiques métier, tenant).
• Définir explicitement les transactions : par Use Case, timeouts, stratégie de conflit.
• Rendre asynchrone les longs traitements : jobs/workers, services Windows ou Linux.
• Intégrer l’observabilité : correlation‑ID, logs structurés, métriques, gestion centralisée des erreurs.
• Planifier le déploiement de façon réaliste : configuration/secrets, rollback, migrations de base de données.
• Moderniser de façon itérative : cas d’usage à valeur ajoutée d’abord, découplage progressif des composants hérités.

Conclusion : les serveurs REST déploient leur valeur en tant qu’architecture métier et d’exploitation

Une architecture serveur REST avec Delphi est particulièrement efficace en entreprise lorsqu’elle n’est pas perçue comme une «surface technique», mais comme le noyau reliant processus, données et canaux. Les éléments décisifs sont des couches propres (architecture Layer-3), des endpoints modélisés métier, une logique de sécurité et de multi‑tenancy conséquente, ainsi qu’un modèle d’exploitation incluant versioning, monitoring et gestion contrôlée de la concurrence. Ainsi, l’API devient une plateforme stable : pour portails, intégrations, services et la modernisation progressive Delphi — sans mettre en risque la substance métier d’un système hérité.

Si vous souhaitez examiner comment implémenter une API REST robuste sur votre paysage Delphi existant (y compris stratégie base de données, FireDAC, services et exploitation), contactez‑nous ici : https://net-base-software-gmbh.de/kontakt/