VBA Protect Sheet dans Excel — verrouiller une feuille sans bloquer vos cellules de saisie

TL;DR — Worksheet.Protect ne décide pas quelles cellules sont verrouillées. C'est un interrupteur maître qui active l'étiquette Locked déjà posée sur chaque cellule — et chaque cellule est Locked = True par défaut. Protéger une feuille sans préparation fige donc tout, y compris les cellules que vos utilisateurs sont censés remplir. Le vrai flux de travail est inversé : déverrouillez d'abord les cellules de saisie, puis protégez la feuille. La protection bloque aussi vos propres macros à moins de passer UserInterfaceOnly:=True, et cet indicateur n'est pas enregistré avec le fichier — vous le ré-appliquez à chaque Workbook_Open.

Sub LockDownForm()
    Dim ws As Worksheet
    Set ws = ThisWorkbook.Worksheets("Form")

    ws.Cells.Locked = True                 ' tout demarre verrouille de toute facon - soyez explicite
    ws.Range("C4:C12").Locked = False      ' deverrouillez UNIQUEMENT les cellules de saisie
    ws.Protect Password:="ac", AllowFiltering:=True   ' basculez maintenant l'interrupteur maitre
End Sub

Protect est le code derrière Révision ▸ Protéger la feuille. C'est l'une des lignes de finition les plus courantes dans une macro qui construit un formulaire ou un rapport, et aussi l'une des plus mal comprises — parce qu'on attend d'elle qu'elle verrouille « les cellules qui m'intéressent » alors qu'en réalité elle verrouille chaque cellule porteuse d'une étiquette Locked, et Excel pose cette étiquette sur toutes dès qu'une feuille naît. Dès que vous voyez Protect comme un interrupteur qui fait respecter une décision que les cellules portent déjà, plutôt que comme ce qui prend la décision, chaque comportement surprenant tombe sous le sens.

Ce que vous allez apprendre

• Le modèle mental — Protect est un interrupteur qui fait respecter l'étiquette Locked, il ne la choisit pas
• La règle qui évite la plupart des bugs — déverrouillez les cellules de saisie d'abord, puis protégez
• Pourquoi Protect sans argument bloque aussi le filtrage, le tri et la mise en forme
• Pourquoi une feuille protégée casse vos propres macros, et ce que fait vraiment UserInterfaceOnly:=True
• Pourquoi cet indicateur disparaît à l'enregistrement, et où le ré-appliquer
• Pourquoi le mot de passe est un garde-fou contre les accidents, pas une vraie sécurité

Le modèle mental : un interrupteur, pas une décision

Voyez la protection comme deux choses distinctes que l'on confond sans cesse. La décision — « quelles cellules un utilisateur peut-il modifier ? » — vit sur chaque cellule dans sa propriété Locked. L'application — « commence à faire respecter ces décisions maintenant » — c'est Worksheet.Protect. L'interrupteur ne lit pas vos intentions ; il lit l'indicateur Locked déjà présent sur chaque cellule, et par défaut cet indicateur vaut True partout.

Ce simple fait explique la plainte numéro un au sujet de la protection de feuille, qui est l'exact opposé de ce qu'attendent les débutants. On suppose qu'un ws.Protect sans préparation ne verrouille rien, ou verrouille « les cellules importantes ». Il les verrouille toutes, parce qu'elles sont toutes nées verrouillées. La surprise n'est donc jamais « ma protection n'a pas marché » — c'est « ma protection a trop bien marché et maintenant personne ne peut rien taper ».

La règle qui compte le plus : déverrouiller les cellules de saisie d'abord, puis protéger

Comme chaque cellule vaut Locked = True par défaut, le bon schéma n'est pas « verrouiller les cellules que je veux protéger ». C'est « déverrouiller les quelques cellules que je veux laisser ouvertes, puis protéger le reste ». Vous marquez les exceptions, pas les cibles :

ws.Cells.Locked = True              ' la valeur par defaut, enoncee pour le prochain lecteur
ws.Range("C4:C12").Locked = False   ' la colonne de saisie - les SEULES cellules modifiables
ws.Protect Password:="ac"           ' faites-la respecter

