NXstep Chronicles

Le 8 avril 2026, la DINUM a annoncé qu'elle quittait Windows pour Linux sur ses propres postes. Elle en compte environ 250.

Le chiffre de 2,5 millions de postes d'État sous Linux circule beaucoup depuis. Il ne figure dans aucune source qui reprend le communiqué. On le retrouve ailleurs : le mandat de janvier 2026 qui remplace Teams et Zoom par Visio concerne 2,5 millions d'agents. Deux décisions, deux périmètres.

Cet article sépare ce qui est décidé de ce qui est attendu. Puis il regarde ce que ça change pour l'authentification et le contrôle d'accès.

Ce que la DINUM a annoncé

Le séminaire interministériel du 8 avril réunissait la DINUM, la DGE, l'ANSSI et la Direction des achats de l'État. Trois points ressortent du communiqué, tel que le rapportent LinuxFr et IT-Connect :

• La DINUM migre ses propres postes vers Linux. Le communiqué ne nomme pas de distribution. La presse spécialisée relève NixOS comme base technique visible, avec Sécurix pour la sécurité (InformatiqueNews).
• Chaque ministère, opérateurs inclus, doit formaliser son propre plan d'ici l'automne 2026. Sept axes : poste de travail, outils collaboratifs, antivirus, intelligence artificielle, bases de données, virtualisation, équipements réseau.
• La DINUM coordonne un plan interministériel de réduction des dépendances extra-européennes.

Aucune date de migration n'a été donnée pour les autres administrations. On est entre la déclaration d'intention et le calendrier. Les plans ministériels sont attendus cet automne. À la date de rédaction, aucune publication de ces plans n'avait été repérée.

La circulaire du 5 février 2026

La circulaire n° 6519/SG sur les achats numériques de l'État place la souveraineté en tête des critères pour un logiciel sur étagère. Elle passe devant la performance, la sécurité, les coûts, la réversibilité, la maintenabilité et la durabilité (JSS).

Elle ne fixe aucune pondération chiffrée. Chaque acheteur interprète. Le logiciel libre y figure comme une recommandation, selon l'analyse d'un cabinet d'avocats.

Ailleurs en Europe

Entité	Décision	État connu
DINUM (France)	Annonce du 8 avril 2026	Environ 250 postes. Plans ministériels attendus à l'automne.
Schleswig-Holstein (Allemagne)	Décision d'avril 2024, 30 000 postes	Près de 80 % des postes sous LibreOffice fin 2025, hors administration fiscale. Linux sur les postes en cours.
Gendarmerie nationale (France)	Ubuntu depuis 2008	Plus de 85 000 postes sous GendBuntu selon la presse spécialisée.
Ministère de la Numérisation (Danemark)	Annonce de juin 2025	Migration progressive, retour à Microsoft possible en cas de blocage. Aucun bilan public trouvé.
Ville de Munich (Allemagne)	LiMux, environ 15 000 postes	Retour à Windows voté en 2017.

Le Schleswig-Holstein chiffre ses résultats : plus de 15 millions d'euros de licences économisés, face à 9 millions d'euros d'investissements ponctuels en 2026 (Born's IT-Blog). Ce sont les chiffres du Land, pas ceux d'un audit indépendant.

Pourquoi ça coince : le cas de Munich

Munich avait migré environ 15 000 postes sous LiMux. Quand le conseil municipal a voté le retour à Windows, 5 000 postes tournaient encore sous Windows. Raison avancée : des applications métier de la ville qui n'existent que sous Windows, et dont les utilisateurs devenaient plus nombreux (Le Monde Informatique).

Les causes restent discutées. Le maire adjoint de l'époque citait la compatibilité et le coût du support. D'autres y voient une décision politique. Dans les deux lectures, le point dur est le même : les applications métier.

Côté Gendarmerie, la méthode a été l'inverse. La bureautique passe sous OpenOffice en 2004. Les premiers postes sous Ubuntu datent de 2008. Les 72 000 postes visés étaient prévus pour l'été 2014 (LeMagIT). Dix ans, par étapes.

Le règlement CRA ne vise pas Linux

Le règlement (UE) 2024/2847, le Cyber Resilience Act, s'adresse aux fabricants de produits comportant des éléments numériques. Pas à un système d'exploitation.

Depuis le 11 septembre 2026, un fabricant doit signaler une vulnérabilité activement exploitée : alerte sous 24 heures, notification sous 72 heures, rapport final sous 14 jours, via la plateforme unique de l'ENISA (Commission européenne).

