VBA Lock Cells dans Excel — la propriété Locked qui ne fait rien à elle seule

TL;DR — Range.Locked est une étiquette, pas un verrou. Mettre Locked = True ne change rien que vous puissiez voir ou sentir ; la cellule ne devient non modifiable qu'une fois la feuille protégée, moment où Excel lit l'étiquette de chaque cellule et fige celles marquées Locked. Voilà pourquoi la plainte classique — « j'ai mis Locked = True mais les utilisateurs peuvent toujours modifier la cellule » — n'est pas un bug : la feuille n'a jamais été protégée. Et comme chaque cellule démarre à Locked = True, le vrai flux de travail est inversé : vous déverrouillez les cellules de saisie (Locked = False) puis vous protégez, en laissant tout le reste hériter du verrou par défaut.

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

    ws.Cells.Locked = True                 ' chaque cellule l'est deja - on est explicite
    ws.Range("C4:C12").Locked = False      ' les cellules de saisie sont les exceptions
    ws.Range("C4:C12").FormulaHidden = False
    ws.Protect Password:="ac"              ' MAINTENANT les etiquettes commencent a compter
End Sub

Locked est la case à cocher Verrouillée de Format de cellule ▸ Protection, et c'est la propriété la plus mal comprise de toute l'automatisation Excel — parce que la définir a l'air de ne rien faire. Vous exécutez cell.Locked = True, vous cliquez sur la cellule, et vous pouvez toujours y taper. Tout fonctionne exactement comme prévu ; vous venez juste de découvrir que Locked est inerte à elle seule. Dès que vous intégrez que Locked est une note au système de protection plutôt qu'un acte de verrouillage, toute la fonctionnalité devient prévisible.

Ce que vous allez apprendre

• Le modèle mental — Locked est une étiquette que lit l'interrupteur de protection, pas un verrou en soi
• La règle qui explique le bug numéro un — Locked ne fait rien tant que vous n'avez pas protégé la feuille
• Pourquoi chaque cellule démarre verrouillée, et le flux de travail inversé « déverrouiller les cellules de saisie » qui en découle
• Pourquoi Locked renvoie Null sur une sélection mixte, et comment le tester
• FormulaHidden — l'étiquette compagne qui masque une formule de la barre de formule
• Pourquoi vous devez définir Locked pendant que la feuille est non protégée

Le modèle mental : une étiquette, pas un verrou

Imaginez Locked comme un pense-bête collé sur chaque cellule qui dit « fige-moi quand la protection est active ». Écrire la note ne fige rien ; elle ne fait qu'enregistrer une intention. Le gel réel survient plus tard, et de la main de quelqu'un d'autre — Worksheet.Protect — qui parcourt la feuille, lit chaque note et la fait respecter. Deux cellules peuvent porter des étiquettes Locked identiques et se comporter tout autrement, uniquement selon que leur feuille est protégée ou non.

Voilà pourquoi Locked et Protect forment une paire qu'il faut comprendre ensemble. Locked est la carte de qui-peut-modifier-quoi ; Protect est l'interrupteur qui se met à honorer la carte. Ni l'un ni l'autre ne fait le travail seul : une carte que personne ne fait respecter ne change rien, et un interrupteur sans carte verrouille tout (parce que la carte par défaut marque chaque cellule comme verrouillée).

La règle qui explique le bug numéro un : Locked est inerte tant que vous ne protégez pas

La frustration la plus recherchée derrière ce sujet est « j'ai mis la cellule à Locked = True mais l'utilisateur peut toujours la modifier ». Ce n'est jamais un bug dans Locked. Cela veut dire que la feuille n'est pas protégée, donc rien ne fait respecter l'étiquette. La propriété Locked n'a strictement aucun effet sur une feuille non protégée — vous pouvez la définir sur chaque cellule du classeur sans rien changer à ce que quiconque peut taper.

ws.Range("A1").Locked = True    ' A1 porte maintenant l'etiquette verrouille...
' (feuille non protegee)        ' ...et reste entierement modifiable
ws.Protect                      ' MAINTENANT A1 est figee

