Migration VB6 vers .NET 8 ou Next.js — Sans perdre vos règles métier

#VB6 en France — État des lieux 2026

Visual Basic 6 a fêté ses 28 ans en 2026. Microsoft a mis fin au support standard en mars 2005, puis au support étendu en avril 2008. Cela fait donc 18 ans que l'environnement d'exécution VB6 ne reçoit plus le moindre correctif de sécurité, plus aucune mise à jour de compatibilité, et aucun support officiel.

Pourtant, si vous lisez cette page, c'est très probablement parce que vous gérez encore une ou plusieurs applications VB6 en production. Vous n'êtes pas seuls. Gartner estimait en 2024 que plus de 200 000 applications VB6 tournaient encore activement dans le monde, traitant des données métier critiques chaque jour. En France, trois secteurs concentrent l'essentiel du parc VB6 survivant.

Le secteur bancaire et financier. Les établissements bancaires de taille moyenne ont souvent construit leurs back-offices de traitement des opérations sur VB6 entre 1996 et 2004, quand la plateforme était en pointe sur Windows. Ces applications traitent encore aujourd'hui des virements, des rapprochements comptables, des éditions réglementaires. Les remplacer n'a jamais été une priorité budgétaire — jusqu'à ce que DORA entre en vigueur.

Le secteur de l'assurance. Les systèmes de gestion des sinistres, de calcul de primes, et d'édition de polices construits sur VB6 au tournant des années 2000 sont nombreux dans les compagnies d'assurance régionales et mutualistes. Le modèle de formulaires VB6 — une Form par écran, une procédure événementielle par bouton — correspondait exactement au workflow papier des gestionnaires sinistres de l'époque. La logique métier est souvent directement dans les procédures Form_Load et Button_Click, sans couche intermédiaire.

L'industrie manufacturière. Les fabricants ont utilisé VB6 massivement pour automatiser des machines-outils via COM/OPC, pour gérer des plannings de production, pour éditer des étiquettes de traçabilité. Ces ERP sur-mesure ont des dizaines d'années de règles métier accumulées — règles de tarification, gammes opératoires, calculs de besoin en composants — qui n'ont jamais été documentées ailleurs que dans le code.

#Pourquoi ces applications tournent encore en 2026

La raison la plus fréquente : "ça marche". L'application fait ce qu'elle doit faire. Les utilisateurs la connaissent par cœur. Changer signifie risquer une régression, imposer une formation, et mobiliser un budget qui peut aller ailleurs.

Deuxième raison : la peur de perdre les règles métier. Des décennies de corrections, d'ajustements, d'exceptions codées — tout ça vit dans des procédures VB6 non documentées, souvent écrites par des développeurs qui ne sont plus dans l'entreprise. La crainte légitime est de migrer et de "casser quelque chose" que personne ne saura expliquer mais que tout le monde remarquera immédiatement.

Troisième raison : l'illusion du statu quo. Tant que l'application tourne, il n'y a pas de crise visible. Les risques sont latents — un incident de sécurité non encore survenu, une incompatibilité Windows qui n'a pas encore frappé, une sanction réglementaire pas encore prononcée. Jusqu'au jour où l'un de ces risques se matérialise.

#Risques techniques et sécurité — Ce que VB6 ne peut plus faire en 2026

#Architecture 32-bit exclusive

VB6 produit exclusivement des binaires Win32 (32-bit). Il ne peut pas générer de code 64-bit. Sur les serveurs Windows modernes, les applications VB6 s'exécutent dans le sous-système de compatibilité WOW64 — ce qui fonctionne encore, mais avec des contraintes importantes : impossible d'accéder à plus de 4 Go de RAM par processus, impossible d'utiliser des bibliothèques natives 64-bit, et des problèmes de performance sur certaines charges de traitement.

#Dépendances COM/ActiveX/OCX

