VB6 fonctionne encore en 2026, mais le build est le risque

Une application VB6 qui démarre sous Windows 11 n'a prouvé qu'une chose bien précise: son exécutable actuel trouve une part suffisante de son environnement d'exécution pour se lancer. Elle n'a pas prouvé qu'elle pouvait être recompilée, réparée, installée sur une machine vierge ou restaurée après la panne d'un disque. Ce sont des capacités distinctes, et la plupart des parcs VB6 anciens n'ont testé que la première.

La date dangereuse n'est pas celle où Windows refusera d'exécuter l'EXE. C'est celle où la dernière machine équipée du bon compilateur, du bon Service Pack, des bons fichiers OCX, bibliothèques de types, réglages du registre, version des sources, projet d'installation et pilote de base de données, ainsi que de la mémoire de son opérateur, cessera de démarrer. Une modification métier d'une ligne peut alors devenir un projet de reprise. L'application en état de marche est une preuve à conserver, pas la preuve qu'il n'existe aucun problème.

La prise en charge du runtime ne couvre pas le développement VB6

Microsoft prend toujours en charge le runtime VB6 principal sur les versions de Windows prises en charge, mais pas l'IDE VB6. Cette distinction explique à la fois pourquoi les anciennes applications continuent de fonctionner et pourquoi leur maintenance devient plus difficile chaque année. La déclaration de prise en charge de Visual Basic 6.0 de Microsoft donne It Just Works comme objectif de compatibilité pour les applications existantes. Le même document précise que le développement dans l'IDE n'est plus pris en charge depuis 2008 et recommande de remplacer les applications VB6 par une technologie moderne.

Le périmètre est aussi plus étroit que beaucoup de responsables ne l'imaginent. Microsoft réserve la maintenance du runtime aux régressions graves et aux problèmes de sécurité critiques qui touchent les applications existantes. Ce n'est pas la promesse qu'un ancien programme d'installation, un contrôle tiers, un fournisseur de données abandonné ou le compilateur fonctionnera sur chaque futur poste. Microsoft sépare les fichiers principaux du runtime livrés avec Windows, les fichiers étendus pris en charge que l'application doit distribuer, les fichiers non pris en charge et les composants tiers soumis aux conditions de leur fournisseur.

Un test de compatibilité Windows réussi ne tranche donc pas la question technique. Il indique que ce binaire et cet ensemble de dépendances ont fonctionné pendant ce test. Il ne dit pas si les sources produisent encore ce binaire. Une application compilée peut rester stable pendant des années tandis que la capacité de la modifier disparaît discrètement.

Lors d'un audit de parc, j'emploie quatre états séparés: exécutable, installable, compilable et explicable. Exécutable signifie qu'une copie déjà installée démarre. Installable signifie qu'une image Windows vierge et prise en charge peut recevoir l'application depuis des supports contrôlés. Compilable signifie que des sources contrôlées produisent un binaire traçable. Explicable signifie que l'équipe connaît les systèmes externes, les formats de fichiers et les règles métier dont dépend l'application. Regrouper les quatre sous le mot pris en charge masque précisément le risque que l'audit doit révéler.

L'EXE dépend de bien plus que MSVBVM60.dll

Un exécutable VB6 classique dépend du runtime 32 bits, de l'inscription COM, de contrôles ActiveX, de fournisseurs d'accès aux données, de paramètres situés hors du dépôt et d'hypothèses sur la machine hôte. L'ensemble réel dépasse souvent la liste du fichier de projet, car le code VB6 crée des objets par ProgID, charge des extensions par convention, lance des programmes auxiliaires et lit des chemins dans le registre ou des fichiers INI.

Commencez par la frontière compilée. VB6 produit habituellement du code natif 32 bits ou du p-code, et les fichiers du runtime restent en 32 bits. Sous Windows 64 bits, le processus s'exécute dans WOW64. Chaque DLL ou OCX chargée dans le processus doit donc avoir une version 32 bits compatible. Un remplacement 64 bits inscrit sous un nom proche ne satisfait pas un client COM 32 bits. L'architecture fait partie de l'interface, même si les sources ne la mentionnent jamais.

Examinez ensuite l'identité COM. Les projets VB6 désignent les bibliothèques de types et les composants par GUID, version et identité de classe. Le registre associe ces identités à un serveur physique. Copier un OCX à côté d'un EXE ne l'inscrit pas forcément, et inscrire la mauvaise version peut réparer une application tout en en cassant une autre. Les réglages de compatibilité binaire du projet VB6 déterminent aussi si une DLL recompilée conserve ses identifiants de classes et d'interfaces pour ses appelants. Une recompilation négligente peut réussir sans erreur et bloquer tous les clients.

