Prolonger la durée de vie et migrer les applications métier VB6 / Access — Tableau de décision entre conserver, envelopper et remplacer

« Une partie de notre système central tourne encore sous VB6 », « le registre que nous avons construit sous Access soutient en réalité toute l’activité d’un service » — dans les missions de conseil auprès des PME, ces deux situations reviennent aujourd’hui encore avec une fréquence remarquablement élevée. Ce qu’elles ont en commun, c’est que la personne qui a construit l’application a généralement déjà quitté l’entreprise, et que plus personne ne peut expliquer précisément pourquoi elle fonctionne encore. Et pourtant, comme elle continue de tourner sans casser, elle finit inévitablement par glisser en bas de la liste des priorités.

Sur ce blog, nous avons déjà traité des éléments techniques individuels tels que ce que sont COM / ActiveX / OCX, le tableau de décision conserver/envelopper/remplacer pour ActiveX / OCX, et les contraintes et l’avenir de VBA. Cet article resserre le sujet et rassemble un guide pratique pour décider, à propos des deux plus grands actifs hérités encore largement répandus aujourd’hui dans les PME japonaises — les applications VB6 et les applications métier Microsoft Access —, s’il faut les conserver telles quelles, prolonger leur durée de vie en n’enveloppant qu’une partie, ou les remplacer. Le cadre de décision reprend tel quel le choix à trois voies « conserver / envelopper / remplacer » utilisé dans l’article sur ActiveX / OCX, mais comme le sujet change, la nature des risques change aussi ; cet article se concentre donc sur les points propres à VB6 et Access.

1. L’essentiel d’abord

• L’EDI et l’environnement de développement VB6 eux-mêmes ont officiellement cessé d’être pris en charge en avril 2008. Il n’existe plus aucun moyen officiel de réaliser de nouveaux développements ou des modifications.¹
• En revanche, le runtime VB6 (msvbvm60.dll et consorts) continue de fonctionner tant que la version de Windows avec laquelle il est fourni est elle-même prise en charge. L’hypothèse selon laquelle « une application VB6 existante continue globalement de fonctionner sur les versions de Windows prises en charge » reste valable aujourd’hui, mais elle dépend entièrement de la durée de support de Windows lui-même.¹
• VB6 est exclusivement 32 bits ; il n’existe pas de compilation native 64 bits. Sur un OS 64 bits, il s’exécute dans WOW64, l’environnement de compatibilité 32 bits.¹ Dès qu’il devient nécessaire d’interagir avec une DLL, un SDK ou un composant COM exclusivement 64 bits, un seul processus ne suffit plus à tout couvrir.
• L’« Access Database Engine » (ACE), qui lit et écrit les fichiers .mdb / .accdb d’Access, est soumis à la même contrainte 32 bits/64 bits. Une seule bitness peut être installée par machine, et elle doit correspondre à celle d’Office.² Depuis Office 2019 / Microsoft 365, l’installation par défaut est passée en 64 bits, si bien que les applications Access ou les composants ActiveX conçus autrefois selon l’hypothèse du 32 bits peuvent cesser de fonctionner dès l’instant où l’on change de poste.³⁴
• L’usage consistant à faire ouvrir simultanément un même fichier .accdb par plusieurs personnes depuis un dossier partagé reste aujourd’hui encore fréquent sur le terrain, mais demeure un facteur de risque de corruption et de dégradation des performances. Il est documenté qu’une écriture via le réseau peut entraîner une corruption des données si la connexion devient instable.⁵ Lorsque la taille du registre ou le nombre d’utilisateurs simultanés augmente, il est temps d’envisager une mise à niveau vers SQL Server ou un système équivalent.
• L’axe de décision est le même que pour ActiveX / OCX : cet actif est-il une simple interface, ou une frontière qui porte aussi la logique métier et les données ? On raisonne dans cet ordre : conserver si le fonctionnement est stable et le périmètre fermé, envelopper si l’on souhaite moderniser seulement une partie, remplacer si les contraintes d’interface ou de socle d’exécution freinent directement l’activité.

2. Où en est VB6 aujourd’hui — le runtime est vivant, mais le développement n’a plus de soutien