Faites-le dans l'ordre inverse et vous obtenez l'échec classique. Appelez ws.Protect sur une feuille neuve puis tentez ws.Range("C4").Locked = False : la deuxième ligne déclenche l'erreur d'exécution 1004 — vous ne pouvez pas changer l'état Locked d'une cellule tant que la feuille est protégée. Les étiquettes Locked doivent être posées pendant que la feuille est non protégée ; Protect est toujours la dernière étape, une fois terminée la carte de qui-peut-modifier-quoi. Voilà tout cet ensemble en une phrase : Locked est la carte, Protect active l'application.

Protect sans argument verrouille plus que vous ne le pensez

ws.Protect a l'air d'un simple marche/arrêt, mais il prend une longue liste d'arguments, et ses valeurs par défaut sont restrictives. Sans argument, une feuille protégée empêche aussi les utilisateurs de trier, filtrer, mettre en forme, et d'insérer ou supprimer des lignes et des colonnes — même dans des cellules déverrouillées. C'est la source de la deuxième plainte la plus fréquente : « j'ai protégé la feuille et maintenant les listes déroulantes d'AutoFilter sont mortes ».

Les arguments sont un menu d'autorisations. Réactivez exactement ce dont la feuille a besoin :

ws.Protect Password:="ac", _
    AllowFiltering:=True, _
    AllowSorting:=True, _
    AllowFormattingCells:=True

Il y a un piège à connaître : AllowFiltering:=True laisse les utilisateurs se servir des listes déroulantes d'AutoFilter qui existent déjà, mais pas en créer de nouvelles — appliquez donc l'AutoFilter avant de protéger. Le bon réflexe ici est de protéger avec intention : partez de « tout est bloqué » et activez les interactions précises que cette feuille est censée permettre, plutôt que de livrer les valeurs par défaut restrictives et d'essuyer les plaintes.

Le piège qui mord tout auteur de macro : la protection bloque votre propre code

Voici celui qui transforme une macro qui marche en erreur d'exécution 1004 le lendemain de l'ajout de la protection. Une feuille protégée ne fait pas la différence entre un utilisateur qui tape et votre VBA qui écrit — elle bloque les deux. Une routine qui faisait tranquillement ws.Range("A1").Value = 42 se met donc à échouer dès l'instant où la feuille est protégée, parce que votre propre code est désormais traité comme un intrus.

Le correctif, c'est l'argument UserInterfaceOnly :

ws.Protect Password:="ac", UserInterfaceOnly:=True

Avec UserInterfaceOnly:=True, la feuille est protégée contre l'interface utilisateur — clics et saisie — mais vos macros peuvent encore la modifier librement, sans valse Unprotect/Protect autour de chaque écriture. C'est la façon la plus propre de garder une feuille verrouillée pour les gens pendant que votre code continue de fonctionner. Mais il y a un revers, et c'est la section suivante.

Pourquoi UserInterfaceOnly disparaît quand vous enregistrez

UserInterfaceOnly:=True n'est pas enregistré avec le classeur. Quand le fichier est fermé puis rouvert, la feuille revient entièrement protégée — contre vos macros aussi — comme si vous n'aviez jamais passé l'indicateur. La protection persiste ; la partie « mais laisse passer mon code » non. Voilà pourquoi une macro marche toute la session puis déclenche 1004 le lendemain matin, à la stupéfaction générale.

Le correctif est de ré-appliquer la protection avec l'indicateur à chaque ouverture du classeur :

' Dans le module ThisWorkbook
Private Sub Workbook_Open()
    Worksheets("Form").Protect Password:="ac", UserInterfaceOnly:=True
End Sub

Cela rétablit au chargement l'état « protégé pour les utilisateurs, ouvert au code » sans rien déprotéger ni perturber la carte Locked. Considérez-le comme le compagnon obligatoire de toute protection UserInterfaceOnly : si vous comptez le moins du monde sur l'indicateur, vous comptez sur Workbook_Open pour le rétablir. Voir Workbook_Open pour la mécanique de l'événement.

Le mot de passe est un garde-fou, pas un verrou

L'argument Password a des airs de sécurité, et il vaut la peine d'être honnête sur ce qu'il n'est pas. Les mots de passe de protection de feuille utilisent un chiffrement faible et bien documenté ; ils sont retirés en un rien de temps par quantité d'outils, et peuvent être réinitialisés entièrement hors d'Excel. Traitez le mot de passe comme un garde-fou — il empêche un collègue de cliquer distraitement dans vos formules ou d'écraser un modèle — pas comme un coffre-fort pour quoi que ce soit de confidentiel. Si les données doivent vraiment rester secrètes, la protection de feuille est le mauvais outil ; ne les mettez pas dans le fichier. Et gardez le mot de passe en lieu sûr : VBA sait Protect et Unprotect avec un mot de passe que vous connaissez, mais il ne peut pas en récupérer un que vous avez oublié.

