Clavier US QWERTY International : les touches « mortes » (apostrophe, accents) tapent deux fois au lieu d’attendre la touche Espace (Windows 11)

Cette réponse a été traduite automatiquement. Par conséquent, elle peut contenir des erreurs grammaticales ou des expressions inhabituelles.

---

Bonjour @Pispa,

Bienvenue sur le forum Microsoft Q&A.

Merci de nous avoir contactés concernant le comportement de votre disposition de clavier. Je comprends que lorsque vous utilisez la disposition États-Unis (international), vos « touches mortes » (telles que l’apostrophe et l’accent circonflexe) s’affichent deux fois immédiatement au lieu d’attendre le caractère suivant pour former un accent.

Ce comportement spécifique se produit généralement lorsque le signal d’entrée est intercepté ou traité deux fois. Dans de nombreux cas, cela est dû à un conflit avec des applications en arrière-plan ou à un retard de synchronisation dans la pile d’entrée, plutôt qu’à un défaut matériel.

Pour remédier à cela, je recommande les étapes suivantes pour les problèmes de méthode d’entrée :

• Effectuer un démarrage propre : Cela nous aidera à déterminer si une application tierce ou un service en arrière-plan interfère avec vos frappes. Vous trouverez le guide officiel ici : Comment effectuer un démarrage propre dans Windows.
• Actualiser la méthode d’entrée : 1. Allez dans Paramètres > Heure et langue > Langue et région. 2. Basculez temporairement vers une disposition standard « US QWERTY » (non internationale). 3. Supprimez la disposition « États-Unis (international) », redémarrez votre appareil, puis réajoutez-la.
• Vérifier les superpositions logicielles (Overlays) : Veuillez vous assurer que toutes les superpositions de jeu (telles que Discord ou Nvidia) ou les gestionnaires de presse-papiers sont temporairement désactivés, car ils surveillent souvent les « hooks » du clavier.
• Mettre à jour les pilotes du clavier :

1. Faites un clic droit sur Démarrer et sélectionnez Gestionnaire de périphériques.
2. Développez la section Claviers, faites un clic droit sur votre clavier et sélectionnez Désinstaller l’appareil.
3. Redémarrez votre ordinateur pour permettre à Windows de réinstaller une copie propre du pilote.

Veuillez essayer ces étapes dès que possible. Une fois terminé, tenez-moi au courant du résultat — en particulier si le comportement persiste après le démarrage propre. Ces informations seront essentielles pour me permettre d'approfondir mes recherches et de vous fournir des ressources techniques plus avancées si nécessaire.

Merci de votre patience et de votre compréhension. Si vous avez des questions, n’hésitez pas à nous contacter.

J’attends votre réponse avec impatience.

Bonjour,

Merci pour votre aide. Je reviens vers vous car le problème persiste malgré toutes les actions locales et vos recommandations. Merci d’ouvrir ce dossier à l’équipe « input / Text Services Framework (TSF) » ou de me fournir un correctif/patch : le comportement est reproductible et il semble venir d’un fallback Windows vers le layout legacy French (0000040C) qui double le traitement des touches mortes (apostrophe, caret, tilde, etc.).

Je fournis ci-dessous le diagnostic complet, les commandes exécutées, les sorties clés et les fichiers de sauvegarde générés. Merci d’indiquer la marche à suivre (hotfix / regression fix) ou d’ouvrir une investigation plus profonde.

---

1) Problème observé (concret, reproductible)

• Disposition physique : Clavier US QWERTY international (layout « United States-International »).

Paramètres système : j’ai forcé la liste des langues pour avoir fr-FR et en-US.

Comportement : quand j’appuie sur ' (apostrophe) la touche est immédiatement émise (par ex. '') au lieu d’être dead key (attendre la lettre suivante).

' seul → affiche immédiatement un/apostrophe

  `'` + `e` → parfois `''e` ou `'é'` avec comportement incohérent

  
  Effet : impossible de taper correctement les accents en français avec ce layout.
```---
## 2) Actions et diagnostics que j’ai effectués (chronologie & commandes importantes)

> J’ai exécuté toutes les commandes suivantes dans **Windows PowerShell (admin)** et j’ai conservé des sauvegardes avant suppression.

### 2.1 Vérification initiale des langues / IME


```sql
Get-WinUserLanguageList | Format-List