Commençons par poser les faits avec précision. Microsoft a déclaré, en date du 8 avril 2008, que « l’EDI de Visual Basic 6.0 (ainsi que l’EDI de Visual Studio 6.0) n’est plus pris en charge », affirmant clairement qu’il n’existe plus de moyen officiel de créer ou de maintenir des applications VB6, et recommandant fortement de migrer vers des technologies modernes.¹

Cette même annonce précise cependant aussi que le runtime VB6 reste pris en charge tant que la version de Windows avec laquelle il est fourni l’est elle-même. On peut s’attendre à ce que les applications VB6 existantes « continuent simplement de fonctionner » sur les versions de Windows prises en charge, mais la portée de ce support se limite au traitement des régressions graves et des problèmes de sécurité critiques.¹ Autrement dit, on peut compter sur l’attente minimale de « ne pas casser une fois installé sur un nouveau Windows », mais il n’existe pas de support au sens de « quelqu’un ajoutera des fonctionnalités ou enquêtera sur des problèmes individuels en cas de difficulté ».

Un autre point qui compte en pratique est que le runtime VB6 est un fichier exclusivement 32 bits, et que sur un OS 64 bits, il n’est pris en charge qu’à l’intérieur de WOW64, l’environnement d’émulation 32 bits.¹ Cela signifie qu’« une application VB6 ne pourra désormais continuer à vivre que sous forme de processus 32 bits ». Le jour où l’on souhaite utiliser un SDK d’instrument de mesure exclusivement 64 bits ou une nouvelle bibliothèque cryptographique, il devient par principe impossible de le charger directement dans le processus VB6. La seule façon de franchir ce mur consiste, en pratique, à « l’isoler dans un processus séparé et à communiquer avec lui » — et la configuration concrète décrite dans « Un pont COM qui appelle une DLL 64 bits depuis une application 32 bits » s’applique telle quelle. Lorsqu’on utilise un pont depuis une application VB6, le principe est identique : confiner la fonctionnalité 64 bits dans un serveur COM hors processus ou un EXE auxiliaire, et faire en sorte que le côté VB6 se contente de l’appeler.

La plupart des applications VB6 embarquent des contrôles ActiveX / OCX comme composants d’interface. La décision conserver/envelopper/remplacer pour ces composants eux-mêmes est traitée en détail dans « Comment traiter ActiveX / OCX aujourd’hui ? » ; reportez-vous-y pour la décision concernant chaque contrôle individuel intégré dans une application VB6. Cet article se concentre sur la décision de niveau supérieur : comment traiter l’application VB6 dans son ensemble.

3. Où en est Access aujourd’hui — formats de fichiers, bitness d’ACE et réalité des dossiers partagés

3.1 .mdb / .accdb et la bitness d’ACE

Les données Access sont stockées dans des fichiers .mdb (ancien format) ou .accdb (2007 et versions ultérieures), et le composant runtime qui les lit et les écrit est l’Access Database Engine (ACE, successeur de Jet). Un problème de désaccord de bitness revient constamment sur le terrain. Le fournisseur Jet OLE DB traditionnel n’est disponible qu’en version 32 bits, et bien qu’ACE soit proposé à la fois en 32 bits et en 64 bits, il est indiqué que seule l’une des deux bitness peut être installée sur un poste donné, et qu’elle doit correspondre à la bitness d’Office sur ce même poste.² Du côté de Visual Studio également, il est explicitement documenté que, Visual Studio 2022 et versions ultérieures s’exécutant en processus 64 bits, certains outils de données utilisant le fournisseur Access 32 bits ne peuvent plus se connecter.⁶

