Windows 11 ARM64 avec Delphi en entreprise : options, risques et un chemin de migration robuste

Windows-appareils avec CPU ARM64 (ARM64 est une architecture processeur 64 bits, connue des SoC mobiles et de plus en plus présente dans les notebooks professionnels) ne sont dans de nombreuses entreprises plus seulement des « exotiques ». Ils arrivent via des parc de notebooks standardisés, des durées de batterie plus longues, de nouvelles fonctions de sécurité au niveau matériel et une diversification stratégique des chaînes d’approvisionnement. Au plus tard lorsque des services métiers achètent de nouveaux appareils ou que des OEM proposent certains modèles uniquement comme Windows on ARM, la question pratique se pose pour les responsables IT : comment se comporte notre logiciel métier basé sur Delphi sous Windows 11 ARM64 — et comment garantir exploitation, support et évolution ?

Le point central est : Windows 11 ARM64 avec Delphi en entreprise n’est pas tant une question de développement pur que d’interdépendances, de stratégies de déploiement, de pilotes, d’interfaces et du comportement réel sur le terrain. Dans la pratique, trois voies existent : maintien via émulation, builds natifs ARM64 ou un modèle de transition qui réduit les risques de manière contrôlée. Cet article positionne les écueils typiques et montre une voie robuste qui fonctionne dans la planification IT, le déploiement et l’exploitation — sans réflexe « tout refaire ».

Pourquoi Windows 11 ARM64 devient maintenant pertinent

Windows on ARM n’est pas nouveau, mais le contexte a changé : les appareils sont disponibles en environnement professionnel, Windows 11 apporte une émulation x64 nettement plus mature, et les éditeurs livrent de plus en plus de variantes ARM64. Pour les entreprises, cela signifie : ARM64 n’apparaît plus comme un projet pilote ponctuel, mais comme une plateforme intégrée aux plans d’achat et de cycle de vie.

Pour les solutions logicielles proches des processus, le problème n’est souvent pas tant le CPU que la réalité périphérie et intégration : impression, cartes de signature, scanners, add-ins Office, composants COM (COM est le modèle de composants de Microsoft pour l’intégration d’applications et de bibliothèques), extensions de shell, clients VPN ou agents de sécurité. Si l’un de ces éléments n’est pas compatible ARM64, cela génère du travail de support — et bien souvent, « l’application » est tenue pour responsable.

Positionnement : que signifie ARM64 techniquement pour les applications Delphi ?

Les applications Delphi en environnement d’entreprise sont souvent des clients desktop classiques Windows (souvent VCL, c’est‑à‑dire la Visual Component Library pour les interfaces Windows) avec accès base de données (p. ex. via la remplacement BDE avec connexion native, la couche d’accès aux données de Delphi) et un mélange d’intégrations locales et distantes. Sous Windows 11 ARM64 se dégagent ainsi trois modes d’exécution :

1) Exécution native ARM64

L’application et toutes les bibliothèques natives (DLLs) sont fournies en ARM64. C’est à long terme l’option la plus propre, car elle rend la performance et la stabilité prévisibles et évite les contraintes liées à l’émulation. Elle n’est toutefois réaliste que si toutes les dépendances natives suivent : pilotes de base de données, impression/aperçu, moteur PDF, bibliothèques cryptographiques, SDKs OCR/scan, pilotes de dongles matériels, etc.

2) x64-Emulation unter Windows 11 ARM64

Windows 11 peut émuler des applications x64. Pour de nombreux clients purement desktop, cela fonctionne étonnamment bien. En pratique, l’émulation n’est toutefois pas un ‚passe-droit‘ : dès que des pilotes, des intégrations de l’explorateur ou des composants in-process (DLL chargées dans le processus) interviennent, l’architecture compte. Un processus x64 ne peut pas charger une DLL ARM64 et inversement. C’est précisément cette limite qui décide souvent si ça « marche » ou « ne marche pas ».

3) Hybride : client ARM64, découpler les composants x64

