Windows 10 : empêcher la migration vers New Outlook et garder Courrier & Calendrier (méthode PowerShell)

Windows 10 force parfois l’ouverture de Courrier & Calendrier dans New Outlook. Voici une méthode PowerShell fiable pour stopper cette redirection, garder l’application classique et prolonger sa durée d’usage, avec variantes, vérifications, rollback et conseils pro.

Sommaire

Problématique

De nombreux utilisateurs de Windows 10 constatent que l’application Courrier & Calendrier (souvent appelée « Windows Mail ») est automatiquement remplacée par New Outlook lors du lancement. Le basculement revient même après :

la désinstallation de New Outlook ;
la suppression du fichier correlation.json ;
des modifications du Registre.

Objectif : empêcher la redirection et conserver Courrier & Calendrier aussi longtemps que possible, en attendant la fin de support officielle.

Solution de contournement la plus complète

Un spécialiste Microsoft a décrit (et testé en interne) une méthode qui bloque efficacement la redirection : supprimer un fichier de migration puis interdire toute écriture dans le dossier de migration via une règle ACL « Deny Write » pour l’utilisateur courant.

Principe

Supprimer le fichier settings.json du dossier Migration lié à Courrier & Calendrier ;
Appliquer une règle « Deny Write » sur ce même dossier pour votre compte Windows, afin d’empêcher toute réécriture future.

Étapes détaillées

Fermez Courrier & Calendrier (et New Outlook s’il est ouvert).
Cliquez droit sur PowerShell > Exécuter en tant qu’administrateur.
Exécutez le script ci‑dessous (en remplaçant <VOTRENOM> par votre dossier de profil Windows) :

# Définir le dossier à protéger
$folderPath = "C:\Users\&lt;VOTRENOM&gt;\AppData\Local\Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration"
$fileToDelete = "$folderPath\settings.json"

# 1) Supprimer settings.json s'il existe
if (Test-Path $fileToDelete) { Remove-Item $fileToDelete -Force }

# 2) Interdire toute écriture ultérieure dans ce dossier
$currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$acl = Get-Acl $folderPath
$deny = New-Object System.Security.AccessControl.FileSystemAccessRule($currentUser,"Write","Deny")
$acl.AddAccessRule($deny)
Set-Acl $folderPath $acl

Effet attendu : Courrier & Calendrier s’ouvre sans être « aspiré » par New Outlook, tant que l’ACL reste en place.

Limite connue : il n’existe pas de désactivation définitive de New Outlook. Cette méthode est un workaround temporaire qui bloque la redirection tant que la règle ACL n’est pas retirée.

Pourquoi cela fonctionne

Le dossier LocalState\Migration stocke des éléments de migration qui influencent le comportement de lancement. En supprimant settings.json puis en refusant toute écriture dans ce dossier pour votre compte, vous empêchez le mécanisme de réactiver ou reposer une configuration qui force l’ouverture de New Outlook. L’ACL de type Deny a priorité sur les autorisations Allow, d’où l’efficacité de la mesure.

Version « auto » (sans renseigner le nom de profil)

Si vous préférez éviter le remplacement manuel de <VOTRENOM>, utilisez ce script équivalent qui détecte le dossier local de l’utilisateur courant et applique une ACL plus explicite (héritée sur fichiers/sous‑dossiers) :

$local = [Environment]::GetFolderPath('LocalApplicationData')
$folderPath = Join-Path $local 'Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration'
$fileToDelete = Join-Path $folderPath 'settings.json'

# Crée le dossier au besoin (certains profils ne l'ont pas encore)
if (-not (Test-Path $folderPath)) { New-Item -ItemType Directory -Path $folderPath -Force | Out-Null }

# 1) Supprimer le fichier s'il existe
if (Test-Path $fileToDelete) { Remove-Item -LiteralPath $fileToDelete -Force }

# 2) ACL Deny Write pour l'utilisateur courant, avec héritage sur fichiers et sous-dossiers
$currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$acl = Get-Acl -LiteralPath $folderPath
$inherit = [System.Security.AccessControl.InheritanceFlags] "ContainerInherit, ObjectInherit"
$prop = [System.Security.AccessControl.PropagationFlags]::None
$rights = [System.Security.AccessControl.FileSystemRights]::Write
$type = [System.Security.AccessControl.AccessControlType]::Deny

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule($currentUser, $rights, $inherit, $prop, $type)
$acl.AddAccessRule($rule)
Set-Acl -LiteralPath $folderPath $acl

Vérifier que la protection est bien en place

Contrôlez la présence de la règle Deny Write pour votre identité :

$folderPath = Join-Path ([Environment]::GetFolderPath('LocalApplicationData')) 'Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration'
$currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
(Get-Acl $folderPath).Access |
  Where-Object { $_.IdentityReference -eq $currentUser } |
  Format-Table IdentityReference, FileSystemRights, AccessControlType, InheritanceFlags, IsInherited

