Migration VB6 : sortir de Visual Basic 6 sans mettre votre activité en danger

Il faut migrer une application VB6 quand le risque de la garder dépasse le coût de la remplacer : composants qui ne s'installent plus, développeur historique parti, besoin d'accès à distance ou d'ouverture vers des clients, postes qu'on n'ose plus mettre à jour. Quatre voies existent : confiner l'application en attendant, la convertir vers VB.NET ou C#, la réécrire en application .NET de bureau, ou la reconstruire en application web. Microsoft recommande lui-même de remplacer ces applications, mais rien n'oblige à le faire en une fois.

Ce guide s'adresse au dirigeant qui doit décider. Les premiers résultats de recherche sur le sujet viennent surtout d'éditeurs d'outils de conversion et de sociétés de services étrangères : utiles sur la technique, muets sur la question qui compte pour vous, à savoir quand migrer, vers quoi, et comment ne pas arrêter l'entreprise pendant ce temps.

Où en est Visual Basic 6 en 2026

Visual Basic 6 date de 1998. Sa déclaration de prise en charge chez Microsoft (consultée le 07/11/2026) distingue trois choses :

Deux précisions comptent. D'abord, la prise en charge du moteur se limite aux régressions graves et aux failles de sécurité critiques. Ensuite, tout reste en 32 bits : sur un Windows 64 bits, l'application tourne dans une couche d'émulation. La même page le dit sans détour : faute de méthode prise en charge pour créer ou maintenir une application VB6, Microsoft recommande fortement de la remplacer par une technologie moderne.

Traduction pour un dirigeant : votre application ne va pas cesser de démarrer demain. Mais chaque correction se fait dans un outil de 1998, souvent sur un vieux poste gardé exprès, par une personne de plus en plus difficile à remplacer.

Les signaux qui justifient une migration

• Le poste de développement est une pièce de musée : une machine ancienne, conservée parce que c'est la seule où le projet compile.
• Un composant tiers bloque : un contrôle de grille, de graphique ou d'impression dont l'éditeur a disparu, qui refuse de s'installer sur un poste récent.
• Le développeur historique part, et personne d'autre ne sait ouvrir le projet.
• Vos équipes ont besoin du logiciel hors du bureau, sur tablette ou téléphone, ou vos clients doivent y accéder.
• La sécurité devient un sujet : audit, assurance cyber, exigences d'un donneur d'ordre. Une application en 32 bits qui dépend d'anciens composants passe mal ce genre d'examen. Voir la sécurité d'une application métier.

Quand il vaut mieux attendre

Une application VB6 qui fonctionne, évolue rarement, ne dépend d'aucun composant tiers fragile et sert des utilisateurs au bureau peut attendre. Dans ce cas, confinez-la :

• postes et serveurs à jour, l'application seule restant ancienne ;
• accès réseau limité, sans exposition directe à Internet ;
• installation documentée et testée sur une machine vierge ;
• sauvegardes de la base vérifiées par une restauration réelle ;
• code source et environnement de compilation archivés.

Ce répit se planifie : fixez une date de réexamen, et lancez la migration dès qu'un des signaux ci-dessus apparaît, plutôt qu'en urgence le jour où un poste ne démarre plus l'application.

Les voies de migration, comparées

Convertir vers VB.NET : la fausse proximité

VB.NET garde des mots-clés de VB6, d'où l'impression d'une simple mise à jour. C'est en réalité un autre langage, sur une autre plateforme : typage strict, gestion des erreurs différente, formulaires reconstruits, accès aux données à revoir. Surtout, Microsoft a écrit en mars 2020, sur le blog de l'équipe Visual Basic, ne plus prévoir de faire évoluer Visual Basic en tant que langage. Le langage reste utilisable et maintenu, mais il n'est pas la cible la plus durable pour un projet qui démarre aujourd'hui.

Passer à C# et .NET

C'est la cible la plus fréquente des migrations VB6. Des outils commerciaux traduisent une bonne partie du code. Leurs taux d'automatisation affichés sont des arguments commerciaux, à vérifier sur un échantillon de votre propre projet. Le résultat peut rester une application Windows de bureau, si vos utilisateurs en ont besoin, ou servir de base à une application web avec ASP.NET Core. Ce choix se justifie surtout si votre informatique est déjà centrée sur Microsoft : SQL Server, Active Directory, Microsoft 365.

Reconstruire en application web

L'application devient accessible dans un navigateur, sur poste, tablette ou téléphone, avec une base comme PostgreSQL ou SQL Server et des interfaces de programmation pour les échanges. Le code VB6 sert alors de spécification : on y lit les calculs, les contrôles et les cas particuliers, sans chercher à le traduire ligne à ligne. C'est la voie qui demande le plus de travail de conception, et celle qui ouvre le plus de possibilités : portail client, accès mobile, intégrations avec votre ERP. Pour la pile technique, voir les technologies d'une application métier.

