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

Windows-Geräte mit ARM64-CPU (ARM64 ist eine 64‑Bit-Prozessorarchitektur, bekannt aus mobilen SoCs und zunehmend auch aus Business-Notebooks) sind in vielen Unternehmen nicht mehr nur „Exoten“. Sie kommen über standardisierte Notebook-Flotten, längere Akkulaufzeiten, neue Sicherheitsfunktionen in der Hardware und eine strategische Diversifizierung der Lieferkette. Spätestens wenn Fachbereiche neue Geräte beschaffen oder OEMs bestimmte Modelle nur noch als Windows on ARM anbieten, stellt sich für IT-Verantwortliche die praktische Frage: Wie verhält sich unsere Delphi-basierte Business-Software unter Windows 11 ARM64 – und wie sichern wir Betrieb, Support und Weiterentwicklung?

Der Kernpunkt ist: Windows 11 ARM64 mit Delphi in Unternehmen ist weniger eine reine Entwicklungsfrage als eine Frage von Abhängigkeiten, Deployment-Strategien, Treibern, Schnittstellen und dem realen Verhalten im Feld. In der Praxis gibt es drei Wege: Weiterbetrieb über Emulation, native ARM64-Builds oder ein Übergangsmodell, das Risiken kontrolliert reduziert. Dieser Beitrag ordnet die typischen Stolpersteine ein und zeigt einen belastbaren Pfad, der in IT-Planung, Rollout und Betrieb funktioniert – ohne „Alles neu“-Reflex.

Warum Windows 11 ARM64 jetzt relevant wird

Windows on ARM ist nicht neu, aber die Rahmenbedingungen haben sich geändert: Die Geräte sind im Business-Umfeld verfügbar, Windows 11 bringt eine deutlich ausgereiftere x64-Emulation, und Softwarehersteller liefern immer häufiger ARM64-Varianten. Für Unternehmen heißt das: ARM64 taucht nicht als einmaliges Pilotprojekt auf, sondern als Plattform, die in Beschaffungs- und Lebenszyklusplanungen eingeht.

Für prozessnahe Softwarelösungen ist dabei weniger die CPU selbst das Problem, sondern die Peripherie- und Integrationsrealität: Druck, Signaturkarten, Scanner, Office-Add-ins, COM-Komponenten (COM ist Microsofts Komponentenmodell zur Integration von Anwendungen und Bibliotheken), Shell-Erweiterungen, VPN-Clients oder Security-Agenten. Wenn davon etwas nicht ARM64-tauglich ist, entsteht Supportaufwand – und häufig wird dann „die Anwendung“ verantwortlich gemacht.

Einordnung: Was bedeutet ARM64 technisch für Delphi-Anwendungen?

Delphi-Anwendungen im Unternehmensumfeld sind oft klassische Windows-Desktop-Clients (häufig VCL, also die Visual Component Library für Windows-GUIs) mit Datenbankzugriff (z. B. über BDE-Ablosung mit nativer Anbindung, Delphis Datenzugriffsschicht) und einer Mischung aus lokalen und entfernten Integrationen. Unter Windows 11 ARM64 ergeben sich dabei drei Ausführungsarten:

1) Native ARM64-Ausführung

Die Anwendung und alle nativen Bibliotheken (DLLs) liegen als ARM64 vor. Das ist langfristig die sauberste Option, weil sie Performance und Stabilität planbar macht und Emulationsrandbedingungen vermeidet. Sie ist aber nur dann realistisch, wenn alle nativen Abhängigkeiten mitziehen: Datenbanktreiber, Druck/Preview, PDF-Engine, Kryptobibliotheken, OCR/Scan-SDKs, Hardware-Dongle-Treiber etc.

2) x64-Emulation unter Windows 11 ARM64

Windows 11 peut émuler des applications x64. Pour de nombreux clients purement bureau, cela fonctionne étonnamment bien. En pratique, l’émulation n’est cependant pas une « carte blanche » : dès que des pilotes, des intégrations du shell ou des composants in-process (DLL chargées dans le processus) sont impliqués, l’architecture compte. Un processus x64 ne peut pas charger une DLL ARM64 et inversement. C’est souvent cette limite qui décide « ça marche » ou « ça ne marche pas ».

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

Un chemin de transition consiste à extraire les composants x64 critiques hors du processus : par exemple 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 d’appoint séparé. Ce n’est pas aussi élégant que « tout natif », mais c’est souvent la voie la plus économique pour sécuriser l’exploitation et moderniser les dépendances étape par étape.

Windows 11 ARM64 mit Delphi in Unternehmen: Die typischen Abhängigkeiten, die über Erfolg entscheiden

Dans les projets, on constate 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 économise ici des semaines d’essais-erreurs.

DLLs et SDK natifs : 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. Sous ARM64, règle stricte : une DLL doit correspondre à l’architecture du processus. L’émulation n’aide que si l’ensemble du processus reste x64. Dès que l’on souhaite exécuter en natif, ces bibliothèques doivent être disponibles en ARM64 ou 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 du shell