Une voie de transition consiste à extraire les composants x64 critiques hors du processus : p. ex. en tant que service externe, en tant que backend REST (REST est un modèle d’interface basé sur HTTP) ou en tant qu’utilitaire séparé. Ce n’est pas aussi élégant que „tout natif“, mais c’est souvent la solution la plus économique pour garantir l’exploitation et moderniser progressivement les dépendances.

Windows 11 ARM64 avec Delphi en entreprise : les dépendances typiques qui déterminent le succès

Dans les projets, il apparaît rapidement : ce n’est pas l’interface graphique qui est le goulot d’étranglement, mais l’écosystème. Une analyse structurée des dépendances permet d’économiser ici des semaines d’essais et d’erreurs.

DLL natives et SDK : le risque invisible

De nombreuses applications Delphi intègrent des DLL tierces : génération de PDF, codes-barres/QR, traitement d’images, chiffrement, bibliothèques de communication propriétaires. Sur ARM64, règle stricte : une DLL doit correspondre à l’architecture du processus. L’émulation n’est utile que si le processus complet reste x64. Dès qu’on souhaite fonctionner nativement, ces bibliothèques doivent être disponibles en ARM64 ou être remplacées.

Conseil pratique pour l’IT : demandez au responsable logiciel une liste des DLL présentes dans le répertoire d’installation et de celles chargées via les chemins système. C’est la base pour évaluer la capacité des éditeurs et les alternatives.

COM, automatisation Office et extensions de l’explorateur

COM est souvent utilisé au quotidien en entreprise sans être explicitement nommé : intégration Outlook, export Excel via Automation, clients DMS, handlers d’aperçu dans l’Explorateur, extensions du menu contextuel. Le problème sous ARM64 n’est pas tant COM lui-même que le couplage de l’architecture (bitness) : les serveurs COM in-process (composants COM basés sur DLL) doivent avoir la même architecture. Le COM out-of-process (serveurs basés sur EXE) est plus flexible car il peut s’exécuter dans un processus séparé.

Si votre application Delphi utilise p. ex. une ancienne DLL COM 32 bits ou 64 bits, cela constitue un blocage pour une exécution native ARM64. Émulée en x64, cela peut fonctionner — tant que toutes les dépendances COM sont également x64 et qu’aucune composante exclusive ARM64 n’intervient.

Impression, PDF et paysage des pilotes

Les problèmes d’impression sont un classique lors des changements de plateforme. Sous Windows 11 ARM64, il est déterminant de savoir si le fabricant de l’imprimante fournit des pilotes ARM64 ou si des pilotes de classe Universal Print/IPP (IPP est un protocole d’impression standardisé) peuvent être utilisés. Les imprimantes PDF, l’impression en lot, l’impression d’étiquettes et les périphériques spécialisés (p. ex. imprimantes thermiques) peuvent aussi dépendre de pilotes disponibles uniquement pour x64.

Pour la direction informatique et l’administration, la conséquence importante est la suivante : les déploiements ARM64 doivent être harmonisés avec la stratégie d’impression. «L’application n’imprime pas» signifie souvent «le pilote n’existe pas» ou «la chaîne d’impression est différente».

Accès aux données : FireDAC, ODBC/OLE DB et clients de bases de données

Sur le plan des données, une séparation nette entre protocole et bibliothèque cliente est souhaitable. BDE-Ablosung mit nativer Anbindung peut, selon la base de données, fonctionner avec des clientlibs natifs ou avec des pilotes. Si, par exemple, un client Oracle, un client PostgreSQL plus ancien ou un pilote ODBC spécifique est requis, il faut qu’il existe en ARM64 — ou vous adoptez une architecture qui encapsule l’accès aux données côté serveur (p. ex. via des services REST ou un Windows-/Windows- et Linux-Services).

Pour un fonctionnement stable, c’est un levier central : moins le client de bureau est lié directement aux pilotes de base de données et aux « stacks » locaux de bases de données, plus la transition vers ARM64 est aisée. Cela vaut aussi pour la sécurité : les identifiants d’accès aux bases, les certificats et les règles réseau peuvent être administrés de manière plus cohérente côté serveur.

Crypto, cartes à puce, signatures, VPN, EDR