Le logiciel libre développé hors activité commerciale est exclu. Les organisations qui soutiennent durablement un logiciel libre destiné à un usage commercial relèvent d'un statut allégé, celui de « steward », avec des obligations de signalement à partir du 11 décembre 2027. Un produit commercial qui embarque du libre reste sous la responsabilité de son fabricant (synthèse de la Commission).

Pour une administration qui maintient sa propre distribution, la qualification exacte est à vérifier au cas par cas avec un juriste.

Ce que ça change côté identité et accès

Un poste Linux ne supprime pas la question de l'authentification. Il la déplace.

Sous Windows, la connexion passe en général par Active Directory. Sous Linux, elle passe par PAM, avec un annuaire à choisir, des clés SSH à gérer et, selon les cas, une carte à puce ou une clé FIDO2. Les briques existent. Il reste à les assembler, et à décider qui les maintient.

Trois questions à poser avant le pilote :

• Quel annuaire reste la référence : Active Directory conservé, ou un annuaire ouvert ?
• Le MFA en place sait-il protéger une session Linux, en local comme en SSH ?
• Les lecteurs de badges sont-ils reconnus par la distribution retenue ?

Sur des postes partagés, ces trois points se testent sur une seule machine avant tout déploiement. Découverts à grande échelle, ils coûtent beaucoup plus cher. Le cadre général est décrit sur la page contrôle d'accès physique et logique.

Par où commencer

1. Cartographier les dépendances Windows. Applications métier, macros, client VPN, annuaire, MFA. C'est la liste qui a fait tomber Munich.
2. Choisir un service pilote avec peu d'applications métier.
3. Fixer la distribution et le responsable de sa maintenance. La DINUM elle-même n'a pas nommé la sienne dans son communiqué.
4. Tester sur le pilote l'authentification, les badges et l'impression. Relever les tickets de support dès le premier mois.

Sources

• LinuxFr : migration de Windows vers Linux à la DINUM
• InformatiqueNews : la DINUM largue Windows en faveur de Linux
• IT-Connect : les autres ministères doivent préparer leur plan
• The Next Web : mandat Visio et annonce de la DINUM
• Banque des Territoires : la circulaire du 5 février 2026
• The Register : Schleswig-Holstein
• PCMag : Danemark
• Règlement (UE) 2024/2847 sur EUR-Lex

Article rédigé le 5 octobre 2026 à partir d'articles de presse et de textes publics. Le communiqué officiel de la DINUM n'a pas été consulté directement : les éléments qui le concernent viennent d'articles qui le citent. Les chiffres du Schleswig-Holstein sont ceux du Land. Les effectifs de la Gendarmerie varient selon les sources, de 85 000 à plus de 100 000 postes.

Résumé

Windows Hello for Business convient aux postes dédiés à une personne. Sur un poste partagé d'hôpital, il tient mal.

Pour ces postes, Microsoft recommande une clé de sécurité FIDO2. Une carte FIDO2 fait le même travail, et le même badge peut ouvrir les portes.

Ce document s'adresse aux DSI, RSSI et directions des établissements de santé belges soumis à la loi NIS 2 du 26 avril 2024. NIS 2 et CyFun demandent une authentification forte. Aucun des deux n'impose de produit. Donc le choix se juge sur l'usage.

NXSTEP distribue les gammes NEOWAVE, HID et RCDevs présentées en section 4.

1. Le cadre belge : NIS 2, CCB et CyFun

La Belgique transpose NIS 2 par la loi du 26 avril 2024. Elle entre en vigueur le 18 octobre 2024. Un arrêté royal du 9 juin 2024 désigne le Centre pour la Cybersécurité Belgique (CCB) comme autorité nationale (source CCB).

Côté hôpital, le classement est simple : entité essentielle. La supervision est plus stricte et proactive (BDO).

Côté authentification, quatre points :

• Mesures proportionnées au risque. La loi demande des mesures adaptées à l'entité. BDO cite le contrôle des accès pour les établissements de soins.
• CyFun comme voie de démonstration. Le CCB conseille le référentiel CyberFundamentals (CyFun). Une mise en œuvre validée donne une présomption de conformité. Le CyFun niveau Important mentionne l'authentification multifactorielle pour l'accès à distance (mesure PR.AC-3) et recommande d'envisager l'authentification forte des utilisateurs.
• Évaluation obligatoire. Les entités essentielles passent une évaluation de conformité régulière. Celles qui choisissent une certification CyFun ou ISO/IEC 27001 l'obtiennent au plus tard le 18 avril 2027. Après analyse de risque, une entité essentielle peut justifier un niveau CyFun inférieur à sa classification (source CCB).
• Responsabilité de la direction. Les sanctions montent à 10 millions d'euros ou 2 % du chiffre d'affaires mondial (BDO).