Testez qu’une écriture est refusée (c’est attendu) :

$probe = Join-Path $folderPath 'probe.tmp'
try {
  Set-Content -Path $probe -Value 'x' -ErrorAction Stop
  'Écriture possible (protection absente) — à corriger'
} catch {
  'Écriture bloquée : OK, protection active'
} finally {
  Remove-Item -LiteralPath $probe -Force -ErrorAction SilentlyContinue
}

Procédure de retour arrière (rollback)

Besoin de rétablir le comportement initial ? Supprimez la règle Deny puis laissez l’application regénérer ses fichiers si nécessaire.

Via PowerShell (suppression spécifique) :

$local = [Environment]::GetFolderPath('LocalApplicationData')
$folderPath = Join-Path $local 'Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration'
$currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name

$acl = Get-Acl -LiteralPath $folderPath
$inherit = [System.Security.AccessControl.InheritanceFlags] "ContainerInherit, ObjectInherit"
$prop = [System.Security.AccessControl.PropagationFlags]::None
$rights = [System.Security.AccessControl.FileSystemRights]::Write
$type = [System.Security.AccessControl.AccessControlType]::Deny

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule($currentUser, $rights, $inherit, $prop, $type)
$removed = $acl.RemoveAccessRuleSpecific($rule)
Set-Acl -LiteralPath $folderPath $acl
if ($removed) { 'Règle Deny supprimée' } else { 'Aucune règle Deny correspondante trouvée' }

Via icacls (pratique en script de connexion) :

cmd /c icacls "%LOCALAPPDATA%\Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration" /remove:d "%USERNAME%"

Autres approches évoquées ou déjà tentées

Tentative	Résultat
Désinstaller New Outlook depuis Applications > Applications installées	New Outlook se réinstalle via Store/Windows Update
Supprimer `correlation.json`	Migration à nouveau forcée au lancement suivant
Modifier le Registre pour bloquer la migration	Sans effet durable

Informations complémentaires utiles

Calendrier de retrait : Microsoft a annoncé la fin du support de Courrier & Calendrier fin 2024 ; l’application sera ensuite retirée du Microsoft Store.
Retarder l’installation (provisoire) :
- Désactiver les mises à jour automatiques d’applications dans Microsoft Store.
- Bloquer le Store via la stratégie de groupe « Turn off the Store application » ou la clé Registre DisableStore.
- Utiliser un client tiers (Thunderbird, eM Client) ou Outlook 2019/2021 « complet » si l’interface New Outlook ne convient pas.
Aucune stratégie Windows Update ciblée ne permet aujourd’hui d’exclure uniquement New Outlook ; toute mesure restera donc transitoire jusqu’à la fin de vie de Courrier & Calendrier.

Bonnes pratiques et mises en garde

Appliquez la règle Deny uniquement au dossier LocalState\Migration. Évitez de poser une règle trop large (ex. sur tout LocalState), qui pourrait gêner d’autres fonctionnalités.
Comprenez l’impact : le refus d’écriture peut empêcher la création ou la mise à jour de fichiers de migration. C’est l’objectif, mais cela peut aussi bloquer des scénarios de correction automatique. Tenez un journal de changements pour revenir en arrière si besoin.
Administrateurs : préférez un script de connexion utilisateur (qui s’exécute dans le contexte utilisateur) pour garantir que la règle vise bien l’IdentityReference attendu.
Conflits éventuels : si des processus lancés en élevé (ou en SYSTEM) modifient le dossier, la règle ciblant uniquement l’utilisateur peut ne pas les affecter. Dans la pratique, le comportement de redirection se produit dans le contexte utilisateur, d’où l’efficacité du blocage.

Déploiement en environnement entreprise

Pour un parc Windows 10, la méthode suivante est simple et réversible :

Distribuez un script PowerShell qui :
- crée le dossier Migration si nécessaire ;
- supprime settings.json ;
- pose la règle Deny Write pour l’utilisateur connecté.
Exécutez‑le comme script de connexion (GPO) ou via votre MDM (Intune) en mode Run in user context.
Ajoutez un script de retrait (rollback) qui supprime la règle Deny.

Exemple minimaliste (utile dans un script de connexion) :

$local = $env:LOCALAPPDATA
$path = Join-Path $local 'Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration'
$file = Join-Path $path 'settings.json'
New-Item -ItemType Directory -Force -Path $path | Out-Null
if (Test-Path $file) { Remove-Item $file -Force }

# Deny Write via icacls (équivalent)

cmd /c "icacls `"$path`" /deny `"%USERNAME%`":(W)" | Out-Null

Rollback (GPO de désactivation) :

cmd /c icacls "%LOCALAPPDATA%\Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration" /remove:d "%USERNAME%"

Diagnostic : que faire si la redirection persiste ?