Extrait (après manipulations) :

LanguageTag : fr-FR
InputMethodTips : {040C:00020409}

LanguageTag : en-US
InputMethodTips : {0409:00000409}

→ configuration voulue : fr-FR -> 040C:00020409 (US-International) ; en-US -> 0409:00000409 (US standard)

2.2 Scan registre (détection de remapping / substitution)

Script de scan utilisé (résumé) : exploration de

HKCU:\Keyboard Layout\Preload

HKCU:\Keyboard Layout\Substitutes

HKLM:\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\*

Sorties pertinentes trouvées :

HKCU\Keyboard Layout\Substitutes
00000409 : 00020409

HKCU\Keyboard Layout\Preload
1 : 0000040c   (ou 00000409 selon moment)

HKLM:\...\Keyboard Layouts\0000040C
Layout Text = French (Legacy, AZERTY)

→ conclusion : Windows (ou TSF) utilisait/remappait des codes (00000409 ↔ 00020409) et la clé système 0000040C existe (French Legacy AZERTY).

2.3 Opérations de nettoyage exécutées (avec sauvegardes)

J’ai créé un dossier de sauvegarde :

C:\RegBackups\

Exports réalisés :

reg export "HKCU\Keyboard Layout\Substitutes" "C:\RegBackups\HKCU_Substitutes_backup.reg" /y
reg export "HKCU\Keyboard Layout\Preload" "C:\RegBackups\HKCU_Preload_backup.reg" /y
reg export "HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\0000040C" "C:\RegBackups\HKLM_0000040C_backup.reg" /y

Suppression / renommage effectué(e) :

Suppression de la propriété 00000409 dans HKCU:\Keyboard Layout\Substitutes.

Nettoyage / écriture de HKCU:\Keyboard Layout\Preload\1 = 00000409.

Renommage sûr de la clé système HKLM:\...\Keyboard Layouts\0000040C → copiée vers DELETED_0000040C (backup conservé) puis suppression de l’ancienne 0000040C.

Commandes (exemples) :

Remove-ItemProperty -Path "HKCU:\Keyboard Layout\Substitutes" -Name "00000409" -Force
New-ItemProperty -Path "HKCU:\Keyboard Layout\Preload" -Name "1" -Value "00000409" -PropertyType String -Force
# backup + rename HKLM key (copie then remove)

2.4 Forçage de la liste de langues (méthode sûre)

$l1 = New-WinUserLanguageList -Language "fr-FR"
$l2 = New-WinUserLanguageList -Language "en-US"
$LangList = $l1 + $l2
$LangList[0].InputMethodTips.Clear(); $LangList[0].InputMethodTips.Add("040C:00020409")
$LangList[1].InputMethodTips.Clear(); $LangList[1].InputMethodTips.Add("0409:00000409")
Set-WinUserLanguageList $LangList -Force

Sortie attendue / obtenue :

fr-FR -> 040C:00020409
en-US -> 0409:00000409

2.5 Tentative de neutralisation TSF / legacy IME (testé)

J’ai essayé de désactiver le fallback legacy via registre :

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\CTF" -Name "DisableLegacyIME" -PropertyType DWord -Value 1 -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Input\Settings" -Name "EnableLegacySwitching" -PropertyType DWord -Value 0 -Force

→ Aucune amélioration visible : le comportement des dead keys reste problématique.

---

3) Comportement actuel & symptômes après nettoyage

Le layout « phantom » AZERTY a parfois disparu des sélecteurs visibles (Win+Space), mais Windows / TSF réinjecte parfois des remappings (ex. HKCU\Keyboard Layout\Substitutes ou Preload sont réécrits sur certains boots / logons).

Après toutes ces manipulations les touches mortes continuent à se comporter incorrectement (double émission), donc le problème n’est pas purement une entrée d’un layout visible : il s’agit d’un fallback/processing double au niveau TSF / pipeline d’entrée.

J’ai créé les fichiers / sauvegardes (chemin) :