L'accès aux données ajoute une couche. Les applications peuvent employer ADO, DAO, RDO, des DSN ODBC, des bases Jet, des clients propriétaires ou des noms de fournisseurs construits à l'exécution. Une chaîne de connexion dans les sources ne constitue qu'une partie de la dépendance. Les DSN machine, alias, bibliothèques clientes, certificats et comptes de service peuvent se trouver entièrement hors du contrôle de version. Les paramètres régionaux peuvent modifier l'analyse des décimales, les dates littérales et l'ordre de tri. Les pilotes d'imprimante peuvent changer la pagination des rapports. Les vieux logiciels de bureau ont tendance à transformer l'état du poste en état de l'application.

Inspectez enfin les fichiers qui semblent secondaires: .vbp, .vbw, .res, .frx, .ctl, .ctx, .dsr, .pag, les scripts d'installation et les binaires de compatibilité. Un fichier de formulaire privé du .frx correspondant peut perdre des images incorporées ou des données de contrôles. Un projet qui désigne une DLL de compatibilité binaire située sur le disque d'un développeur peut générer de nouvelles identités COM lorsque ce fichier disparaît. Les sources seules ne forment pas une archive de build.

Windows 11 maintient un îlot de compatibilité 32 bits

Les applications VB6 fonctionnent sur un Windows 64 bits actuel parce que Microsoft livre et teste le runtime principal, et parce que Windows fournit l'environnement WOW64 aux processus 32 bits. C'est un travail de compatibilité délibéré, pas la preuve que VB6 est redevenu une plateforme de développement actuelle. Le runtime, l'IDE et chaque composant externe ont des responsables et des niveaux de prise en charge différents.

WOW64 explique aussi plusieurs chemins trompeurs. Un processus 32 bits qui vise le répertoire système peut être redirigé, tandis que les inscriptions COM 32 bits apparaissent dans la vue 32 bits du registre. Les administrateurs qui utilisent le regsvr32 64 bits sur un OCX 32 bits obtiennent une erreur ou inscrivent le mauvais contexte de composant. Sur un système 64 bits, l'outil d'inscription 32 bits se trouve normalement sous SysWOW64, malgré son nom. Cette appellation historique a fait perdre de nombreuses fenêtres de maintenance.

Ne copiez pas des DLL au hasard dans les répertoires système jusqu'à ce que le programme démarre. Cela modifie l'état global de la machine sans consigner l'application propriétaire du fichier, la version retenue ni la façon de reproduire le résultat. Regroupez exactement les dépendances redistribuables que vous avez le droit de distribuer, installez-les de façon prévisible et testez sur une image vierge. Si l'application exige un contrôle tiers non pris en charge, consignez-le comme contrainte de migration au lieu de prétendre que la prise en charge du runtime principal s'y applique.

Les déploiements sur serveur exigent une vérification supplémentaire. La déclaration de Microsoft limite la prise en charge de Windows Server indiquée aux éditions 64 bits et exclut Server Core pour VB6. Le fait qu'un exécutable de bureau fonctionne sous WOW64 sur une installation complète de Windows Server ne signifie pas qu'il peut rejoindre une image Server Core sans interface. La frontière d'hébergement prise en charge doit figurer dans le dossier de déploiement de l'application.

Construisez l'inventaire des dépendances à partir de preuves

Un inventaire utile associe les références statiques, l'état de la machine et le comportement observé. Aucune de ces sources ne suffit seule. Les fichiers de projet montrent les références déclarées, le registre montre ce que résout la machine de build, et l'observation à l'exécution révèle les objets à liaison tardive et les processus externes. Capturez les trois tant que la machine de référence fonctionne.

Sur la machine de build, exécutez ces commandes dans PowerShell et conservez les résultats avec l'instantané des sources:

Get-ChildItem -Recurse -Include *.vbp,*.mak |
  Select-String -Pattern '^(Reference|Object)=' |
  ForEach-Object { '{0}:{1}:{2}' -f $_.Path,$_.LineNumber,$_.Line } |
  Set-Content declared-com-references.txt

Get-ChildItem -Recurse -Include *.vbp |
  ForEach-Object { Get-FileHash $_.FullName -Algorithm SHA256 } |
  Export-Csv project-hashes.csv -NoTypeInformation

