Migration Access vers le web : reprendre la base sans tout arrêter
Migrer une base Access vers le web, c’est d’abord déplacer les tables vers un serveur (SQL Server, Azure SQL ou PostgreSQL), puis reconstruire les formulaires, les états et le code VBA dans une application web. Access peut rester connecté en tables liées pendant la transition. On bascule alors écran par écran, sans tout arrêter. Anaska, dont l’éditeur est WebGuard Agency, décrit ici cette méthode. Le tarif se définit sur devis, après audit.
Access est pratique pour démarrer : un fichier, des formulaires, un peu de VBA, et une petite équipe s’en sort. Les difficultés arrivent quand plusieurs personnes travaillent en même temps dans la même base, quand il faut y accéder à distance, ou quand le fichier grossit et se corrompt de temps en temps. Un fichier partagé sur un serveur se copie aussi facilement, ce qui pose un vrai sujet de droits et de copies sauvages.
Ce n’est pas la même opération qu’une migration WinDev ni que le remplacement d’Excel et de macros VBA. Ici, le cœur du sujet, c’est le fichier .accdb ou .mdb, ses tables, ses requêtes et ses écrans.
Ce que devient chaque élément d’Access
| Élément Access | Devient | Point de vigilance |
|---|---|---|
| Tables | Tables SQL Server, Azure SQL ou PostgreSQL | Types de champs à vérifier un par un |
| Requêtes | Vues ou requêtes côté serveur | Certaines fonctions Access n’existent pas en SQL |
| Formulaires | Pages web | L’ergonomie se revoit au passage |
| États | Documents PDF ou exports générés par le serveur | Mise en page à reprendre |
| Code VBA | Règles côté serveur | Relu, documenté, réécrit et testé, pas converti tel quel |
| Droits d’accès | Comptes et rôles dans l’application | Plus un fichier que l’on copie |
Étape 1 : déplacer les données
Microsoft fournit un outil gratuit, SQL Server Migration Assistant for Access (SSMA), qui aide à transférer tables et données vers SQL Server ou Azure SQL. La marche à suivre est décrite dans la documentation officielle Microsoft (page vérifiée en 200 le 11/11/2026). Pour PostgreSQL, on passe par d’autres outils ou par des scripts. Dans les deux cas, on compare les totaux avant et après le transfert : nombre d’enregistrements, sommes sur les champs métier, contrôles de dates.
Une fois les tables sur le serveur, Access peut s’y connecter en tables liées. Les utilisateurs continuent à travailler comme avant pendant que les écrans web se préparent. C’est souvent la phase la plus rassurante du projet, à condition d’avoir vérifié les types de champs (oui/non, mémo, pièces jointes, valeurs multiples). Un transfert « réussi » sur le nombre de lignes peut quand même décaler une date ou perdre une pièce jointe.
Étape 2 : reconstruire les écrans, les états et le VBA
Chaque formulaire devient une page web, en commençant par les plus utilisés. Les règles écrites en VBA sont relues avec les personnes qui s’en servent, documentées, puis codées côté serveur. On ne convertit pas le VBA ligne à ligne : on en extrait le métier, on le teste, on le réécrit. Les états deviennent des PDF ou des exports. La mise en page, elle, se reprend. Un état Access se retrouve rarement à l’identique.
On met un écran en production, on le recette sur des cas réels, on passe au suivant. Un retour arrière reste possible tant que l’ancienne base, ou les tables liées, sont encore là. Cette progression évite l’arrêt général d’activité, qui fait peur pour peu de gain.
Quelle cible choisir ?
| Cible | Pour quel besoin | Limite |
|---|---|---|
| SQL Server ou Azure SQL, puis application web | Environnement déjà Microsoft, plusieurs utilisateurs | Licences selon l’édition retenue |
| PostgreSQL, puis application web | Base ouverte, sans licence de moteur | Outillage de transfert moins intégré qu’avec SSMA |
| SharePoint, Dataverse, Power Apps | Besoins simples, déjà dans Microsoft 365 | Limites dès que les règles se compliquent |
| Application web sur mesure | Règles riches, accès externes, usage mobile | Projet plus construit au départ |
SharePoint, Dataverse et Power Apps peuvent suffire pour des listes et des formulaires simples, déjà dans Microsoft 365. Dès que les calculs, les droits fins ou les impressions spécifiques pèsent, une application web sur mesure évite de buter plus tard sur les limites du low-code.
Les pièges qui reviennent souvent
Les champs Oui/Non, les champs à valeurs multiples et les pièces jointes n’ont pas d’équivalent direct. Il faut décider comment les représenter avant le transfert, pas après.
Les macros Access et le VBA cachent souvent des règles que personne n’a écrites ailleurs. Les relire prend du temps, et ce temps se rattrape rarement en fin de projet.
Les requêtes qui appellent des fonctions VBA doivent être réécrites côté serveur. Les dates et les formats régionaux méritent un contrôle particulier.
Si plusieurs fichiers Access se parlent (une base pour les données, une autre pour les écrans, des imports Excel), l’inventaire doit tous les lister. Un oubli se paie au moment de la bascule.
Le guide plus général sur la migration de logiciels rappelle le cadre : besoins, planification, validation. Cette page détaille le cas Access.
Comment cadrer le travail, et le budget
Avant de signer, demandez un inventaire : nombre de tables, de formulaires, d’états, volume de VBA, nombre d’utilisateurs, fichiers liés, et la cible envisagée. Le budget se fixe sur devis après cet audit. Aucun montant n’est annoncé ici, parce qu’il dépend trop de cet existant.
Pour poser le contexte, le formulaire de contact d’Anaska suffit. Décrivez la base (Access, ordre de grandeur du nombre d’écrans, SQL Server ou PostgreSQL si vous avez déjà une préférence). Aucun délai de réponse n’est promis ici.