Jusqu'à quand les applications VB6 continueront-elles de fonctionner ? — état du support du runtime et démarche concrète vers une migration .NET

« Ce système en VB6, jusqu’à quand va-t-il continuer à fonctionner ? » — c’est l’une des questions les plus fréquentes lors des consultations portant sur des systèmes existants.

La réponse est étonnamment claire : Microsoft a publié une politique de support officielle. Mais son contenu est asymétrique — « le runtime continuera de fonctionner pour un moment, mais il n’y a plus de soutien côté développement ». Sans comprendre correctement cette asymétrie, on finit par osciller entre deux conclusions extrêmes : « ça fonctionne encore, donc tout va bien » et « il faut tout reconstruire immédiatement ».

Sur ce blog, l’article « Prolonger la durée de vie et migrer les applications métier VB6 / Access — un tableau de décision entre conserver, envelopper et remplacer » a permis d’organiser la décision de savoir quoi faire de vos actifs VB6. Cet article en est la suite : une fois la décision de « remplacer (migrer) » prise — ou pour vous aider à la prendre — il aborde de façon concrète comment mener réellement une migration de VB6 vers .NET.

1. D’abord, l’essentiel

• Le support de l’EDI VB6 (environnement de développement) a pris fin le 8 avril 2008. Il n’existe plus aucun moyen pris en charge de créer ou de maintenir des applications VB6, et Microsoft recommande fortement de les remplacer par des technologies modernes.¹
• En revanche, le runtime VB6 reste pris en charge « tant que la version de Windows avec laquelle il est fourni l’est elle-même ». La liste des systèmes d’exploitation couverts inclut Windows 11, Windows 10 et Windows Server 2025, l’objectif étant que les applications existantes « continuent simplement de fonctionner » (It Just Works).² Autrement dit, la réponse à « jusqu’à quand cela fonctionnera-t-il » est : pour la seule exécution, aussi longtemps que Windows lui-même est pris en charge.
• Ce support se limite toutefois à la prise en charge des régressions graves et des problèmes de sécurité critiques touchant les applications existantes. Le runtime est par ailleurs exclusivement 32 bits, et sous Windows 64 bits, il n’est pris en charge qu’au sein de l’environnement WOW64.²
• Le vrai risque n’est pas que « ça s’arrête de fonctionner », mais que l’on perde la capacité de le corriger. Obtenir et conserver l’EDI devient plus difficile chaque année, le support des éditeurs des contrôles OCX utilisés s’arrête, et les personnes encore capables d’écrire du VB6 partent à la retraite ou changent d’entreprise. Ces trois phénomènes progressent indépendamment de la durée de support de Windows lui-même.
• La migration peut suivre trois grandes approches : réécriture complète, conversion automatisée et migration progressive. La première chose à décider n’est pas l’approche, mais l’inventaire : il faut d’abord cerner le nombre d’écrans, les intégrations externes, le volume de contrôles OCX et de déclarations d’API avant de choisir une approche.
• Pour le langage cible de la migration, C# est recommandé pour tout ce qui est écrit à neuf. Microsoft a officiellement déclaré que VB.NET (Visual Basic) est sur une trajectoire de stabilité, sans nouvelle syntaxe ni extension à de nouveaux types de charges de travail.³

2. La réponse précise à « jusqu’à quand cela fonctionnera-t-il » — comment lire la politique de support

La politique de support VB6 de Microsoft explique VB6 en le décomposant en trois composants.²

Dans le tableau des systèmes d’exploitation couverts, Windows 11, Windows 10 et Windows Server de 2012 à 2025 sont explicitement marqués « runtime : pris en charge » et « EDI : non pris en charge ».²

Il y a trois points clés pour bien lire cette politique.

Premièrement, le support du runtime est entièrement subordonné au cycle de vie de Windows. Il n’existe pas de date indépendante appelée « fin de support du runtime VB6 » : la fin du support de la version de Windows utilisée constitue, telle quelle, l’échéance.

Deuxièmement, le contenu réel de ce support est plus proche d’une garantie de « continuité de fonctionnement » que d’autre chose. Ce qui est traité se limite aux régressions graves (lorsqu’une mise à jour de l’OS casse une application existante) et aux problèmes de sécurité critiques ; cela n’inclut ni investigations individuelles ni améliorations de fonctionnalités.²