C:\RegBackups\HKCU_Substitutes_backup.reg

  `C:\RegBackups\HKCU_Preload_backup.reg`

  
     `C:\RegBackups\HKLM_0000040C_backup.reg`

     
        Scripts : `RemoveFrenchAZERTY.ps1` (scan/remove), `EnforceKeyboardLayouts.ps1` (enforcement), présents dans `C:\Users\<monCompte>\Downloads\`.
```---
## 4) Reproduction simple (pour ingénieurs)

Configurer Windows avec : `fr-FR` (display/lang) + clavier physique **US QWERTY** + layout **United States-International**.

Ouvrir Notepad.

Taper `’` (apostrophe) seul → observer s’il s’affiche immédiatement (devrait **attendre** la lettre suivante si dead key fonctionne).

Taper `’` + `e` → observer si `é` est produit *sans* apparition précédente de `'` (comportement attendu). → Sur ma machine, l’appui produit `''` (double) ou comportement incohérent.

---
## 5) Ce que j’attends de Microsoft / demande d’escalade

Merci de :

**Escalader ce cas** auprès de l’équipe Windows Input / Text Services Framework (TSF) et de vérifier si l’OS effectue un fallback automatique vers la clé système `0000040C` (French Legacy AZERTY) malgré suppression/renommage, et pourquoi un second pipeline (legacy) double-traite les dead keys.

Vérifier la logique responsable de l’injection de `HKCU\Keyboard Layout\Substitutes` et/ou `Preload` (quels services/processus réécrivent ces clés à logon/boot).

Fournir un correctif (hotfix) ou une recommandation officielle :

   patch TSF empêchant le fallback vers 0000040C si IME FR-US-International est chargé, **OU**
   
```java
  endpoint d’administration (GPO) officiel pour bloquer définitivement le fallback legacy, **OU**

  
     une commande officielle/outil Microsoft (non-workaround) pour verrouiller la configuration de layout.

     
     Si nécessaire, autoriser un diagnostic plus profond (logs, Sysmon/traces d’événements, dump TSF) — je peux fournir des logs supplémentaires et exécuter des captures (traces d’événement, ProcMon) sur demande d’un ingénieur.
```---
## 6) Informations système (ce que je peux joindre)

Modèle : **Lenovo ThinkPad P1 Gen 1 (Type 20MD / 20ME)**

PowerShell : **7.5.4** (utilisé pour diagnostics)

BIOS : j’ai effectué des mises à jour récentes (BIOS pack 1.51, 30 Oct 2025) — disponible si besoin.

Actions déjà tentées : clean boot, suppression/réinstallation du layout, suppression des substitutions dans le registre, renommage sauvegardé de la clé HKLM `0000040C`, forçage de `WinUserLanguageList`, tentative de désactivation legacy IME via registre, création d’un script d’enforcement exécuté au logon.

Sauvegardes : `C:\RegBackups\*` (exports .reg disponibles).

Je suis prêt à fournir : `winver` output, liste complète des `Get-WinUserLanguageList`, captures de `Get-ItemProperty` pour `Preload` & `Substitutes`, et un enregistrement vidéo montrant le phénomène dans Notepad.

---
## 7) Pièces jointes que je joins (ou peux joindre si demandé)

`C:\RegBackups\HKCU_Substitutes_backup.reg`

`C:\RegBackups\HKCU_Preload_backup.reg`

`C:\RegBackups\HKLM_0000040C_backup.reg`

`RemoveFrenchAZERTY.ps1` (scan & remove)

`EnforceKeyboardLayouts.ps1` (script d’enforcement au logon)

---
## 8) Logs / sorties significatives (à coller si vous le souhaitez)

Extraits observés lors debug :