Ce qui complique encore les choses, c’est le changement de valeur par défaut côté Office. Office 2010 à 2016 installait par défaut la version 32 bits, mais depuis Office 2019 et Microsoft 365, l’installation par défaut est passée à la version 64 bits.³ De plus, un processus Office 64 bits ne peut pas charger de binaires 32 bits, si bien que les contrôles ActiveX 32 bits existants et les compléments COM ne fonctionnent pas tels quels sous Office 64 bits.⁴ Autrement dit, la plupart des incidents du type « nous utilisions la même application Access depuis des années, et elle a soudainement cessé de fonctionner après un remplacement de PC » sont dus au basculement par défaut de la bitness d’Office, combiné à l’incapacité d’ACE et des contrôles embarqués à suivre ce basculement. La procédure de diagnostic pour ce type d’incident est détaillée dans « Pourquoi ActiveX cesse de fonctionner sous Office 2024/Microsoft 365, et comment le vérifier ».

3.2 Le risque de l’utilisation multi-utilisateurs sur dossier partagé

Une autre configuration classique pour les applications Access consiste à faire ouvrir simultanément par plusieurs personnes un fichier .accdb placé dans un dossier partagé. À petite échelle, cela peut fonctionner sans problème pendant des années, mais il s’agit d’une configuration intrinsèquement précaire. Il est documenté qu’une écriture via le réseau peut entraîner un échec d’écriture ou une corruption de fichier si la connexion devient instable,⁵ et l’on connaît de longue date des cas où Access signale une erreur de disque/réseau lorsque l’accès au serveur de fichiers est retardé ou expire.⁷ Le germe même de la corruption — l’accès simultané à un fichier partagé — présente une structure très proche des schémas de contention traités dans l’article de ce blog « Les bases du contrôle d’exclusion pour l’intégration par fichiers ». Access intègre un contrôle d’exclusion par fichier de verrouillage (.laccdb), mais plus les « voies sujettes à l’instabilité de connexion » se multiplient — ordinateurs portables en Wi-Fi, télétravail via VPN, reconnexion après une sortie de veille —, plus le taux d’incidents augmente.

L’échappatoire classique lorsque le nombre d’utilisateurs simultanés augmente, ou que le traitement devient plus lourd, consiste à déplacer les tables Access vers SQL Server ou Azure SQL, et à faire référencer celles-ci depuis Access sous forme de tables liées. En utilisant un outil tel que SQL Server Migration Assistant (SSMA), on migre les tables Access puis on remplace les tables Access d’origine par des liens vers les tables migrées : les écrans (formulaires, états, requêtes) restent inchangés, et seules les données sont déplacées vers un socle plus robuste.⁸ Cependant, le passage aux tables liées introduit des problèmes propres à l’après-migration : le traitement d’agrégation peut ralentir (si une requête dépend de fonctions que le serveur ne peut pas exécuter, Access rapatrie d’abord toute la table en local avant de la traiter), et le comportement des colonnes NuméroAuto change — des situations qui obligent parfois à remplacer ces requêtes par des requêtes pass-through ou des vues.⁸ Il est par ailleurs recommandé de longue date de scinder une application Access en une base « back-end » contenant les tables et une base « front-end » contenant les écrans, requêtes et macros.⁹ Le point crucial ici est que le simple fractionnement ne suffit pas. La configuration correcte consiste à ne placer dans le dossier partagé que le back-end (les tables), et à copier le front-end sur le poste de chaque utilisateur, chacun l’exploitant depuis sa propre copie locale. Un usage où même le front-end reste un unique fichier sur le dossier partagé, ouvert en continu par tout le monde, conserve — même après fractionnement — le risque de « lectures et écritures simultanées des écrans, requêtes et macros sur un fichier partagé », provoquant des problèmes tels que l’allongement du temps d’ouverture ou des conflits lors des changements de conception. Que l’on prolonge la durée de vie du dossier partagé ou que l’on bascule vers SQL Server, le premier point de contrôle consiste à vérifier si le « partage du back-end » et le « déploiement local du front-end sur chaque poste » sont déjà en place tous les deux.

4. Tableau de décision

En organisant les applications VB6 et Access selon leur usage et leurs facteurs de risque, on obtient les décisions suivantes.

À titre de précision, « envelopper » dans ce tableau signifie le plus souvent moderniser d’abord seulement les données, ou seulement la frontière, tout en conservant pour l’instant les écrans et la sensation d’utilisation. Il ne s’agit pas de tout reconstruire d’un coup, mais de considérer cela comme un point d’atterrissage temporaire pour traiter en priorité les parties les plus risquées.