Troisièmement, les applications VB6 ne pourront désormais survivre que sous forme de processus 32 bits. Le runtime est exclusivement 32 bits, et sur les OS 64 bits, il n’est pris en charge que dans l’environnement d’émulation WOW64.² Dès qu’un besoin d’interopérer avec une DLL ou un SDK exclusivement 64 bits apparaît, un processus unique ne suffit plus à couvrir l’ensemble du besoin. Nous avons traité la façon de franchir cet obstacle dans « Étude de cas d’un pont COM appelant une DLL 64 bits depuis une application 32 bits ».

3. « Fonctionner » et « rester maintenable » sont deux problèmes distincts

À ne lire que la politique de support, on pourrait croire qu’« il n’y a pas d’urgence ». Mais en pratique, l’environnement de développement et de maintenance s’effondre bien avant l’environnement d’exécution.

• Impossible de se procurer l’EDI. L’EDI VB6 n’est pas pris en charge sur les OS actuels, et maintenir un moyen officiel de l’obtenir et de l’installer devient plus difficile chaque année. Il n’est pas rare de trouver une entreprise où « il n’existe qu’une seule machine dans les locaux encore capable de corriger le code ».
• Le support éditeur des contrôles OCX tiers a cessé. La politique de support elle-même précise clairement que les contrôles tiers relèvent de la responsabilité de l’éditeur.² Il est fréquent que les contrôles OCX de grilles ou d’états imprimés soient déjà introuvables, et le cadre de décision que nous avons présenté dans « Comment traiter ActiveX / OCX aujourd’hui » s’applique directement ici.
• Les personnes capables d’écrire ce code disparaissent. Ce n’est pas un problème de spécification du langage, mais un problème humain. Presque aucun ingénieur n’apprend VB6 aujourd’hui, donc le nombre de personnes capables d’en assurer la maintenance ne fait que diminuer.
• Les exigences périphériques se heurtent au mur du 32 bits. Les nouveaux SDK d’équipements, bibliothèques d’authentification et intégrations cloud supposent de plus en plus le 64 bits et .NET, et les exigences impossibles à intégrer dans un processus VB6 s’accumulent.

Autrement dit, « jusqu’à quand cela fonctionnera-t-il » n’est que la moitié du problème. L’autre moitié est : « lorsque la prochaine correction sera nécessaire, disposera-t-on encore des personnes et de l’environnement pour la réaliser ? » Les plans de migration doivent être établis non pas après qu’un incident survient, mais pendant que les personnes et l’environnement capables de corriger le système sont encore disponibles.

4. Un tableau de décision pour les approches de migration

Même une fois la décision de « remplacer » prise, il existe une gamme de façons de procéder. Voici un panorama des principales approches.

Le choix ne se détermine pas uniquement par le nombre de lignes de code. Microsoft elle-même, en plus de ses guides officiels, oriente vers des partenaires de mise à niveau et de migration (y compris des éditeurs d’outils de migration) pour ce type de projet¹, si bien que la conversion mécanique est une option réelle et concrète. Quelle que soit l’approche retenue, cependant, l’inventaire du chapitre suivant en est un préalable commun.

Notez que les aspects pratiques du choix de « maintenir en l’état + documenter » (figer l’environnement d’exécution, sauvegarder, comment assumer le risque) sont traités dans l’article précédent sur VB6 / Access.

5. Inventaire préalable à la migration — ce qu’il faut examiner avant de toucher au code

La précision de l’estimation et le choix de l’approche dépendent tous deux de la précision de l’inventaire. Établissez au minimum les listes suivantes.