Get-CimInstance Win32_Product |
  Select-Object Name,Version,Vendor |
  Export-Csv installed-products.csv -NoTypeInformation

Le premier résultat associe chaque ligne déclarée Reference= ou Object= à son fichier source et à son numéro de ligne. Le deuxième fournit un condensat pour chaque fichier de projet. L'inventaire des produits est imparfait, car toutes les dépendances n'utilisent pas Windows Installer, mais il offre un point de comparaison. N'exécutez pas Win32_Product de manière répétée dans le parc de production, car il peut déclencher des contrôles de cohérence de l'installateur. Il s'agit d'une capture ponctuelle sur le poste de build isolé.

Ajoutez les métadonnées de chaque DLL et OCX réellement référencée: chemin d'origine, SHA-256, version de fichier, version du produit, signataire, architecture, source de la licence et droit de redistribution. N'exportez les inscriptions COM 32 bits concernées qu'après avoir résolu chaque GUID du projet. Consignez les versions des clients de base de données, les pilotes ODBC et DSN, variables d'environnement, polices, paramètres régionaux, pilotes d'imprimante, tâches planifiées, partages et comptes de service. Les secrets appartiennent au coffre de secrets, pas à l'inventaire. Celui-ci doit nommer le secret et son propriétaire sans en copier la valeur.

Observez ensuite une exécution représentative avec un moniteur d'activité des fichiers et du registre. Exercez le démarrage, la connexion, une transaction normale, les imports, exports, rapports, impressions, erreurs et l'arrêt. Comparez les accès aux fichiers, au registre, au réseau et aux processus avec l'inventaire déclaré. Chaque ProgID à liaison tardive, EXE auxiliaire, lecteur réseau ou dossier d'installation inscriptible qui n'apparaît qu'à l'exécution rejoint l'inventaire.

Terminez par une installation en salle blanche. Partez d'une image Windows éphémère et prise en charge, appliquez uniquement les prérequis documentés, installez l'application et exécutez le parcours de recette. Si un ingénieur doit récupérer un contrôle sur un vieux poste ou se souvenir d'une commande d'inscription non documentée, l'application n'est pas encore installable. Consignez l'écart au lieu de réparer l'image à la main et de déclarer le test terminé.

Quand la dernière machine de build meurt, les sources ne suffisent pas

Si l'unique machine de build éprouvée tombe en panne, l'équipe perd un environnement résolu, pas seulement un ordinateur. Le reconstruire demande de retrouver les médias et le Service Pack du compilateur, les composants sous licence, la résolution des références, les fichiers de compatibilité binaire qui fixaient les identités COM, les étapes préalables ou d'installation, et la version des sources qui a produit la mise en production.

Le premier symptôme apparaît généralement pendant une modification urgente. Une règle fiscale, un endpoint, un certificat, une politique de mot de passe de base de données ou un format de fichier change. Un ingénieur installe l'IDE dans une machine virtuelle, ouvre le projet, ferme quelques alertes de références manquantes, remplace un contrôle indisponible et obtient une compilation réussie. Le nouvel exécutable démarre et part en production. Puis un formulaire rare échoue parce que le contrôle de remplacement sérialise différemment ses propriétés, ou un client COM ne peut plus créer une classe recompilée dont l'identité d'interface a changé. La réussite de la compilation a été confondue avec la parité fonctionnelle.

Les contrôles ActiveX sous licence aggravent la reprise. Certains nécessitent des entrées de licence de conception pour se charger dans l'IDE alors que l'application compilée fonctionne avec une licence d'exécution. Le fournisseur peut avoir disparu, l'activation ne plus exister et la copie d'un OCX installé enfreindre la licence ou oublier des données du registre. Aucune astuce technique ne répare l'absence de droits juridiques. Identifiez la propriété et les conditions de redistribution tant que les dossiers d'achat et la mémoire du personnel existent.

Une image disque du poste de build aide, mais ne résout pas tout. Elle transporte un état caché, des identifiants, un risque de logiciel malveillant et un système d'exploitation qu'il deviendra dangereux de connecter. Elle ne prouve pas non plus qu'un checkout vierge compile. Conservez une image à accès restreint comme preuve et pont d'urgence, puis créez un build scripté et isolé à partir d'entrées contrôlées. Si le build reste impossible sans l'image, dites-le clairement dans le registre des risques.