Pour utiliser ce tableau, commencez par restreindre les lignes correspondant à la « cible », puis vérifiez si votre situation correspond à l’« usage / facteur de risque ». Il est important de garder à l’esprit que, même pour une seule et même application VB6, il est tout à fait légitime de répartir la décision ligne par ligne, fonctionnalité par fonctionnalité — tel écran sera conservé, telle fonctionnalité sera enveloppée. Si l’on se contente de trancher globalement « c’est une application VB6, donc on traite tout de la même façon », on finit par entraîner dans l’effort même les parties stables qui auraient pu être conservées, et la charge de travail gonfle inutilement.

5. Comment appliquer la décision selon le scénario

Lorsqu’on applique le tableau de décision à des situations réelles de conseil, on converge le plus souvent vers l’un des trois schémas suivants.

Scénario 1 : une application VB6 de gestion des stocks à usage interne, avec des demandes de changement réduites. Si les postes concernés sont fixés à quelques unités et que la configuration ne sort jamais sur le réseau, le tableau de décision penche vers « conserver ». La démarche pratique se résume alors à empiler méthodiquement les mesures d’atténuation des risques du chapitre 7 (sauvegardes, documentation, fixation de l’environnement d’exécution). Sauf motivation réelle de migrer vers .NET, le rapport coût/bénéfice ne s’y prête généralement pas.

Scénario 2 : un registre Access partagé entre plusieurs services, dont le nombre d’utilisateurs a augmenté. Une consultation fréquente concerne une application Access utilisée il y a quelques années par 2 ou 3 personnes, qui a atteint une dizaine d’utilisateurs simultanés à la suite d’une fusion de services ou d’une expansion de l’activité. Dans ce cas, le tableau de décision penche vers « envelopper ». On commence par vérifier si le partage du back-end et le déploiement local du front-end sur chaque poste sont en place (section 3.2) ; si ce n’est pas le cas, on procède d’abord au fractionnement et au redéploiement. Ensuite, si des signes de corruption ou de dégradation des performances apparaissent (allongement du temps d’ouverture, fichiers .laccdb qui persistent sans que le verrou ne se libère, etc.), on migre les tables vers SQL Server et l’on bascule Access en référencement via tables liées.⁸ Les écrans pouvant rester quasiment inchangés, on renforce uniquement le socle de données tout en limitant le coût de formation des utilisateurs.

Scénario 3 : une application centrale VB6 dont le développeur est parti, avec une demande de passage au Web. Dans une situation où le code source existe mais où personne n’est capable d’y toucher, et où une demande d’accès depuis l’extérieur de l’entreprise a émergé, le tableau de décision penche vers « remplacer ». Cependant, plus l’application est centrale, plus une réécriture complète immédiate présente un risque élevé. Comme indiqué au chapitre 9, il est réaliste de commencer par un inventaire de la logique métier et par l’extraction des fonctionnalités à faible impact, puis de progresser par migration en étapes.

6. Anti-patterns fréquents

Partageons d’abord les schémas d’échec que l’on rencontre de façon récurrente dans les projets de prolongation et de migration de VB6/Access. Avant d’appliquer le tableau de décision, vérifiez d’abord si vous ne vous reconnaissez pas dans l’un de ces cas.

Parmi ces cas, les deux qui se produisent le plus fréquemment sont la cohabitation de bitness laissée en l’état et la croissance non maîtrisée du nombre d’utilisateurs sur un dossier partagé. Aucun des deux n’est un problème qui « cassera aujourd’hui » ; ils partagent le trait commun de ne se révéler qu’à l’occasion d’un déclencheur qui finira immanquablement par survenir un jour — renouvellement de poste, augmentation du nombre d’utilisateurs, etc.

7. Mesures réalistes d’atténuation des risques en cas de conservation

La décision de conserver l’application est réaliste dans de nombreux cas, et ce n’est pas une erreur en soi. Mais plus l’on prolonge la logique « ça fonctionne, donc on n’y touche pas », plus s’accumule le risque que plus personne ne puisse expliquer les hypothèses sous-jacentes. Il faut, au minimum, prendre en charge les points suivants :