De nombreux processus métier reposent aujourd’hui sur des composants cryptographiques : S/MIME, certificats clients, middleware de carte à puce, cartes de signature, inspection TLS dans les proxys. S’y ajoutent les solutions de sécurité des endpoints (EDR signifie Endpoint Detection and Response) et les clients VPN. Ces composants doivent être compatibles ARM64, sinon se crée un problème du type « l’appareil est présent, mais n’est pas autorisé à se connecter au réseau ».

Pour l’application Delphi, cela signifie : si vous utilisez par exemple des certificats depuis le magasin de certificats Windows ou si vous déléguez TLS aux composants système, c’est généralement moins critique que si une DLL cryptographique tierce spécifique est chargée dans le processus.

Matrice de décision : émulation ou portage natif ARM64 ?

Les entreprises ont besoin d’une décision qui reflète la réalité du support et du cycle de vie. Une question binaire (« on porte ? ») est rarement utile. Mieux vaut une matrice qui pondère dépendances et risques :

• Client pur avec API Windows standard (fichiers, réseau, impression via pilotes standards) : l’émulation peut suffire à court terme ; un portage natif ARM64 est plus propre à moyen terme.
• Client avec de nombreuses DLL tierces natives (PDF, OCR, matériel) : vérifier d’abord la disponibilité, puis décider. Un chemin hybride est souvent pertinent.
• Client avec COM-DLLs / extensions du Shell : s’attendre à des conflits d’architecture ; envisager un découplage hors-processus.
• Client avec un zoo de pilotes de bases de données : soit consolider les pilotes, soit déplacer l’accès aux données vers des services.
• Forte régulation / signature / carte à puce : vérifier tôt la compatibilité ARM64 de la chaîne sécurité et middleware.

Important : l’émulation n’est pas une « seconde classe », mais elle constitue un risque opérationnel si vous envisagez à long terme des appareils ARM64 dans votre parc. Lors de mises à jour majeures, de changements de pilotes ou de changement d’agents de sécurité, vous ne voulez pas vous retrouver enchaîné à une suite de cas particuliers.

Un chemin de migration robuste : vers ARM64 sans Big Bang

Pour les équipes IT et les responsables de projet, un chemin est pertinent s’il peut se déployer par vagues, comporte des critères d’acceptation clairs et n’écrase pas le support. Dans les environnements Delphi, une approche en cinq étapes a fait ses preuves.

Étape 1 : inventaire du point de vue opérationnel

Recensez non seulement les modules, mais surtout les points d’exploitation :

• Quelles classes d’appareils : ordinateurs portables, appareils durcis (Rugged Devices), terminaux ?
• Quelle périphérie : imprimantes, scanners, lecteurs de cartes, imprimantes d’étiquettes ?
• Quelles intégrations : Office, DMS, ERP, services locaux, composants de navigateur ?
• Quelle forme d’installation : MSI, Setup-EXE, ClickOnce, dépôt manuel ?
• Quels droits : administrateur nécessaire, services locaux, règles de pare-feu ?

Cette vue montre rapidement si « un seul client » signifie en réalité cinq dépendances système.

Étape 2 : Vérification de compatibilité avec un pilote ARM64 représentatif

Le pilote ne doit pas être « le plus beau appareil », mais un candidat typique de la flotte cible. Testez délibérément les chemins critiques : impression dans toutes les variantes, export/import, signature, hors ligne/en ligne, mises à jour, bascule de mandant, scénarios proxy/VPN. Documentez les écarts comme des incidents opérationnels, pas comme des bugs de développement. Ainsi la priorisation reste propre.

Étape 3 : Réduire les dépendances – d’abord celles qui ont le plus d’impact sur le support

Mesures typiques qui apportent beaucoup au quotidien :

• Standardiser le chemin PDF/impression : se détourner des DLL d’imprimante propriétaires, au profit de pipelines stables et testés.
• Découpler l’intégration Office : plutôt que des add-ins in-process, privilégier les formats d’export et la génération documentaire côté serveur.
• Consolider l’accès DB : une voie de pilote définie au lieu de « ODBC selon le poste ».
• Encapsuler la liaison matérielle : si possible via des processus/services externes qui peuvent être mis à jour séparément.