```sql
Get-WinUserLanguageList:
fr-FR -> 040C:00020409
en-US -> 0409:00000409

HKCU\Keyboard Layout\Substitutes (avant suppression):
00000409 : 00020409

HKLM:\...\Keyboard Layouts\0000040C:
Layout Text = French (Legacy, AZERTY)

---

9) Résumé et demande finale

Le problème ne vient pas d’un conflit d’application ou pilote « simple » : il s’agit d’un comportement de fallback du moteur d’entrée Windows (TSF) qui provoque un double traitement des touches mortes. J’ai nettoyé les entrées utilisateur/registre et renommé la clé système 0000040C (sauvegarde faite) mais le comportement reste. Merci d’ouvrir une investigation technique côté ingénierie Windows Input / TSF et de me proposer un correctif (ou une commande / politique officielle) afin d’empêcher le fallback legacy qui double-traite les dead keys.

Je reste disponible pour fournir :

captures/exports supplémentaires,

trace ProcMon / ETW / logs TSF si un ingénieur me le demande,

tests en live ou en remote (si vous proposez une méthode sécurisée).

Merci d’avance pour la prise en charge.

Cordialement, Papis Shadows Killer]
Bonjour,

Merci pour votre aide. Je reviens vers vous car le problème persiste malgré toutes les actions locales et vos recommandations. Merci d’ouvrir ce dossier à l’équipe « input / Text Services Framework (TSF) » ou de me fournir un correctif/patch : le comportement est reproductible et il semble venir d’un fallback Windows vers le layout legacy French (0000040C) qui double le traitement des touches mortes (apostrophe, caret, tilde, etc.).

Je fournis ci-dessous le diagnostic complet, les commandes exécutées, les sorties clés et les fichiers de sauvegarde générés. Merci d’indiquer la marche à suivre (hotfix / regression fix) ou d’ouvrir une investigation plus profonde.

---

1) Problème observé (concret, reproductible)

Disposition physique : Clavier US QWERTY international (layout « United States-International »).

Paramètres système : j’ai forcé la liste des langues pour avoir fr-FR et en-US.

Comportement : quand j’appuie sur ' (apostrophe) la touche est immédiatement émise (par ex. '') au lieu d’être dead key (attendre la lettre suivante).

' seul → affiche immédiatement un/apostrophe

  `'` + `e` → parfois `''e` ou `'é'` avec comportement incohérent

  
  Effet : impossible de taper correctement les accents en français avec ce layout.
```---
## 2) Actions et diagnostics que j’ai effectués (chronologie & commandes importantes)

> J’ai exécuté toutes les commandes suivantes dans **Windows PowerShell (admin)** et j’ai conservé des sauvegardes avant suppression.

### 2.1 Vérification initiale des langues / IME


```yaml
Get-WinUserLanguageList

Extrait (après manipulations) :

LanguageTag :

→ configuration voulue : fr-FR -> 040C:00020409 (US-International) ; en-US -> 0409:00000409 (US standard)

2.2 Scan registre (détection de remapping / substitution)

Script de scan utilisé (résumé) : exploration de

HKCU:\Keyboard Layout\Preload

HKCU:\Keyboard Layout\Substitutes

HKLM:\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\*

Sorties pertinentes trouvées :

HKCU\

→ conclusion : Windows (ou TSF) utilisait/remappait des codes (00000409 ↔ 00020409) et la clé système 0000040C existe (French Legacy AZERTY).

2.3 Opérations de nettoyage exécutées (avec sauvegardes)

J’ai créé un dossier de sauvegarde :

C:\RegBackups\

Exports réalisés :

reg 

Suppression / renommage effectué(e) :

Suppression de la propriété 00000409 dans HKCU:\Keyboard Layout\Substitutes.

Nettoyage / écriture de HKCU:\Keyboard Layout\Preload\1 = 00000409.

Renommage sûr de la clé système HKLM:\...\Keyboard Layouts\0000040C → copiée vers DELETED_0000040C (backup conservé) puis suppression de l’ancienne 0000040C.

Commandes (exemples) :

Remove-ItemProperty

2.4 Forçage de la liste de langues (méthode sûre)

$l1

Sortie attendue / obtenue :

fr-FR 

2.5 Tentative de neutralisation TSF / legacy IME (testé)

J’ai essayé de désactiver le fallback legacy via registre :

New-ItemProperty

→ Aucune amélioration visible : le comportement des dead keys reste problématique.

---

3) Comportement actuel & symptômes après nettoyage

Le layout « phantom » AZERTY a parfois disparu des sélecteurs visibles (Win+Space), mais Windows / TSF réinjecte parfois des remappings (ex. HKCU\Keyboard Layout\Substitutes ou Preload sont réécrits sur certains boots / logons).

Après toutes ces manipulations les touches mortes continuent à se comporter incorrectement (double émission), donc le problème n’est pas purement une entrée d’un layout visible : il s’agit d’un fallback/processing double au niveau TSF / pipeline d’entrée.

