Prévoir Windows 11 ARM64 dès le départ pour les applications Delphi

Windows 11 ARM64 n’est plus dans le quotidien B2B un cas particulier réservé aux passionnés de technologie. Les nouvelles générations de notebooks, des autonomies de batterie plus longues, des scénarios « Always-on » et le désir croissant de postes de travail légers et mobiles conduisent les entreprises à acheter des clients ARM64 — parfois délibérément, parfois par défaut via des modèles standards dans le cadre d’un contrat-cadre. Pour des équipes avec des logiciels métiers évolués, le message est clair : ARM64 doit être intégré tôt dans la planification technique, sinon cela deviendra plus tard un projet de retrofit coûteux.

Pour les applications Delphi, la question centrale n’est que rarement « Delphi peut-il compiler cela ? ». En pratique, les déploiements ARM64 échouent presque toujours à cause de la périphérie : DLLs natives, composants d’impression/scan, pilotes de base de données, moteurs de reporting, intégrations COM, routines d’installation, signature de code ou pipelines de build qui, tacitement, ne connaissent que x64. C’est précisément pourquoi il est pertinent de traiter Windows 11 ARM64 comme une exigence d’architecture et d’exploitation — et non comme une simple fonctionnalité de plateforme.

Ce billet montre quels pièges techniques surviennent typiquement avec Delphi, comment identifier systématiquement les risques et quelles voies de migration pragmatiques se sont révélées efficaces — depuis la mise à niveau progressive de modules individuels jusqu’à une architecture cible claire avec des services et des REST-Servers.

Pourquoi Windows 11 ARM64 est désormais un sujet d’architecture

Dans de nombreuses entreprises, « Windows » a longtemps été synonyme de x86/x64. Cette hypothèse est ancrée dans des scripts, des installateurs, des composants tiers et parfois même dans le modèle de données (p. ex. chemins, clés de registre, interfaces de pilotes). Dès que des clients ARM64 apparaissent, on voit combien de connaissances implicites sont présentes dans le système. Et c’est précisément le cœur économique : des adaptations tardives ne sont pas seulement « quelques flags de compilateur », mais un nettoyage d’hypothèses consolidées sur des années.

ARM64 devient pratiquement pertinent surtout dans trois situations :

• Logiciel client à longue durée de vie : applications métiers utilisées pendant 8–15 ans et étendues de manière itérative. Une nouvelle plateforme client en plein cycle de vie est plus probable qu’une réécriture complète.
• Flottes mixtes : forces de vente/maintenance, notebooks de direction, scénarios proches du BYOD ou filiales qui achètent du matériel différent.
• Pression sécurité et conformité : modernisation du code-signing, durcissement, principe du moindre privilège, updaters contrôlés — les processus d’installation et de mise à jour sont de toute façon modifiés. C’est précisément à ces moments qu’ARM64 est avantageusement intégré comme exigence secondaire.

La bonne nouvelle : qui travaille déjà sur une modernisation Delphi, une migration 64 bits, le découplage des accès aux données ou une architecture cible orientée services, peut souvent « emmener » Windows 11 ARM64 avec lui — à condition que cela figure tôt dans le backlog et non pas seulement lors du premier poste ARM en support.

Delphi sur ARM64 : qu’est-ce qui est « facile », qu’est-ce qui est « difficile » ?

Les projets Delphi varient fortement : clients VCL desktop purs jusqu’à des systèmes multicouches avec des REST-Servers, des services Windows, des report-workers, des composants d’intégration et des tâches d’arrière-plan. Pour Windows 11 ARM64, il est déterminant de savoir quelles parties doivent réellement s’exécuter nativement sur le client et quelles parties peuvent de toute façon être raisonnablement externalisées vers des services.

Le compilateur est rarement le principal problème

Si votre code est propre (pas d’assembleur inline, pas d’hypothèses 32 bits anciennes, pas de casts de pointeurs fragiles, pas d’appels d’API obsolètes), la compilation pour une nouvelle plateforme cible est souvent réalisable. Les problèmes surviennent à cause de :

