VBA Unprotect dans Excel — ôter la protection d'une feuille en toute sécurité (et le piège du mot de passe)

TL;DR — Worksheet.Unprotect, c'est l'interrupteur maître mis sur arrêt. Il empêche Excel de faire respecter les étiquettes Locked, mais il ne touche pas à ces étiquettes — ôter la protection d'une feuille ne déverrouille pas ses cellules, il cesse simplement d'honorer les verrous pour l'instant. Si la feuille a été protégée avec un mot de passe, vous devez passer exactement le même, sinon vous obtenez l'erreur d'exécution 1004 (mauvais mot de passe) ou une boîte de dialogue modale qui bloque une macro sans surveillance. Presque toute macro d'édition enveloppe son travail dans un sandwich ôter la protection ▸ modifier ▸ protéger — et la seule règle qui compte est : reprotégez dans un gestionnaire d'erreurs, pour qu'un plantage ne laisse jamais la feuille ouverte.

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

    ws.Unprotect Password:="ac"          ' coupe l'application (mot de passe exact)
    On Error GoTo ReLock                 ' quoi qu'il arrive ensuite...
    ws.Range("C4:C12").ClearContents     ' ...faire le travail...
ReLock:
    ws.Protect Password:="ac"            ' ...toujours la remettre en marche
End Sub

Unprotect est le code derrière Révision ▸ Ôter la protection de la feuille, et c'est le premier geste obligé dès qu'une macro doit écrire sur une feuille que vous avez verrouillée. Il a l'air anodin — une ligne, un argument facultatif — et il l'est, jusqu'au moment où la feuille a un mot de passe ou bien où la macro échoue à mi-parcours. Chacun de ces deux cas transforme un une-ligne en ticket de support. Le modèle mental qui vous évite les ennuis, c'est qu'Unprotect est temporaire et va par paire : vous retirez le verrou pour faire un travail, et c'est à vous de le remettre.

Ce que vous allez apprendre

Le modèle mental — Unprotect désactive l'application, il ne change pas les étiquettes Locked
La seule règle qui compte — reprotéger dans un gestionnaire d'erreurs pour qu'un plantage ne laisse jamais la feuille ouverte
Le piège du mot de passe : pourquoi un mot de passe erroné ou absent déclenche 1004 ou se bloque sur une boîte de dialogue
Pourquoi appeler Unprotect sur une feuille déjà ouverte est une opération sans effet inoffensive sur laquelle compter
Comment ôter la protection de chaque feuille d'un classeur en une seule boucle
La limite honnête — VBA ne peut pas récupérer un mot de passe que vous avez oublié

Le modèle mental : interrupteur coupé, étiquettes intactes

La protection tient en deux couches : l'étiquette Locked par cellule (la décision sur qui peut modifier quoi) et Protect/Unprotect (l'interrupteur qui fait respecter ces étiquettes ou les ignore). Unprotect n'agit que sur l'interrupteur. Chaque cellule conserve l'état Locked exact qu'elle avait ; vous avez simplement dit à Excel de cesser de le faire respecter.

C'est important parce qu'on attend d'Unprotect qu'il « ouvre les cellules », puis on est surpris de reprotéger et de retrouver les mêmes cellules verrouillées qu'avant. Rien n'a été déverrouillé — l'application a été suspendue puis reprise. Si vous voulez changer quelles cellules sont modifiables, c'est l'affaire de la propriété Locked pendant que la feuille est non protégée, pas d'Unprotect lui-même.

La règle qui compte le plus : reprotéger dans un gestionnaire d'erreurs

La forme standard de toute macro qui modifie une feuille protégée est un sandwich : ôter la protection, faire le travail, reprotéger. Le danger vit dans la tranche du milieu. Si l'étape « faire le travail » déclenche une erreur — une mauvaise référence, une feuille manquante, une incompatibilité de type — l'exécution s'arrête, le Protect de clôture ne tourne jamais, et la feuille reste grande ouverte. L'utilisateur ferme le fichier sans se douter de rien, et votre modèle soigneusement verrouillé est désormais modifiable par n'importe qui.