Les pièges propres aux applications VB6

Les contrôles ActiveX et les DLL

Une application VB6 typique assemble des contrôles OCX : grilles, calendriers, graphiques, onglets, communication série. Ceux de Microsoft ont souvent un équivalent .NET. Ceux de tiers n'en ont pas toujours, et Microsoft ne les prend pas en charge. Ajoutez les appels directs à l'API Windows et les DLL maison : chacun est à inventorier avant tout chiffrage sérieux.

La base Access derrière l'application

Beaucoup d'applications VB6 lisent une base Access (fichier .mdb) par DAO ou ADO, parfois sur un partage réseau. Ce couple pose ses propres problèmes : corruption, verrouillages, limites de taille. La reprise suit la même logique que la migration d'Access vers une application web. Quand la base est déjà sur SQL Server, elle peut souvent rester en place pendant la transition, ce qui simplifie la cohabitation.

Les états imprimés

Crystal Reports, le générateur d'états de VB6 ou des impressions dessinées à la main : une application ancienne compte souvent des dizaines d'états, factures, bons, étiquettes. Ils se refont un par un, en PDF ou pour l'imprimante concernée, et se sous-estiment presque toujours dans les devis.

Les données et les types

VB6 tolère beaucoup : variables non typées, dates saisies en texte, valeurs vides traitées comme des zéros. Ces tolérances ont laissé des traces dans la base. La reprise demande un nettoyage et des migrations de test validées par le métier, détaillés dans la reprise de données lors d'une migration de logiciel.

Les règles métier enfouies

Calculs de prix, remises, échéances, contrôles de saisie écrits dans les événements des boutons, parfois en double dans plusieurs formulaires. On les retrouve en lisant le code, quand vous l'avez, et en observant les utilisateurs. Si le code source est perdu, la conversion est impossible et seule la réécriture reste, guidée par l'observation.

Migrer par étapes

Une bascule unique concentre tous les risques sur une date. La méthode la plus sûre :

1. Inventaire : formulaires et états réellement utilisés, composants, DLL, fichiers échangés.
2. Sécurisation de l'existant : code source archivé, compilation reproductible, sauvegardes testées.
3. Premier module choisi pour sa valeur, souvent ce qui manque le plus aujourd'hui.
4. Prototype validé par les utilisateurs avant tout développement.
5. Cohabitation sur une base partagée ou synchronisée, VB6 assurant tout ce qui n'a pas basculé.
6. Bascule module par module, avec retour arrière prévu, jusqu'à l'arrêt de l'application VB6.

La méthode est détaillée dans la refonte d'une application métier par étapes, et le cas plus large des logiciels sans éditeur dans la refonte d'un logiciel métier qui n'est plus maintenu. Les environnements voisins suivent la même logique : voir la migration Delphi vers le web et la migration WinDev. Si votre « VB » vit en réalité dans des macros Excel, c'est un autre sujet : remplacer des macros VBA Excel.

Combien coûte une migration VB6

Le prix ne se calcule pas au nombre de lignes. Il dépend des formulaires réellement utilisés, des composants à remplacer, des états, des intégrations et de l'état des données. Ce qui alourdit le plus une migration VB6 : les contrôles tiers sans équivalent, la logique dupliquée dans les formulaires et l'absence de documentation. Les postes de coût sont détaillés dans le prix de la refonte d'un logiciel métier.

Les erreurs fréquentes

• Croire qu'un convertisseur livre une application finie : il livre du code à reprendre.
• Reproduire chaque écran à l'identique, au lieu de profiter de la migration pour supprimer ce qui ne sert plus.
• Attendre la panne : migrer dans l'urgence, c'est négocier mal et tester peu.
• Oublier les postes de saisie spécifiques : douchettes, balances, imprimantes d'étiquettes.
• Laisser partir le développeur historique avant d'avoir écrit ce qu'il sait.

La check-list du dirigeant

• Disposez-vous du code source complet et d'un poste qui le compile ?
• Quels contrôles ActiveX tiers l'application utilise-t-elle ?
• La base est-elle un fichier Access, SQL Server ou autre chose ?
• Quels formulaires et quels états servent chaque semaine ?
• Quel besoin justifie la migration : sécurité, mobilité, ouverture, dépendance à une personne ?
• Qui validera les règles métier de la nouvelle application ?

Par où commencer

Rassemblez quelques captures des écrans les plus utilisés, la liste des états et des composants, et si possible une copie de la base. Un premier échange suffit alors à dire s'il faut confiner, convertir ou reconstruire.

Chez LPR Studio, cet échange débouche sur un prototype visuel gratuit du premier module, présenté en visio sous 5 jours ouvrés : vos équipes voient leur futur écran avant toute décision. La démarche est expliquée dans voir son logiciel avant de le payer.