• Composants tiers avec des parties natives (DLLs, BPLs, ponts C/C++)
• Pilotes et connexion d’appareils (impression, scan, pads de signature, dongles)
• Accès base de données via ODBC/OLE DB/bibliothèques clientes non compatibles ARM64
• Reporting et intégration Office (COM-Automation, anciens filtres d’export)
• Installateur/Updater qui ne testent que x64 ou utilisent des chemins codés en dur

Donc Windows 11 ARM64 est surtout un « test d’écosystème » : dans quelle mesure votre paquet logiciel est-il découplé des hypothèses anciennes de la plateforme ?

VCL, FMX et dépendances UI

Beaucoup d’applications métiers B2B sont basées sur VCL et utilisent des composants d’interface accumulés sur des années. Ce n’est pas en soi un problème — mais l’UI concentre souvent les dépendances : imprimantes PDF, générateurs de codes-barres, bibliothèques d’images, contrôles navigateur, objets COM. Pour ARM64, règle générale : plus vous utilisez de composants spécifiques proches de l’UI, plus une liste de compatibilité précoce devient importante.

Dans les stratégies multiplateformes (p. ex. Windows + macOS), FMX intervient souvent. Indépendamment du framework, une stratégie robuste consiste à séparer la logique métier et les intégrations de l’UI. Cela bénéficie à la fois à la multiplateforme Delphi et à Windows 11 ARM64.

Pièges techniques typiques (et comment les détecter tôt)

En pratique, la plupart des problèmes ARM64 peuvent être détectés tôt si vous effectuez une inventaire structuré et un « ARM64 Readiness »-check. Il est crucial d’examiner non seulement le code Delphi, mais tout ce qui appartient au produit : installateurs, pilotes, configuration, plugins, outils tiers, chaîne de mise à jour, scripts de support.

1) DLLs natives, BPLs et environnements de processus mixtes

Beaucoup d’applications Delphi chargent des DLLs supplémentaires : cryptographie, visionneuses CAD, OCR, signature, SDKs matériels, parseurs spécialisés. Sur x64, on suppose souvent sans le dire qu’« il existe une DLL 64 bits ». Pour ARM64, c’est différent : vous avez besoin explicitement de binaires ARM64 ou d’une architecture qui retire cette dépendance du client.

Approche pratique :

• Établissez la liste de tous les modules natifs chargés (y compris indirectement via des composants).
• Classez-les : « ARM64 disponible », « x64-only », « 32-bit-only », « incertain ».
• Évaluez si le module doit vraiment être local ou s’il peut être externalisé en service.

Constat fréquent : un seul module x64-only bloque l’ensemble du client ARM64. C’est le moment où une couche ordonnée ou une Layer-3 architecture devient économiquement pertinente : l’UI/client reste léger, les intégrations migrent vers des couches serveur/service contrôlées.

2) COM, automatisation Office et intégrations Shell

Dans de nombreuses entreprises, l’export Word/Excel, la liaison Outlook, les menus contextuels de l’Explorer ou les intégrations DMS sont historiquement basés sur COM. COM n’est pas automatiquement « ARM64-ready », en particulier si des serveurs COM tiers ou des add-ins ne sont distribués qu’en x64. Le fonctionnement en mélange 32-bit/64-bit (out-of-proc vs in-proc) devient rapidement complexe.

Clarifications précoces :

• Quels objets COM sont utilisés (liste ProgIDs/CLSIDs) ?
• In-Proc ou Out-of-Proc ? Y a-t-il des enregistrements ARM64 ?
• L’export peut-il être réalisé via des bibliothèques côté serveur (p. ex. formats documentaires) plutôt que par Office-Automation ?

Cela représente souvent un levier de modernisation : passer d’une automation liée à l’UI vers des services d’export reproductibles (p. ex. PDF/Excel via bibliothèque), utilisables aussi bien pour Windows x64 que pour ARM64 ou même des Linux-Servers.

