VBA Breakpoint dans Excel — geler une macro et l'exécuter pas à pas, ligne par ligne

TL;DR — Un breakpoint met votre macro en pause sur une ligne avant qu'elle ne s'exécute et vous dépose en break mode. Là, vous pouvez lire chaque valeur vivante — survolez une variable pour une data tip, ou interrogez l'Immediate Window — puis parcourir le code une ligne à la fois. F9 pose ou retire un breakpoint, F5 court jusqu'à lui, F8 avance d'une ligne, Shift+F8 enjambe une procédure appelée. C'est ainsi que vous trouvez quelle ligne dérape, pas seulement quelles étaient les valeurs. Deux choses à savoir : les breakpoints ne sont pas enregistrés avec le fichier, et une instruction Stop dans du code livré gèlera l'Excel d'un utilisateur.

Sub Investigate()
    Dim total As Double, r As Long
    For r = 2 To 100
        total = total + Cells(r, 3).Value   ' F9 ici pose un breakpoint (point rouge)
    Next r                                   ' F8 avance ; survolez 'total' pour le suivre
    Debug.Assert total > 0                   ' rompt dans l'editeur SEULEMENT si c'est False
End Sub

Ce que vous allez apprendre

• Le modèle mental — un breakpoint gèle le temps pour que vous puissiez parcourir le code
• Les trois observateurs, de puissance croissante, et pourquoi celui-ci est le lourd
• Poser des breakpoints avec F9, et avancer avec F8 contre Shift+F8
• Pourquoi les breakpoints disparaissent, et pourquoi Stop ne doit jamais être livré
• Comment Debug.Assert vous donne un breakpoint sûr en production
• Quand avancer pas à pas, et quand parsemer Debug.Print à la place

Le modèle mental : geler le temps, puis parcourir le code

Un breakpoint arrête l'exécution sur une ligne choisie avant que cette ligne ne s'exécute, et vous remet la macro figée en plein vol. Chaque variable garde sa valeur vivante, la pile d'appels est intacte, et Excel est en pause exactement là où se trouve votre logique. De là, vous avancez pas à pas : F8 exécute la ligne courante et s'arrête sur la suivante, si bien que vous faites avancer le programme à vitesse humaine, en regardant chaque instruction prendre effet.

C'est la différence qui compte. Debug.Print vous dit *ce qu'*étaient les valeurs après l'exécution ; un breakpoint vous laisse trouver sur quelle ligne le comportement diverge d'abord de ce que vous attendiez. Quand les valeurs sont fausses mais que vous ne savez pas dire où elles ont mal tourné, vous n'avez pas besoin de plus de journalisation — vous devez geler la macro et la regarder se dérouler.

Les trois observateurs, de puissance croissante

Un breakpoint est le barreau du haut d'une échelle. Quand une macro se comporte mal, chaque outil répond à une question différente, et celui-ci est celui qui arrête le temps :

Debug.Print montre le passé ; l'Immediate Window interroge le présent ; un breakpoint crée le présent, gelant la macro pour que vous puissiez inspecter et avancer. C'est le plus puissant des trois et le plus lent à employer — parcourir 10 000 itérations de boucle à la main n'a rien d'un bel après-midi — donc vous le saisissez précisément quand les observateurs moins chers ne peuvent pas répondre « quelle ligne ? ».

Poser des breakpoints, et F8 contre Shift+F8

Cliquez dans la marge grise à gauche d'une ligne, ou placez le curseur sur la ligne et appuyez sur F9 — un point rouge la marque, et la prochaine exécution s'y met en pause. Une fois en pause, quatre touches font la marche :

• F8 (Step Into) — exécute cette ligne ; si elle appelle un Sub ou une Function, y entre et continue ligne par ligne à l'intérieur.
• Shift+F8 (Step Over) — exécute une procédure appelée en entier et s'arrête sur la ligne suivante ici.
• Ctrl+Shift+F8 (Step Out) — termine la procédure courante et s'arrête là où elle a été appelée.
• F5 (Run) — cesse d'avancer pas à pas et court jusqu'au prochain breakpoint ou jusqu'à la fin.