• Faire tourner mécaniquement une gestion de sauvegardes par génération. Le .accdb d’Access étant contenu dans un seul fichier, le simple fait de prendre des sauvegardes générationnelles quotidiennes permet déjà d’absorber un nombre non négligeable d’incidents. Pour les applications VB6, préservez l’ensemble du code source (.vbp, .frm, .bas, .cls) ainsi que les OCX, DLL et informations d’enregistrement de registre dont l’application dépend.
• Documenter les hypothèses de l’environnement d’exécution, comme parade à l’absence de successeur. Consignez l’OS pris en charge, la bitness d’Office, ainsi que les runtimes, DLL dépendantes et procédures d’enregistrement nécessaires, au moins avec un niveau de détail permettant de savoir « que vérifier lorsque cela cesse de fonctionner sur un nouveau PC ».
• Figer délibérément l’environnement d’exécution. Comme les mises à jour automatiques de Windows ou d’Office, en modifiant la bitness ou les réglages par défaut, peuvent déclencher des incidents (section 3.1), appliquez une politique de mise à jour distincte aux postes concernés, avec une vérification préalable au déploiement.
• Préparer un test de fumée (smoke test) sur environnement propre. Disposer, avant tout déploiement sur un nouveau poste, d’une procédure permettant de vérifier que l’installation, l’enregistrement, le lancement et les opérations principales fonctionnent sur un environnement vierge réduit le temps perdu, à chaque déploiement, sur des blocages du type « ça devrait marcher, mais ça ne marche pas ».
• Regrouper les points d’appel en un seul endroit. Plutôt que de disperser les appels COM de VB6 ou les références aux tables liées d’Access dans toute l’application, réduire autant que possible le nombre de points d’entrée rend explicite le point de départ le jour où l’on souhaitera envelopper ou remplacer.

À titre de point d’attention propre à VB6, mentionnons également la préservation de la machine de développement elle-même. Le support d’installation et la licence de l’EDI, les versions développeur des contrôles externes (OCX) nécessaires à la compilation, ainsi que les notes de procédure de build, sont des actifs qui se dispersent encore plus facilement que l’environnement d’exécution. Même sans projet de modification à court terme, conserver un environnement (par exemple un instantané de machine virtuelle) permettant de reproduire la compilation élargit considérablement les options disponibles le jour où une petite modification devient nécessaire.

Si vous souhaitez maintenir et modifier un logiciel Windows existant sans le casser, cela relève du champ Modification et maintenance de logiciels Windows existants.

8. Options réalistes en cas d’enveloppement

« Envelopper » est une approche qui consiste à confiner l’ancien actif à l’intérieur d’une frontière étroite, tout en présentant une nouvelle interface vis-à-vis de son environnement. Pour VB6 et Access, cela se ramène globalement aux trois schémas suivants.

(a) Appeler un composant COM VB6 depuis .NET via l’interopérabilité COM. Si un module de classe écrit en VB6 est exposé sous forme de DLL ActiveX (ou d’EXE, s’il est hors processus), il peut être appelé depuis .NET via l’interopérabilité COM. Le côté VB6 restant en 32 bits, l’appeler depuis une application .NET 64 bits se heurte au même mur de bitness évoqué au chapitre 2. Le choix entre aligner l’appelant sur le 32 bits ou le confiner dans un processus 32 bits en tant que serveur COM hors processus peut s’appuyer directement, en le retournant, sur la configuration décrite dans « Un pont COM qui appelle une DLL 64 bits depuis une application 32 bits ». Pour les bases de COM lui-même, reportez-vous à « Que sont COM / ActiveX / OCX ? »

(b) Migrer par étapes la logique VBA d’Access vers .NET / le Web. Parmi les applications Access, certaines concentrent une logique métier dense derrière leurs formulaires, tandis que d’autres se limitent à de la simple saisie de données ou de l’affichage de listes — les deux cas coexistent souvent au sein d’une même application. Une démarche réaliste consiste à commencer par inventorier les modules VBA, à extraire d’abord vers une bibliothèque de classes .NET la logique de calcul et de validation pure, indépendante des autres systèmes, puis à faire en sorte que le côté Access l’appelle via COM ou via une API Web intermédiaire. Les contraintes propres à VBA lui-même, et jusqu’où il convient de le laisser en VBA, sont détaillées dans « Qu’est-ce que VBA - contraintes, avenir, et cas où il faut le remplacer ».

