🚀The world's best VBA AI has evolved. ExcelMaster is now an autonomous Agent.Read more →
Back to Blog

VBA CreateObject dans Excel — liaison tardive, GetObject, et pourquoi Outlook reste ouvert

|

VBA CreateObject dans Excel — liaison tardive, GetObject, et pourquoi Outlook reste ouvert

TL;DR — CreateObject("ProgID") démarre n'importe quelle application COM par son nom — Scripting.FileSystemObject, Outlook.Application, WScript.Shell. Comme l'objet est nommé par une chaîne, le compilateur ne peut pas le vérifier : un mauvais ProgID échoue à l'exécution avec l'error 429. CreateObject démarre toujours une nouvelle instance (utilisez GetObject pour vous raccrocher à une instance en cours), et tout ce que vous démarrez, vous devez le libérer — faire .Quit sur l'application et Set obj = Nothing — sinon vous laissez tourner un processus sans interface.

Sub CreateObjectDemo()
    Dim fso As Object
    Set fso = CreateObject("Scripting.FileSystemObject")   ' liaison tardive : nomme par chaine
    Debug.Print fso.FileExists("C:\data.txt")

    Set fso = Nothing                                      ' liberez ce que vous avez cree
End Sub

CreateObject est le mot qui transforme VBA d'un langage d'Excel en un langage d'automatisation Windows. Donnez-lui un ProgID — le nom enregistré d'un composant COM — et il démarre ce composant et vous remet un objet que vous pouvez piloter : lire des fichiers avec Scripting.FileSystemObject, envoyer du courrier avec Outlook.Application, exécuter des commandes avec WScript.Shell. C'est l'outil le plus puissant du langage pour atteindre l'extérieur d'Excel, et il réclame le plus de soin en retour, car le compilateur est désactivé pour tout ce qu'il vous donne.

Ce que vous allez apprendre

  • Le modèle mental — CreateObject est une porte dont la clé est une chaîne (un ProgID), résolue à l'exécution
  • La vraie décision : liaison tardive (CreateObject) et liaison précoce (une référence + New)
  • Pourquoi CreateObject crée toujours une nouvelle instance, et quand utiliser GetObject à la place
  • Pourquoi un processus Outlook/Excel sans interface reste ouvert, et comment le libérer correctement
  • Ce que signifie l'error 429 et la poignée de causes qui le provoquent
  • Quand préférer chaque style — développer en précoce, livrer en tardive

Le modèle mental : une porte dont la clé est une chaîne

Chaque composant Windows automatisable enregistre un ProgID — un nom textuel comme Scripting.Dictionary ou Word.Application. CreateObject prend cette chaîne, la recherche dans le registre Windows à l'exécution, démarre le composant et en renvoie une référence :

Dim dict As Object
Set dict = CreateObject("Scripting.Dictionary")   ' recherche registre par nom -> un objet vivant

Le mot important est exécution. L'objet est nommé par une chaîne, donc rien de lui n'est connu pendant que vous tapez ou quand le projet compile — VBA ne découvre ce qu'est dict que lorsque cette ligne s'exécute réellement. Ce seul fait — un objet identifié par une chaîne au lieu d'un type déclaré — est ce que signifie « liaison tardive », et il gouverne tous les compromis et pièges ci-dessous.

Liaison tardive et liaison précoce — la vraie décision

Il y a deux façons d'atteindre un objet COM, et choisir entre elles est le cœur du sujet.

La liaison tardive, c'est CreateObject avec une variable Object. Pas de référence, pas de type déclaré :

Dim ol As Object
Set ol = CreateObject("Outlook.Application")   ' tardive : une chaine, un Object
Dim mail As Object
Set mail = ol.CreateItem(0)                    ' 0 = olMailItem - le nom de la constante n'est pas disponible

La liaison précoce, c'est une référence vérifiée (Outils → Références → Microsoft Outlook Library) plus un type déclaré et New :

Dim ol As New Outlook.Application              ' precoce : un vrai type
Dim mail As Outlook.MailItem
Set mail = ol.CreateItem(olMailItem)           ' des constantes nommees comme olMailItem existent desormais

Elles compilent en presque la même chose ; la différence, c'est quand l'objet est compris et ce que vous obtenez en échange :

  • Tardive (CreateObject) — portable : aucune référence à poser, survit aux différences de version, se livre à toute machine qui a l'application. Mais pas d'IntelliSense, les constantes nommées (olMailItem) n'existent pas donc vous codez leurs numéros en dur ou déclarez vos propres Const, et chaque faute de frappe ne se révèle qu'au moment où la ligne s'exécute.
  • Précoce (New + référence) — IntelliSense pendant que vous tapez, le compilateur attrape les membres mal orthographiés, et les constantes nommées fonctionnent. Mais la référence est liée à une version précise de la bibliothèque et peut casser sur une autre machine ou une autre build d'Office.

La règle pratique que suit la plupart des professionnels : développez en liaison précoce pour l'IntelliSense et les contrôles de compilation, puis passez en liaison tardive pour livrer — changez les types Dim en Object, remplacez New par CreateObject, définissez les constantes que vous avez utilisées, et retirez la référence. Vous obtenez le confort de la saisie et un livrable portable.

