VBA WorksheetFunction dans Excel — appeler les fonctions natives d'Excel depuis le code (et les deux façons dont elles échouent)

En bref — Application.WorksheetFunction est la porte par laquelle VBA atteint les plus de 450 fonctions intégrées d'Excel, si bien que vous ne réécrivez jamais SUM, VLOOKUP ou COUNTIF sous forme de boucle faite main. Il existe deux façons d'en appeler une, et toute la partie se joue sur leur différence. Application.WorksheetFunction.VLookup(...) déclenche une erreur d'exécution dès qu'il n'y a pas de correspondance — à utiliser quand le succès est attendu et qu'un échec doit se faire entendre. Application.VLookup(...) (sans le .WorksheetFunction) renvoie une valeur d'erreur que vous testez avec IsError — à utiliser quand un échec est normal. Et la variable qui reçoit un résultat d'Application.X doit être un Variant, sinon elle plante avec une error 13 avant même que vous puissiez la tester.

' Combien de fois "West" apparait-il dans la colonne B ? Une ligne, sans boucle.
Dim ws As Worksheet: Set ws = ThisWorkbook.Worksheets("Sales")
Dim n As Long
n = Application.WorksheetFunction.CountIf(ws.Columns("B"), "West")
MsgBox "West appears " & n & " times"

Dégainer une boucle For Each pour additionner une colonne ou rechercher une valeur, c'est la façon la plus courante pour VBA de finir à la fois lent et bogué. Excel embarque déjà un moteur de calcul — des centaines de fonctions optimisées — et WorksheetFunction en est la porte d'entrée. Le savoir-faire n'est pas d'écrire plus de code ; c'est de reconnaître quand Excel possède déjà la fonction et de l'appeler. Ce guide s'articule autour du seul fait qui piège tout le monde : il existe deux styles d'appel, et ils échouent de façons opposées.

Ce que vous allez apprendre

Le modèle mental — emprunter le moteur d'Excel, ne pas le réimplémenter dans une boucle
La règle la plus importante — WorksheetFunction.X plante en cas d'échec, Application.X renvoie une erreur testable
Le piège du type — pourquoi la variable réceptrice doit être un Variant
Quelles fonctions vous pouvez appeler, lesquelles non, et celles que vous ne devriez pas
Passer une plage entière plutôt que de boucler cellule par cellule
WorksheetFunction face à l'écriture d'une chaîne de formule dans une cellule

Le modèle mental : emprunter le moteur, ne pas le reconstruire

Chaque fonction de feuille que vous connaissez — SUM, AVERAGE, VLOOKUP, MATCH, COUNTIF, SUMIF, MAX, TRIM, PROPER — est accessible depuis VBA via Application.WorksheetFunction. Vous n'appelez pas une copie VBA de la fonction ; vous appelez le moteur même qu'utilise la feuille, si bien que le résultat correspond exactement à la formule.

Cela compte, parce que l'alternative est presque toujours pire. Une boucle For Each qui somme une colonne, compte des correspondances ou balaie à la recherche d'une valeur est plus longue à écrire, plus lente à exécuter et plus facile à rater que l'unique fonction qu'Excel a déjà optimisée. WorksheetFunction.Sum(ws.Range("B2:B100000")) répond en une passe ; l'équivalent en boucle s'échine sur 100 000 itérations de VBA interprété. Gardez cette image en tête — Excel a la fonction, je n'ai qu'à l'appeler — et la plupart des questions « comment calculer X en VBA » se répondent d'elles-mêmes.

La règle la plus importante : deux styles d'appel, deux modes de défaillance

Voici la seule chose à retenir. La même fonction peut s'appeler de deux manières, et elles se comportent de façon radicalement différente quand l'opération échoue — par exemple lorsqu'une recherche ne trouve rien.

' Style 1 : WorksheetFunction.X - PLANTE en l'absence de correspondance.
Dim price As Double
price = Application.WorksheetFunction.VLookup("Widget", ws.Range("A:C"), 3, False)
' Si "Widget" est absent : run-time error 1004, et l'execution s'arrete.

' Style 2 : Application.X (sans .WorksheetFunction) - RENVOIE une erreur testable.
Dim result As Variant
result = Application.VLookup("Widget", ws.Range("A:C"), 3, False)
If IsError(result) Then
    MsgBox "Widget not found"      ' gere proprement, sans plantage
Else
    MsgBox "Price is " & result
End If

Même fonction, mêmes arguments — mais WorksheetFunction.VLookup lève une erreur en l'absence de correspondance, tandis qu'Application.VLookup renvoie une valeur d'erreur #N/A que IsError intercepte. Aucun n'est « correct » ; ils répondent à des intentions différentes :