COM est souvent utilisé dans le quotidien en entreprise sans être explicitement nommé : intégration Outlook, export Excel via automation, clients DMS, gestionnaires de prévisualisation dans l’Explorateur, extensions de 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 par ex. une ancienne DLL COM 32‑bit ou 64‑bit, c’est un blocage pour une exécution native ARM64. Émulée en tant que x64, cela peut fonctionner — tant que toutes les dépendances COM sont aussi x64 et qu’aucune composante réservée 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 crucial que le fabricant des imprimantes fournisse des pilotes ARM64 ou que des pilotes de classe Universal Print/IPP (IPP est un protocole d’impression standardisé) puissent être utilisés. Les imprimantes PDF, l’impression en lot, l’impression d’étiquettes et les équipements spécialisés (p. ex. imprimantes thermiques) peuvent aussi dépendre de pilotes disponibles uniquement pour x64.

Pour la direction IT et l’administration, la conséquence importante est la suivante : les déploiements ARM64 doivent être aligné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 ex., un client Oracle, un client PostgreSQL ancien ou un pilote ODBC spécifique est requis, il faut qu’il existe en ARM64 – ou vous choisissez une architecture qui encapsule l’accès aux données côté serveur (p. ex. via des services REST ou un Windows-/Windows- und 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 simple. Cela vaut aussi pour la sécurité : les identifiants d’accès aux bases, les certificats et les règles réseau peuvent être gérés de façon plus cohérente côté serveur.

Krypto, Smartcards, Signaturen, VPN, EDR

Beaucoup de processus métiers reposent aujourd’hui sur des composants cryptographiques : S/MIME, certificats client, middleware de cartes à puce, cartes de signature, inspection TLS dans les proxys. S’ajoutent les solutions de sécurité endpoint (EDR signifie Endpoint Detection and Response) et les clients VPN. Ces composants doivent être compatibles ARM64, sinon vous vous retrouvez avec un problème du type « l’appareil est présent, mais ne peut pas accéder au réseau ».

Pour l’application Delphi cela signifie : si vous utilisez par ex. des certificats du magasin de certificats Windows ou si le TLS repose sur les composants système, c’est généralement moins critique que lorsqu’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 simple question oui/non (« on porte ? ») est rarement utile. Mieux vaut une matrice qui pondère dépendances et risques :

• Client pur avec des API Windows standard (fichier, réseau, impression via pilotes standards) : l’émulation peut suffire à court terme ; un ARM64 natif 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 base de données directs : soit consolider les pilotes, soit basculer l’accès aux données dans des services.
• Forte régulation / signature / carte à puce : vérifier tôt la compatibilité ARM64 de la chaîne de sécurité et de la middleware.

Important : l’émulation n’est pas une « seconde classe », mais elle constitue un risque opérationnel si vous prévoyez des appareils ARM64 à long terme dans le parc. Au plus tard lors de mises à jour majeures, de changements de pilotes ou de changements d’agents de sécurité, vous ne voulez pas vous retrouver avec une chaîne de cas particuliers.

Un parcours de migration solide : d’aujourd’hui à ARM64 sans Big Bang

Pour les responsables IT et de projets, un parcours est satisfaisant s’il peut être déployé par vagues, comporte des critères d’acceptation clairs et ne surcharge pas le support. Dans les environnements Delphi, une approche en cinq étapes s’est avérée efficace.

Étape 1 : inventaire avec une « perspective opérationnelle »

Recensez non seulement les modules, mais surtout les points opérationnels :

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

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

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

Le pilote ne doit pas être « le plus bel appareil », mais un candidat typique de la flotte cible. Testez délibérément les chemins critiques : impression sous toutes ses formes, export/import, signature, hors ligne/en ligne, mises à jour, basculement de client/tenant, scénarios Proxy/VPN. Documentez les écarts comme des incidents opérationnels, pas comme des bugs de développement. Cela maintient une priorisation propre.

Étape 3 : Réduire les dépendances — d’abord celles avec fort levier de support

Mesures typiques qui apportent beaucoup au quotidien :

• Standardiser le chemin PDF/impression : sortir des DLLs d’imprimante propriétaire, vers des pipelines stables et testés.
• Désaccoupler l’intégration Office : plutôt que des add-ins en process, privilégier des formats d’export et une génération de documents côté serveur.
• Consolider l’accès BD : une voie de pilote définie au lieu de « ODBC selon le poste ».
• Encapsuler les connexions matérielles : si possible via des processus/services externes, pouvant être mis à jour séparément.

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

ARM64 est une bonne occasion de nettoyer l’installation et les mises à jour. Pour les entreprises, ce ne sont pas les fonctionnalités qui comptent, mais la capacité de retour en arrière (rollback), la reproductibilité et la conformité aux politiques. Vérifiez :

• Packaging : MSI vs. MSIX (MSIX est le format d’applications moderne de Microsoft, avec installation/désinstallation propre et signature).
• Signature : Signature du code (signature numérique des EXE/DLL) réduit les frictions SmartScreen et EDR et est pertinente pour des rollouts contrôlés.
• Gestion de configuration : séparation des fichiers programme et de la configuration, chemins clairs, pas de dépendances cachées au Registre.
• Canaux de mise à jour : Pilote, Ring 1, Ring 2 — avec télémétrie/journalisation au niveau applicatif et opérationnel.

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

Les builds ARM64 natifs sont pertinents lorsque vous (a) maîtrisez les dépendances et (b) prévoyez de faire évoluer l’application sur le long terme. Typiquement cela vaut pour des clients centraux utilisés quotidiennement par de nombreux utilisateurs et que vous modernisez de toute façon. Pour des outils peu utilisés, l’émulation x64 peut être une transition acceptable, tant que le support et la sécurité sont assurés.

Impacts architecturaux : ARM64 comme occasion de renforcer interfaces et services

Beaucoup de paysages Delphi ont historiquement évolué en tant que « client lourd ». Cela fonctionne, mais cela lie le fonctionnement et les mises à jour à des configurations de poste individuelles. ARM64 met en lumière où ce couplage devient coûteux. Une étape de modernisation pragmatique n’est donc souvent pas « refonte de l’UI », mais révision des interfaces.

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

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

• des versions unifiées de pilotes et de bibliothèques,
• une sécurité mieux contrôlable (certificats, secrets, réseau),
• une moindre complexité sur le client (ARM64, x64, et à l’avenir d’autres plateformes),
• points de monitoring et de journalisation plus clairs.

Pour les décideurs informatiques, c’est un véritable avantage opérationnel : les problèmes deviennent côté serveur plus rapidement reproductibles, au lieu de rester bloqués sur « un notebook particulier ».

REST-API comme couche de découplage

Une REST-API n’est pas automatiquement « moderne », mais elle constitue un 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 tokens, certificats ou SAML 2.0 comme standard d’identité en environnement d’entreprise). Pour ARM64, cela signifie : le client doit porter moins de connaissances opérationnelles 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 d’API bien délimité (p. ex. génération de documents, vérification de licence, synchronisation des données de base) peut retirer des dépendances du client et ainsi réduire les risques liés à ARM64.