CreateObject crée une nouvelle instance ; GetObject se raccroche

CreateObject démarre toujours une instance neuve du composant. Pour un utilitaire sans état comme le FileSystemObject, c'est exactement ce qu'il faut. Pour une application que l'utilisateur a peut-être déjà ouverte, c'est un piège :

Set xl = CreateObject("Excel.Application")   ' demarre un SECOND Excel invisible - meme si un est deja ouvert

Il y a maintenant deux Excel, et l'invisible retient des ressources que l'utilisateur ne voit pas. Quand vous visez celui qui tourne déjà, utilisez GetObject sans chemin et avec le ProgID :

Dim ol As Object
On Error Resume Next
Set ol = GetObject(, "Outlook.Application")      ' se raccroche a un Outlook en cours, s'il y en a un
If ol Is Nothing Then Set ol = CreateObject("Outlook.Application")   ' sinon en demarre un
On Error GoTo 0

Ce motif « se raccrocher si en cours, sinon démarrer » est la bonne façon d'automatiser une application visible par l'utilisateur comme Outlook ou Excel sans engendrer de doublons. GetObject a aussi une seconde forme — GetObject(path) — qui ouvre directement l'objet d'un fichier (par exemple un classeur) sans passer par la méthode Open de l'application. La distinction à retenir : CreateObject = nouveau, GetObject(, progID) = existant, GetObject(path) = un fichier comme objet.

Pourquoi Outlook reste ouvert : libérez ce que vous démarrez

Voici l'échec que tout le monde rencontre une fois. Vous automatisez Outlook ou un second Excel, la macro se termine, et un processus OUTLOOK.EXE ou EXCEL.EXE continue de tourner dans le Gestionnaire des tâches sans fenêtre — invisible, retenant de la mémoire et parfois un verrou de fichier. La cause : vous avez démarré un objet application et ne lui avez jamais dit de se fermer.

Un objet que vous créez avec CreateObject ne disparaît pas quand votre variable sort de portée si l'application se maintient elle-même en vie. Vous devez quitter l'application et libérer la référence, idéalement dans un nettoyage qui s'exécute même en cas d'erreur :

Dim ol As Object
On Error GoTo Cleanup
Set ol = CreateObject("Outlook.Application")
' ... utiliser ol ...

Cleanup:
    If Not ol Is Nothing Then
        ol.Quit               ' demande a l'application de se fermer
        Set ol = Nothing      ' libere la reference
    End If

Deux habitudes évitent la fuite : appelez le .Quit de l'application (ou .Close pour un classeur/document) avant de finir, et faites Set obj = Nothing sur chaque objet que vous avez créé. Mettez les deux dans un gestionnaire d'erreurs — voir la gestion des erreurs VBA — pour qu'un plantage en cours de macro nettoie quand même. Les objets légers comme Scripting.Dictionary ou le FileSystemObject n'engendrent pas de processus et n'ont pas besoin de .Quit, mais les passer à Nothing reste soigné.

L'erreur que vous rencontrerez : 429, à l'exécution

Parce que le ProgID est une chaîne que le compilateur ne vérifie jamais, l'échec classique de CreateObject n'apparaît qu'au moment où la ligne s'exécute : error 429, « ActiveX component can't create object ». Il a une courte liste de causes :

  • Un ProgID mal orthographié — CreateObject("Scripting.FileSystemObjectt"). Il n'y a aucun correcteur orthographique à la compilation pour une chaîne.
  • L'application n'est pas installée — CreateObject("Outlook.Application") sur une machine sans Outlook. La liaison tardive se livre partout, mais l'application cible doit réellement être présente.
  • Un problème de bitness ou d'enregistrement — un composant 32 bits sur un Office 64 bits, ou un composant qui ne s'est jamais enregistré correctement.