(c) Remplacer d’abord uniquement l’UI, en préservant les données et la logique. Si les insatisfactions portent principalement sur des formulaires Access datés, lents, ou inaccessibles depuis l’extérieur de l’entreprise, une option consiste à laisser inchangées la couche de données (tables migrées vers SQL Server) et la logique, et à remplacer uniquement l’UI par une technologie Web ou de bureau moderne. Combinée au passage en tables liées du chapitre 3.2, cette approche rend possible un fonctionnement transitoire en double, où « les données résident dans SQL Server, et l’ancienne UI (Access) comme la nouvelle UI consultent les mêmes données ». Cependant, si le VBA côté Access couple étroitement l’UI et la logique, ce travail de séparation lui-même ne peut aboutir sans avoir d’abord réalisé l’inventaire décrit en (b).

Pour résumer ces trois options :

Si vous souhaitez d’abord échanger sur l’organisation des frontières ou l’orientation de la migration, cela relève de l’Accompagnement à la réutilisation et à la migration des actifs existants ; pour une revue de conception avant la mise en œuvre, c’est le Conseil technique et revue de conception.

9. Démarche à suivre en cas de remplacement

On choisit le remplacement lorsque les contraintes d’UI ou de bitness freinent directement le rythme de l’activité, ou lorsque l’absence de développeur rend la maintenance elle-même intenable. Plutôt que de se lancer d’emblée dans une réécriture complète, suivre l’ordre suivant réduit les incidents.

1. Vérifier d’abord la migration des données. Dans des migrations comme Access → SQL Server, certains écarts ne se révèlent qu’après coup : différences dans le moment d’attribution des NuméroAuto, dépendance à des fonctions propres à Access, absence d’index unique, etc.⁸ Effectuez des allers-retours de tests de migration et de scénarios métier sur une copie des données de production avant de passer à la bascule en production.
2. Inventorier la logique métier. Passez en revue, fonctionnalité par fonctionnalité, le contenu des formulaires/modules VB6 et du VBA/macros/requêtes d’Access, et distinguez ce qui est une « simple interface » de ce qui est une « frontière porteuse de spécifications ». Cette distinction s’opère de la même façon que pour ActiveX / OCX, mais pour VB6 et Access, la compréhension métier accumulée au fil de longues années d’exploitation constitue elle-même un actif, ce qui rend la découverte intrinsèquement plus longue à mener.
3. Progresser par migration en étapes (le pattern strangler). Plutôt que de remplacer toutes les fonctionnalités d’un coup, extrayez d’abord vers le nouveau système les fonctionnalités les moins risquées et les plus indépendantes, et faites coexister l’ancienne et la nouvelle application pendant une période donnée. Clarifier, fonctionnalité par fonctionnalité, laquelle des données — anciennes ou nouvelles — fait foi, et décider à l’avance des conditions de fin de la période de coexistence, sont les conditions minimales pour éviter que cette démarche n’échoue.
4. Régler d’abord le remplacement des composants d’UI ou de la disposition des écrans facilite la suite. Si une application VB6 utilise ActiveX / OCX comme composants d’interface, remplacer d’abord uniquement ces composants par des contrôles modernes facilite l’estimation du remplacement global qui suivra. Pour les décisions individuelles, reportez-vous à « Comment traiter ActiveX / OCX aujourd’hui ? »
5. Préparer des moyens d’observation pendant la période de coexistence. Tant que l’ancienne et la nouvelle application fonctionnent en parallèle, préparez des journaux ou un mécanisme de rapprochement permettant de comparer les résultats produits par l’un et l’autre traitement. Procéder à la bascule sans aucun moyen d’observation risque de retarder de plusieurs mois la découverte d’un incident du type « depuis le passage au nouveau système, les chiffres ne correspondent plus ».

