Depuis mi‑novembre 2024, certains classeurs Excel (locaux ou OneDrive) refusent de s’ouvrir et affichent « The file could not be accessed ». Voici les causes confirmées et des corrections concrètes, avec pas‑à‑pas et scripts pour rétablir l’accès et éviter les rechutes.
Symptômes et message d’erreur
Au double‑clic sur un fichier .xlsx, .xlsm ou .xls, Excel affiche une boîte de dialogue avec le message : “The file could not be accessed” (souvent accompagné d’une précision indiquant que le fichier ou le dossier est introuvable ou inaccessible). Le même fichier :
- peut être visible dans l’Explorateur Windows ;
- peut parfois s’ouvrir quand on passe par Excel > Fichier > Ouvrir ;
- peut se trouver soit sur le disque local, soit dans un dossier synchronisé OneDrive/SharePoint.
Ce qui a changé et pourquoi
Les retours de terrain convergent sur deux déclencheurs :
- Nom (ou chemin) contenant des caractères « double‑octet » issus d’écritures CJK (kanji, kana, hanzi) ou d’espaces pleine largeur (U+3000). Exemple :
Rapport Annuel.xlsx(avec un espace pleine largeur invisible à l’œil nu) ou\\serveur\Données\経理\実績.xlsx. - Apparition soudaine après une mise à jour Microsoft 365 aux alentours de la mi‑novembre 2024, ayant modifié la manière dont Excel gère les chemins/noms non‑Unicode dans certains contextes.
Concrètement, si le système et/ou certaines bibliothèques traitent un nom de fichier en dehors d’Unicode (code page « ANSI »), les caractères double‑octet peuvent être mal transcodés, et Excel échoue à localiser le fichier lorsqu’il est lancé via le Shell (double‑clic), bien que l’ouverture manuelle depuis Excel aboutisse parfois.
Solutions et contournements validés
| Objectif | Action détaillée | Remarques |
|---|---|---|
| Ouvrir immédiatement le fichier | Renommez le fichier et/ou chaque segment du chemin pour retirer les caractères double‑octet (espaces pleine largeur, kanji, etc.) et n’utiliser que l’alphabet latin/romaji (A‑Z, a‑z, 0‑9, tirets, underscores). | Rapide et efficace, mais à répéter pour chaque fichier/dossier concerné. |
| Ouvrez Excel, puis Fichier > Ouvrir et naviguez jusqu’au classeur. | Fonctionne souvent, mais moins pratique que le double‑clic. | |
| Rétablir l’accès à tous les fichiers concernés sans les renommer | Changez la locale système (programmes non‑Unicode) : Panneau de configuration > Région > onglet Administratif > Modifier la locale système… → choisir Japonais (Japon). Redémarrez Windows. | N’impacte pas la langue de l’interface Windows ; modifie seulement la manière dont les programmes non‑Unicode gèrent l’encodage. |
| Alternative : dans la même boîte de dialogue, cochez la case bêta Utiliser Unicode UTF‑8 pour la prise en charge linguistique mondiale, puis redémarrez. | Plus universel, mais peut perturber quelques logiciels anciens qui supposent une page de codes spécifique. | |
| Réparer l’installation Office | Panneau de configuration > Programmes et fonctionnalités > Microsoft 365 → Modifier → Réparation en ligne. | Réinstalle des composants corrompus ; utile si l’erreur tient à un binaire endommagé ou à une intégration Shell défectueuse. |
| Limiter les risques futurs | Conservez des chemins complets < 218 caractères et n’utilisez aucun caractère réservé (< > ? [ ] : * /). Préférez des noms simples, stables et ASCII. | Bonnes pratiques valables indépendamment du bogue de 2024. |
Pas‑à‑pas détaillés
Renommer le fichier/le chemin pour éliminer les caractères double‑octet
- Dans l’Explorateur, affichez l’extension des fichiers (Affichage > Afficher > Extensions de noms de fichiers).
- Renommez le fichier : remplacez les caractères non ASCII (kanji, kana, hanzi, espace pleine largeur) par lettres/chiffres latins, tiret (
-) ou underscore (_). - Si nécessaire, renommez aussi les dossiers parents pour supprimer tout caractère double‑octet dans le chemin complet.
- Relancez l’ouverture par double‑clic. Si vous êtes dans un dossier OneDrive, attendez la fin de la synchronisation avant de tester (icône nuage).
Astuce : l’espace pleine largeur (U+3000) ressemble à un espace normal mais casse de nombreux outils hérités. Tapez un espace « classique » (U+0020) à la place.
Changer la locale système (programmes non‑Unicode)
- Ouvrez le Panneau de configuration (pas l’app Paramètres).
- Allez dans Région → onglet Administratif → Modifier la locale système….
- Sélectionnez Japonais (Japon), validez et redémarrez Windows.
Quand choisir cette option ? Si vous manipulez de nombreux chemins/nommages japonais, définir la locale système sur « Japonais » restaure une compatibilité large avec les applications qui reposent encore sur des API non‑Unicode.
Activer l’option bêta « Utiliser Unicode UTF‑8 »
- Au même endroit (Région > Administratif), cochez Utiliser Unicode UTF‑8 pour la prise en charge linguistique mondiale.
- Redémarrez Windows et testez l’ouverture par double‑clic.
À savoir : cette option rend le comportement plus homogène entre applications, mais quelques logiciels anciens peuvent se comporter différemment (ex. tri, lecture de fichiers legacy). Testez d’abord sur un poste pilote.
Effectuer une réparation en ligne de Microsoft 365
- Fermez toutes les applications Office.
- Ouvrez Panneau de configuration > Programmes et fonctionnalités, sélectionnez Microsoft 365, cliquez sur Modifier.
- Choisissez Réparation en ligne, puis laissez la procédure se terminer. Redémarrez et testez.
Check‑list de diagnostic rapide
- Le même fichier s’ouvre‑t‑il via Excel > Fichier > Ouvrir ? → Oui : problème lié à l’association/double‑clic ou au Shell.
- Le chemin complet contient‑il des kanji, des caractères de ponctuation pleine largeur, ou un espace U+3000 ? → Oui : renommer ou changer la locale système.
- Le chemin dépasse‑t‑il ~218 caractères ? → Raccourcir dossiers/nom du fichier.
- Le fichier est‑il dans un dossier OneDrive ? → Attendre la fin de la synchronisation et vérifier que le nom est identique côté cloud.
- Excel démarre‑t‑il en mode sans échec (
Win+R→excel /safe) ? → Si oui, tester l’ouverture et vérifier les compléments.
Cas fréquents qui déclenchent l’erreur
| Exemple | Pourquoi ça bloque | Remède |
|---|---|---|
\\srv\部門\会計\実績 2024.xlsx (espace pleine largeur avant 2024) | Le Shell/Excel interprète mal l’espace U+3000 dans une API non‑Unicode. | Remplacer l’espace par U+0020 et/ou basculer la locale système. |
C:\データ\営業\見積\顧客別\案件.xlsx | Segments de chemin en double‑octet ; le double‑clic échoue selon la build. | Renommer les dossiers ou activer UTF‑8/locale JP. |
| Chemin > 218 caractères | Les API Office tolèrent moins que le MAX_PATH traditionnel. | Raccourcir les noms/segments, rapprocher du lecteur racine. |
| Nom contenant des caractères réservés (ou proches) | Windows refuse certains caractères ou les normalise de façon imprévisible. | Éviter < > ? [ ] : * / et tout caractère exotique. |
OneDrive : points d’attention
- Propagation du renommage : OneDrive peut conserver l’ancien nom côté cloud quelques instants. Attendez la fin de la synchro (icône nuage sans flèches), puis rouvrez le fichier.
- Files On‑Demand : si le fichier est « en ligne uniquement », forcer Toujours conserver sur cet appareil pour écarter un souci d’accès hors connexion.
- Conflits de nom : s’il existe deux versions (local/cloud) avec des noms qui ne se normalisent pas de la même façon, résolvez manuellement (renommer l’une des copies, puis Fusionner si nécessaire).
Impacts, risques et choix entre « Locale JP » et « UTF‑8 »
| Option | Avantages | Risques potentiels | Quand l’adopter ? |
|---|---|---|---|
| Locale système Japonais (Japon) | Compatibilité éprouvée avec anciens outils JIS/Shift‑JIS ; règle beaucoup de cas Excel/chemins japonais. | Programmes non‑Unicode non‑japonais peuvent s’afficher différemment (tri, saisie). | Parc avec nombreux chemins CJK et applications historiques. |
| UTF‑8 (bêta) | Uniformise l’encodage, simplifie les échanges multilingues. | Quelques logiciels anciens supposant une page de codes fixe peuvent dysfonctionner. | Environnement moderne, majorité d’apps Unicode, besoin multilingue. |
Procédures avancées (administrateurs)
Inventorier et renommer en masse les noms problématiques (PowerShell)
Testez d’abord sur un échantillon et utilisez toujours le paramètre -WhatIf avant de renommer réellement.
# Lister les fichiers dont le nom contient des caractères non ASCII (> U+007F)
Get-ChildItem -Path "C:\Chemin\Dossier" -Recurse -File |
Where-Object { $_.Name.ToCharArray() | Where-Object { [int]$_ -gt 127 } } |
Select-Object FullName
# Détecter l'espace pleine largeur U+3000
Get-ChildItem -Path "C:\Chemin\Dossier" -Recurse -File |
Where-Object { $_.Name -match "\u3000" } |
Select-Object FullName
# Remplacer U+3000 par espace normal et supprimer le reste des non ASCII
# (prévisualisation avec -WhatIf)
Get-ChildItem -Path "C:\Chemin\Dossier" -Recurse -File | ForEach-Object {
$newName = ($*.Name -replace "\u3000"," ") -replace "[^\u0000-\u007F]",""
if ($newName -ne $*.Name) {
$newPath = Join-Path -Path $*.DirectoryName -ChildPath $newName
Rename-Item -LiteralPath $*.FullName -NewName $newPath -WhatIf
}
} Conseils : adaptez la regex pour conserver certains caractères (ex. tirets cadratins) si vous le souhaitez ; en production, logguez systématiquement les renommages.
Réparer ou réinitialiser l’association de fichiers
- Paramètres Windows > Applications > Applications par défaut → associez .xlsx/.xlsm/.xls à Microsoft Excel.
- Si le double‑clic échoue encore, démarrez Excel en
excel /safe, désactivez temporairement les compléments, puis réessayez.
Revenir temporairement à une build antérieure
Si votre service IT l’autorise, vous pouvez figer Microsoft 365 sur une build stable antérieure (canal, version). Procédez via vos outils de gestion (ODT, Intune, ConfigMgr), après validation sécurité. Cette mesure est transitoire en attendant une build corrigée.
Bonnes pratiques de nommage pour Excel et Windows
- Respecter un chemin < 218 caractères (marge de sécurité côté Office).
- Éviter les caractères réservés au système :
< > ? [ ] : * /(et, plus largement, tout caractère exotique dans les noms de fichiers). - Préférer le format :
AAAA‑MM‑JJ_projet_version.xlsx(ASCII, lisible, tri naturel). - Uniformiser le séparateur (tiret ou underscore), bannir l’espace pleine largeur U+3000.
- Sur OneDrive/SharePoint, éviter les cascades de sous‑dossiers très profonds.
FAQ
Pourquoi l’ouverture via « Fichier > Ouvrir » marche alors que le double‑clic échoue ?
Le chemin est parfois résolu différemment selon la méthode d’appel (Shell vs. dialogue interne), et certaines transitions d’encodage n’affectent pas les deux parcours de la même façon.
Changer la locale système va‑t‑il traduire l’interface Windows en japonais ?
Non. La locale système ne modifie pas la langue de l’interface ; elle définit la page de codes utilisée par les programmes non‑Unicode.
Activer l’UTF‑8 bêta est‑il sûr ?
Dans la majorité des environnements modernes, oui. Testez néanmoins vos applications historiques ; quelques‑unes supposent encore une page de codes spécifique.
Quid des partages réseau (UNC) ?
Les serveurs et NAS hérités peuvent ajouter une couche de normalisation (NFD/NFC, code pages). Appliquez les mêmes règles : pas de double‑octet, pas d’espace pleine largeur, chemins courts.
Ce problème touche‑t‑il Word/PowerPoint ?
Le déclencheur est lié au chemin et à la façon dont l’application l’ouvre ; des cas comparables ont été observés de manière plus rare. Les mêmes remèdes (noms ASCII, locale/UTF‑8) aident.
Existe‑t‑il un correctif officiel ?
Les cas ont émergé à partir de mi‑novembre 2024. En pratique, les trois leviers renommage + locale système (ou UTF‑8) + réparation en ligne résolvent l’erreur dans l’immense majorité des situations rapportées.
Résumé exécutable
- Urgence : renommez le fichier/le chemin pour éliminer tout caractère double‑octet (y compris espace U+3000).
- Confort : ouvrez via Excel > Fichier > Ouvrir si le double‑clic échoue.
- Pérennité : changez la locale système – Japonais ou activez UTF‑8, puis redémarrez.
- Hygiène : réparez Microsoft 365 en ligne si l’intégration Shell/Office semble corrompue.
- Prévention : chemins < 218 caractères, pas de caractères réservés, conventions de nommage stables.
Historique et contexte
Les incidents ont démarré autour du 16 novembre 2024 à la suite d’une mise à jour Office ayant modifié la gestion des noms non‑Unicode dans certains enchaînements (notamment à l’ouverture par double‑clic). Le comportement varie selon la build et l’environnement (locale, compléments, OneDrive). Les recommandations ci‑dessus demeurent valables : standardiser les noms, stabiliser l’encodage et réparer Office si nécessaire.
En attendant (ou en complément de) toute correction côté éditeur, le trio renommage + locale système (ou UTF‑8) + réparation en ligne élimine quasi systématiquement l’erreur « The file could not be accessed » et sécurise vos ouvertures de classeurs Excel, en local comme via OneDrive.