Comme c'est une erreur d'exécution, protégez l'appel avec une gestion des erreurs et donnez à l'utilisateur un message clair (« Outlook n'est pas installé ») au lieu d'un 429 brut. Cet échec exclusivement à l'exécution est le prix de la liaison tardive, et la raison pour laquelle beaucoup de développeurs écrivent d'abord en liaison précoce : le compilateur aurait attrapé la faute de frappe.

Le verdict honnête : la porte d'entrée vers Windows, compilateur éteint

CreateObject est le mot le plus capable pour sortir d'Excel — la porte vers les fichiers, la messagerie, le shell, les bases de données, et toutes les autres applications Office. Sa puissance et son danger ne font qu'un : un objet nommé par une chaîne, non vérifié jusqu'à son exécution. Quatre règles le gardent sûr :

  • C'est de la liaison tardive par chaîne → un ProgID résolu à l'exécution ; une faute de frappe ou une application manquante échoue avec l'error 429 quand la ligne s'exécute, jamais à la compilation.
  • Choisissez tardive ou précoce délibérément → précoce (New + référence) pour l'IntelliSense et les contrôles de compilation pendant le développement ; tardive (CreateObject) pour livrer un fichier portable.
  • CreateObject crée du neuf ; GetObject vise l'existant → utilisez le motif « se raccrocher si en cours, sinon créer » pour les applications visibles, afin de ne jamais engendrer un doublon invisible.
  • Libérez ce que vous démarrez → faites .Quit sur l'application et Set obj = Nothing, dans un gestionnaire d'erreurs, sinon vous laissez un processus sans interface retenir mémoire et verrous de fichier.

Tout ce qui précédait vivait à l'intérieur du modèle objet propre à Excel, où un appel se termine avant la ligne suivante et où une erreur lève une alerte bien visible. Shell, Environ et CreateObject sortent de cette sécurité — et CreateObject va le plus loin, vous remettant un objet que le compilateur n'a jamais vu. Respectez les quatre règles et c'est une porte d'entrée, pas un champ de mines.

Comment ExcelMaster aide

Les bugs de CreateObject qui coûtent vraiment du temps sont les invisibles : un second Excel sans interface resté ouvert, un processus Outlook qui n'a jamais quitté, un 429 à l'exécution sur une machine à laquelle l'application manque, une constante de liaison tardive codée en dur avec le mauvais numéro. Chacun vient de ce que le compilateur est éteint pour les objets nommés par une chaîne.

ExcelMaster écrit correctement la colle d'automatisation. Décrivez la tâche — « envoie cette plage comme un e-mail Outlook », ou « lis un fichier texte avec le FileSystemObject » — et il produit la bonne liaison (tardive, pour que ça se livre partout), se raccroche à une application en cours avec GetObject quand c'est ce que vous voulez dire, définit les constantes qui manquent à la liaison tardive, et nettoie chaque objet qu'il a démarré dans un gestionnaire d'erreurs. Vous décrivez quelle application piloter ; il écrit le code qui la pilote et ne laisse rien de suspendu.

Questions fréquentes

Quelle est la différence entre CreateObject et New en VBA ?

New (liaison précoce) a besoin d'une référence vérifiée vers la bibliothèque du composant et d'un type déclaré — Dim ol As New Outlook.Application — et vous donne IntelliSense, contrôle à la compilation et constantes nommées. CreateObject("Outlook.Application") (liaison tardive) nomme le composant par une chaîne ProgID, n'a besoin d'aucune référence, et fonctionne à travers versions et machines, mais n'a pas d'IntelliSense et n'échoue qu'à l'exécution si le nom est faux. Développez avec New pour l'outillage, livrez avec CreateObject pour la portabilité.

Qu'est-ce que la liaison tardive et la liaison précoce en VBA ?

La liaison précoce déclare un objet comme un type précis (As Outlook.Application) adossé à une entrée Outils → Références, si bien que le compilateur connaît l'objet et offre IntelliSense et constantes nommées. La liaison tardive le déclare comme un Object générique et le crée avec CreateObject("ProgID"), si bien que l'objet est résolu par chaîne à l'exécution, sans connaissance du compilateur. La liaison précoce est meilleure pour écrire le code ; la liaison tardive est meilleure pour livrer, car elle ne dépend pas de la présence d'une référence de bibliothèque précise.

Comment corriger l'erreur « ActiveX component can't create object » (error 429) ?

L'error 429 signifie que CreateObject n'a pas pu démarrer le ProgID que vous avez passé. Vérifiez trois choses : le ProgID est bien orthographié (Scripting.FileSystemObject, pas une variante) ; l'application est réellement installée sur cette machine (la liaison tardive se livre partout mais l'application cible doit être présente) ; et il n'y a pas de décalage de bitness (un composant 32 bits sous un Office 64 bits). Enveloppez l'appel dans une gestion des erreurs pour que les utilisateurs voient un message clair plutôt que le 429 brut.

Comment utiliser CreateObject avec une application déjà ouverte ?

CreateObject démarre toujours une nouvelle instance, donc pour une application que l'utilisateur a peut-être déjà ouverte, utilisez plutôt GetObject : Set ol = GetObject(, "Outlook.Application") se raccroche à un Outlook en cours. Le motif sûr est « se raccrocher si en cours, sinon créer » : tentez GetObject sous On Error Resume Next, et si l'objet Is Nothing, repliez-vous sur CreateObject. Cela évite d'engendrer une seconde copie invisible d'Excel, d'Outlook ou de Word.

Pourquoi Excel ou Outlook reste-t-il ouvert après la fin de ma macro ?

Parce que vous avez créé un objet application et ne l'avez jamais libéré. Une application automatisée maintient son processus en vie jusqu'à ce que vous appeliez .Quit et passiez la référence à Nothing. Si la macro se termine — ou plante — sans faire les deux, le processus EXCEL.EXE ou OUTLOOK.EXE s'attarde invisiblement dans le Gestionnaire des tâches, retenant de la mémoire et parfois un verrou de fichier. Placez toujours obj.Quit : Set obj = Nothing dans une section de nettoyage atteinte par un gestionnaire d'erreurs, pour que cela s'exécute même quand quelque chose échoue.

Testé dans

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

Guides connexes : VBA Shell · VBA Environ · VBA FileSystemObject · VBA Dictionary · VBA Outlook Automation