3) Accès base de données : ODBC, client-libraries, legacy-BDE

L’accès aux données est une interface fréquente pour ARM64, car les écosystèmes de pilotes et les bibliothèques clientes entrent en jeu. Sont particulièrement critiques les anciens setups ODBC, clients propriétaires de bases de données ou bases locales avec couches d’accès historiques.

Pour les stacks Delphi, c’est un classique : si Borland BDE, de vieilles structures Paradox ou des chaînes de pilotes difficilement maintenables sont encore présentes, ARM64 devient un catalyseur. Une BDE-Ablösung et la migration vers une BDE-Ablösung mit nativer Anbindung avec une stratégie claire de pilotes DB réduisent significativement les risques liés à la plateforme.

Points de contrôle concrets :

• Quelles bases sont utilisées (SQL Server, PostgreSQL, MariaDB, Firebird, moteurs locaux) ?
• Quels pilotes sont employés (ODBC, client natif, BDE-Ablosung mit nativer Anbindung-drivers, OLE DB) ?
• Où se trouvent les connection-strings et les DSNs (par utilisateur, par machine, dans l’installateur) ?
• Existe-t-il des dépendances à des pilotes ODBC 32 bits ou d’anciens providers ?

Avec SQL Server/ODBC, un client ARM64 peut fonctionner — mais seulement si la chaîne de pilotes et la routine d’installation sont propres. Ce n’est pas un sujet que l’on souhaite déboguer « sur le terrain ».

4) Reporting, impression, scan, PDF et workflows de sortie

La sortie est souvent critique dans les applications métiers : bons de livraison, étiquettes, factures, procès-verbaux, relevés, certificats, labels d’expédition. Beaucoup de ces workflows dépendent de composants de reporting ou de pilotes/scanners spécifiques.

Sur Windows 11 ARM64, les pièges typiques sont :

• Pilotes d’imprimantes d’étiquettes / pilotes spécialisés disponibles uniquement en x64
• Logiciels/SDKs de scanners sans support ARM64
• Anciens moteurs de reporting avec modules natifs de preview/export
• Génération PDF via « imprimantes virtuelles » au lieu de bibliothèques

Une approche robuste consiste à standardiser les workflows de sortie : produire PDF/format Office via des bibliothèques, imprimer via des interfaces standardisées, encapsuler au maximum les accès matériels. Là où ce n’est pas possible, il faut tôt une matrice matériel/pilotes pour ARM64.

5) Installateur, Updater, signature de code et exploitation

Beaucoup de projets ARM64 échouent non pas à cause du programme, mais de la livraison : l’installateur détecte mal l’architecture, n’installe pas les pilotes, n’enregistre pas les COM, positionne des chemins erronés ou bute sur les politiques de code-signing. Les mises à jour automatiques (delta-updates, self-updaters) sont souvent fortement dépendantes de l’architecture.

Questions importantes pour l’exploitation :

• Comment est fait l’installation (MSI, Inno Setup, updater propriétaire) ?
• Comment les dépendances sont-elles installées (VC++ Runtimes, pilotes, certificats) ?
• Comment est effectué le signature (EXE, DLL, installateur, paquets de pilotes) ?
• Comment est testé : matériel ARM64 réel ou seulement des suppositions ?

Pour les entreprises, c’est un sujet de gouvernance : si Windows 11 ARM64 apparaît dans la flotte client, le déploiement doit être reproductible — incluant rollback, capacité de support et versioning clair.

Stratégie : traiter Windows 11 ARM64 comme une « exigence non fonctionnelle » précoce

L’approche économiquement sensée est de considérer ARM64 comme une exigence non fonctionnelle (NFA) — à l’instar de la performance, la sécurité ou la capacité hors-ligne. Cela signifie : pas seulement « quand c’est urgent » dans un sprint, mais comme une ligne directrice définie pour l’architecture et la chaîne d’approvisionnement.

ARM64 Readiness-Check : inventaire plutôt que feeling