Les pages consultées ne désignent aucun produit. Ni Windows Hello for Business ni un badge n'est exigé ou exclu. L'établissement doit justifier que sa mesure convient à ses usages.

2. Ce que Windows Hello for Business apporte

Hello remplace le mot de passe par une paire de clés. La clé privée est protégée par le TPM de l'appareil. Un PIN la déverrouille, ou une biométrie en option. Microsoft parle de deux facteurs : un élément possédé (la clé liée à l'appareil) et un élément connu (le PIN) (FAQ Microsoft).

Pour un établissement de santé :

• La clé ne quitte pas l'appareil. Pas de vol du secret par hameçonnage.
• Les données biométriques restent sur le poste, chiffrées. Rien n'est envoyé à Microsoft ni à un serveur.
• La clé satisfait l'exigence MFA de Microsoft Entra.
• Deux voies de déploiement : le modèle cloud Kerberos trust, préféré par Microsoft hors scénarios de certificats, et un déploiement sur site pour les organisations qui n'utilisent qu'Active Directory.

Pour un poste attribué à une seule personne, c'est une réponse solide.

3. Ses limites en environnement hospitalier

Hello est conçu autour de l'ordinateur d'une personne. Microsoft documente plusieurs limites, et plusieurs touchent l'hôpital.

Côté soignants :

• Dix enrôlements par appareil. Microsoft fixe à 10 le maximum pris en charge sur un appareil. Au-delà de 10 utilisateurs, ou pour un utilisateur qui se connecte à de nombreux appareils, Microsoft recommande des clés FIDO2. Un poste de soins utilisé par plusieurs équipes de garde peut dépasser ce nombre. À vérifier sur le parc.
• Un enrôlement par poste. Le PIN est lié à l'appareil où il est créé. Un soignant qui change de poste configure Hello sur chacun.
• Port du masque. Microsoft déconseille d'enrôler le visage avec un masque. Si le masque est imposé, Microsoft suggère de renoncer au visage et d'utiliser le PIN ou l'empreinte.

Côté DSI :

• Accès à distance. Hello sert à l'ouverture de session locale. Il n'est pas pris en charge pour s'enrôler ni s'authentifier sur l'appareil distant lui-même. Avec cloud Kerberos trust, il ne sert pas d'identifiant en RDP ou VDI sans contournement : certificat ou Remote Credential Guard.
• Périmètre. Hello ne gère pas les comptes locaux ni les systèmes hors Windows. Microsoft Entra Domain Services n'est pas non plus pris en charge.
• Récupération. Après un PIN oublié ou verrouillé, la ré-inscription demande une nouvelle authentification MFA auprès du fournisseur d'identité. Cette procédure s'encadre.

Source de toute cette section : FAQ Microsoft, mise à jour le 1er juin 2026.

4. Badges, clés, lecteurs et logiciel : l'offre pour les postes partagés

Une clé ou une carte FIDO2 garde la clé privée dans un composant sécurisé. Un PIN la libère. Microsoft indique que les clés FIDO2 sont prévues pour les appareils partagés, ou quand l'enrôlement Hello pose problème (Microsoft Entra). Une carte FIDO2 joue le même rôle, en badge.

NEOWAVE. NXSTEP distribue la gamme : clés USB Winkeo, cartes Badgeo (détail). La fiche du Badgeo NFC FIDO2 + OTP (NEOWAVE) indique :

• une carte sans contact FIDO2 (CTAP 2.1), FIDO U2F et OTP, certifiée FIDO2 L2 ;
• un composant Java Card certifié Critères Communs EAL6+ ;
• une interface sans contact ISO/IEC 14443-A avec DESFire EV2/EV3, pour un contrôle d'accès physique compatible ;
• Windows 10/11 avec Microsoft Entra ID, et des fédérations d'identité comme Evidian, Ilex, Okta ou Ping Identity ;
• un PIN de 4 à 63 caractères, 8 essais avant réinitialisation, aucune installation sur le poste.

Le soignant présente la carte au lecteur. Il tape son PIN. La session s'ouvre. Le même badge ouvre une porte. Un seul support par personne.

Précision sur les certifications. La certification CSPN de l'ANSSI, avec Visa de sécurité remis le 15 septembre 2022, porte sur les clés Winkeo-A et Winkeo-C FIDO2 (NEOWAVE). Pour les cartes Badgeo, NEOWAVE annonce FIDO2 L2 et un composant EAL6+. Nous n'avons pas trouvé de CSPN ANSSI propre aux cartes Badgeo.