J’ai créé les fichiers / sauvegardes (chemin) :

C:\RegBackups\HKCU_Substitutes_backup.reg

  `C:\RegBackups\HKCU_Preload_backup.reg`

  
     `C:\RegBackups\HKLM_0000040C_backup.reg`

     
        Scripts : `RemoveFrenchAZERTY.ps1` (scan/remove), `EnforceKeyboardLayouts.ps1` (enforcement), présents dans `C:\Users\<monCompte>\Downloads\`.
```---
## 4) Reproduction simple 

Configurer Windows avec : `fr-FR` (display/lang) + clavier physique **US QWERTY** + layout **United States-International**.

Ouvrir Notepad.

Taper `’` (apostrophe) seul → observer s’il s’affiche immédiatement (devrait **attendre** la lettre suivante si dead key fonctionne).

Taper `’` + `e` → observer si `é` est produit *sans* apparition précédente de `'` (comportement attendu).  
 → Sur ma machine, l’appui produit `''` (double) ou comportement incohérent.

---
## 5) Ce que j’attends de Microsoft / demande d’escalade

Merci de :

**Escalader ce cas** auprès de l’équipe Windows Input / Text Services Framework (TSF) et de vérifier si l’OS effectue un fallback automatique vers la clé système `0000040C` (French Legacy AZERTY) malgré suppression/renommage, et pourquoi un second pipeline (legacy) double-traite les dead keys.

Vérifier la logique responsable de l’injection de `HKCU\Keyboard Layout\Substitutes` et/ou `Preload` (quels services/processus réécrivent ces clés à logon/boot).

Fournir un correctif (hotfix) ou une recommandation officielle :

   patch TSF empêchant le fallback vers 0000040C si IME FR-US-International est chargé, **OU**
   
```java
  endpoint d’administration (GPO) officiel pour bloquer définitivement le fallback legacy, **OU**

  
     une commande officielle/outil Microsoft (non-workaround) pour verrouiller la configuration de layout.

     
     Si nécessaire, autoriser un diagnostic plus profond (logs, Sysmon/traces d’événements, dump TSF) — je peux fournir des logs supplémentaires et exécuter des captures (traces d’événement, ProcMon) sur demande d’un ingénieur.
```---
## 6) Informations système (ce que je peux joindre)

Modèle : **Lenovo ThinkPad P1 Gen 1 (Type 20MD / 20ME)**

PowerShell : **7.5.4** (utilisé pour diagnostics)

BIOS : j’ai effectué des mises à jour récentes (BIOS pack 1.51, 30 Oct 2025) — disponible si besoin.

Actions déjà tentées : clean boot, suppression/réinstallation du layout, suppression des substitutions dans le registre, renommage sauvegardé de la clé HKLM `0000040C`, forçage de `WinUserLanguageList`, tentative de désactivation legacy IME via registre, création d’un script d’enforcement exécuté au logon.

Sauvegardes : `C:\RegBackups\*` (exports .reg disponibles).

Je suis prêt à fournir : `winver` output, liste complète des `Get-WinUserLanguageList`, captures de `Get-ItemProperty` pour `Preload` & `Substitutes`, et un enregistrement vidéo montrant le phénomène dans Notepad.

---
## 7) Logs / sorties significatives (à coller si vous le souhaitez)

Extraits observés lors debug :


```yaml
Get-WinUserLanguageList:

---

Résumé et demande finale

Le problème ne vient pas d’un conflit d’application ou pilote « simple » : il s’agit d’un comportement de fallback du moteur d’entrée Windows (TSF) qui provoque un double traitement des touches mortes. J’ai nettoyé les entrées utilisateur/registre et renommé la clé système 0000040C (sauvegarde faite) mais le comportement reste. Merci d’ouvrir une investigation technique côté ingénierie Windows Input / TSF et de me proposer un correctif (ou une commande / politique officielle) afin d’empêcher le fallback legacy qui double-traite les dead keys.

Je reste disponible pour fournir :

captures/exports supplémentaires,

trace ProcMon / ETW / logs TSF si un ingénieur me le demande,

tests en live ou en remote (si vous proposez une méthode sécurisée).

Merci d’avance pour la prise en charge.

Cordialement,
[Note du modérateur : informations personnelles supprimées]