Un contrôle solide comprend typiquement :

• Inventaire des dépendances : tous les composants tiers, DLLs, pilotes, SDKs, contrôles navigateur, modules crypto, reporting.
• Analyse build/pipeline : targets de build, packaging, signature, dépôt d’artefacts, numérotation des versions, reproductibilité.
• Chaîne installateur/update : logique de setup, prérequis, chemins registre/système de fichiers, politiques, droits.
• Modèle d’exploitation : support, logging, crash-dumps, télémétrie (si présente), plan de rollout.

Le résultat ne doit pas être un simple « ARM64 : oui/non », mais une liste priorisée : quels blockers existent, quels modules sont affectés, quelles alternatives sont disponibles et quel investissement est réaliste.

Matrice de décision : natif sur ARM64 ou découpler ?

Pour chaque dépendance problématique, une décision claire est nécessaire :

• Remplacement natif ARM64 possible : mise à jour, changement de fournisseur, migration vers une autre bibliothèque.
• La dépendance peut être externalisée : p. ex. dans un service [[NBML_TERM_5_aea23489 ]], un worker d’arrière-plan ou un serveur REST.
• La dépendance doit rester locale : p. ex. parce que le matériel est connecté directement au client. Dans ce cas, des validations matérielles/pilotes ARM64 contraignantes sont nécessaires.

Pour les intégrations, l’externalisation est souvent la solution la plus propre : le client reste UI + dialogues métier, tandis que la logique d’intégration complexe s’exécute dans des services contrôlés. Cela aide non seulement pour ARM64, mais aussi pour les mises à jour centralisées, les concepts de droits et une meilleure testabilité.

Patterns d’architecture qui stabilisent les projets ARM64

Si Windows 11 ARM64 est pris en compte tôt, plusieurs décisions d’architecture peuvent être prises pour éviter des révisions coûteuses ultérieures.

1) Couches claires : UI, logique métier, intégration, accès aux données

Les clients Delphi historiques rassemblent souvent « tout dans un seul processus » : UI, règles métier, accès aux données, connexion DMS, impression et export. C’est maintenable tant que la plateforme reste stable. Dès que des variantes de plateforme (ARM64, éventuellement [[NBML_TERM_8_8b06df02 ]], éventuellement Terminal Server) entrent en jeu, la valeur d’une schématisation claire augmente.

Objectif pragmatique :

• Couche UI : minimale, testable, sans dépendances directes aux pilotes/SDKs.
• Logique métier : aussi neutre que possible par rapport à la plateforme, modélisée proprement.
• Couche d’intégration : encapsule COM, formats de fichiers, connecteurs DMS/ERP, SDKs matériels.
• Accès aux données : consolidé (p. ex. FireDAC), frontières de transaction claires, pas de SQL dispersé.

Ce n’est pas de la « théorie », mais permet d’économiser de réels coûts : si seule la couche d’intégration pose des problèmes ARM64, tout le client n’a pas besoin d’être reconstruit.

2) Services et REST-Servers comme ancrage de stabilité

Beaucoup de systèmes B2B gagnent à exécuter des fonctions centrales comme REST-Servers ou comme services Windows / Linux-Services : vérification des droits, workflows documentaires, validation des données, export, import, interfaces vers ERP/DMS/CRM. Lorsque ces fonctions s’exécutent côté serveur, la complexité côté client diminue fortement — et donc la surface d’exposition ARM64 aussi.

Répartitions typiques et efficaces :

• Client : dialogues, affichage, logique hors-ligne (si nécessaire), intégrations locales minimales.
• REST-Server : opérations métier, validation, multi-tenancy, journalisation centrale.
• Worker/Service : tâches planifiées, polling d’interfaces, génération de rapports, exports batch.

Cela s’accorde aussi avec des modèles d’exploitation modernes : une fonction côté serveur est mise à jour une fois — au lieu d’être mise à jour sur chaque client ARM64 individuellement.