HID. Gamme Crescendo : des cartes à puce FIDO2 (niveau CTAP 2.1 L2, selon HID). Un seul identifiant pour l'accès logique (PKI, FIDO2, OATH) et pour l'accès physique (Seos, iCLASS, DESFire EV3, Prox). Des clés USB-A et USB-C compatibles FIDO, PKI et OATH aussi (HID). Le choix entre NEOWAVE et HID dépend de la technologie de badge déjà installée pour les portes.

Les lecteurs. Un poste a besoin d'un lecteur de cartes, avec ou sans contact. NEOWAVE propose ses lecteurs. D'autres lecteurs du marché sont compatibles (NEOWAVE).

Le logiciel : RCDevs OpenOTP. Badges et clés authentifient. Il faut aussi un serveur pour les facteurs, les règles et les enrôlements. OpenOTP, construit sur la console WebADM, gère notamment FIDO2, les cartes à puce, l'OTP et les notifications push. Les règles se posent par utilisateur, groupe, application ou réseau (RCDevs).

Son fournisseur d'identifiants pour Windows ajoute le MFA à l'ouverture de session, au RDP et à l'élévation de droits, avec FIDO2 et carte à puce. Il tourne sur des postes joints à un domaine, en groupe de travail ou joints à Entra ID. Il reste utilisable hors ligne après une première connexion en ligne. Sur un poste partagé, chaque utilisateur doit avoir fait cette première connexion sur chaque poste (RCDevs). OpenOTP peut aussi servir de méthode d'authentification externe pour Microsoft Entra ID, avec des licences Entra ID P1 ou P2 (RCDevs).

Effet sur les limites de la section 3. L'authentification passe par le serveur. Elle ne dépend plus d'un enrôlement lié au poste. La limite de 10 enrôlements Windows Hello ne devrait pas s'appliquer, et l'accès à distance (RDP, RDS) est couvert. À confirmer en pilote.

5. Une répartition par type de poste

Sur un poste partagé, deux options. Chacune a un coût.

• Windows Hello for Business. Aucun support en plus. Mais 10 enrôlements maximum par appareil.
• Badge ou clé FIDO2. Microsoft le recommande au-delà de 10 utilisateurs. Mais il faut un support par personne, un lecteur par poste pour une carte, et un serveur MFA.

Les deux ne s'excluent pas. On les affecte selon l'usage. Proposition à adapter au parc de l'établissement :

• Poste dédié à une personne (administration, bureautique) : Windows Hello for Business. Clé liée au TPM du poste, sans support supplémentaire. La limite de 10 enrôlements ne joue pas.
• Poste partagé (zone de soins, salle commune) : badge ou clé FIDO2 avec PIN, géré par un serveur MFA (RCDevs OpenOTP). L'identifiant suit la personne et non le poste. Microsoft recommande FIDO2 au-delà de 10 utilisateurs.
• Comptes administrateurs et à privilèges : clé ou badge FIDO2. Authentifiant matériel utilisable sur plusieurs postes d'administration.
• Accès à distance (RDP, VDI) : MFA par clé ou carte FIDO2, via le fournisseur d'identifiants Windows de RCDevs OpenOTP. Hello ne s'authentifie pas sur l'appareil distant lui-même.

Pour que ce choix tienne en audit, trois points :

• rattacher l'émission, la perte et la révocation du badge au processus d'arrivée et de départ du personnel, comme pour un compte d'annuaire ;
• prévoir une procédure de secours en cas d'oubli ou de perte du badge, sans retour au mot de passe seul ;
• consigner le choix par type de poste dans la politique de contrôle d'accès, avec l'analyse de risque qui le justifie.

6. Points de vigilance

Ce document ne démontre pas tout. Cinq points à valider avant décision :

• Pilote technique. On vérifie la carte, le lecteur, la version de Windows et l'annuaire (Entra ID ou Active Directory seul) sur un échantillon de postes. On mesure aussi le temps d'ouverture de session en conditions de soins.
• Accès physique. Partager un badge entre portes et postes dépend du système de contrôle d'accès en place : DESFire EV2/EV3, encodage, gestion des identifiants.
• Portée des chiffres. Les 10 enrôlements par appareil sont le maximum pris en charge par Microsoft. L'effet réel dépend du nombre de personnes par poste.
• Serveur MFA et continuité. Le serveur d'authentification devient un composant critique. On dimensionne son hébergement, sa redondance et le mode hors ligne. L'accès hors ligne exige une première connexion en ligne de chaque utilisateur sur chaque poste. L'intégration à Entra ID par méthode externe exige des licences Entra ID P1 ou P2.
• Statut du texte. Seuls les textes publiés au Moniteur belge font foi. Le niveau CyFun applicable se confirme avec le CCB. Ce document n'est ni un avis juridique ni une attestation de conformité.