Le premier gouffre à temps, c'est de faire F8 droit dans un assistant de 500 lignes en qui vous avez déjà confiance — une routine de formatage, un appel de bibliothèque — et de le parcourir en entier. Si ce n'est pas vous qui avez écrit le bug, enjambez-le avec Shift+F8. F8 est pour le code que vous soupçonnez ; Shift+F8 pour le code que vous ne soupçonnez pas.

Piège 1 : les breakpoints ne s'enregistrent pas — et Stop est le piège qui le fait

Fermez le classeur et chaque breakpoint a disparu. Ils vivent dans la session de l'éditeur, pas dans le fichier, donc ils ne voyagent jamais avec votre macro et ne se déclenchent jamais pour personne d'autre. C'est généralement ce que vous voulez.

Le correctif tentant, c'est l'instruction Stop — un breakpoint permanent écrit dans le code :

Sub Risky()
    Stop                     ' pause ici a CHAQUE execution - y compris sur la machine d'un utilisateur
    ' ... votre vrai travail ...
End Sub

Stop est vraiment utile pendant le développement parce qu'il survit à un redémarrage. Mais s'il atteint la production, un utilisateur lance la macro, tombe sur Stop, et Excel paraît gelé sur une rupture qu'il ne peut ni comprendre ni lever sans l'éditeur VBA. Traitez Stop comme un marqueur réservé au développement que vous devez supprimer avant de livrer — jamais comme de la gestion d'erreurs, et jamais dans du code qui quitte votre machine.

Piège 2 : Debug.Assert est le breakpoint que l'on peut livrer sans risque

Quand vous voulez un breakpoint qui vérifie une condition et reste inoffensif en production, utilisez Debug.Assert :

Debug.Assert cnt = expected      ' rompt dans l'editeur si les comptes divergent
Debug.Assert Not rng Is Nothing  ' rompt si la plage n'a pas pu se resoudre

Debug.Assert condition rompt l'exécution seulement quand la condition est False, et seulement à l'intérieur de l'éditeur VBA — à l'exécution, hors de l'IDE, la ligne est complètement ignorée. C'est ce qui en fait la bonne façon d'encoder un invariant que vous croyez toujours vrai (« le compte après égale le compte avant », « cet objet n'est pas Nothing ») : pendant le développement, il vous arrête à l'instant où l'hypothèse casse, et dans la copie d'un utilisateur, il ne coûte rien et ne gèle personne. C'est un breakpoint conditionnel qui se documente lui-même.

Piège 3 : éditer en pause jette votre état

En break mode, vous pouvez éditer le code — et VBA va souvent réinitialiser l'exécution pour appliquer le changement, remettant chaque variable vivante à vide et repartant de zéro. C'est la raison habituelle pour laquelle quelqu'un rapporte que ses variables ont « disparu » au milieu du pas à pas : une petite édition a discrètement redémarré la macro. Si vous êtes au cœur d'une exécution en pause, résistez à l'envie de corriger la coquille que vous venez de repérer avant d'avoir lu l'état pour lequel vous vous êtes arrêté. Outil de pouvoir voisin : Set Next Statement (Ctrl+F9) vous laisse tirer la flèche jaune pour rejouer ou sauter une ligne — inestimable pour retenter une étape, mais sautez une initialisation et l'état que vous inspectez ensuite est un mensonge.

Breakpoint contre Debug.Print

Ce ne sont pas des rivaux ; ce sont des phases différentes de la même traque :

Utilisez Debug.Print pour resserrer une boucle de 10 000 lignes jusqu'à la région où les nombres cassent ; puis posez un breakpoint là — ou un Add Watch avec une condition de rupture qui ne met en pause que lorsqu'une valeur passe pour la première fois sous zéro — pour geler sur la seule itération qui compte au lieu de faire F8 à travers toutes. La journalisation trouve le quartier ; un breakpoint trouve la ligne.