1. Une liste des écrans et des états imprimés — le nombre de formulaires, les écrans réellement utilisés (migrer des écrans inutilisés est un effort gaspillé), les types d’états imprimés et leur destination (impression directe, ou via Excel)
2. Une liste des intégrations externes — laquelle des technologies ADO/DAO/RDO est utilisée pour la base de données et vers quelle cible elle se connecte, les entrées/sorties de fichiers, la communication série ou par socket, les appels à d’autres systèmes
3. Une liste des références OCX / ActiveX / COM — vous pouvez les extraire mécaniquement à partir des références du fichier projet (.vbp). La disponibilité de chaque composant et l’existence d’une alternative influencent directement le choix de l’approche
4. Une liste des déclarations d’API Win32 (instructions Declare) — classez chacune selon son usage (impression, lecture/écriture de fichiers INI, manipulation de fenêtres, etc.), et déterminez si elle peut être remplacée par une fonctionnalité standard de .NET
5. Les règles métier qui n’existent que dans le code — arrondis, dates de clôture, exceptions propres à chaque partenaire, etc. Les endroits où « personne ne sait pourquoi c’est écrit ainsi » sont précisément le terreau des bugs après migration
6. La disponibilité d’un moyen de test — à quoi comparer le comportement migré pour en confirmer l’exactitude. Dans la plupart des cas, la comparaison avec les sorties de l’ancien système (états imprimés, CSV, contenu de la base de données) constitue le moyen de vérification le plus pratique

Cet inventaire n’est pas gaspillé même si vous ne choisissez finalement pas la réécriture complète. Il est même courant que les résultats de l’inventaire révèlent un angle pour une migration progressive — « nous pensions qu’une réécriture complète était nécessaire, mais en réalité la logique du cœur peut être déportée vers la base de données », ou « migrer seulement ces dix écrans en premier suffit à franchir le mur du 64 bits ».

6. Principaux points d’incompatibilité entre VB6 et .NET

VB6 et VB.NET/C# sont des langages plus éloignés que ne le laisse penser leur nom. Que vous optiez pour une conversion mécanique ou une réécriture manuelle, les différences suivantes exigeront toujours des décisions de conception.

Ce qui compte ici, c’est de ne pas se laisser submerger par le volume d’incompatibilités au point de considérer la réécriture complète comme la seule option. Au contraire, le simple fait que les actifs du côté gauche de ce tableau (VB6) fonctionnent encore correctement aujourd’hui constitue la meilleure spécification disponible pour la migration. Faire fonctionner l’ancien système en parallèle comme une « spécification vivante » et comparer les sorties au fur et à mesure est, en pratique, la démarche la plus fiable.

7. Modèles pratiques de migration progressive

Lorsqu’on migre sans arrêter l’activité, la façon dont l’ancien et le nouveau coexistent devient l’élément central. Voici trois modèles représentatifs.

7.1 Migrer d’abord la couche de données

Il s’agit ici de migrer d’abord les données de l’application VB6, depuis un fichier Access ou un format propriétaire, vers par exemple SQL Server, tandis que le côté VB6 continue de fonctionner en changeant simplement sa cible de connexion. Une fois les données modernisées en premier, les nouveaux écrans (côté .NET) peuvent être ajoutés progressivement en s’appuyant sur la même base de données. Pour les étapes concrètes concernant Access, reportez-vous au chapitre sur la mise à niveau (upsizing) de l’article précédent.

7.2 Construire de nouvelles fonctionnalités et de nouveaux écrans en .NET, reliés par interopérabilité COM

Il s’agit d’un montage où les écrans VB6 existants restent tels quels, et où de nouvelles fonctionnalités sont construites en .NET pour coexister avec eux. Deux directions sont possibles.

• Appeler des composants côté .NET depuis VB6 : en exposant une classe .NET en tant que COM, VB6 peut la référencer comme un composant COM ordinaire. Nous avons expliqué comment l’exposer de façon typée même sous .NET 8 et versions ultérieures dans « Appeler une DLL .NET 8 depuis VBA de façon typée — dscom et le TLB » ; la même logique s’applique lorsque l’appelant est VB6 plutôt que VBA.
• Appeler des actifs côté VB6 depuis .NET : une DLL ActiveX construite en VB6 peut être référencée depuis .NET par interopérabilité COM. Cela s’utilise lorsqu’on veut conserver la logique intacte, en bloc, et ne moderniser que les écrans vers .NET dans un premier temps. La contrainte du 32 bits subsiste cependant, il faut donc traiter cette solution comme un pont pour la période de migration, et non comme une solution permanente.

7.3 Séparer les processus et les faire communiquer

Faire coexister l’ancien et le nouveau dans le même processus via l’interopérabilité COM se heurte à des contraintes liées à la « bitness » (32 bits/64 bits) et à la propagation des incidents. Lorsqu’une nouvelle fonctionnalité 64 bits est nécessaire, ou que l’on souhaite isoler les incidents entre l’ancien et le nouveau, on les sépare en processus distincts et on les fait communiquer via des fichiers, des tubes nommés, une communication localhost, etc. Nous avons résumé les options d’intégration entre processus dans le « Tableau de décision pour l’IPC sous Windows », et un exemple concret de pont 32 bits→64 bits dans l’« Étude de cas d’un pont COM ».