NXSTEP distribue les produits NEOWAVE, HID et RCDevs. Cet intérêt commercial est déclaré en tête de document.

Sources

Consultées le 2 octobre 2026.

• CCB, NIS2 : êtes-vous dans le champ ? : entrée en vigueur, évaluation de conformité, échéance d'avril 2027, présomption de conformité.
• BDO, NIS2 dans le secteur des soins de santé : classement des hôpitaux, obligations, sanctions.
• CCB, CyFun niveau Important : mesures sur l'authentification multifactorielle (lu dans un extrait de recherche).
• Microsoft, Windows Hello for Business : FAQ : fonctionnement, 10 enrôlements, accès à distance.
• Microsoft, Passwordless et clés FIDO2 : dépannage : usage des clés FIDO2 sur appareils partagés (lu dans un extrait de recherche).
• NEOWAVE, Badgeo NFC FIDO2 + OTP : caractéristiques et certifications de la carte.
• NEOWAVE, Visa de sécurité ANSSI pour les clés Winkeo FIDO2 : portée de la certification CSPN.
• Texte faisant foi : loi du 26 avril 2024, non reproduite ici.
• HID, Crescendo Cards : un identifiant pour l'accès physique et logique (spécifications techniques lues dans un extrait de recherche).
• RCDevs, Windows MFA hors ligne avec OpenOTP Credential Provider : MFA à l'ouverture de session, RDP, postes partagés, mode hors ligne.
• RCDevs, OpenOTP et méthode externe pour Entra ID : méthodes prises en charge, règles, licences Entra (lus dans des extraits de recherche).
• NEOWAVE, FAQ produits FIDO : lecteurs compatibles (lu dans un extrait de recherche).

Lexique

Active Directory (AD). Annuaire Microsoft installé sur les serveurs de l'établissement. Il gère les comptes des utilisateurs, des postes et leurs droits.

ANSSI. Agence nationale de la sécurité des systèmes d'information, autorité française de cybersécurité.

Annuaire. Base centrale qui recense les utilisateurs, les postes et leurs droits d'accès. Active Directory et Entra ID en sont deux exemples.

Biométrie. Reconnaissance d'une caractéristique physique de la personne, comme le visage ou l'empreinte digitale.

CCB. Centre pour la Cybersécurité Belgique, autorité nationale chargée de superviser l'application de la loi NIS 2 belge.

Cloud Kerberos trust. Modèle de déploiement de Windows Hello for Business pour les environnements qui combinent Active Directory et Entra ID. Kerberos est le protocole d'authentification d'Active Directory.

Critères Communs, EAL6+. Norme internationale d'évaluation de la sécurité des produits (ISO/IEC 15408). EAL signifie Evaluation Assurance Level et va de 1 à 7. Le signe + indique des exigences supplémentaires.