La décompilation est une technique de secours, pas un substitut au contrôle de version. Les exécutables en code natif perdent les noms et la structure, le p-code offre d'autres possibilités de récupération, et aucun ne restitue de manière fiable les commentaires, scripts de build, formulaires d'origine ou intentions de conception. Vous pourrez peut-être retrouver assez de comportement pour étudier un défaut. Ne fondez pas une modernisation planifiée sur l'espoir de retransformer un binaire en projet d'origine.

Préservez un build avant de modifier l'application

Le premier geste le plus sûr consiste à figer et reproduire le build actuel, sans mêler ce travail à des fonctions ou changements de migration. Il faut une référence dont on puisse comparer les entrées, la chaîne d'outils, les sorties et le comportement. Modifier le code pendant la reconstruction de l'environnement détruit ce point de comparaison.

Capturez ces éléments dans un seul paquet contrôlé:

1. La révision complète du dépôt, avec les ressources de formulaires, sources d'installation et références de compatibilité binaire.
2. Les médias d'installation, Service Packs, contrôles redistribuables, preuves de licence et sommes de contrôle.
3. Un inventaire de la machine et une image à accès restreint du poste de référence.
4. Les commandes exactes, l'ordre des projets, les symboles de compilation conditionnelle et les étapes de création du paquet.
5. Les condensats des binaires de production et une trace signée de la version déployée à chaque emplacement.

Effectuez maintenant un checkout et un build propres dans une machine virtuelle isolée. Gardez le réseau coupé sauf si une entrée documentée du build l'exige. Comparez les fichiers produits, interfaces COM exportées et contenus de l'installateur. Une égalité octet pour octet n'est pas toujours possible à cause des horodatages et des métadonnées du compilateur. Définissez donc l'égalité avant d'accepter le build. Inspectez au minimum les versions de fichiers, dépendances, identités de classes et comportements dans la recette.

Tenez un petit dossier pour chaque tentative. Il peut être en JSON, CSV ou texte signé, mais doit contenir la révision des sources, l'identifiant de l'image d'environnement, les condensats des outils et dépendances, les commandes, l'opérateur, l'horodatage, les condensats des sorties et le résultat des tests. Le but est la traçabilité. Six mois plus tard, un autre ingénieur doit pouvoir identifier exactement ce qui a produit un exécutable sans interroger son auteur.

Ne connectez pas la VM sauvée au réseau normal de l'entreprise en appelant cela de la continuité. Un IDE non pris en charge et de vieux installateurs tiers élargissent la surface d'attaque, tandis que d'anciens clients de base de données peuvent exiger des protocoles qui auraient dû disparaître. Isolez le build, faites passer entrées et sorties par un transfert contrôlé, analysez les artefacts, retirez les identifiants permanents et journalisez les accès. Cela achète du temps. Cela ne rend pas saine une chaîne d'outils non prise en charge.

L'âge seul ne fixe pas la date de migration

La priorité d'une application VB6 dépend de sa capacité de reprise, de la pression des changements et des conséquences d'une panne, pas de son âge. Deux programmes compilés la même année peuvent appeler des décisions opposées. Un outil de consultation en lecture seule sur un poste isolé peut rester confiné, tandis qu'un client de saisie de commandes modifié chaque semaine et écrivant directement en production peut devoir être remplacé avant la prochaine fonction.

Évaluez d'abord la reprise. L'équipe peut-elle installer le paquet publié sur une image Windows vierge et prise en charge? Peut-elle compiler la révision déployée depuis un checkout propre? Chaque contrôle, licence et fournisseur de données est-il répertorié? Plusieurs personnes peuvent-elles publier une version? Un non au build propre augmente l'urgence même sans défaut signalé, car le délai de la prochaine modification est inconnu.

Mesurez ensuite la pression des changements. Comptez les demandes réelles qui exigent du code, pas une insatisfaction générale. Renouvellements de certificats, évolutions d'API, règles fiscales, exigences d'authentification, mises à niveau des bases et nouveaux formats sollicitent tous la même chaîne d'outils qui se réduit. Un carnet de fonctions compte, mais une évolution externe obligatoire à date fixe pèse davantage. L'application peut être achevée sur le plan fonctionnel et subir tout de même les changements imposés par son entourage.

Les conséquences doivent prendre la forme de pannes concrètes. Demandez ce qui arrive si l'application ne démarre pas pendant une journée, calcule mal, perd une transaction ou ne peut être réinstallée après le remplacement d'un poste. Nommez la procédure manuelle et testez-la au volume actuel. Un plan de reprise qui dépend d'un salarié parti ou d'une boîte de médias jamais ouverte ne peut pas être chiffré sérieusement.