L'avis : l'outil lourd, employé à dessein

Un breakpoint est le débogueur le plus puissant que VBA vous donne et le plus lent à manier, alors dépensez-le là où les outils moins chers s'épuisent : quand les valeurs sont fausses et que vous ne savez vraiment pas dire quelle instruction est responsable. Pour tout ce à quoi vous pouvez répondre à partir des valeurs — cette variable est-elle ce que j'attends, cette boucle tourne-t-elle le bon nombre de fois — un Debug.Print ou une requête Immediate Window est plus rapide et n'arrête pas le monde.

Deux disciplines séparent les gens qui déboguent vite de ceux qui se battent avec l'éditeur. Ne livrez jamais un Stop ; encodez vos hypothèses toujours-vraies en Debug.Assert à la place, pour qu'elles vous gardent en développement et disparaissent en production. Et ne faites jamais F8 à travers du code que vous n'avez pas écrit — enjambez-le. Le but n'est pas de regarder chaque ligne ; c'est d'atteindre la seule ligne qui vous ment.

Quand tout le travail est de trouver la ligne cassée — décrivez-le plutôt

Le pas à pas est superbe pour une seule exécution cassée et misérable pour « laquelle des 8 000 lignes casse le total ». Le temps d'avoir posé un breakpoint, ajouté une surveillance, et avancé jusqu'à ce qu'une valeur tourne mal, vous avez simulé à la main ce qu'une requête répond en une passe. ExcelMaster vous laisse énoncer la question en langage courant — « trouve la première ligne où le total cumulé cesse de correspondre à la colonne E, et montre-moi les lignes autour » — et il écrit du Python qui lit la feuille, sauvegarde d'abord votre fichier, vérifie chaque ligne, et renvoie le coupable exact. Utilisez un breakpoint pour comprendre une défaillance ; décrivez la règle quand le travail est de trouver quel cas échoue.

Foire aux questions

Comment poser un breakpoint en VBA ?

Cliquez dans la marge grise à gauche d'une ligne, ou placez le curseur sur la ligne et appuyez sur F9. Un point rouge marque la ligne, et la prochaine fois que la macro tourne, elle se met en pause juste avant cette ligne, vous déposant en break mode. Appuyez de nouveau sur F9 sur la ligne pour retirer le breakpoint.

Pourquoi mes breakpoints n'arrêtent-ils pas de disparaître ?

Parce que les breakpoints ne sont pas enregistrés avec le classeur — fermer le fichier les efface tous. Si vous avez besoin d'une pause qui vit dans le code, utilisez l'instruction Stop, mais retirez-la avant de partager la macro, car un Stop gèlera Excel pour quiconque l'exécute.

Quelle est la différence entre F8 et Shift+F8 ?

F8 (Step Into) exécute une ligne et entre dans tout Sub ou Function qu'elle appelle, si bien que vous parcourez aussi le code appelé. Shift+F8 (Step Over) exécute une procédure appelée en entier et s'arrête sur la ligne suivante de la procédure courante. Utilisez Step Over pour les routines d'aide en qui vous avez déjà confiance.

Comment voir la valeur d'une variable pendant qu'une macro est en pause ?

Survolez le nom de la variable avec le pointeur pour une data tip, tapez ? varName dans l'Immediate Window, ou ajoutez la variable au Watch Window. Cela ne fonctionne que pendant que la macro est en pause en break mode, car les variables locales n'existent que pendant l'exécution.

Que fait Debug.Assert en VBA ?

Debug.Assert condition rompt l'exécution dans l'éditeur VBA seulement quand la condition est False, et est entièrement ignoré quand le code s'exécute hors de l'éditeur. C'est une façon sûre de vérifier un invariant pendant le développement — les comptes correspondent, un objet n'est pas Nothing — sans laisser un Stop qui pourrait geler l'Excel d'un utilisateur.

Testé dans

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

Guides associés : VBA Debug.Print · VBA Immediate Window · VBA Gestion des erreurs · VBA On Error · VBA Boucle For