Visual Basic 6 date de 1998 et son environnement de développement n'est plus supporté depuis longtemps. Pourtant, des millions d'applications VB6 tournent encore en entreprise. Tôt ou tard, la question se pose : faut-il migrer vers .NET ? Et si oui, comment s'y prendre sans casser une application qui fonctionne ?

Pourquoi migrer

  • Pérennité : recruter un développeur VB6 devient difficile, et le runtime dépend du bon vouloir de Microsoft en matière de compatibilité ;
  • Sécurité : le code natif VB6 ne bénéficie pas des protections mémoire modernes ;
  • Écosystème : accès aux bibliothèques .NET, au web, au cloud, aux outils de test et de CI/CD actuels ;
  • Intégration : interopérer avec des systèmes modernes est bien plus simple depuis .NET.

Le prérequis souvent oublié : disposer du code source

La plupart des guides de migration supposent que vous avez le projet VB6 sous la main. Dans la réalité, ce n'est pas toujours le cas : le code source a pu être perdu au fil des années. Or on ne migre pas ce qu'on n'a pas. C'est là qu'intervient la décompilation : reconstituer un projet VB6 exploitable à partir de l'exécutable est le point de départ obligé de toute migration quand les sources manquent. Nous détaillons cette étape dans notre article sur la récupération de code source perdu.

Les stratégies de migration

Réécriture complète. On repart de zéro en .NET moderne. C'est le plus propre, mais aussi le plus long et le plus risqué — la logique métier accumulée sur des années doit être fidèlement reproduite.

Migration assistée. Des outils convertissent automatiquement une partie du code VB6 en VB.NET ou C#. Le résultat demande toujours des reprises manuelles, mais accélère le démarrage.

Migration progressive. On encapsule l'existant et on remplace les modules un à un. Approche la plus sûre pour les applications critiques qui ne peuvent pas s'arrêter.

Les pièges classiques

  • Les contrôles ActiveX et OCX tiers sans équivalent .NET direct ;
  • Le comportement des types de données (Variant, Currency) qui diffère subtilement ;
  • La gestion des erreurs (On Error GoTo) à repenser en exceptions structurées ;
  • Les appels d'API Win32 via Declare à réécrire proprement.

Par où commencer concrètement

Commencez par un inventaire : que fait l'application, de quels composants dépend-elle, et disposez-vous des sources ? Si oui, vous pouvez évaluer les outils de conversion. Si non, la première brique est la récupération du code depuis le binaire — VBReFormer reconstruit interface, ressources et logique, vous donnant une base saine avant d'entamer la modernisation. Vous pouvez tester la récupération gratuitement avec la version gratuite.