Tests et qualité : ce que vous devez vérifier différemment sous ARM64

Beaucoup d’équipes testent les logiciels de bureau principalement sur le plan fonctionnel. Pour ARM64, il convient d’intensifier les tests opérationnels, car les profils d’erreur sont différents : pas une « erreur de calcul », mais plutôt « composant qui ne se charge pas », « pilote manquant », « échec de mise à jour », « intégration Office interrompue ».

Checklist pour l’acceptation orientée ARM64

• Installation/Désinstallation : propre, sans résidus, sans contournements administrateur.
• Processus de mise à jour : upgrade sur plusieurs versions, scénario de rollback, vérification des signatures.
• Journalisation : journaux centraux, codes d’erreur clairs pour les problèmes de chargement de DLL, parcours d’impression traçables.
• Performance : temps de démarrage, opérations de données, grandes listes/rapports – mesurer séparément en émulation et en natif.
• Périphériques : profils d’imprimante, impression spécialisée, 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 essentielle : si un problème est causé par des pilotes ARM64 manquants, ce n’est pas un « bugfix in Delphi », mais une décision d’approvisionnement ou de standardisation.

Exploitation et support : comment intégrer ARM64 au quotidien

Au quotidien, l’important est la rapidité de résolution des incidents de support. Pour ARM64, il vaut la peine d’améliorer proactivement la capacité de support :

Profils d’appareils standardisés et validations claires

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

Capacité de diagnostic dans l’application

Même sans orientation développeur, une exigence claire pour le logiciel est pertinente : une page d’information système affichant l’architecture (x64 émulé vs. ARM64 natif), les chemins importants, les versions des composants cœur et la configuration d’impression réduit nettement les temps de support. Ce n’est pas un « nice to have », mais de l’hygiène opérationnelle.

Licences et dongles

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

Qu’est-ce que cela implique pour votre stratégie Delphi ?

Delphi est, dans un contexte d’entreprise, souvent un élément 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écifiques locaux, moins de composants exécutés dans le même processus, des interfaces plus claires, un déploiement amélioré.

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

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 pour les achats, la sécurité et le support. Pour les logiciels métier basés sur Delphi, la réussite ne se joue pas à une option de compilateur, mais sur la chaîne formée par les pilotes, les DLLs, les intégrations COM, l’accès aux données et les processus de mise à jour. Une démarche solide consiste à : d’abord rendre visibles les dépendances et les parcours d’exploitation, puis tester avec des appareils pilotes, ensuite découpler de façon ciblée et professionnaliser le déploiement — et fournir des builds ARM64 natifs là où ils apportent durablement valeur et stabilité.

Si vous souhaitez déployer Windows 11 ARM64 dans votre parc et sécuriser de manière planifiable les applications Delphi, la périphérie et les interfaces, parlez-nous d’un état des lieux structuré et d’une trajectoire de migration réaliste :

Dans le contexte métier, les Delphi ARM64 Windows et l’émulation X64 Windows 11 jouent également un rôle important, lorsque intégrations, flux de données et évolutions doivent bien s’articuler.

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