Utilisez WorksheetFunction.X quand vous attendez que l'opération réussisse et qu'un échec signale un vrai problème. Le plantage est une fonctionnalité — il arrête la macro au lieu de laisser une mauvaise valeur se propager en aval.
Utilisez Application.X quand un échec est un résultat normal que vous voulez gérer — une recherche qui trouve ou non sa clé, une valeur présente la plupart du temps. Vous testez IsError et vous aiguillez.

Le bug numéro un de tout ce sujet, c'est d'utiliser WorksheetFunction.Match pour vérifier si quelque chose existe, puis d'être surpris par une error 1004 quand ce n'est pas le cas. Les tests d'existence sont précisément le cas d'usage d'Application.Match + IsError.

Le piège du type : le résultat doit être un Variant

Le style 2 ne fonctionne que si la variable qui reçoit le résultat peut contenir une valeur d'erreur. En VBA, seul un Variant le peut. Déclarez-la avec un type plus étroit et c'est l'affectation elle-même qui explose :

Dim result As Double
result = Application.VLookup("Widget", ws.Range("A:C"), 3, False)
' Si absent : error 13 "Type mismatch" - un Double ne peut pas contenir #N/A

Le correctif tient en Dim result As Variant. Dès lors, IsError(result) s'appelle sans risque, et en cas de succès vous utilisez la valeur normalement. C'est la seconde moitié discrète du schéma « renvoie une erreur » : un résultat d'Application.X va toujours dans un Variant. Oubliez-le, et le type mismatch masque justement la gestion d'erreur que vous cherchiez à mettre en place.

Quelles fonctions vous pouvez appeler — et celles que vous ne devriez pas

L'essentiel de la bibliothèque est disponible, mais trois cas limites méritent votre attention :

Tout n'est pas exposé. Une poignée de fonctions récentes ou volatiles n'apparaissent pas sur WorksheetFunction. Si un nom manque, vous pouvez généralement vous rabattre sur Application.Evaluate ou écrire la formule dans une cellule (voir plus bas).
Certaines fonctions existent déjà nativement en VBA — utilisez celles-là. N'appelez pas WorksheetFunction.Left, Mid, Right, Trim, Upper ni Lower. VBA possède ses propres Left, Mid, Right, Trim, UCase, LCase, plus rapides et sans aller-retour vers Excel. (Une subtilité : le Trim de VBA ne retire que les espaces de début et de fin, alors que WorksheetFunction.Trim réduit aussi les doubles espaces internes — ils ne sont donc pas identiques, et il vous arrivera bel et bien de vouloir la version feuille de calcul.)
Les noms diffèrent parfois. Le nom du membre VBA correspond généralement à la fonction, mais quelques-uns conservent l'ancienne orthographe interne d'Excel. Dans le doute, tapez Application.WorksheetFunction. et laissez IntelliSense lister ce qui existe réellement.

La règle empirique : recourez à WorksheetFunction pour les fonctions analytiques lourdes où Excel excelle — recherches, comptages et sommes conditionnels, statistiques — et utilisez les mots-clés propres à VBA pour le travail de base sur les chaînes et les calculs.

Passez une plage entière, ne bouclez pas cellule par cellule

Le plus grand gain de vitesse est aussi le plus facile à manquer. Les fonctions WorksheetFunction acceptent des plages, alors passez-leur la plage entière d'un coup au lieu de boucler et d'appeler cellule par cellule :

' LENT - appelle le moteur une fois par ligne.
Dim i As Long, total As Double
For i = 2 To lastRow
    total = total + ws.Cells(i, "B").Value
Next i

' RAPIDE - un seul appel, le moteur fait la boucle en interne.
total = Application.WorksheetFunction.Sum(ws.Range("B2:B" & lastRow))

La version rapide n'est pas seulement plus courte ; elle fait descendre l'itération dans le moteur compilé d'Excel au lieu de l'exécuter en VBA interprété. Il en va de même pour CountIf, SumIf, Average, Max, Min — donnez-leur la plage et laissez-les compter. Si vous vous surprenez à accumuler un total dans une boucle, c'est presque toujours une fonction de feuille qui attend d'être appelée.

WorksheetFunction face à l'écriture d'une formule dans une cellule