Le principe commun à tous ces modèles est le suivant : « regrouper la frontière entre l’ancien et le nouveau en un seul endroit, et fixer le format des données qui la traversent ». Si les frontières se multiplient de façon éparse, écran par écran ou fonctionnalité par fonctionnalité, le coût de la période de coexistence finit par ronger le bénéfice attendu de la migration.

8. Le langage cible de la migration — C# ou VB.NET ?

On a tendance à penser que « venant de VB6, VB.NET est le choix naturel », mais compte tenu de la stratégie linguistique actuelle de Microsoft, ce n’est pas si simple.

La stratégie linguistique officielle positionne Visual Basic (VB.NET) comme « un langage accessible et familier qui conserve une conception stable », en indiquant explicitement qu’en principe, les nouvelles fonctionnalités se limitent à de la consommation (consumption-only), qu’aucune nouvelle syntaxe ne sera ajoutée, et qu’il ne sera pas étendu à de nouveaux types de charges de travail. Parallèlement, l’investissement dans les scénarios cœurs comme Windows Forms et les bibliothèques, ainsi que l’amélioration de l’expérience de développement sous Visual Studio, sont censés se poursuivre.³

Lu du point de vue de la migration, cela donne ce qui suit.

• Même en choisissant VB.NET, les scénarios existants (applications métier WinForms) continueront de fonctionner sans problème dans un avenir prévisible. Pour les équipes comptant de nombreuses personnes expérimentées en VB6, où la proximité syntaxique réduit le coût d’apprentissage, c’est un choix raisonnable.
• Cela dit, C# est recommandé comme socle pour tout ce qui sera écrit à neuf désormais. Son langage et son écosystème continuent d’évoluer, et l’offre d’exemples, de bibliothèques et de compétences se concentre sur C#. C’est un choix fait pour ne pas répéter, dans dix ans, le problème « plus personne pour maintenir VB6 » sous la forme « plus personne pour maintenir VB.NET ».
• En guise de compromis, on peut aussi recevoir la sortie de l’outil de conversion en VB.NET tout en écrivant les nouveaux développements en C#. Sous .NET, les assemblies des deux langages peuvent se référencer mutuellement, donc mélanger les langages en soi ne constitue pas un obstacle.

Pour le choix du framework d’interface (WinForms / WPF / WinUI), reportez-vous au « Tableau de décision pour WinForms, WPF et WinUI » ; pour ce qu’il faut vérifier lors d’une migration directe vers .NET actuel plutôt que vers .NET Framework, reportez-vous à la « Liste de contrôle avant migration de .NET Framework vers .NET ». Sauf contrainte liée à une bibliothèque référencée, il n’y a aucune bonne raison d’adopter délibérément .NET Framework 4.8 comme nouvelle cible lors d’une migration depuis VB6.

9. Conclusion

• La réponse à « jusqu’à quand VB6 fonctionnera-t-il » est : le runtime est pris en charge tant que Windows lui-même l’est (Windows 11 inclus). Mais le support de l’EDI a pris fin dès 2008, donc il n’existe déjà plus de soutien officiel pour reconstruire ou corriger le code — une situation asymétrique.²¹
• L’échéance réelle n’est pas fixée par l’OS, mais par le fait que l’environnement et les personnes nécessaires pour corriger le système soient encore disponibles ou non. Établissez votre plan de migration non pas après un incident, mais pendant que l’ancien système peut encore servir de « spécification vivante ».
• Il existe trois approches : réécriture complète, conversion automatisée et migration progressive. Avant d’en choisir une, dressez l’inventaire de vos écrans, de vos intégrations externes, de vos contrôles OCX, de vos déclarations d’API et des règles métier qui n’existent que dans le code.
• Pour les migrations qui ne peuvent pas arrêter l’activité, utilisez la priorité à la couche de données, l’interopérabilité COM ou la séparation des processus pour faire coexister l’ancien et le nouveau — et regroupez la frontière en un seul endroit.
• Pour tout ce qui est écrit à neuf, C# est recommandé. La trajectoire de stabilité de VB.NET est une politique officielle³, et C# présente un avantage comme socle pour une maintenance à long terme.