Le modèle de composants de VB6 repose entièrement sur COM (Component Object Model) et sur des contrôles ActiveX (OCX). Ces contrôles nécessitent une registration dans le registre Windows (regsvr32) — une opération qui devient problématique sur Windows 11 et dans les environnements containerisés ou virtualisés modernes. Certains contrôles OCX (notamment ceux qui s'appuient sur le moteur IE/Trident pour le rendu HTML) ont commencé à dysfonctionner avec le retrait d'Internet Explorer en juin 2022.

Les composants COM tiers — contrôles de grille, d'édition de texte enrichi, d'impression — dont les éditeurs ont cessé l'activité depuis 10-15 ans ne sont plus maintenus. Le runtime de ces contrôles tourne encore sur des machines avec les bonnes DLL en cache, mais toute migration vers un poste vierge ou une VM fraîche peut échouer.

#Protocoles réseau et cryptographie

La bibliothèque Winsock de VB6 supporte TLS 1.0 et TLS 1.1 au maximum. TLS 1.0 et 1.1 sont considérés comme non sécurisés depuis au moins 2018 (PCI DSS 3.2.1 a exigé leur désactivation avant juin 2018). Les navigateurs modernes et la majorité des APIs externes n'acceptent plus TLS < 1.2. Une application VB6 qui communique avec un service externe via HTTPS est donc contrainte de passer par une couche proxy ou un shim pour upgrader le TLS — une complexité opérationnelle supplémentaire et une surface d'attaque additionnelle.

#Zéro patch de sécurité depuis 2008

C'est le point le plus critique pour les directions de la sécurité et les équipes de conformité. Le runtime VB6 (msvbvm60.dll) n'a pas reçu de mise à jour de sécurité depuis 2008. Toutes les CVE publiées après cette date concernant le moteur d'exécution VB6 sont restées sans patch officiel. À titre de comparaison, .NET 8 reçoit des correctifs de sécurité réguliers et bénéficie d'un support LTS jusqu'en novembre 2026, avec .NET 9 et .NET 10 LTS déjà disponibles en relais.

#Accès aux données — DAO, ADO, ODBC

L'accès aux bases de données dans les applications VB6 repose typiquement sur DAO (Data Access Objects), ADO (ActiveX Data Objects), ou ODBC via des DSN Windows. Ces couches d'accès aux données sont obsolètes, ne supportent pas les fonctionnalités modernes des bases de données (JSON, full-text search avancé, types de données modernes de PostgreSQL), et présentent des vecteurs de vulnérabilité connus non patchés.

#Trois chemins de migration

Il n'existe pas un seul chemin de migration VB6. Le bon choix dépend du volume de code, des ressources internes, du budget disponible, et surtout de l'évolution fonctionnelle attendue de l'application dans les 5 prochaines années. Voici les trois routes que nous mettons en œuvre chez Nehos.

#Chemin 1 — Retranscription assistée VB6 → VB.NET → C#

Microsoft a fourni l'Upgrade Wizard VB6-to-VB.NET dans Visual Studio, permettant une migration semi-automatique. L'outil convertit entre 40 et 60 % du code de façon exploitable — les formulaires Windows Forms, une partie de la logique événementielle, les types de base. Le résultat nécessite ensuite un refactoring substantiel pour supprimer les patterns COM hérités, remplacer les contrôles ActiveX par des équivalents WinForms ou WPF modernes, et corriger les nombreuses incompatibilités sémantiques entre VB6 et VB.NET.

À l'issue de cette première phase, une deuxième phase optionnelle mais recommandée consiste à migrer de VB.NET vers C# — les deux langages sont équivalents sur le CLR, mais C# est le standard de facto de l'écosystème .NET moderne, avec un pool de développeurs 3 à 4 fois plus large que VB.NET sur le marché de l'emploi.

Quand choisir ce chemin. Codebase > 200 000 lignes, équipe interne maîtrisant .NET, délai contraint (< 12 mois), pas d'évolution fonctionnelle majeure prévue — on veut juste sortir de VB6 et retrouver un environnement patchable.

Risques. Le code résultant de l'Upgrade Wizard est fonctionnel mais rarement élégant — la dette technique initiale du VB6 se retrouve dans le VB.NET converti. Sans refactoring rigoureux, on sort de VB6 pour entrer dans un VB.NET technique difficile à maintenir.

#Chemin 2 — Réécriture C# .NET 8 / MAUI / Blazor

La réécriture C# .NET 8 LTS est le choix le plus propre pour une application desktop Windows devant rester desktop. .NET 8 est la version LTS actuelle, avec support garanti jusqu'en novembre 2026, et .NET 10 LTS prendra le relais. MAUI (Multi-platform App UI) permet de cibler Windows, macOS, iOS et Android depuis une base de code C# unique — pertinent si l'application doit un jour tourner sur des terminaux mobiles ou sur Mac. Blazor permet de créer une interface utilisateur en C# qui s'exécute dans le navigateur via WebAssembly, avec un paradigme de composants qui conserve le modèle mental des développeurs .NET.

Sur le back-end, la cible naturelle est ASP.NET Core 8 pour les APIs HTTP, Entity Framework Core 8 pour l'accès aux données, et SQL Server 2022 ou PostgreSQL 16 selon les contraintes de licence.

Quand choisir ce chemin. Application majoritairement desktop, équipe interne .NET disponible ou recrutement prévu, volume de code 50 000-200 000 lignes, nécessité de conserver une interface utilisateur riche (grilles de données, reports, formulaires complexes).

Avantages. Écosystème .NET unifié, pool de recrutement large, excellente intégration avec Active Directory / Entra ID, support LTS garanti, compatibilité native Windows 11.

#Chemin 3 — Réécriture full web Next.js 15 + React

Si l'application VB6 doit évoluer vers une accessibilité web (navigateur, mobile, accès distant sans VPN), la réécriture full web est la solution la plus ambitieuse et la plus durable. La stack Nehos privilégiée : Next.js 15 (App Router) + TypeScript 5 + React 19 en frontend, tRPC pour les contrats d'API type-safe entre front et back, PostgreSQL 16 en base de données (remplaçant Access ou SQL Server 2000/2005 souvent trouvés derrière les applications VB6), et OVHcloud pour l'hébergement souverain français.

Le state management remplace les formulaires VB6 par Zustand (état global léger) et React Hook Form (validation). L'authentification est assurée par Keycloak (SSO entreprise SAML/OIDC) ou NextAuth v5 selon la complexité de l'environnement d'identité existant.

Quand choisir ce chemin. Application dont le périmètre fonctionnel doit évoluer significativement, accès web ou mobile requis dans les 24 mois, remplacement simultané de la base de données Access/SQL Server 2000, opportunité de repenser l'UX (les interfaces VB6 des années 90-2000 sont souvent peu ergonomiques selon les standards actuels).

Risques. Rupture technologique plus marquée, courbe d'apprentissage pour les équipes habituées à .NET pur, durée de projet plus longue (+20-40 % vs chemin 2 à périmètre équivalent).

#Méthodologie Nehos pour la migration VB6

#Étape 1 — Analyse statique du code VB6

Avant de choisir un chemin de migration, il faut comprendre ce qu'on a. L'analyse statique d'un codebase VB6 utilise plusieurs outils complémentaires.

NDepend analyse les assemblies .NET mais peut être couplé avec un pré-traitement du code VB6. VBMigration.com (partenaire Nehos) propose un analyseur VB6 qui produit un rapport détaillé : nombre de formulaires, modules, classes, procédures, lignes de code, complexité cyclomatique par module, liste des dépendances COM et OCX détectées. Ce rapport est la base de l'estimation de migration.

L'analyse manuelle reste indispensable pour un périmètre représentatif. Un ingénieur Nehos examine les modules les plus critiques — souvent identifiés par le client comme "les trucs qu'on ne touche pas" — pour évaluer la densité de logique métier, la qualité des commentaires (ou leur absence totale), et la présence de code mort.

#Étape 2 — Cartographie des dépendances COM

C'est souvent l'étape la plus révélatrice. Les applications VB6 peuvent dépendre de dizaines de composants COM enregistrés localement : contrôles OCX tiers (Sheridan, VSFlexGrid, MSFlexGrid, Crystal Reports), bibliothèques COM Windows (MSXML, ADO, DAO, CDOSYS pour l'envoi de mails), et COM custom développés en interne parfois par des prestataires introuvables.

Nehos extrait la liste complète des dépendances COM depuis les fichiers .vbp (fichiers de projet VB6), le registre Windows, et les références dans les formulaires .frm. Chaque dépendance est classifiée : disponible en équivalent open-source direct, nécessitant un développement de remplacement, ou candidat à l'élimination si la fonctionnalité est devenue obsolète.

#Étape 3 — Extraction et documentation des règles métier

C'est la partie la plus chronophage et la plus délicate. Dans les applications VB6, les règles métier vivent à plusieurs endroits : dans les procédures événementielles des formulaires (Form_Load, Button1_Click), dans des modules standard .bas, dans des stored procedures PL/SQL ou T-SQL côté base de données, et parfois même dans des macros Excel ou Access liées à l'application.

Nehos utilise plusieurs techniques pour extraire et documenter ces règles. L'analyse du flux de données à rebours depuis les écrans de saisie identifie les calculs critiques. L'exécution de l'application en environnement isolé avec capture des trames SQL révèle les requêtes qui implémentent la logique métier côté base. Les entretiens avec les utilisateurs-clés permettent de valider que les règles extraites du code correspondent bien au comportement attendu — et de détecter les cas où le code a divergé des règles officielles.

Le livrable de cette étape : un document de spécifications fonctionnelles reconstituées, en langage naturel structuré, pour chaque module de l'application. Ce document devient la référence de validation pour les tests de régression.

#Étape 4 — Tests de régression automatisés

Avant d'écrire la première ligne de code de remplacement, Nehos construit une suite de tests de régression sur l'application VB6 existante — pour capturer le comportement actuel comme référence. Cela peut sembler paradoxal (tester une application qu'on va remplacer), mais c'est la seule façon de valider que la migration ne perd pas de comportements.

Pour les applications VB6 avec une interface utilisateur, Playwright permet d'automatiser des scénarios end-to-end via l'accessibilité Windows. Pour les couches de données et de calcul, xUnit (sur le code .NET cible) reproduit les calculs VB6 validés manuellement. Les stored procedures sont testées avec pgTAP (PostgreSQL) ou tSQLt (SQL Server) selon la cible.

#Étape 5 — Migration itérative Strangler Fig

Nehos applique le pattern Strangler Fig de Martin Fowler pour les migrations d'applications VB6 de taille significative. Plutôt que de tout réécrire en une fois (big bang — approche hautement risquée), on remplace progressivement des modules de l'application legacy par leur équivalent moderne, les deux systèmes coexistant pendant la transition.

Concrètement : un module de l'application VB6 est remplacé par son équivalent .NET ou web. L'ancien module est désactivé mais pas supprimé. Les utilisateurs sont basculés progressivement. Si un problème survient, le rollback est immédiat. Cette approche permet de mettre en production des résultats tangibles dès les 3-4 premiers mois, tout en réduisant le risque global.

#Étape 6 — Décommissionnement progressif

Quand l'ensemble des modules a été migré et validé en production, le décommissionnement du système VB6 peut commencer. Cette étape inclut l'archivage du code source VB6 (pour référence historique des règles métier), la suppression des entrées COM du registre Windows, la désinstallation du runtime VB6 (msvbvm60.dll) des postes concernés, et la mise à jour de la documentation IT.

#Stack technique cible

#Si migration vers .NET

La stack .NET recommandée par Nehos en 2026 :

Blazor mérite une mention spéciale pour les migrations VB6 : son modèle de composants (un composant = un formulaire avec état et logique) est conceptuellement proche du modèle de formulaires VB6, ce qui facilite la transition pour les développeurs qui connaissent le code original. La courbe d'apprentissage est plus douce que React pour une équipe sortant de VB6.

#Si migration vers le web

La stack Next.js recommandée par Nehos en 2026 :

Le remplacement de Microsoft Access ou SQL Server 2000/2005 (souvent trouvés en backend des applications VB6) par PostgreSQL 16 est systématiquement recommandé pour les migrations full web. PostgreSQL offre des types de données modernes (JSONB, UUID, arrays), des performances supérieures sur les requêtes analytiques, et une licence open-source sans coût de licence.

#DORA et conformité — Ce que VB6 vous expose 2025

DORA (Digital Operational Resilience Act, Règlement EU 2022/2554) est applicable dans l'ensemble de l'Union Européenne depuis le 17 janvier 2025. Il s'applique aux entités financières — banques, assureurs, sociétés de gestion d'actifs, institutions de paiement, fintechs — et à leurs prestataires TIC critiques.

#Article 25 — Gestion des risques liés aux TIC

L'Article 25 de DORA exige explicitement que les entités financières maintiennent un inventaire complet de leurs actifs TIC, incluant les dépendances logicielles, et que cet inventaire soit tenu à jour avec le statut de patch de chaque composant.

Une application VB6 sans patch de sécurité depuis avril 2008 constitue un risque ICT non géré documenté au sens de DORA. En cas d'inspection des autorités compétentes (ACPR en France, NBB en Belgique, FINMA en Suisse), la présence d'applications VB6 en production sans plan de migration formalisé peut être qualifiée de violation de l'obligation de gestion des risques TIC.

#Calendrier réglementaire

DORA est applicable depuis janvier 2025. Les premières inspections ACPR ciblant la conformité DORA ont démarré en 2025. Les établissements n'ayant pas encore formalisé leur plan de sortie des applications non patchées (VB6 en est l'exemple emblématique) ont intérêt à le faire sans attendre — le plan de migration formalisé et daté est en lui-même un élément de conformité, même si la migration n'est pas encore terminée.

#Ce que Nehos peut livrer pour la conformité DORA

Dans le cadre d'un projet de migration VB6, Nehos produit systématiquement :

• Un rapport d'inventaire des dépendances VB6 et de leur statut de patch (exploitable comme pièce justificative pour l'ACPR)
• Un plan de migration formalisé avec jalons et dates (constitue un élément du plan de gestion des risques ICT au sens DORA)
• Une attestation d'avancement à chaque jalon (pour dossier de conformité en continu)

#Métriques et ROI — Ce que la migration VB6 change concrètement

Les migrations VB6 conduites par Nehos sur 2024-2025 donnent les métriques de résultats suivantes.

Réduction des incidents de production : -60 à -80 %. Les crashes COM/OCX, les erreurs de registre, les incompatibilités suite aux mises à jour Windows — tous ces incidents disparaissent une fois sur la cible moderne. Pour les applications VB6 en production intensive (usage quotidien par des dizaines d'utilisateurs), ce chiffre représente souvent plusieurs heures de support et de remédiation économisées chaque semaine.

Réduction du coût de maintenance : -40 à -60 %. Trouver un développeur capable de corriger du code VB6 en 2026 est difficile et coûteux. Le bassin de développeurs C# ou React/TypeScript est 20 à 30 fois plus large. Le coût journalier d'un profil VB6 compétent (quand on en trouve) est 40-80 % plus élevé qu'un profil C# ou JavaScript équivalent. Une fois sur .NET 8 ou Next.js, le recrutement redevient standard.

Time-to-feature divisé par 3 à 5. Les frameworks modernes, l'outillage (hot reload, type-checking, tests automatisés, CI/CD), et la documentation disponible réduisent drastiquement le temps nécessaire pour ajouter de nouvelles fonctionnalités. Une story qui prenait 5 jours dans le codebase VB6 (à cause de la complexité, du manque de tests, et de la fragilité du code) peut descendre à 1-2 jours sur la cible moderne.

Compliance DORA. Pour les établissements financiers, la valeur du risque réglementaire évité est difficile à chiffrer mais réelle. Les sanctions DORA pour violations de gestion des risques ICT peuvent atteindre 1 % du chiffre d'affaires annuel mondial pour les entités financières systémiques.

#Exemple de calcul ROI sur un cas réel

Etablissement de crédit régional. Application VB6 de gestion des dossiers de crédit (120 écrans, 180 000 lignes de code, 14 OCX tiers, 3 COM custom en interne, base Access + SQL Server 2000). Coût de la migration vers C# .NET 8 + Blazor + SQL Server 2022 : 520 000 € HT (projet de 14 mois, pattern Strangler Fig).

Gains annuels post-migration : réduction incidents IT (-3h/semaine évitées à à partir de 50 k€/h) =374 6 400 €/an. Réduction coût maintenance (-40 % sur 2 profils juniors VB6 à7 3 200 €/j, 220 j/an) =1 267 3 200 €/an. Disponibilité nouveaux profils pour recrutement =480 000 €/an de delta salaire. Risque DORA formellement couvert : valeur difficile à chiffrer, inscrite en « avoided risk ». Total gains estimés :2 121 9 600 €/an. ROI en 8-9 mois post-migration.

#Tarification — 30 à 2560 k€ HT

La tarification d'une migration VB6 dépend de trois variables principales : le nombre d'écrans (formulaires VB6), la complexité et le volume des dépendances COM/OCX, et le volume de logique métier en PL/SQL ou T-SQL à migrer.

Ces fourchettes incluent : l'analyse statique et la cartographie COM (Phase 1), les spécifications fonctionnelles reconstituées (Phase 2), la mise en place des tests de régression (Phase 3), le développement itératif sur la cible (Phases 4-5), et l'accompagnement au décommissionnement (Phase 6).

Elles n'incluent pas : les licences logicielles éventuelles sur la cible (SQL Server, licences Windows Server), la formation des utilisateurs finaux, et les développements de nouvelles fonctionnalités au-delà du périmètre existant.

Première évaluation en 30 minutes via RDV : [Calendly audit VB6](https://calendly.com/raphael-poirier_/decouverte15min-nehos-groupe