Étape 4 : Moderniser le déploiement et la capacité de mise à jour

ARM64 est une bonne occasion de clarifier l’installation et les mises à jour. Pour les entreprises, ce ne sont pas les fonctionnalités qui comptent ici, mais la capacité de rollback, la reproductibilité et la conformité aux politiques. Vérifiez :

• Paquetage : MSI vs. MSIX (MSIX est le format d’app package moderne de Microsoft offrant une installation/désinstallation propre et la signature).
• Signature : Code Signing (signature numérique des EXE/DLL) réduit les frictions avec SmartScreen et les EDR et est pertinent pour des rollouts contrôlés.
• Gestion des configurations : séparation des fichiers programme et de la configuration, chemins clairs, pas de dépendances « cachées » dans le registre.
• Canaux de mise à jour : pilote, Ring 1, Ring 2 – avec télémétrie/logging au niveau applicatif et opérationnel.

Étape 5 : ARM64 natif là où cela en vaut vraiment la peine

Des builds ARM64 natifs sont pertinents lorsque vous (a) avez les dépendances sous contrôle et (b) prévoyez de faire évoluer l’application sur le long terme. En règle générale, cela vaut pour les clients cœur utilisés quotidiennement par de nombreux utilisateurs et que vous modernisez par ailleurs. Pour des outils peu sollicités, l’émulation x64 peut être une transition acceptable, tant que le support et la sécurité suivent.

Axes d’architecture : ARM64 comme occasion de renforcer les interfaces et les services

De nombreuses paysages Delphi se sont historiquement développés en tant que « client lourd ». Cela fonctionne, mais lie l’exploitation et les mises à jour aux configurations individuelles des postes. ARM64 met en évidence là où ce couplage devient coûteux. Une étape de modernisation pragmatique n’est donc souvent pas « une nouvelle UI », mais une refonte des interfaces.

Plus de stabilité grâce à des responsabilités côté serveur

Lorsque la logique critique, l’accès aux données ou les processus documentaires migrent vers un service central (Windows- et Linux-Services ou Windows- und Linux-Services, c’est‑à‑dire un service en arrière-plan sans UI interactive), vous gagnez :

• des versions uniformes de pilotes et de bibliothèques,
• une sécurité plus contrôlable (certificats, secrets, réseau),
• une complexité réduite sur le client (ARM64, x64, et à terme d’autres plateformes),
• points de supervision et de journalisation plus clairs.

Pour les décideurs informatiques, c’est un réel avantage opérationnel : les problèmes deviennent plus rapidement reproductibles côté serveur, au lieu de rester liés à « un ordinateur portable spécifique ».

REST-API als Entkopplungsschicht

Une REST-API n’est pas automatiquement « moderne », mais elle constitue une couche de découplage robuste entre les clients et le backend. Elle définit clairement quelles données et quelles actions sont autorisées, et peut être sécurisée proprement (p. ex. via des tokens, des certificats ou SAML 2.0 comme standard d’identité en environnement d’entreprise). Pour ARM64, cela signifie : le client doit porter moins de connaissances générales sur les bases de données, les pilotes et les détails réseau.

Même si vous ne migrez pas tout immédiatement : un petit composant API bien délimité (p. ex. génération de documents, contrôle de licence, synchronisation des données de référence) peut éliminer des dépendances côté client et ainsi réduire les risques liés à ARM64.

Test und Qualität: Was Sie unter ARM64 anders prüfen sollten

Nombre d’équipes testent les logiciels de bureau principalement sur le plan fonctionnel. Sur ARM64, vous devriez tester davantage les aspects opérationnels, car les profils d’erreur diffèrent : pas des « erreurs de calcul », mais plutôt « composant qui ne se charge pas », « pilote manquant », « mise à jour qui échoue », « intégration avec Office qui se rompt ».

Checkliste für ARM64-nahe Abnahme