Locked est donc toujours la moitié d'un processus en deux temps, et le second temps est celui qu'on oublie. Si une cellule doit résister à l'édition, mettre Locked = True est nécessaire mais pas suffisant — la feuille doit être protégée pour que l'étiquette morde. Chaque fois que le verrouillage « ne marche pas », la première chose à vérifier est de savoir si ws.ProtectContents vaut seulement True.

Chaque cellule démarre verrouillée — alors déverrouillez les exceptions

Voici le fait qui renverse tout le flux de travail : chaque cellule d'une feuille neuve est déjà Locked = True. Autrement dit, « verrouiller les cellules que je veux protéger » n'est presque jamais le bon geste — elles sont déjà verrouillées. Le bon schéma est l'inverse : laissez la valeur par défaut en place et déverrouillez la poignée de cellules que vous voulez laisser modifier.

ws.Cells.Locked = True              ' la valeur par defaut ; enoncee pour le prochain lecteur
ws.Range("C4:C12").Locked = False   ' deverrouiller les cellules de saisie - les exceptions
ws.Protect Password:="ac"           ' tout le reste herite du verrou

Raisonnez en « quelles cellules sont les saisies ? » et déverrouillez celles-là ; tout le reste — étiquettes, formules, titres — garde le verrou par défaut et est figé dès que vous protégez. Cela passe bien mieux à l'échelle que d'essayer d'énumérer chaque cellule qui devrait être en lecture seule, et c'est pourquoi les modèles bien conçus déverrouillent une petite zone de saisie évidente et verrouillent le reste par omission.

Le piège du Null : lire Locked sur une sélection mixte

Locked ne se lit proprement que lorsqu'une plage est uniforme. Si une plage contient à la fois des cellules verrouillées et déverrouillées, lire .Locked renvoie Null, pas True ni False. Un test naïf explose donc :

If ws.Range("A1:A10").Locked Then      ' erreur d'execution si la plage est mixte (Null)

Quand A1:A10 a des cellules tantôt verrouillées, tantôt déverrouillées, .Locked vaut Null, et If Null Then déclenche « Invalid use of Null ». Protégez-le avec IsNull quand une plage peut être mixte :

Dim state As Variant
state = ws.Range("A1:A10").Locked
If IsNull(state) Then
    ' mixte - decider cellule par cellule
ElseIf state Then
    ' tout verrouille
Else
    ' tout deverrouille
End If

C'est le même comportement à trois états que vous voyez avec WrapText et d'autres propriétés de cellule : les plages uniformes donnent un Boolean, les plages mixtes donnent Null. Lisez une cellule à la fois quand vous avez besoin de certitude.

FormulaHidden : verrouiller la cellule, cacher la recette

Locked a une étiquette compagne, FormulaHidden, et ensemble elles couvrent les deux choses que vous voulez d'ordinaire d'un modèle livré : l'utilisateur ne peut pas changer la formule, ni même la voir. Comme Locked, FormulaHidden ne fait rien tant que la feuille n'est pas protégée ; une fois qu'elle l'est, une cellule avec FormulaHidden = True affiche son résultat dans la grille mais une barre de formule vide quand on la sélectionne.

ws.Range("D4:D100").Locked = True
ws.Range("D4:D100").FormulaHidden = True   ' cacher le calcul de la barre de formule
ws.Protect Password:="ac"

Utilisez-la quand vous livrez un calcul comme une boîte noire — un modèle de tarification, une formule de scoring — et que vous voulez que les gens fassent confiance au nombre sans soulever le capot. Comme toujours, c'est un geste de confort et de propriété intellectuelle, pas de sécurité : comme les mots de passe de protection, elle se contourne facilement. Mais pour garder une formule hors de la vue ordinaire, c'est exactement la bonne étiquette.

Pourquoi vous devez définir Locked pendant que la feuille est non protégée