Pour un service couvrant l’ensemble du processus, de l’inventaire des spécifications d’une ancienne application Windows jusqu’au remplacement par étapes, voir Remplacement d’application Windows (page en japonais).

10. Liste de contrôle pour démarrer une migration

Réaliser l’inventaire dans l’ordre suivant avant d’appliquer le tableau de décision (chapitre 4) permet de raccourcir considérablement le temps nécessaire pour arrêter une orientation.

1. Recenser les cibles. Dressez la liste des fichiers .exe / .dll / .ocx de VB6 et des fichiers .mdb / .accdb d’Access, par nom de fichier, version et emplacement.
2. Vérifier l’usage. Confirmez le nombre d’utilisateurs, la présence ou non d’accès simultané, s’il s’agit d’une exploitation sur dossier partagé, et si l’usage est quotidien ou mensuel.
3. Vérifier les hypothèses de l’environnement d’exécution. Identifiez la version de Windows prise en charge, la bitness d’Office, et la présence des runtimes, DLL dépendantes et enregistrements COM nécessaires (chapitres 2 et 3).
4. Vérifier l’emplacement et le volume des données. Pour Access, relevez la taille du fichier, le nombre de tables, le nombre d’enregistrements et leur rythme de croissance. Ces éléments serviront de base pour décider de la nécessité d’un passage à SQL Server.
5. Estimer la complexité de la logique métier. À partir du nombre de lignes des modules VBA, du nombre de macros, du nombre de formulaires, et du nombre de formulaires/modules de classe côté VB6, faites-vous une idée approximative de la charge de travail que représentera l’inventaire.
6. Vérifier l’existence de sauvegardes et de procédures de restauration. Pour toute cible sans sauvegarde en place, ou dont la restauration n’a jamais été testée, il faut d’abord régler ce point, avant même de prendre une décision.
7. Appliquer les résultats obtenus jusqu’ici au tableau de décision. Une fois la cible et l’usage clarifiés, confrontez-les au tableau du chapitre 4 pour déterminer provisoirement, fonctionnalité par fonctionnalité, si l’on penche vers conserver, envelopper ou remplacer.

Sauter cette étape tend à mener, plus tard, à une situation où la charge de travail gonfle sans que personne ne puisse expliquer ce qui a réellement posé problème.

11. Résumé

Ce qu’il faut examiner en premier lorsqu’on décide du traitement à réserver à VB6/Access n’est pas « son ancienneté », mais les trois points suivants.

• Comprenez-vous correctement l’hypothèse selon laquelle VB6 est un environnement d’exécution exclusivement 32 bits ayant perdu le soutien de son EDI (chapitre 2) ?
• Avez-vous intégré le fait que l’ACE et l’ActiveX d’Access sont liés à la bitness d’Office, et que l’exploitation sur dossier partagé voit son risque de corruption augmenter à mesure que l’accès simultané se développe (chapitre 3) ?
• Êtes-vous capable de distinguer si cet actif est une simple interface, ou une frontière qui porte aussi la logique métier et les données (le tableau de décision du chapitre 4) ?

Une fois ces trois points clarifiés, la démarche à suivre en découle naturellement : si l’on « conserve », figer l’environnement d’exécution et ne pas négliger les sauvegardes ni la documentation (chapitre 7) ; si l’on « enveloppe », protéger les données et la logique via un pont 32/64 bits ou un passage progressif à .NET/au Web (chapitre 8) ; si l’on « remplace », vérifier d’abord la migration des données et inventorier la logique métier (chapitre 9). VB6 et Access ne sont pas des actifs à jeter aveuglément simplement parce qu’ils sont anciens — ce sont des objets concrets qui concentrent des années de connaissance métier. Mais on ne peut pas indéfiniment fuir les devoirs nécessaires pour continuer à vivre avec eux : fixation de l’environnement d’exécution, clarification des frontières, vérification des migrations. Nous recommandons de commencer par l’inventaire, en suivant la liste de contrôle du chapitre 10.

Articles connexes

