Après la mise à jour 16.0.17928.20114 (canal Current, 2408), Microsoft Access 365 devient instable : erreurs aléatoires, verrouillage .laccdb et processus MSACCESS.EXE qui ne se termine pas. Voici les symptômes, un diagnostic clair et des solutions concrètes (contournements, rollback, correctif 17928.20156).
Vue d’ensemble du problème
Suite à l’installation du build 16.0.17928.20114 d’Office Microsoft 365 (canal Current, mise à jour 2408), de nombreux environnements constatent un comportement anormal d’Access :
- Messages d’erreur imprévisibles (« mémoire insuffisante », « ressources système insuffisantes », erreurs de compilation VBA sans cause apparente, disparition du volet de navigation, etc.).
- Verrouillage persistant du fichier
.accdbet de son.laccdb: impossible de renommer, compacter/réparer ou fermer proprement la base. - Processus résiduel
MSACCESS.EXEqui reste en arrière‑plan après fermeture, empêchant la réouverture correcte de la base et entraînant des verrous « fantômes ». - Reproductibilité : le phénomène survient même sur d’autres fichiers, y compris une base vierge.
- Portée : Excel, PowerPoint et Word ne sont pas concernés.
Bonne nouvelle : aucune corruption durable de fichier n’a été mise en évidence. Le dysfonctionnement tient au cycle de fermeture d’Access dans ce build et se corrige par mise à jour ou rollback.
Tableau récapitulatif des solutions
Commencez par la mise à jour corrective si elle est disponible. À défaut, déroulez les options de repli et les contournements ci‑dessous.
| Horizon | Mesures proposées | Détails |
|---|---|---|
| Immédiat (contournements) | Travail hors volet d’aperçu, fermeture manuelle du processus résiduel, démarrage en mode sans échec d’Access, désactivation provisoire des compléments COM. | Réduit l’apparition du verrou .laccdb et évite qu’MSACCESS.EXE reste actif. Utile pendant l’attente d’un correctif ou d’un rollback. |
| Réparer Office (Applications > Microsoft 365 > Modifier) | Effectuez d’abord une Réparation rapide, puis une Réparation en ligne si nécessaire. Efficace chez certains utilisateurs, non garanti. | |
| Démarrage « Clean Boot » de Windows | Écarte l’influence de services/logiciels tiers (antivirus, outils d’aperçu, DLP, etc.) susceptibles d’aggraver les verrous de fichiers. | |
| Temporaire (repli) | Rétrograder Office vers une build stable antérieure (ex. 16.0.17726.20160 ou dernière build de juillet 2024) | Commande Click‑to‑Run :cd %programfiles%\Common Files\Microsoft Shared\ClickToRunofficec2rclient.exe /update user updatetoversion=16.0.17726.20160Puis désactivez les mises à jour automatiques jusqu’à déploiement du correctif. |
| Définitif (correctif officiel) | Installer le build 16.0.17928.20156 (publié le 10 septembre 2024 dans le canal Current) | Intègre la correction du bug. Une fois installé, réactivez les mises à jour automatiques et vérifiez la version dans Access : Fichier > Compte > À propos d’Access. |
| Suivi & informations | Consulter les retours de la communauté (rubrique « Bugs », ex. AccessForever.org) | Utile pour l’état du déploiement du correctif, les retours d’expérience et variantes de symptômes. (Ne pas oublier d’aligner la build sur tous les postes d’un même groupe de travail.) |
Diagnostiquer proprement avant d’agir
Vérifier la version exacte d’Office/Access
- Ouvrez Access (si possible). Allez dans Fichier > Compte et cliquez sur À propos d’Access. Notez le numéro de version et le canal.
- Si Access refuse de s’ouvrir, tapez
winverdans Windows + R pour vérifier Windows, puis utilisez la commande PowerShell ci‑dessous pour Office (administrateur) :PowerShell Get-ItemProperty -Path "HKLM:\Software\Microsoft\Office\ClickToRun\Configuration" ` | Select-Object -ExpandProperty VersionToReport
Identifier un processus fantôme MSACCESS.EXE
- Fermez Access. Ouvrez le Gestionnaire des tâches et vérifiez l’onglet Processus : si
MSACCESS.EXEpersiste, c’est un résidu. - En ligne de commande (administrateur) :
tasklist /fi "imagename eq MSACCESS.EXE" taskkill /f /im MSACCESS.EXE - Si le fichier
.laccdbdemeure, attendez 5 à 10 s après l’arrêt du processus ; si tous les utilisateurs ont quitté la base, le verrou devrait disparaître. À défaut, redémarrez la machine concernée.
Écarter les facteurs aggravants
- Explorateur Windows : désactivez le volet d’aperçu (Affichage > Volet d’aperçu) pour éviter qu’Explorer ne verrouille les fichiers Access.
- Antivirus/DLP : ajoutez temporairement des exclusions sur les répertoires de vos bases (test contrôlé) afin d’observer l’impact.
- Compléments COM : lancez Access en « mode sans échec » (
MSACCESS.EXE /safe) et désactivez tout complément non essentiel. - Réseau : si la base est partagée, vérifiez que tous les postes opèrent sur la même build (corrigée ou rétrogradée).
Procédure recommandée : ordre de priorité
- Mettre Office à jour vers le build corrigé 16.0.17928.20156 si disponible dans votre canal.
- Si non disponible, désactiver les mises à jour et rétrograder vers 16.0.17726.20160 (ou la dernière build de juillet 2024) en Click‑to‑Run.
- Appliquer les contournements (fermeture manuelle du processus, travail sans aperçu, Clean Boot, etc.) le temps de la bascule.
Mettre à jour Access vers la build corrigée (17928.20156)
Pour les installations Microsoft 365 Apps (abonnement) :
- Dans Access, allez à Fichier > Compte, puis Options de mise à jour > Mettre à jour maintenant.
- Patientez jusqu’à la fin du processus, puis redémarrez Access et vérifiez À propos d’Access.
- Après installation, réactivez les mises à jour automatiques si vous les aviez coupées.
Astuce : si la mise à jour n’apparaît pas encore selon votre canal ou politique IT, passez temporairement au repli (rollback) ci‑dessous.
Repli contrôlé : rollback Click‑to‑Run
Le rollback restaure une build antérieure connue pour sa stabilité. Cette opération doit être effectuée avec prudence et, idéalement, en horaires creux.
- Fermez toutes les applications Office et tuez tout processus résiduel (
taskkill /f /im MSACCESS.EXE). - Ouvrez une invite de commandes en administrateur et exécutez :
cd "%ProgramFiles%\Common Files\Microsoft Shared\ClickToRun" officec2rclient.exe /update user updatetoversion=16.0.17726.20160 - Au besoin, désactivez les mises à jour automatiques dans Fichier > Compte > Options de mise à jour pour stabiliser le parc jusqu’au correctif.
- Après le déploiement du correctif, réactivez les mises à jour et remontez vers la build corrigée.
Bonnes pratiques IT : alignez la version sur tous les postes connectés à une base partagée (front‑end/back‑end). Un mélange de builds peut multiplier les verrous et effets de bord.
Contournements fiables en environnement de production
Désactiver le volet d’aperçu et les miniatures
- Ouvrez l’Explorateur Windows, allez dans Affichage et désactivez « Volet d’aperçu » et « Volet de détails ».
- Dans Options des dossiers, onglet Affichage, cochez Toujours afficher des icônes, jamais des miniatures pour les répertoires contenant des
.accdb.
Fermer proprement MSACCESS.EXE et nettoyer les verrous
- Avant toute suppression du
.laccdb, assurez‑vous que plus aucun utilisateur n’est connecté à la base. - Fermez Access, puis :
taskkill /f /im MSACCESS.EXE - Attendez quelques secondes ; si le
.laccdbpersiste et que vous êtes certain d’être seul, supprimez‑le. Relancez Access et exécutez un Compacter et réparer (copie locale de préférence).
Démarrer Access en mode sans échec
Le mode sans échec évite le chargement de compléments COM potentiellement impliqués.
MSACCESS.EXE /safePuis désactivez les compléments via Fichier > Options > Compléments > en bas « Gérer : Compléments COM » > Atteindre.
Effectuer un « Clean Boot » Windows
- Lancez
msconfig, onglet Services : cochez Masquer tous les services Microsoft puis Désactiver tout. - Ouvrez le Gestionnaire des tâches > onglet Démarrage et désactivez les éléments non essentiels.
- Redémarrez, testez Access. Si le problème disparaît, réactivez par lot pour identifier l’élément déclencheur.
Procédures détaillées pour administrateurs
Sécuriser un poste avant rollback
- Créer un point de restauration et une sauvegarde de tout répertoire hébergeant des bases Access (y compris les éventuels back‑ends
.accdbou.mdb). - Informer les utilisateurs de la fenêtre d’indisponibilité et de la nécessité de fermer Access pendant l’opération.
- Vérifier l’intégrité réseau (latence/partages). Les partages instables augmentent le risque de verrous persistants.
Scripts utiles (PowerShell)
Afficher la version Office et le canal Click‑to‑Run :
PowerShell
$cfg = Get-ItemProperty -Path "HKLM:\Software\Microsoft\Office\ClickToRun\Configuration"
$cfg.VersionToReport
$cfg.UpdateChannelForcer l’arrêt d’Access et vérifier ensuite :
PowerShell
Stop-Process -Name MSACCESS -Force -ErrorAction SilentlyContinue
Get-Process MSACCESS -ErrorAction SilentlyContinueExemple de rollback encapsulé :
PowerShell
$ctr = "$env:ProgramFiles\Common Files\Microsoft Shared\ClickToRun"
Start-Process "$ctr\officec2rclient.exe" -ArgumentList '/update user updatetoversion=16.0.17726.20160' -Wait -Verb runAsBonnes pratiques Access pour limiter les risques
- Front‑end / Back‑end : séparez l’interface (front) et les données (back) et distribuez un front local par utilisateur pour réduire les verrous réseau.
- Temp : veillez à ce que chaque poste dispose d’un dossier
%TEMP%sain et accessible (nettoyage régulier). - OneDrive/SharePoint : évitez d’ouvrir une base Access directement depuis un dossier synchronisé ; travaillez sur une copie locale ou utilisez un back‑end approprié.
- Contrôles ActiveX et compléments : limitez‑les au strict nécessaire, tenez‑les à jour.
- Compact & Repair : planifiez‑le hors production (sur copie) après toute séquence d’incident.
FAQ rapide
Ce bug corrompt‑il mes bases ?
Aucun signal de corruption irréversible n’a été établi. Les symptômes relèvent d’un défaut de fermeture/gestion de verrous. Par prudence, travaillez sur des copies lors des opérations de maintenance.
Pourquoi Excel/Word/PowerPoint ne sont pas touchés ?
Le problème se manifeste dans le cycle de vie d’Access (MSACCESS.EXE) et sa gestion des verrous, distincte des autres applications Office.
Je ne vois pas la build 17928.20156 dans les mises à jour ; que faire ?
Selon votre canal/politiques IT, elle peut être décalée. Utilisez le rollback temporaire (17726.20160 ou une build de juillet 2024) puis remontez quand le correctif est disponible.
Puis‑je supprimer un .laccdb à la main ?
Oui uniquement si vous êtes absolument certain qu’aucun poste n’est connecté. Sinon, vous risquez de couper une session valide.
Les performances se dégradent après l’incident.
Nettoyez %TEMP%, exécutez Compacter et réparer (sur copie), et vérifiez que tous les postes sont sur la même build.
Checklist d’intervention
| Étape | Action | Validation |
|---|---|---|
| 1 | Vérifier la version et le canal d’Access | Capture d’écran À propos d’Access archivée |
| 2 | Couper les mises à jour automatiques (temporairement) | Option grisée dans Compte |
| 3 | Mettre à jour vers 17928.20156 ou rollback vers 17726.20160 | Numéro de build confirmé |
| 4 | Désactiver volet d’aperçu / compléments COM | Reproduction des tests sans verrou |
| 5 | Assainir .laccdb et compacter (sur copie) | Ouverture/fermeture propre, aucune persistance |
| 6 | Réactiver les mises à jour une fois stabilisé | Politique conforme, parc homogène |
Modèle de communication vers les utilisateurs
Sujet : Incident Access – verrous de fichiers et fermeture incomplète
Bonjour, un bug dans la mise à jour 16.0.17928.20114 d’Office a pu empêcher Access de se fermer correctement, entraînant des verrous. Notre équipe applique [mise à jour 17928.20156 / rollback contrôlé]. Merci de fermer Access pendant la maintenance. Un message suivra une fois la situation résolue.
Points d’attention en environnement partagé
- Uniformité de version : imposez la même build pour tous les membres d’un même service utilisant la base.
- Latence et instabilité réseau : elles amplifient les symptômes (verrous persistants quand un poste se « fige » avec un
MSACCESS.EXErésiduel). - Ouverture simultanée dans l’Explorateur : éviter de laisser des fenêtres Explorer ouvertes sur le dossier de la base avec un volet d’aperçu actif.
Cas pratiques et exemples
Cas 1 : base locale monoposte
Les erreurs « mémoire insuffisante » apparaissent au bout de quelques minutes. Après fermeture, MSACCESS.EXE reste présent. Décision : mise à jour vers 17928.20156. Résultat : disparition des messages et fermeture instantanée du processus.
Cas 2 : base partagée sur serveur de fichiers
Après déploiement 17928.20114, des .laccdb persistent. Deux postes sur 17928.20114, trois postes sur 17726.20160. Décision : rollback global vers 17726.20160 en attendant le correctif, puis montée coordonnée vers 17928.20156. Résultat : plus de verrous fantômes et stabilité retrouvée.
Cas 3 : environnement avec compléments
Un complément COM de suivi documentaire retarde la fermeture d’Access. En 17928.20114, le délai déclenche un processus résiduel. Décision : MSACCESS.EXE /safe puis désactivation du complément, test ok, mise à jour 17928.20156, réactivation progressive.
Résumé exécutable
- Symptômes clés : erreurs aléatoires, processus résiduel,
.laccdbpersistant. - Action n°1 : mettre à jour vers 16.0.17928.20156.
- Action n°2 : sinon, rollback vers 16.0.17726.20160 et désactiver les mises à jour automatiques.
- Contournements : pas de volet d’aperçu,
taskkill, mode sans échec, Clean Boot, compléments COM off. - Réseau : alignez les builds sur tous les postes et sauvegardez avant toute manipulation.
Annexe : commandes et raccourcis
| Objectif | Commande | Remarques |
|---|---|---|
| Tuer Access | taskkill /f /im MSACCESS.EXE | Ferme tout processus résiduel d’Access. |
| Lancer en mode sans échec | MSACCESS.EXE /safe | Sans compléments ni personnalisations. |
| Rollback Click‑to‑Run | officec2rclient.exe /update user updatetoversion=16.0.17726.20160 | Exécuter depuis %ProgramFiles%\Common Files\Microsoft Shared\ClickToRun. |
| Version Office (PowerShell) | (Get-ItemProperty "HKLM:\Software\Microsoft\Office\ClickToRun\Configuration").VersionToReport | Requiert PowerShell en administrateur. |
Conclusion
Le build 16.0.17928.20114 d’Office Microsoft 365 introduit un dysfonctionnement spécifique à Access : erreurs sporadiques, verrous tenaces et processus MSACCESS.EXE qui ne se ferme pas. La voie royale est la mise à jour vers 16.0.17928.20156. En attendant, un rollback vers 16.0.17726.20160, couplé aux contournements (pas de volet d’aperçu, fermeture forcée du processus, compléments désactivés, Clean Boot), permet de poursuivre l’exploitation en sécurité. Sauvegardez vos bases, harmonisez la build sur tous les postes et documentez chaque étape : vous retrouverez une Access stable et prévisible.
Note pratique : pour suivre l’état d’avancement et les retours d’expérience, référez‑vous aux communautés spécialisées (ex. AccessForever.org – rubrique « Bugs »). Même sans lien direct, ces sources sont précieuses pour anticiper les variations de comportement selon les canaux de mise à jour.