Le correctif est de rendre la reprotection inconditionnelle grâce à un gestionnaire d'erreurs, pour qu'elle tourne que le travail réussisse ou explose :

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

    ws.Unprotect Password:="ac"
    On Error GoTo CleanExit
    ' ... le vrai travail, qui peut echouer ...
    ws.Range("C4:C12").ClearContents
CleanExit:
    ws.Protect Password:="ac", UserInterfaceOnly:=True
    If Err.Number <> 0 Then MsgBox "Update failed: " & Err.Description
End Sub

C'est la même discipline CleanExit que toute macro fiable emploie pour fermer des fichiers ou rétablir ScreenUpdating — une étiquette de sortie unique où vit le code qui « remet les choses en place ». Voir gestion des erreurs pour le motif complet. Le jugement est simple : la ligne qui reprotège la feuille ne doit pas être atteignable seulement sur le chemin heureux.

Le piège du mot de passe

Si une feuille a été protégée avec un mot de passe, Unprotect réclame ce mot de passe exact, et se tromper échoue de deux manières différentes et tout aussi agaçantes. Passez le mauvais mot de passe et vous obtenez l'erreur d'exécution 1004, « The password you supplied is not correct ». Ne passez aucun mot de passe à une feuille protégée par mot de passe et, dans une session interactive, Excel affiche la boîte de dialogue de saisie du mot de passe — qui bloque en silence, pour toujours, une macro sans surveillance ou planifiée, parce qu'il n'y a personne pour le taper.

ws.Unprotect Password:="ac"     ' correct : mot de passe exact, s'execute proprement
ws.Unprotect                    ' sur une feuille a mot de passe : ouvre une boite modale - bloque un traitement par lots
ws.Unprotect Password:="wrong"  ' erreur d'execution 1004

La règle qui en découle : une macro automatisée doit toujours passer le mot de passe explicitement, et ne jamais compter sur la présence d'un humain pour répondre à une boîte de dialogue. Si vous protégez avec un mot de passe quelque part, rangez-le dans une constante que votre code de déprotection peut lire, pour que les deux ne divergent jamais.

Ôter la protection d'une feuille ouverte est une opération sans effet sûre