L'exposition de sécurité change aussi la réponse. Un outil local qui lit des fichiers contrôlés présente un autre risque qu'un client acceptant des documents venus d'internet, se connectant avec de larges droits de base ou exigeant des protocoles réseau obsolètes. Ne classez pas tout logiciel VB6 comme dangereux uniquement à cause du langage. Retracez ses entrées, droits, dépendances et chemins réseau. L'IDE non pris en charge doit vivre dans un environnement de build isolé, quel que soit le lieu d'exécution de l'application.

Je consigne la décision avec un propriétaire, une date de preuve et un déclencheur, plutôt qu'avec un statut rouge imprécis. Le confinement peut rester valable jusqu'à la fin de prise en charge de l'OS hôte, l'impossibilité de renouveler une licence, l'échec du build propre ou l'annonce d'une évolution incompatible par une intégration nommée. Réexaminez ces déclencheurs. Cela évite autant les réécritures paniquées que l'échec plus courant, une exception temporaire renouvelée indéfiniment sans responsable du risque.

La comparaison des coûts doit dépasser les heures de développement. Ajoutez la conservation des vieilles images, les zones réseau restreintes, les compétences rares sur les composants, le déploiement manuel, la reprise après incident et les changements métier retardés. Pour le remplacement, comptez la réconciliation des données, le fonctionnement parallèle, la formation, la bascule et le retrait. Une estimation honnête peut encore favoriser le confinement. Elle ne doit pas effacer le travail du vieux système sous prétexte qu'il relève des opérations et non d'un budget projet.

Les sorties réalistes ont des profils de risque différents

Il existe cinq voies défendables. La bonne dépend du rythme des changements, de l'exposition opérationnelle et de la part du comportement que vous pouvez observer. Ne rien changer n'est une décision que si l'exécutable a une durée de vie restante bornée, si le build est récupérable, si l'hôte est contrôlé et si le métier accepte le plan de panne. Continuer par inertie n'est pas ce choix.

La virtualisation conserve un ancien environnement et peut le séparer du renouvellement des postes. Elle convient aux outils internes peu modifiés, surtout avec une faible dépendance au matériel. Elle fige aussi dans une image les anciennes faiblesses, contraintes de licence et connaissances d'exploitation. Elle protège la disponibilité lors du remplacement d'un ordinateur portable, mais ne modernise pas l'application et ne rétablit pas le support du fournisseur.

Placer le système VB6 derrière une API peut réduire l'accès direct à sa base et offrir une frontière stable aux nouveaux clients. Cela fonctionne si l'ancien programme expose déjà des opérations métier appelables ou peut être piloté par un adaptateur contrôlé. Cela fonctionne mal si l'automatisation dépend du rythme de l'interface, de boîtes modales, de fichiers partagés ou de l'état global de la machine. L'automatisation de l'interface est un pont provisoire avec une date de retrait explicite, pas une architecture d'intégration.

Le remplacement progressif déplace une capacité délimitée à la fois. Il peut réduire le risque de déploiement quand les frontières de modules sont réelles et que l'équipe peut exécuter les anciens et nouveaux parcours ensemble. Si ces frontières n'existent que sur un schéma, il peut aussi créer des années de doubles écritures, d'interop COM, de règles dupliquées et de rapprochements. Découpez autour de transactions métier observables, pas de dossiers de sources.

Une réécriture complète se justifie quand le système est très couplé, le build échoue, l'architecture cible change le modèle d'exploitation ou le maintien de deux systèmes coûte plus que la transition. L'objection habituelle est qu'une réécriture perd les règles métier cachées. C'est vrai lorsque l'équipe prend les sources pour la spécification et ne teste que les cas heureux. Elle devient défendable quand les comportements enregistrés, les données et les cas limites forment un oracle de comparaison exécutable.

Je déconseille la conversion automatique ligne par ligne. Elle plaît parce qu'elle semble préserver le périmètre et produit un pourcentage mesurable. Elle transporte généralement l'état global, le couplage à l'interface et le comportement accidentel de la base dans un nouveau langage, puis ajoute de la colle d'interopérabilité là où elle échoue. On obtient une architecture ancienne plus difficile à diagnostiquer parce que sa sémantique d'exécution familière a changé. Préservez le comportement, pas l'ancienne disposition des fichiers et formulaires.

Le comportement enregistré est le contrat de migration