• Installation/Désinstallation: propre, sans résidus, sans contournements administratifs.
• Parcours de mise à jour: montée de version sur plusieurs versions, scénario de rollback (retour arrière), vérification des signatures.
• Journalisation: journaux centraux, codes d’erreur clairs pour les problèmes de chargement de DLL, chemins d’impression traçables.
• Performance: temps de démarrage, opérations sur les données, grandes listes/rapports – mesurer séparément sous émulation et en natif.
• Périphériques: profils d’imprimante, impression spéciale, workflows de scanner, fonctions de carte à puce.
• Sécurité: interaction EDR/AV, proxy/TLS, magasin de certificats, principe du moindre privilège.

La documentation est importante : si un problème provient de pilotes ARM64 manquants, ce n’est pas un « Bugfix in Delphi », mais une décision d’achat ou de standardisation.

Betrieb und Support: Wie Sie ARM64 in den Alltag integrieren

Au quotidien, ce qui compte, c’est la rapidité de résolution des incidents de support. Pour ARM64, il vaut la peine d’augmenter proactivement la capacité de support :

Standardisierte Geräteprofile und klare Freigaben

Définissez les modèles ARM64 pris en charge ou au moins des profils minimaux (stratégie de pilotes, stratégie d’impression, versions des agents de sécurité). Un « fonctionne sur ARM64 » sans ces précisions mène à des environnements hétérogènes et donc à des incidents difficiles à reproduire.

Diagnosefähigkeit in der Anwendung

Même sans focalisation développeur, il est raisonnable d’attendre ceci d’un logiciel : une page d’informations système affichant l’architecture (x64 émulé vs. ARM64 natif), les chemins importants, les versions des composants centraux et la configuration d’impression, réduit sensiblement les temps de support. Ce n’est pas un « nice to have », mais de l’hygiène opérationnelle.

Lizenzierung und Dongles

Si des dongles matériels ou d’anciens pilotes de licence sont en jeu, ARM64 devient rapidement problématique. Dans de nombreux environnements, il est judicieux de migrer la gestion des licences vers des mécanismes réseau ou côté serveur. Cela diminue la dépendance aux pilotes sur les postes et rend le parc plus interchangeable.

Was bedeutet das für Ihre Delphi-Strategie?

Delphi est dans le contexte d’entreprise souvent un composant stable pour les clients de bureau et les services. Windows 11 ARM64 n’est pas un argument « contre Delphi », mais un argument en faveur d’une encapsulation plus propre des dépendances et d’une modernisation orientée exploitation : moins de pilotes spécialisés locaux, moins de composants In-Process, des interfaces plus nettes, un déploiement amélioré.

Si vous êtes déjà engagé aujourd’hui sur une trajectoire de modernisation (p. ex. remplacement de BDE, migration 64 bits, intégration renforcée de REST, accès aux données consolidé avec FireDAC), alors ARM64 est souvent « seulement » un jalon supplémentaire qui clarifie les priorités. En revanche, si votre application dépend fortement d’anciens pilotes, de DLL propriétaires et de configurations spécifiques par poste de travail, ARM64 est une occasion pertinente de rendre ces risques transparents et de les réduire de manière planifiable.

Conclusion : ARM64 est moins un projet de portage qu’un projet d’architecture et d’exploitation

Pour les entreprises, Windows 11 ARM64 est avant tout une question de plateforme en matière d’achats, de sécurité et de support. Pour les logiciels métier basés sur Delphi, le succès ne se joue pas sur une option de compilateur, mais sur la chaîne composée de pilotes, DLLs, intégrations COM, accès aux données et processus de mise à jour. Une approche robuste consiste à : d’abord rendre visibles les dépendances et les parcours d’exploitation, puis tester avec des postes pilotes, ensuite découpler de façon ciblée et professionnaliser le déploiement — et fournir des builds natifs ARM64 là où ils apportent à long terme bénéfice et stabilité.

Si vous souhaitez déployer Windows 11 ARM64 dans votre parc et sécuriser de manière planifiable les applications, la périphérie et les interfaces Delphi, échangez avec nous sur un inventaire structuré et une trajectoire de migration réaliste :

Dans l’environnement métier, les Delphi ARM64 Windows et l’émulation X64 Windows 11 jouent également 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 opération de modernisation avec Net-Base.