Le dossier est-il correct ? Vérifiez précisément le chemin microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration dans le profil utilisateur concerné.
La règle Deny cible-t-elle la bonne identité ? Comparez $currentUser avec la sortie de whoami.
Héritage actif ? Si vous avez utilisé la première version du script, ajoutez l’héritage (variante « auto ») pour couvrir les fichiers du dossier.
Application encore ouverte ? Fermez Courrier & Calendrier et New Outlook avant d’appliquer la règle.
Test d’écriture (ci‑dessus) : s’il est « possible », la protection n’est pas en place ; rejouez le script.

Alternatives et stratégies d’atténuation

Ce blocage est temporaire par conception. Pour traverser la période de transition :

Geler les mises à jour d’apps côté Microsoft Store (provisoirement) afin d’éviter la réinstallation de New Outlook en arrière‑plan.
Bloquer le Store via stratégie (Turn off the Store application) ou via la clé DisableStore pour limiter les réintroductions intempestives.
Clients alternatifs : opter pour Thunderbird ou eM Client, ou utiliser Outlook 2019/2021 « complet » pour disposer d’une interface différente si New Outlook ne convient pas.

FAQ express

Cette méthode empêche‑t‑elle l’installation de New Outlook ?
Non. Elle bloque la redirection depuis Courrier & Calendrier en interdisant l’écriture dans son dossier de migration. New Outlook peut toutefois être installé par ailleurs (Store, mises à jour).

Puis‑je conserver Courrier & Calendrier indéfiniment ?
Non. Microsoft a planifié la fin de support de l’application fin 2024 et son retrait du Store. La méthode proposée prolonge l’usage, mais ne constitue pas une solution durable.

Le Deny Write présente‑t‑il un risque ?
Appliqué uniquement au dossier de migration de l’application, le risque est contenu. Évitez d’étendre le Deny à des dossiers larges. Conservez une procédure de rollback et testez sur un poste pilote.

Résumé opérationnel

Action	Commande / Script	Résultat
Supprimer le fichier de migration	`Remove-Item "$folderPath\settings.json" -Force`	Efface la configuration qui déclenche la redirection
Interdire l’écriture dans `Migration`	ACL Deny Write sur l’utilisateur courant	Empêche la recréation de paramètres de redirection
Vérifier	`(Get-Acl $folderPath).Access`	Confirme la présence de la règle Deny
Rollback	`icacls ... /remove:d "%USERNAME%"`	Restaure le comportement par défaut

Conclusion

Face au remplacement répété de Courrier & Calendrier par New Outlook dans Windows 10, la combinaison suppression de settings.json + ACL Deny Write sur le dossier de migration constitue, à ce jour, le contournement le plus efficace pour stopper la redirection. Gardez néanmoins en tête son caractère temporaire : l’application classique s’achemine vers sa fin de vie. En parallèle, préparez la bascule vers New Outlook ou un client alternatif, et organisez votre politique de mises à jour pour éviter les réintroductions non souhaitées.

Annexe : scripts prêts à copier

Script de base (version courte)

$local = $env:LOCALAPPDATA
$folderPath = Join-Path $local 'Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration'
$fileToDelete = Join-Path $folderPath 'settings.json'
if (Test-Path $fileToDelete) { Remove-Item $fileToDelete -Force }
$currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$acl = Get-Acl $folderPath
$deny = New-Object System.Security.AccessControl.FileSystemAccessRule($currentUser,"Write","Deny")
$acl.AddAccessRule($deny)
Set-Acl $folderPath $acl

Script avec héritage explicite et contrôles

# Exécuter en PowerShell Admin
$ErrorActionPreference = 'Stop'
$local = [Environment]::GetFolderPath('LocalApplicationData')
$folderPath = Join-Path $local 'Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration'
New-Item -ItemType Directory -Path $folderPath -Force | Out-Null

# Nettoyage

$file = Join-Path $folderPath 'settings.json'
if (Test-Path $file) { Remove-Item -LiteralPath $file -Force }

# ACL Deny Write (héritée)

$currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$acl = Get-Acl -LiteralPath $folderPath
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
$currentUser,
[System.Security.AccessControl.FileSystemRights]::Write,
[System.Security.AccessControl.InheritanceFlags] "ContainerInherit, ObjectInherit",
[System.Security.AccessControl.PropagationFlags]::None,
[System.Security.AccessControl.AccessControlType]::Deny
)
$acl.AddAccessRule($rule)
Set-Acl -LiteralPath $folderPath $acl

# Validation

(Get-Acl $folderPath).Access | Where-Object { $_.IdentityReference -eq $currentUser } |
Format-Table IdentityReference, FileSystemRights, AccessControlType, InheritanceFlags, IsInherited

Rollback universel

cmd /c icacls "%LOCALAPPDATA%\Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration" /remove:d "%USERNAME%"

Rappel : même si ce contournement bloque la redirection, New Outlook demeure la voie officielle et Courrier & Calendrier n’est plus maintenu après fin 2024. Considérez ce guide comme une mesure transitoire pour prolonger l’usage et préparer sereinement la migration.