Il existe une troisième option, et savoir quand la préférer garde votre code honnête. WorksheetFunction calcule une valeur une seule fois, dans le code — la feuille ne change pas, et la réponse ne se recalcule pas quand les données évoluent. Écrire une chaîne de formule dans une cellule (ws.Range("D2").Formula = "=SUM(B2:B100)") laisse une formule vivante qui se met à jour indéfiniment.

Utilisez WorksheetFunction quand il vous faut un nombre maintenant, au cœur de votre logique — un seuil à comparer, un décompte pour aiguiller, un total à estampiller dans un rapport. Écrivez une formule dans la cellule quand l'utilisateur doit voir un résultat qui reste juste au fil de ses modifications. Recourir à WorksheetFunction puis coller sa réponse figée là où une formule aurait dû être, c'est une façon courante pour un rapport de se périmer en silence.

Comment ExcelMaster aide

WorksheetFunction concentre une quantité surprenante de décisions dans un seul appel : lequel des deux styles employer, si le résultat exige un Variant, si un mot-clé VBA natif ferait mieux l'affaire, et si la valeur doit être calculée une fois ou laissée sous forme de formule vivante. Chacun de ces choix a un mode de défaillance qui renvoie une mauvaise réponse — ou qui plante sur des données que vous n'avez pas testées.

ExcelMaster vous laisse plutôt décrire le calcul. Dites « compte combien de commandes viennent de la région Ouest » ou « recherche le prix de chaque produit et signale ceux que nous ne stockons pas », et il choisit le bon style d'appel — celui qui plante quand un échec est une vraie erreur, celui qui se teste quand un échec est attendu — déclare le résultat en Variant quand il le faut, et passe des plages entières plutôt que de boucler. Vous gardez le classeur et le code ; vous vous épargnez le moment où une error 1004 non gérée arrête une macro en plein milieu d'un rapport.

Questions fréquentes

Quelle est la différence entre WorksheetFunction et Application en VBA ?

Les deux appellent la même fonction Excel, mais elles échouent différemment. Application.WorksheetFunction.X déclenche une erreur d'exécution (souvent 1004) quand la fonction ne peut pas renvoyer de résultat, par exemple une recherche sans correspondance. Application.X — sans .WorksheetFunction — renvoie plutôt une valeur d'erreur Excel comme #N/A, que vous testez avec IsError. Utilisez la première quand un échec doit arrêter la macro, la seconde quand un échec est un cas normal à gérer.

Pourquoi WorksheetFunction.VLookup déclenche-t-il une error 1004 ?

Parce que WorksheetFunction.VLookup lève une erreur d'exécution quand la valeur est introuvable, au lieu de renvoyer #N/A. Ici, une error 1004 signifie presque toujours « aucune correspondance », pas une formule cassée. Si vous prévoyez que certaines recherches échouent, appelez Application.VLookup dans un Variant et testez IsError(result), ou entourez l'appel WorksheetFunction d'un gestionnaire On Error.

Pourquoi ai-je un type mismatch (error 13) avec Application.VLookup ?

Parce qu'Application.VLookup peut renvoyer une valeur d'erreur, et que seul un Variant peut en contenir une. Déclarer la variable réceptrice en Double, Long ou String provoque une error 13 à l'instant même où le résultat est #N/A. Déclarez-la As Variant, puis appelez IsError avant d'utiliser la valeur.

Puis-je utiliser n'importe quelle fonction Excel en VBA via WorksheetFunction ?

La plupart, mais pas toutes. Les fonctions analytiques courantes — VLOOKUP, MATCH, COUNTIF, SUMIF, SUM, AVERAGE, les statistiques — sont toutes là. Quelques fonctions récentes ou volatiles ne sont pas exposées ; pour celles-là, utilisez Application.Evaluate ou écrivez la formule dans une cellule. Et pour le texte et les calculs de base, préférez les Left, Mid, Trim, UCase propres à VBA ainsi que ses opérateurs, plutôt que les versions feuille de calcul.

WorksheetFunction.Sum est-il plus rapide qu'une boucle en VBA ?

Oui, nettement, sur de grandes plages. Passer la plage entière à WorksheetFunction.Sum exécute l'itération dans le moteur compilé d'Excel en un seul appel, alors qu'une boucle For Each ou For la déroule en VBA interprété, une cellule à la fois. Chaque fois que vous accumulez un total ou un décompte dans une boucle, une fonction de feuille appelée sur la plage entière est en général à la fois plus courte et plus rapide.

Testé dans

Testé dans : Excel 365 (Windows 11), VBA 7.1 — dernière vérification le 10/08/2026.

Guides associés : VBA VLOOKUP · VBA Remove Duplicates · VBA Advanced Filter · VBA For Loop · VBA Range