Comment ExcelMaster vous aide

La protection est un système en deux temps qui se lit à l'envers, et il échoue de façons qui ne déclenchent jamais d'erreur à l'instant où vous vous trompez — vous bloquez toutes les cellules de saisie parce qu'elles étaient verrouillées par défaut, vous livrez une feuille « en lecture seule » dont les filtres sont morts, ou votre propre macro déclenche 1004 le lendemain matin parce que UserInterfaceOnly a été perdu à l'enregistrement.

ExcelMaster vous laisse dire ce que vous voulez vraiment — « verrouille ce modèle mais laisse les gens remplir les cellules jaunes et se servir encore des filtres » — et il écrit les étapes déverrouiller-puis-protéger dans le bon ordre, active les autorisations AllowXxx dont la feuille a besoin, ajoute UserInterfaceOnly:=True avec un Workbook_Open pour la garder vivante d'un enregistrement à l'autre, et vous dit clairement que le mot de passe protège des accidents, pas d'un lecteur déterminé. Vous gardez le classeur et le code.

Questions fréquentes

Pourquoi plus personne ne peut rien taper après que j'ai protégé la feuille en VBA ?

Parce que chaque cellule vaut Locked = True par défaut, ws.Protect verrouille donc toute la feuille. La protection ne choisit pas « les cellules importantes » — elle fait respecter l'étiquette Locked déjà présente sur toutes. Mettez Locked = False sur votre plage de saisie avant de protéger : ws.Range("C4:C12").Locked = False, puis ws.Protect. Déverrouillez les exceptions, puis basculez l'interrupteur.

Comment protéger une feuille avec un mot de passe en VBA ?

Passez l'argument Password : ws.Protect Password:="ac". Pour ôter la protection, fournissez le même mot de passe : ws.Unprotect Password:="ac". Gardez le mot de passe dans votre code ou en lieu sûr — VBA ne peut pas en récupérer un oublié. Et traitez-le comme un garde contre les accidents, pas comme une sécurité : les mots de passe de protection de feuille se retirent en un rien de temps et ne doivent jamais être chargés de garder cachées des données confidentielles.

Pourquoi ma macro reçoit-elle l'erreur 1004 sur une feuille protégée ?

Une feuille protégée bloque vos écritures VBA exactement comme elle bloque un utilisateur. Protégez avec UserInterfaceOnly:=True pour que la feuille reste verrouillée pour les gens pendant que votre code peut encore la modifier. Notez que cet indicateur n'est pas enregistré avec le classeur : ré-appliquez-le donc dans un événement Workbook_Open — Worksheets("Form").Protect Password:="ac", UserInterfaceOnly:=True — sinon la macro échouera après réouverture du fichier.

Comment garder le filtrage et le tri fonctionnels sur une feuille protégée ?

Par défaut, Protect les bloque. Réactivez-les avec les arguments : ws.Protect AllowFiltering:=True, AllowSorting:=True. AllowFiltering:=True laisse les utilisateurs manœuvrer les listes déroulantes d'AutoFilter qui existent déjà, mais pas en créer de nouvelles — appliquez donc l'AutoFilter avant de protéger. Ajoutez AllowFormattingCells:=True et les autres indicateurs AllowXxx pour toute interaction dont la feuille a encore besoin.

Quelle est la différence entre protéger une feuille et protéger le classeur ?

Worksheet.Protect empêche de modifier les cellules d'une feuille. Workbook.Protect verrouille la structure du classeur — il empêche d'ajouter, supprimer, renommer, déplacer ou masquer des feuilles — et ne touche en rien au contenu des cellules. Ils résolvent des problèmes différents : la protection de feuille garde la saisie de données, la protection de classeur garde la disposition des onglets. On utilise souvent les deux sur un modèle terminé.

Testé dans

Testé dans : Excel 365 (Windows 11), VBA 7.1 — vérifié le 11/09/2026.

Guides associés : VBA Unprotect · VBA Verrouiller les cellules · VBA Workbook_Open · VBA AutoFilter · VBA Range