Articles connexes

• Prolonger la durée de vie et migrer les applications métier VB6 / Access - un tableau de décision entre conserver, envelopper et remplacer
• Comment traiter ActiveX / OCX aujourd’hui - un tableau de décision entre conserver, envelopper et remplacer
• Étude de cas d’un pont COM appelant une DLL 64 bits depuis une application 32 bits
• Appeler une DLL .NET 8 depuis VBA de façon typée - dscom et le TLB
• Liste de contrôle avant migration de .NET Framework vers .NET
• Tableau de décision pour WinForms, WPF et WinUI
• Qu’est-ce que VBA - contraintes, avenir, cas où il faut le remplacer et modèles de migration réalistes

Domaines de conseil associés

KomuraSoft LLC (合同会社小村ソフト) prend en charge l’inventaire des actifs existants, y compris VB6, et l’élaboration de la stratégie de migration, la conception et la mise en œuvre d’architectures de coexistence entre ancien et nouveau système via des ponts COM et la séparation de processus, ainsi que les projets de remplacement progressif vers .NET.

• Réutilisation des actifs existants et accompagnement à la migration
• Modification et maintenance de logiciels Windows existants
• Développement d’applications Windows
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Les applications VB6 fonctionnent-elles encore sous Windows 11 ?

Oui, elles restent dans le périmètre du support. Selon la politique de support de Microsoft, le runtime VB6 (msvbvm60.dll et autres) reste pris en charge tant que la version de Windows avec laquelle il est fourni l'est elle-même, et la liste des systèmes d'exploitation couverts inclut Windows 11, Windows 10 et Windows Server 2025. Ce support se limite toutefois à la prise en charge des régressions graves et des problèmes de sécurité critiques touchant les applications existantes. Par ailleurs, le runtime VB6 est exclusivement 32 bits : sous Windows 64 bits, il n'est pris en charge qu'au sein de l'environnement de compatibilité WOW64.

Peut-on mener une migration de VB6 vers .NET en s'appuyant uniquement sur un outil de conversion automatisée ?

Il vaut mieux considérer que ce n'est pas possible. Les outils de conversion peuvent réduire le travail de réécriture des définitions d'écran et de la logique simple, mais des éléments comme la gestion d'erreurs par On Error, le code dépendant du type Variant ou des propriétés par défaut, les contrôles ActiveX ou les déclarations d'API Win32 exigent des décisions de conception et des corrections humaines. Plutôt que de déployer directement en production la sortie brute de l'outil, il faut estimer l'ensemble du projet en incluant le travail humain de finition après conversion, et définir à l'avance la méthode de vérification du résultat converti (fonctionnement en parallèle, comparaison des sorties, etc.).

Faut-il choisir VB.NET ou C# comme cible de migration ?

Pour tout ce qui est écrit à neuf, C# est recommandé. La stratégie linguistique de Microsoft positionne Visual Basic (VB.NET) comme un langage qui conserve une conception stable, en indiquant explicitement qu'aucune nouvelle syntaxe ne sera ajoutée et qu'il ne sera pas étendu à de nouveaux types de charges de travail. L'investissement dans les scénarios existants comme Windows Forms se poursuit, donc VB.NET ne devient pas inutilisable, mais comme socle d'un code que vous maintiendrez pendant la prochaine décennie, C#, dont le langage et l'écosystème continuent d'évoluer, présente un avantage en matière de disponibilité de compétences. Les équipes comptant de nombreux développeurs expérimentés en VB6 peuvent raisonnablement choisir de passer par VB.NET, dont la syntaxe est proche.

Avant une réécriture complète, que faut-il faire en premier ?

Il faut faire un inventaire avant même d'écrire une ligne de code. Concrètement : une liste des écrans et des états imprimés, une liste des intégrations externes (bases de données, fichiers, communication série, autres systèmes), une liste des contrôles OCX/ActiveX et des composants COM référencés, une liste des déclarations d'API Win32 (instructions Declare), et un recensement des règles métier qui n'existent que dans le code. Le résultat de cet inventaire révèle très souvent qu'une migration progressive — ne détacher qu'une partie du système, ou migrer d'abord la couche de données — est plus réaliste qu'une réécriture complète.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.