Ouvrir un fichier Excel VBA en lecture seule : sécuriser vos données en quelques lignes

Ouvrir un fichier Excel VBA en lecture seule avec Workbooks.Open et son paramètre ReadOnly:=True reste la méthode la plus directe pour empêcher une macro d’écraser des données par erreur. Le réflexe est ancien, documenté sur la page officielle Microsoft Learn, et fonctionne en quelques lignes. Le problème, c’est que cette ligne de code ne protège rien du tout contre une modification volontaire, et que l’environnement Microsoft 365 a déplacé les vrais leviers de sécurité bien au-dessus du classeur lui-même.

Lecture seule VBA et chiffrement AES-256 : deux niveaux de protection distincts

La confusion la plus répandue dans les tutoriels consiste à traiter la lecture seule comme un mécanisme de sécurité. Le paramètre ReadOnly de Workbooks.Open indique à Excel d’ouvrir le fichier sans verrouiller l’accès en écriture pour les autres utilisateurs. L’utilisateur peut toujours copier le contenu, enregistrer sous un autre nom ou modifier le fichier localement.

Les guides pratiques récents distinguent deux catégories. La première, qualifiée de « convenience », regroupe Mark as Final et le mot de passe de modification : ce sont des barrières d’intention, pas de sécurité. La seconde repose sur le chiffrement du fichier via « Encrypt with Password », qui applique un algorithme AES-256 rendant le contenu illisible sans la clé.

En VBA, la syntaxe pour ouvrir un classeur protégé par mot de passe de modification ressemble à ceci :

Workbooks.Open Filename:="C:\Dossier\Rapport.xlsx", ReadOnly:=True, WriteResPassword:="motdepasse"

Le paramètre WriteResPassword déverrouille l’accès en écriture si le mot de passe est correct. Sans lui, Excel bascule automatiquement en lecture seule. En revanche, un fichier chiffré par AES-256 exige le paramètre Password, qui correspond au mot de passe d’ouverture, pas de modification.

Workbooks.Open ReadOnly face aux contrôles d’accès OneDrive et SharePoint

Depuis quelques années, la protection en lecture seule migre vers la couche de partage OneDrive et SharePoint. Un lien de partage configuré en « Can view » (consultation uniquement, option « Allow editing » désactivée) interdit la modification du fichier côté serveur, quel que soit le code VBA exécuté côté client.

Cette bascule change la donne pour les développeurs VBA. Trois scénarios coexistent :

• Le fichier est stocké localement : ReadOnly:=True fonctionne comme prévu, le classeur s’ouvre sans verrouillage, mais rien n’empêche un SaveAs ultérieur dans la macro.
• Le fichier est sur SharePoint avec un lien « Can view » : Excel l’ouvre en lecture seule indépendamment du paramètre VBA. Toute tentative d’écriture via la macro échoue avec une erreur runtime.
• Le fichier est sur OneDrive avec co-édition active : le paramètre ReadOnly n’empêche pas un autre utilisateur de modifier le fichier en parallèle. La lecture seule ne concerne que la session VBA locale.

La conséquence pratique est directe : piloter la sécurité uniquement depuis le code VBA ne suffit plus dans un environnement cloud. Le contrôle d’accès au niveau de la plateforme prime sur la déclaration d’intention du paramètre ReadOnly.

Lecture seule subie : quand Excel force le mode sans que le code le demande

Les retours de support Microsoft signalent une augmentation des cas où Excel ouvre des fichiers en lecture seule pour des raisons sans rapport avec le code VBA. Licence Office non activée, mode protégé (Protected View) déclenché par un fichier téléchargé depuis Internet, stockage OneDrive saturé, ou verrouillage résiduel par une session précédente qui ne s’est pas fermée proprement.

Cette « lecture seule subie » crée une zone grise que les tutoriels classiques ignorent. Une macro qui ouvre un classeur avec ReadOnly:=False peut se retrouver en lecture seule malgré tout, sans lever d’erreur explicite. Le fichier s’ouvre, le code s’exécute, mais l’appel à .Save échoue silencieusement ou déclenche une boîte de dialogue inattendue.

Pour détecter cette situation dans le code, il faut tester la propriété ReadOnly du classeur après ouverture :

If Workbooks("Rapport.xlsx").ReadOnly Then MsgBox "Fichier ouvert en lecture seule - vérifiez vos droits"

Tester systématiquement l’état ReadOnly après ouverture permet d’éviter des écritures silencieusement perdues. Sans ce contrôle, une macro peut tourner pendant plusieurs minutes avant d’échouer à l’enregistrement.

Articuler le code VBA avec la gouvernance Microsoft 365

Les organisations qui utilisent Microsoft 365 E3 ou E5 disposent de labels de rétention et de stratégies de protection des données (DLP) qui s’appliquent aux fichiers Excel indépendamment de toute macro. Un label de confidentialité peut chiffrer un classeur, restreindre l’impression, interdire le copier-coller, et tout cela sans que le développeur VBA n’ait à écrire une seule ligne.

Le rôle du code VBA change dans ce contexte. Il ne porte plus la responsabilité de la sécurité du fichier. Sa fonction se limite à :

• Ouvrir le classeur en lecture seule pour éviter les conflits d’accès lors d’un traitement batch.
• Lire et extraire des données sans modifier la source.
• Détecter les restrictions appliquées par la plateforme et adapter le comportement de la macro (mode dégradé, message d’erreur explicite, journalisation).

Confier la sécurité au label Microsoft 365 et la logique métier au code VBA produit une séparation nette des responsabilités. Le VBA gère le flux de travail, la plateforme gère la protection.

Erreurs fréquentes dans l’articulation code/plateforme

Stocker un mot de passe en clair dans le code VBA pour alimenter le paramètre Password ou WriteResPassword est la faille la plus courante. Le code source d’un module VBA est lisible par quiconque accède au fichier, même avec une protection du projet VBA (qui reste contournable avec des outils tiers).

Autre piège : forcer ReadOnly:=False sur un fichier partagé en lecture seule via SharePoint. La macro semble fonctionner localement, mais les modifications ne se synchronisent jamais. Aucune erreur n’est levée dans certaines configurations, ce qui donne l’illusion que le traitement s’est déroulé correctement.

La lecture seule en VBA reste un outil utile pour structurer le flux d’une macro, éviter les verrouillages de fichiers en réseau et signaler une intention de non-modification. Elle n’a jamais été conçue comme un dispositif de sécurité, et l’écosystème Microsoft 365 rend cette distinction plus visible que jamais. Le réflexe à adopter : écrire ReadOnly:=True pour la logique du code, et configurer les droits d’accès sur la plateforme pour la protection réelle des données.