Un test de migration doit comparer les effets métier à la frontière d'une transaction, pas seulement des écrans ou des valeurs de retour. Pour chaque opération représentative, capturez la requête normalisée, les données de départ, la configuration concernée, les réponses externes, les changements en base, fichiers produits, messages et résultat visible. Rejouez le même cas sur le remplacement et comparez les effets après retrait des champs variables comme les horodatages et identifiants générés.

Un cas de parité compact peut prendre cette forme:

{
  "case": "invoice-credit-partial",
  "input": {"invoice_id": 4812, "amount": "37.50"},
  "expected": {
    "status": "partially_credited",
    "ledger_delta": "-37.50",
    "document_type": "credit_note"
  }
}

Le nom du cas compte moins que sa provenance. Notez le flux de production qui l'a fourni, retirez les données personnelles, versionnez le jeu d'essai et rendez la comparaison déterministe. Échantillonnez les cas ordinaires et gênants: chaînes vides contre valeurs nulles, décimales locales, jours bissextiles, soumissions en double, délais dépassés, échecs partiels et tentatives répétées. Les applications VB6 codent souvent la gestion des erreurs dans l'ordre des événements et l'état partagé. Testez les séquences autant que les opérations isolées.

Les tests de référence seuls peuvent conserver des bogues. Classez les écarts en correction voulue, différence de représentation sans effet, comportement absent ou défaut du test. Un responsable métier doit approuver les changements voulus, car un ingénieur ne peut pas décider à la lecture du code qu'une règle comptable étrange est accidentelle. Gardez le résultat d'origine à côté de la nouvelle attente approuvée pour laisser une décision vérifiable.

Le trafic de production couvre mieux les usages que des tests unitaires inventés, lorsqu'il peut être enregistré légalement et sans danger. CodeHero utilise un banc de parité fondé sur le trafic de production enregistré tout en modernisant l'architecture plutôt qu'en translittérant les sources. Le principe reste valable sans fournisseur particulier: capturez les demandes réelles, nettoyez-les, rejouez-les et comparez les effets durables.

Choisissez la cible à partir de la frontière du système

La cible doit suivre les frontières de déploiement, de panne et de propriété, pas la mode d'un langage. Une application de bureau qui valide surtout des saisies avant d'appeler une base centrale peut devenir un client TypeScript, des services et Postgres. Un module riche en calculs peut justifier Rust autour d'un petit noyau numérique. Un service transactionnel à la concurrence et à l'exploitation simples peut convenir à Go. Ce sont des conclusions de conception, pas des remplacements automatiques de la syntaxe VB6.

Dessinez d'abord la frontière d'exécution actuelle. Marquez le travail qui doit rester sur la machine de l'utilisateur, celui qui appartient près de la base, les intégrations qui exigent des appels ordonnés et les sorties qui doivent rester compatibles octet par octet. Décidez où vivent l'identité, l'autorisation, les nouvelles tentatives et les traces d'audit. Si deux composants de remplacement doivent partager une transaction de base et être déployés ensemble, les appeler services séparés apporte un mode de panne réseau, pas de l'indépendance.

La migration des données exige la même discipline que le code. Conservez les identifiants, la précision décimale, l'encodage, le traitement des valeurs nulles et les anciens états avant d'améliorer le schéma. Exécutez des requêtes de rapprochement sur les totaux et transitions d'état, pas seulement le nombre de lignes. Si l'ancienne application écrit directement dans les tables depuis de nombreux formulaires, placez une frontière d'écriture contrôlée autour de ce comportement avant de séparer les responsabilités.

Pour un système qui doit quitter VB6 rapidement, CodeHero lit l'ensemble des sources, le réécrit en Go, Rust et TypeScript avec Postgres lorsque c'est pertinent, et livre chaque projet en moins de 30 jours. Que vous reteniez cette voie ou votre équipe, exigez les mêmes preuves: une base de sources reproductible, des décisions d'architecture explicites et des résultats de parité liés à des comportements enregistrés.

N'attendez pas qu'une version de système d'exploitation décide à votre place. La compatibilité Windows peut maintenir l'EXE en vie pendant que le savoir de build, les droits sur les composants et la mémoire de l'équipe disparaissent. Prouvez maintenant un build propre, capturez l'inventaire des dépendances et enregistrez de vraies transactions. Choisissez ensuite confinement, remplacement progressif ou réécriture pendant que le système en service peut encore dire exactement ce que son successeur doit faire.