Un petit fait qui rend le code défensif plus propre : appeler Unprotect sur une feuille qui n'est pas protégée ne fait rien et ne déclenche aucune erreur. Autrement dit, vous pouvez Unprotect en tête d'une routine sans vérifier d'abord ws.ProtectContents — si la feuille était déjà ouverte, l'appel passe sans effet ; si elle était verrouillée, il l'ouvre. C'est d'une tolérance inhabituelle pour VBA, et cela vous laisse écrire l'étape de déprotection sans garde-fou. (L'inverse n'est pas symétrique : Protect sur une feuille déjà protégée, lui, déclenche une erreur — reprotéger à l'aveugle demande donc plus de soin.)

Ôter la protection de chaque feuille en une seule boucle

Une tâche réelle fréquente consiste à lever la protection sur tout un classeur avant une reconstruction en masse. Parcourez la collection Worksheets et ôtez la protection de chacune en passant le mot de passe commun :

Sub UnprotectAllSheets()
    Const PW As String = "ac"
    Dim ws As Worksheet
    For Each ws In ThisWorkbook.Worksheets
        ws.Unprotect Password:=PW      ' sans effet sur toute feuille non protegee
    Next ws
End Sub

Comme Unprotect est sans effet sur les feuilles non protégées, la boucle est sûre même quand seuls certains onglets étaient verrouillés. Associez-la à une boucle tout protéger symétrique à la fin de la reconstruction. Si des feuilles différentes utilisaient des mots de passe différents, cette boucle simple ne marchera pas — un bon argument pour n'utiliser qu'un seul mot de passe (ou aucun) sur un classeur que vous devez automatiser. Voir Worksheets pour parcourir la collection.

La limite honnête : les mots de passe oubliés

Il vaut la peine de le dire sans détour, car c'est l'une des recherches les plus fréquentes derrière ce sujet : Unprotect exige le mot de passe qui a été défini. VBA ne vous offre aucun moyen pris en charge de récupérer ou de révéler un mot de passe que vous avez vraiment oublié — le langage ne sait qu'appliquer un mot de passe que vous connaissez déjà. Si vous avez protégé votre propre feuille et perdu le mot de passe, la voie pratique est de restaurer une sauvegarde ou une version antérieure du fichier. Prenez l'habitude de garder le mot de passe dans une constante à côté du code qui l'emploie, pour que « je l'ai oublié » n'arrive jamais à un classeur que vous maintenez.

Comment ExcelMaster vous aide

Ôter la protection est facile à réussir presque parfaitement, puis à se le voir retourner contre soi : une macro échoue entre la déprotection et la reprotection et laisse en silence votre modèle ouvert, une tâche planifiée se bloque pour toujours sur une boîte de dialogue de mot de passe que personne ne voit, ou une boucle trébuche sur des feuilles qui avaient chacune un mot de passe différent.

ExcelMaster vous laisse décrire le travail — « mets à jour ces cellules sur la feuille verrouillée et remets la protection » — et il écrit le sandwich ôter la protection-travailler-reprotéger avec la reprotection dans un gestionnaire CleanExit pour qu'un plantage ne puisse jamais laisser la feuille ouverte, passe le mot de passe explicitement pour que rien ne se bloque sur une boîte de dialogue, et vous rappelle qu'un mot de passe oublié ne peut pas être récupéré depuis le code. Vous gardez le classeur et le code.

Questions fréquentes

Comment ôter la protection d'une feuille avec un mot de passe en VBA ?

Passez le mot de passe exact à l'argument Password : ws.Unprotect Password:="ac". Il doit correspondre au mot de passe utilisé lors de la protection de la feuille. Un mauvais mot de passe déclenche l'erreur d'exécution 1004 ; omettre le mot de passe sur une feuille protégée par mot de passe ouvre une boîte de dialogue modale qui bloquera une macro sans surveillance. Passez toujours le mot de passe explicitement dans du code automatisé.

Pourquoi ai-je l'erreur 1004 en ôtant la protection d'une feuille ?

La cause la plus fréquente est un mauvais mot de passe — « The password you supplied is not correct ». Vérifiez que le mot de passe d'Unprotect correspond à celui utilisé pour Protect, idéalement en rangeant les deux dans une seule constante. L'erreur 1004 peut aussi apparaître si vous référencez une feuille qui n'existe pas ; confirmez que le nom Worksheets("...") est orthographié exactement comme l'onglet.

Ôter la protection d'une feuille déverrouille-t-il ses cellules ?

Non. Unprotect ne fait que couper l'application des étiquettes Locked ; chaque cellule conserve l'état Locked exact qu'elle avait. Quand vous reprotégez la feuille, les mêmes cellules sont verrouillées qu'avant. Pour changer quelles cellules sont modifiables, définissez la propriété Locked pendant que la feuille est non protégée — ôter la protection seul ne change rien aux verrous.

Comment ôter la protection de toutes les feuilles d'un classeur ?

Parcourez la collection et ôtez la protection de chacune avec le mot de passe commun : For Each ws In ThisWorkbook.Worksheets: ws.Unprotect Password:="ac": Next ws. Comme Unprotect est sans effet sur toute feuille qui n'était pas protégée, la boucle est sûre même quand seuls certains onglets étaient verrouillés. Cela suppose un seul mot de passe sur tout le classeur ; des mots de passe différents par feuille exigeraient chacun sa propre valeur.

VBA peut-il récupérer un mot de passe de protection de feuille oublié ?

Non. VBA ne sait qu'appliquer un mot de passe que vous connaissez déjà ; il n'a aucun moyen pris en charge de révéler ou de récupérer un mot de passe oublié. Si vous avez perdu le mot de passe de votre propre feuille, restaurez le classeur depuis une sauvegarde ou une version antérieure. Gardez le mot de passe dans une constante à côté de votre code de déprotection, pour qu'il ne se perde jamais sur un fichier que vous maintenez.

Testé dans

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

Guides associés : VBA Protect Sheet · VBA Verrouiller les cellules · VBA Gestion des erreurs · VBA Worksheets · VBA Workbook_Open