Credential Provider (fournisseur d'identifiants). Module qui ajoute une méthode de connexion à l'écran d'ouverture de session de Windows.

CSPN, Visa de sécurité. Certification de sécurité de premier niveau, délivrée par l'ANSSI après évaluation par un laboratoire agréé. Le Visa de sécurité est le label qui la signale.

CTAP 2.1. Client to Authenticator Protocol : langage utilisé par l'ordinateur pour dialoguer avec une clé ou une carte FIDO2. 2.1 désigne la version.

CyFun (CyberFundamentals). Référentiel de cybersécurité du CCB, en quatre niveaux : Small, Basic, Important et Essential.

DESFire EV2, EV3. Technologie de carte sans contact de NXP, très répandue pour le contrôle d'accès aux portes. EV2 et EV3 sont des générations.

DSI, RSSI. Directeur des systèmes d'information ; responsable de la sécurité des systèmes d'information.

Enrôlement. Inscription d'un moyen d'authentification (PIN, visage, empreinte, clé, carte) sur un appareil ou auprès d'un serveur.

Entité essentielle, entité importante. Catégories de la loi NIS 2 selon le secteur et la taille. Les hôpitaux sont des entités essentielles, supervisées plus strictement.

Entra ID. Service d'annuaire et d'identité de Microsoft dans le cloud, ancien Azure Active Directory. Les licences P1 et P2 en sont des niveaux payants.

FIDO2, FIDO Alliance. Standard ouvert d'authentification sans mot de passe, fondé sur une paire de clés dont la clé privée ne quitte pas la clé ou la carte. La FIDO Alliance l'édite et certifie les produits.

FIDO2 L2. Niveau 2 de la certification de la FIDO Alliance, qui évalue la sécurité de l'authentificateur. Les niveaux montent de L1 à L3+.

Hameçonnage (phishing). Technique qui pousse l'utilisateur à livrer son mot de passe sur un faux site ou un faux message.

IAM. Identity and Access Management : gestion des identités et des droits d'accès.

ISO/IEC 27001. Norme internationale de management de la sécurité de l'information, certifiable par un organisme accrédité.

ISO/IEC 14443-A. Norme de communication des cartes sans contact à 13,56 MHz, utilisée notamment par DESFire.

Java Card. Plateforme logicielle des puces de cartes à puce, sur laquelle fonctionnent les applications d'authentification.

MFA. Authentification multifacteur : combine au moins deux éléments parmi ce que l'on sait (PIN), ce que l'on possède (badge, clé) et ce que l'on est (biométrie).

NFC. Near Field Communication : communication sans contact à quelques centimètres, utilisée par les cartes et les téléphones.

NIS 2. Directive européenne 2022/2555 sur la cybersécurité, transposée en Belgique par la loi du 26 avril 2024.

OATH, OTP, HOTP, TOTP. OTP : mot de passe à usage unique. HOTP le calcule à partir d'un compteur, TOTP à partir de l'heure (30 ou 60 secondes). OATH est l'initiative qui a défini ces deux méthodes.

OpenOTP, WebADM. Logiciels de RCDevs : OpenOTP est le serveur d'authentification multifacteur, WebADM sa console d'administration.

Passkey (clé d'accès). Identifiant FIDO2 qui remplace le mot de passe.

PIN. Code personnel. Avec Windows Hello, il reste sur l'appareil et n'est jamais envoyé sur le réseau.

PKI. Infrastructure à clés publiques : système de certificats numériques qui relie une identité à une clé.

Poste joint à un domaine. Ordinateur enregistré dans l'annuaire de l'organisation, qui en applique les règles.

RDP, RDS, VDI. Remote Desktop Protocol : bureau à distance de Windows. RDS : Remote Desktop Services, les serveurs qui l'hébergent. VDI : Virtual Desktop Infrastructure, bureaux virtuels.

Remote Credential Guard. Fonction de Windows qui évite d'envoyer les identifiants au poste distant lors d'une connexion RDP.

Seos, iCLASS, Prox. Familles de cartes sans contact de HID pour le contrôle d'accès. Prox est une ancienne technologie à 125 kHz.

TPM. Trusted Platform Module : puce de sécurité intégrée à l'ordinateur, qui génère et garde les clés cryptographiques. Une clé protégée par le TPM ne peut pas être copiée vers un autre appareil. Windows Hello for Business recommande la version 2.0.

U2F. Universal 2nd Factor : ancien standard FIDO de second facteur, prédécesseur de FIDO2.

Windows Hello for Business. Fonction de Windows qui remplace le mot de passe par une clé liée à l'appareil, déverrouillée par un PIN ou une biométrie.

Winkeo, Badgeo. Noms des gammes NEOWAVE : Winkeo pour les clés USB, Badgeo pour les cartes.

L'IA locale désigne l'exécution d'un modèle sur l'infrastructure de l'organisation, sans appel à un service externe. Appliquée à des données sensibles, elle supprime la transmission à un tiers — et avec elle une part des obligations qui bloquent les projets : plus de sous-traitant à encadrer au sens de l'article 28 du RGPD, plus de transfert hors Union européenne à justifier au titre du chapitre V, plus de clause à négocier. C'est précisément ce qui débloque les dossiers qui meurent en comité de sécurité.

Ce basculement est récent. En août 2026, plusieurs laboratoires ont publié des modèles exécutables sur du matériel grand public — dont un système de reconnaissance vocale dont la plus petite déclinaison pèse moins de 500 Mo et fonctionne sans carte graphique. La capacité n'est plus enfermée derrière une API payante.

Mais l'exécution locale n'est pas la conformité. La licence des poids d'un modèle diffère de celle de son code, l'exploitation revient à vos équipes, et un modèle local reste un acteur sans identité ni journal tant que vous ne lui en donnez pas. Cet article détaille ce qui change réellement, ce qui ne change pas, et comment trancher.

Ce qui a changé en août 2026

Plusieurs publications convergentes, sur une même semaine, ont déplacé le seuil d'accès :

• Un modèle de génération vidéo produisant image et bande son dans la même passe, annoncé comme fonctionnant avec 5 à 16 Go de mémoire vidéo.
• Un système d'animation de personnages annoncé sous la seconde de latence dans sa version allégée.
• Un modèle de langage parmi les plus gros connus publiquement, dont les poids sont annoncés comme ouverts.
• Un outil de reconnaissance vocale dont le plus petit modèle tient sous 500 Mo et s'exécute sans GPU.

Le point commun n'est pas la performance brute mais le support d'exécution : du matériel qu'un établissement possède déjà. Ces chiffres proviennent des communications des éditeurs et n'ont pas fait l'objet d'une vérification indépendante de notre part — ils indiquent un ordre de grandeur, pas un engagement de service.

Cloud ou exécution locale : ce que chaque option engage

Le choix ne se réduit pas à une comparaison de coût. Il déplace des obligations juridiques et opérationnelles d'un côté à l'autre du contrat.

Critère	API d'un fournisseur	Exécution locale
Statut RGPD du fournisseur	Sous-traitant, contrat art. 28 requis	Aucun tiers, pas de contrat de sous-traitance
Transfert hors UE	À justifier (chapitre V)	Sans objet
Modèle de coût	Variable, à l'usage	Fixe : matériel et exploitation
Coût marginal d'un test	Facturé	Nul
Traçabilité des traitements	Partagée avec le fournisseur	Entièrement chez vous
Mises à jour et correctifs	Assurés par le fournisseur	À votre charge
Réversibilité	Dépend des conditions d'usage	Totale, le modèle est stocké
Disponibilité	Soumise au fournisseur	Soumise à votre exploitation

Aucune colonne n'est supérieure dans l'absolu. L'API reste rationnelle pour un usage ponctuel ou exploratoire ; l'exécution locale se justifie quand le volume est régulier, ou quand la sensibilité des données l'impose.

Le point qui débloque : il n'y a plus de sous-traitant

C'est l'effet le plus immédiat et le plus sous-estimé.

Lorsqu'un traitement passe par une API externe, le fournisseur devient sous-traitant au sens de l'article 28 du RGPD. Cela suppose un contrat écrit, un encadrement des sous-traitants ultérieurs, une documentation des mesures de sécurité au titre de l'article 32, et une justification des transferts si les serveurs sortent de l'Union européenne. Pour un traitement de données de santé, s'y ajoutent les exigences d'hébergement applicables.

Un modèle exécuté sur votre infrastructure ne déclenche aucune de ces obligations, parce qu'aucune donnée ne quitte votre périmètre. Le traitement reste sous votre seule responsabilité de responsable de traitement.

C'est ce point, et non l'économie sur la facture, qui décide du sort de la plupart des projets. Une automatisation techniquement aboutie est abandonnée en comité parce que personne ne peut garantir le trajet des données — un problème de responsabilité, qu'aucune clause contractuelle ne dissipe complètement. L'exécution locale le règle par construction.

Trois limites à connaître avant de décider

La licence des poids n'est pas celle du code

« Open source » ne signifie pas « libre de tout usage ». Un modèle se compose de deux artefacts distincts, soumis à deux licences distinctes : le code d'inférence, souvent permissif, et les poids du modèle, fréquemment assortis de restrictions — usage non commercial, plafond d'utilisateurs mensuels, interdictions sectorielles, obligation d'attribution.

Lire l'annonce d'un éditeur mentionnant une licence permissive et en conclure que l'ensemble est utilisable commercialement est une erreur courante, et coûteuse dans un contexte réglementé. Les deux fichiers de licence se lisent avant tout déploiement en production, et la conclusion se consigne dans le dossier du projet.

L'exploitation revient chez vous

L'exécution locale déplace vers vos équipes ce que le fournisseur assurait : mise à jour des modèles, supervision de la charge, reprise après incident, sauvegarde, veille sur les vulnérabilités, et maintien d'une compétence interne.

Ce coût est réel mais rarement chiffré au moment de la décision. Il se compare à l'abonnement évité, pas au coût nul. Pour un usage occasionnel, l'arbitrage penche souvent vers l'API ; pour un traitement récurrent portant sur des données sensibles, vers l'internalisation.

Un modèle local reste un acteur non gouverné

Un modèle qui tourne dans vos murs échappe au réseau, pas à la gouvernance. Il lit des fichiers, produit des sorties, et parfois déclenche des actions. Sans identité propre, sans droits délimités et sans journal distinct, ces opérations sont indiscernables de celles de l'utilisateur qui a lancé le processus.

La disparition de l'API supprime aussi un garde-fou involontaire : la facture. Un modèle téléchargé ne laisse aucune trace d'achat, donc aucun signal pour les équipes sécurité. C'est un cas de shadow IT dont l'ampleur ne se mesure qu'en inventoriant les postes.

Ce que ça change pour le contrôle d'accès et l'IAM

Un agent automatisé qui agit dans le système d'information est un acteur, au même titre qu'un collaborateur ou qu'un compte de service. Il devrait donc relever des mêmes principes que ceux appliqués au contrôle d'accès physique et logique : une identité distincte, des droits limités à son périmètre fonctionnel, une date d'expiration, et une trace exploitable.

Dans la pratique, la plupart des agents s'exécutent sous le compte de la personne qui les a lancés. Le journal attribue alors à un humain des centaines d'opérations qu'il n'a pas réalisées — une attribution fausse, difficile à défendre lors d'une revue d'accès ou d'un audit.

Les mécanismes nécessaires existent déjà et ne sont pas propres à l'IA : modèles RBAC ou ABAC, provisionnement et révocation, revues d'habilitations périodiques, journalisation séparée. Les établissements engagés dans une trajectoire de mise en conformité, notamment sous NIS2 en milieu hospitalier (directive UE 2022/2555), disposent déjà du cadre : il reste à y inscrire les acteurs non humains.

Par où commencer

1. Inventorier l'existant. Quels modèles tournent déjà sur les postes, lancés par qui, sur quelles données. Sans cet état des lieux, toute politique d'usage est écrite à l'aveugle.
2. Choisir un processus répétitif à faible enjeu. Transcription de réunions, tri de documents entrants, comptes rendus standardisés. Le critère n'est pas la difficulté technique mais le fait qu'une erreur y soit rattrapable.
3. Mesurer avant. Combien d'heures par mois, par qui, pour quel résultat. Un gain non mesuré au départ ne sera pas démontrable à l'arrivée, et un projet non démontrable n'est pas reconduit.
4. Écrire le cadre. Données admises, données interdites, qui valide une sortie avant qu'elle produise un effet, à quel seuil un humain est alerté. Une page suffit, et c'est l'étape la plus souvent sautée.
5. Vérifier les deux licences et consigner la conclusion dans le dossier du projet.
6. Tester à petite échelle, sur des données réelles mais sans conséquence, avant tout élargissement.

Questions fréquentes

Un modèle exécuté en local dispense-t-il d'une analyse d'impact ?

Non. L'analyse d'impact relative à la protection des données relève de l'article 35 du RGPD et dépend de la nature du traitement, pas de son lieu d'exécution. Un traitement à grande échelle de données de santé la requiert, qu'il soit local ou externalisé. L'exécution locale simplifie le volet transferts et sous-traitance, elle ne supprime pas l'obligation d'analyse.

Quel matériel faut-il prévoir ?

Cela dépend entièrement du modèle retenu. Les annonces d'août 2026 mentionnent des besoins allant de l'absence de carte graphique, pour de la reconnaissance vocale compacte, à 16 Go de mémoire vidéo pour de la génération d'images animées. Beaucoup d'organisations disposent déjà d'un parc suffisant sans l'avoir identifié comme tel. L'inventaire précède l'achat.

« Open source » signifie-t-il utilisable commercialement ?

Pas nécessairement. Le code d'inférence et les poids relèvent de licences distinctes, et les poids sont fréquemment assortis de restrictions d'usage. Les deux documents se lisent séparément avant tout déploiement en production.

Faut-il abandonner les API des fournisseurs ?

Non. Les deux approches coexistent : l'API pour l'exploration et les usages ponctuels, l'exécution locale pour les traitements récurrents ou portant sur des données sensibles. Ce qui change, c'est que l'internalisation est devenue une option crédible — donc un levier de négociation et un plan de repli.

À retenir

L'écart entre l'IA propriétaire et l'IA ouverte s'est refermé plus vite que la plupart des feuilles de route ne l'anticipaient, et la contrainte qui justifiait d'attendre — le coût et l'accès — a largement disparu.

Ce qui reste est un travail d'organisation : inventorier, cadrer, attribuer une identité aux acteurs non humains, journaliser. Ce travail-là ne s'accélère pas tout seul, et c'est lui qu'un auditeur examinera. Nos engagements de conformité détaillent le cadre dans lequel nous l'accompagnons.

Les éléments d'actualité cités proviennent d'annonces publiques d'éditeurs relayées en août 2026. Les chiffres de performance et de configuration matérielle sont ceux communiqués par ces éditeurs et n'ont pas fait l'objet d'une vérification indépendante. Les références réglementaires renvoient au RGPD (règlement UE 2016/679) et à la directive NIS2 (UE 2022/2555).