• Qu’est-ce que VBA ? Contraintes, avenir et cas où le remplacer — modèles de migration réalistes
• Comment traiter ActiveX / OCX aujourd’hui ? — Tableau de décision conserver, envelopper, remplacer
• Que sont COM / ActiveX / OCX ? — Différences et relations expliquées
• Pourquoi ActiveX cesse de fonctionner sous Office 2024/Microsoft 365, et comment le vérifier
• Un pont COM qui appelle une DLL 64 bits depuis une application 32 bits
• Les bases du contrôle d’exclusion pour l’intégration par fichiers — bonnes pratiques de verrouillage de fichiers et de claim atomique

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge l’inventaire des actifs existants — VB6 et Access compris — et la clarification de l’orientation de migration, la conception de solutions de prolongation incluant des ponts 32 bits/64 bits, ainsi que la planification et la mise en œuvre de remplacements par étapes.

• Accompagnement à la réutilisation et à la migration des actifs existants
• Remplacement d’application Windows (page en japonais)
• Modification et maintenance de logiciels Windows existants
• 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.

Une application VB6 fonctionne-t-elle encore sur les versions actuelles de Windows ?

L'EDI (environnement de développement) de VB6 a officiellement cessé d'être pris en charge en avril 2008, mais le runtime VB6 (msvbvm60.dll et consorts) reste pris en charge tant que la version de Windows avec laquelle il est fourni l'est elle-même. Autrement dit, les applications VB6 existantes continuent globalement de fonctionner sur les versions de Windows prises en charge. Cependant, VB6 est exclusivement 32 bits et s'exécute, sur un OS 64 bits, dans l'environnement de compatibilité WOW64 ; dès qu'une interaction avec une DLL, un SDK ou un composant COM exclusivement 64 bits devient nécessaire, il faut mettre en place une architecture où cette partie est isolée dans un processus séparé.

Pourquoi mon application Access a-t-elle cessé de fonctionner après un remplacement de PC ?

Dans la plupart des cas, la cause est un changement de bitness d'Office. Office 2010 à 2016 s'installait par défaut en version 32 bits, mais depuis Office 2019 et Microsoft 365, l'installation par défaut est passée en 64 bits. L'ACE (Access Database Engine), qui lit et écrit les données Access, ne peut être installé qu'en une seule bitness — 32 bits ou 64 bits — par poste, et cette bitness doit correspondre à celle d'Office. De plus, la version 64 bits d'Office ne peut pas charger de contrôles ActiveX ou de compléments COM 32 bits, si bien que les composants conçus autrefois selon l'hypothèse du 32 bits cessent de fonctionner sur le nouveau poste.

Est-il problématique que plusieurs personnes ouvrent un fichier Access depuis un dossier partagé ?

C'est un facteur de risque de corruption et de dégradation des performances. Une écriture via le réseau peut entraîner une corruption des données si la connexion devient instable, et le taux d'incidents augmente à mesure que se multiplient les ordinateurs portables en Wi-Fi ou le télétravail via VPN. Au minimum, il faut adopter une architecture scindée où seul le back-end contenant les tables est partagé, et où le front-end contenant les écrans et les requêtes est copié sur le poste de chaque utilisateur. Lorsque le nombre d'utilisateurs simultanés augmente, il devient temps d'envisager de migrer les tables vers SQL Server et de faire référencer celles-ci par Access sous forme de tables liées.

Faut-il conserver, envelopper ou remplacer une application VB6/Access ?

L'axe de décision est de savoir si cet actif est une simple interface ou une frontière qui porte aussi la logique métier et les données. Si le poste et la version de Windows sont fixes et que les demandes de changement sont réduites, conserver l'application — en s'appuyant sur des sauvegardes, une documentation et un environnement d'exécution figé — est souvent le choix le plus rentable. Si une interaction 64 bits ou un renforcement du socle de données est nécessaire, on enveloppe seulement une partie via un pont COM ou une bascule vers des tables liées SQL Server. En l'absence de développeur pour assurer la maintenance, ou face à une demande de passage au Web, on choisit le remplacement — mais plutôt qu'une réécriture complète immédiate, une migration par étapes, en vérifiant d'abord la migration des données puis en réalisant un inventaire de la logique métier, est la démarche réaliste.

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.