3) Un système de build, plusieurs targets (x64 + ARM64) dès le départ

Si ARM64 est un objectif, la pipeline de build doit en tenir compte. Pas comme « on fera un build spécial plus tard », mais comme standard : chaque candidate de release se construit de manière reproductible pour x64 (et, si prévu, ARM64), incluant la signature et le packaging de l’installateur.

L’important n’est pas tant l’outil que la discipline :

• Nommez clairement les artefacts (architecture dans le nom du paquet/structure de dossier).
• Séparez les valeurs de configuration par target (chemins, prérequis, paquets de pilotes).
• Définissez des smoke-tests par architecture (démarrage, login, connexion DB, impression/PDF).

Ainsi, ARM64 cesse d’être un « Big Bang » et devient un target additionnel contrôlé.

Modernisation Delphi : ARM64 comme occasion d’éliminer la dette technique

Beaucoup d’entreprises profitent de nouvelles exigences de plateforme pour tout réécrire. C’est risqué et souvent superflu. Il est nettement plus économique d’utiliser Windows 11 ARM64 comme garde-fou pour une modernisation progressive : réduire la dette technique là où elle bloque ARM64 ou met en péril la capacité de livraison.

64 bits et Unicode : ne pas reporter les vieux chantiers

Si la base de code contient encore des hypothèses 32 bits ou des vestiges de premières versions [[NBML_TERM_7_4c4a218d ]], ils réapparaîtront lors du changement de plateforme. ARM64 n’implique pas automatiquement Unicode, mais beaucoup de projets qui s’engagent sérieusement sur ARM64 en profitent pour garantir que Unicode est correctement géré, que les chemins 64 bits sont établis et que les problématiques de mémoire/pointeurs sont corrigées.

L’objectif n’est pas la perfection, mais un standard fiable : un code qui peut être construit pour de nouvelles cibles sans reproduire systématiquement les mêmes familles d’erreurs.

BDE-Ablösung et accès aux données consolidé comme facilitateur ARM64

Lorsque des couches d’accès historiques subsistent ([[NBML_TERM_11_901e2bf2 ]], données Paradox locales, accès mixtes), une consolidation est un levier à effets multiples : code plus maintenable, déploiements plus stables, stratégie de pilotes plus claire. Avec FireDAC, l’accès peut être unifié dans de nombreux scénarios, incluant gestion centralisée des paramètres, stratégies de pooling et gestion d’erreurs propre.

Important : une BDE-Ablösung n’est pas seulement « remplacer des composants ». Elle affecte la logique transactionnelle, les types de données, les tris, la sémantique des filtres et parfois le modèle de données. Voilà pourquoi elle doit être planifiée — et non traitée comme une mesure d’urgence quand des clients ARM64 apparaissent soudainement sur le terrain.

Tests et assurance qualité : ARM64 est planifiable seulement s’il devient mesurable

Planifier ARM64 tôt signifie aussi : il faut le tester — pas un test complet de chaque fonctionnalité, mais des tests ciblés sur la chaîne critique. L’étape la plus importante est d’avoir un environnement de test ARM64 réel. L’émulation peut aider ponctuellement, mais ne remplace pas la pratique sur matériel réel, avec pilotes réels et politiques de sécurité réelles.

Smoke-test ARM64 minimal : ce qui doit être couvert le plus tôt

Un ensemble de smoke-tests pragmatique mais efficace pour chaque candidate de release :

• Démarrage du programme, login, fonctions UI de base
• Connexion DB (incl. authentification, certificats, DNS/Proxy si pertinent)
• Un processus clé « end-to-end » (p. ex. créer une commande, la sauvegarder, imprimer/exporter)
• Updater/Installateur : installation neuve et mise à jour d’une version à une autre
• Logging/dialogues d’erreur : les diagnostics sont-ils exploitables aussi sur ARM64 ?

Cela mettra tôt en évidence les blockers typiques ARM64 : DLL manquantes, pilotes erronés, problèmes de setup, exigences de droits inattendues.