La carte Locked doit être tracée pendant que la feuille est ouverte. Tenter cell.Locked = False sur une feuille protégée déclenche l'erreur d'exécution 1004 — vous ne pouvez pas réécrire la carte tant que l'interrupteur qui la fait respecter est en marche. L'ordre est donc fixe et non négociable : Unprotect (si nécessaire), poser chaque étiquette Locked et FormulaHidden, puis Protect. Si une macro doit changer quelles cellules sont modifiables à l'exécution, elle doit d'abord ôter la protection, ajuster les étiquettes, et reprotéger — vous ne pouvez jamais modifier les étiquettes à travers un verrou actif.

Comment ExcelMaster vous aide

Locked échoue en silence de la façon la plus déroutante qui soit : elle ne fait exactement rien, sans la moindre erreur, jusqu'à ce que la feuille soit protégée — alors on la définit, on regarde les utilisateurs modifier quand même les cellules « verrouillées », et on en conclut que la propriété est cassée. Ensuite le flux de travail inversé fait trébucher, ou une lecture de plage mixte déclenche « Invalid use of Null », ou l'on essaie de réétiqueter des cellules à travers une protection active et l'on tombe sur 1004.

ExcelMaster vous laisse dire l'objectif — « laisse les gens modifier uniquement les cellules de saisie jaunes et masque les formules » — et il définit Locked et FormulaHidden dans le bon ordre, déverrouille les cellules de saisie plutôt que d'essayer de verrouiller tout le reste, associe les étiquettes à l'appel Protect qui les fait vraiment respecter, et protège les lectures de plage mixte contre Null. Vous gardez le classeur et le code.

Questions fréquentes

Pourquoi les utilisateurs peuvent-ils encore modifier une cellule après que j'ai mis Locked à True en VBA ?

Parce que Locked ne fait rien tant que la feuille n'est pas protégée. Ce n'est qu'une étiquette que lit le système de protection — une feuille non protégée l'ignore entièrement. Mettez les cellules à Locked = True (ou laissez la valeur par défaut), puis appelez ws.Protect. Si l'édition reste possible après ça, confirmez que la feuille est réellement protégée avec ws.ProtectContents.

Comment verrouiller seulement certaines cellules et laisser le reste modifiable ?

Utilisez le flux de travail inversé. Chaque cellule démarre à Locked = True, donc déverrouillez les exceptions plutôt que de verrouiller les cibles : ws.Cells.Locked = True puis ws.Range("C4:C12").Locked = False pour les cellules de saisie, puis ws.Protect. Tout ce que vous n'avez pas déverrouillé hérite du verrou par défaut et est figé dès que la feuille est protégée.

Pourquoi lire la propriété Locked donne-t-il une erreur ?

Parce que la plage est mixte. Locked renvoie Null quand une plage contient à la fois des cellules verrouillées et déverrouillées, et If Range.Locked Then sur un Null déclenche « Invalid use of Null ». Testez d'abord avec IsNull, ou lisez une cellule à la fois : une plage uniforme renvoie un Boolean, une plage mixte renvoie Null.

Quelle est la différence entre Locked et FormulaHidden ?

Locked empêche une cellule d'être modifiée une fois la feuille protégée ; FormulaHidden empêche sa formule d'être vue dans la barre de formule une fois la feuille protégée. Les deux sont des étiquettes qui ne prennent effet que sous protection. Utilisez-les ensemble pour livrer un calcul que l'utilisateur ne peut ni changer ni inspecter — verrouillez la cellule et masquez la formule, puis protégez.

Puis-je changer l'état Locked d'une cellule pendant que la feuille est protégée ?

Non. Définir Locked (ou FormulaHidden) sur une feuille protégée déclenche l'erreur d'exécution 1004. Vous devez tracer la carte pendant que l'application est coupée : Unprotect si nécessaire, poser les étiquettes Locked, puis Protect. Une macro qui change la modifiabilité à l'exécution doit ôter la protection, ajuster, et reprotéger.

Testé dans

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

Guides associés : VBA Protect Sheet · VBA Unprotect · VBA Renvoyer à la ligne · VBA Range · VBA Formula