Capacité de diagnostic : crash-dumps, logs, transparence des versions

Lorsque ARM64 est présent dans la flotte, des cas de support apparaîtront — rien que pour des nouvelles combinaisons de pilotes. Il est donc utile de standardiser les diagnostics : build-IDs clairs, logs explicites, chemins d’installation et de mise à jour reproductibles. Ce n’est pas spécifique à ARM64, mais ARM64 rend les lacunes ici particulièrement coûteuses.

Rollout et exploitation : flottes mixtes sans chaos

La plupart des entreprises exploiteront à moyen terme des flottes clientes mixtes : une partie x64, une partie ARM64. La clé est de gérer cet état de manière délibérée.

Packaging : installateurs séparés, détection claire, voies de téléchargement explicites

En pratique, il fonctionne mieux lorsqu’on sépare les installateurs/paquets : le paquet x64 est x64, le paquet ARM64 est ARM64. « Un installateur pour tout » paraît commode, mais devient rapidement complexe (logique de vérification, prérequis, chemins de pilotes, signature, réparation). Pour des rollouts d’entreprise contrôlés, la clarté est souvent la voie la plus robuste.

Stratégie de mise à jour : pas de chemins spéciaux pour ARM64

ARM64 ne doit pas être un cas spécial dans le processus de mise à jour. L’objectif : même fréquence de release, même numéro de version fonctionnelle, mais artefacts séparés. Si ARM64 n’est mis à jour que « manuellement », des divergences apparaissent dans la flotte qui feront grimper les coûts de support ultérieurement.

Documenter proprement les intégrations

Beaucoup de problèmes ARM64 ne se trouvent pas dans votre code mais dans les intégrations : connecteur ERP, client DMS, service de signature, logiciel de scanner, pilote d’imprimante d’étiquettes. Une liste d’intégrations maintenue avec versions et indications d’architecture est utile pour les systèmes B2B — et rend les décisions ARM64 transparentes.

Ce que les entreprises doivent faire maintenant (sans actionnisme)

Prendre ARM64 en compte tôt ne veut pas dire tout refondre immédiatement. Cela signifie répondre tôt aux bonnes questions et éliminer les blockers tant que l’effort reste planifiable. Une démarche éprouvée :

• 1) Inventaire (2–10 jours selon la taille du système) : dépendances, installateurs, pilotes, accès aux données, COM, reporting.
• 2) Image cible et trajectoire : qu’est-ce qui doit être natif sur le client ? Qu’est-ce qui devient service/REST ? Quelles composantes seront remplacées ?
• 3) Proof of Feasibility : un build ARM64 fonctionnel avec installateur et un cas d’utilisation end-to-end.
• 4) Durcissement progressif : fonctions restantes, tests, chaîne de mise à jour, capacité de diagnostic.

Ainsi ne naît pas un « projet ARM64 » isolé pendant des mois, mais une extension contrôlée de la capacité de livraison.

Conclusion : Windows 11 ARM64 n’est pas un buzz, mais un indicateur précoce de maturité technique

Windows 11 ARM64 devient pour de nombreuses entreprises une réalité simple — par achats de matériel, exigences de mobilité ou standardisation. Pour les applications Delphi, le véritable défi n’est pas seulement le code source, mais l’ensemble du système : dépendances, processus d’installation et de mise à jour, intégrations et pilotes. Qui planifie ARM64 tôt peut clarifier ces points de manière structurée, au lieu de les « patcher » sous contrainte de temps.

Au final, ARM64 est un test utile : dans quelle mesure votre application est-elle découplée, testable et livrable ? Si vous répondez à cette question maintenant, vous gagnez non seulement en options de plateforme, mais aussi une base plus stable pour la modernisation, les services, les architectures REST et la maintenabilité à long terme.

Contactez Net-Base Software GmbH, si vous souhaitez évaluer de manière fiable Windows 11 ARM64 dans votre roadmap Delphi et le mettre en œuvre avec une trajectoire technique claire.