Migrer une base Access vers une application web : les trois options

Une base Access se migre vers le web de trois façons : garder Access comme interface et déplacer les données dans SQL Server, reconstruire l'outil dans Power Apps, ou faire développer une application web sur mesure. Le bon choix dépend de trois questions : qui doit y accéder (et d'où), quelle part de la logique vit dans le code VBA, et combien de temps l'outil doit encore durer. Dans tous les cas, la reprise des données et l'inventaire des macros pèsent plus lourd que le développement des écrans.

Cet article s'adresse au dirigeant ou au responsable qui a hérité d'une base Access devenue indispensable, et qui veut savoir quoi faire avant d'appeler un prestataire.

Pourquoi les bases Access arrivent en bout de course

Access a rendu d'immenses services. Un collaborateur débrouillard a construit en quelques semaines un outil de suivi des commandes, des interventions ou des stocks, et l'entreprise tourne dessus depuis quinze ans. Le problème n'est pas Access lui-même, c'est ce que l'entreprise lui demande aujourd'hui.

Des limites techniques documentées

Microsoft publie les spécifications d'Access (relevé du 06/11/2026) : une base est plafonnée à 2 Go, objets système compris, et le nombre théorique d'utilisateurs simultanés est de 255. Dans la pratique, une base partagée sur un dossier réseau devient fragile bien avant ce plafond : verrous, lenteurs, fichiers à compacter et à réparer, sauvegardes faites à la main.

Un outil de bureau dans un monde nomade

Access est une application Windows installée sur chaque poste. Elle ne s'ouvre ni sur une tablette de chantier, ni sur le téléphone d'un commercial, ni chez un client ou un partenaire. Chaque nouveau besoin d'accès à distance se règle par un bureau à distance ou un VPN, avec les licences et la sécurité qui vont avec.

La fin du support des versions anciennes

Access 2016 et Access 2019, comme le reste d'Office 2016 et 2019, ne reçoivent plus de correctifs de sécurité depuis le 14 octobre 2025, selon l'annonce de fin de support de Microsoft. Une base ouverte avec ces versions continue de fonctionner, mais sur un logiciel qui ne sera plus corrigé.

Une dépendance à une personne

Le signal le plus fréquent n'est pas technique : l'auteur de la base est parti, ou va partir à la retraite, et personne ne sait modifier une requête ou un état sans tout casser. C'est la même situation que celle décrite dans notre article sur le logiciel métier qui n'est plus maintenu.

Les trois options, sans langue de bois

Option 1 : SQL Server derrière, Access devant

Microsoft fournit un outil gratuit, SQL Server Migration Assistant pour Access (page mise à jour le 20/04/2026), qui transfère les tables vers SQL Server ou Azure SQL. Les tables Access sont ensuite liées aux tables du serveur : formulaires, requêtes et états continuent de fonctionner, mais lisent les données sur le serveur.

Ce que vous y gagnez : une base plus robuste, des sauvegardes sérieuses, la fin de la limite des 2 Go, et une première étape vers le web, car une future application web pourra lire les mêmes tables.

Ce que vous n'y gagnez pas : l'interface reste Access, sur des postes Windows. La documentation de Microsoft liste elle-même les problèmes possibles après migration : requêtes devenues lentes parce que le moteur rapatrie des tables entières, code VBA à adapter pour les numéros automatiques, liens hypertextes transformés en simple texte, et mot de passe stocké en clair dans les tables liées si l'on utilise l'authentification SQL Server plutôt que Windows.

Pour qui : une équipe interne, sur site, qui veut fiabiliser l'existant sans changer ses habitudes, ou qui prépare une migration web en deux temps.

Option 2 : Power Apps

Power Apps est la plateforme « low-code » de Microsoft. On y reconstruit les écrans, les données vivent dans Dataverse, dans SharePoint ou dans SQL Server, et l'application s'ouvre dans un navigateur ou sur mobile. La page de tarifs officielle affiche Power Apps Premium à 17,30 € HT par utilisateur et par mois, en paiement annuel (relevé du 06/11/2026, prix indicatif selon Microsoft).

Les atouts sont réels si vous vivez déjà dans Microsoft 365 : connexion avec Teams, Outlook et SharePoint, authentification de vos salariés déjà en place, prise en main rapide pour des formulaires simples.

Les limites aussi : rien ne se convertit automatiquement depuis Access, les règles métier complexes deviennent vite difficiles à lire, le coût suit le nombre d'utilisateurs, et ouvrir l'outil à des clients ou à des partenaires extérieurs demande d'autres licences et d'autres réglages. Surtout, l'application ne peut pas quitter l'écosystème Microsoft. Nous comparons les deux voies en détail dans Power Apps ou développement sur mesure.

Pour qui : une entreprise déjà sous Microsoft 365, un usage interne, des écrans de saisie simples, un nombre d'utilisateurs stable.

Option 3 : une application web sur mesure

On reprend le modèle de données (le capital le plus précieux de votre base Access), on le nettoie, et on construit une application web : base de données serveur (PostgreSQL ou SQL Server), écrans pensés pour chaque métier, règles métier réécrites côté serveur, droits d'accès par profil.

Ce que vous y gagnez : un accès depuis n'importe quel navigateur, sur mobile si besoin, l'ouverture possible à vos clients ou à vos sous-traitants, des intégrations avec la comptabilité ou l'ERP, et aucune licence par utilisateur imposée par une plateforme. Le code et les données font l'objet de droits définis au cas par cas dans le contrat.

Ce que cela coûte : un vrai projet, avec un cadrage, un développement et une maintenance. C'est l'option la plus durable, pas la plus rapide.

Pour qui : un outil qui porte le cœur de l'activité, des utilisateurs hors de l'entreprise, une logique métier riche, un horizon de plusieurs années.

Le tableau pour trancher

Il n'y a pas de mauvaise option en soi, seulement une option mal assortie au besoin. Garder Access devant SQL Server pour une équipe de cinq personnes au bureau est souvent la meilleure décision de l'année.

Ce qu'il faut inventorier avant de choisir

Une base Access ancienne ressemble à une maison agrandie plusieurs fois : on y trouve des pièces qui ne servent plus. Avant tout chiffrage, faites ou faites faire l'inventaire suivant.

1. Les tables et leurs relations. Combien, lesquelles portent des données vivantes, lesquelles sont des copies ou des archives.
2. Les formulaires réellement ouverts. Demandez aux utilisateurs de lister ceux qu'ils utilisent chaque semaine. Le chiffre est souvent bien plus bas que le total.
3. Les états imprimés. Bons de livraison, fiches d'intervention, récapitulatifs mensuels : chacun devient une page ou un document à produire.
4. Les macros et modules VBA. Ce qu'ils font, qui les déclenche, et s'ils écrivent dans d'autres fichiers (Excel, Word, e-mails Outlook).
5. Les liens vers l'extérieur. Tables liées à d'autres bases, imports de fichiers, exports vers la comptabilité.
6. Les utilisateurs et leurs droits. Access gère mal les droits : qui doit voir quoi, qui doit pouvoir modifier quoi.
7. Les règles cachées. Une valeur par défaut, un contrôle de saisie, un calcul dans une requête : ce sont souvent des règles métier que personne n'a jamais écrites ailleurs.

Cet inventaire a deux effets. Il réduit le périmètre (et donc le budget), et il évite la mauvaise surprise de la règle oubliée découverte après la bascule.

Reprendre les données sans tout casser

La reprise des données est un chantier à part entière, que nous détaillons dans notre guide sur la reprise de données lors d'une migration. Pour une base Access, quelques points reviennent presque toujours :

• les champs texte fourre-tout : un champ « Remarques » qui contient un numéro de téléphone, une date et un statut ;
• les doublons : le même client saisi trois fois avec trois orthographes ;
• les types approximatifs : des dates stockées en texte, des montants avec des virgules et des points ;
• les clés absentes : des tables sans clé primaire, ou des relations jamais déclarées ;
• les pièces jointes : champs « pièce jointe » ou chemins vers des fichiers sur un lecteur réseau qui a changé de lettre.

La règle d'or : faire au moins une migration à blanc, vérifiée par les utilisateurs sur leurs propres dossiers, avant la bascule définitive.

Réécrire les macros et le VBA

Aucun outil sérieux ne convertit automatiquement du VBA en application web. La bonne démarche consiste à lire le code pour en extraire les règles métier, puis à les réécrire proprement :

• les contrôles de saisie deviennent des validations côté serveur, que personne ne peut contourner ;
• les calculs (tarifs, remises, délais) deviennent des fonctions testées automatiquement, avec des cas réels tirés de l'ancienne base ;
• les automatismes (générer un document, envoyer un e-mail, exporter un fichier) deviennent des actions explicites ou des tâches programmées ;
• le code mort disparaît, ce qui est souvent la meilleure économie du projet.

Un conseil : comparez les résultats des deux outils sur les mêmes données pendant la période de transition. Si le devis calculé par l'application web diffère de celui d'Access, l'un des deux a tort, et il faut savoir lequel avant la bascule.

Une migration progressive plutôt qu'un grand soir

Le scénario le plus sûr, quelle que soit l'option finale, se déroule en étapes :

1. Sécuriser l'existant : sauvegarde automatique, copie de travail, documentation minimale des tables.
2. Déplacer les données dans un vrai serveur de base de données, en gardant les écrans Access liés.
3. Construire le premier module web sur le processus qui gagne le plus à sortir du bureau (la saisie terrain, le portail client, le suivi de commandes).
4. Faire tourner les deux en parallèle sur ce périmètre, puis retirer les écrans Access correspondants.
5. Recommencer module par module, jusqu'à ce qu'Access ne serve plus qu'à consulter l'historique, puis plus à rien.

L'entreprise continue de travailler pendant toute la migration, et chaque étape apporte un gain visible.

Les erreurs qui coûtent cher

• Reproduire les écrans Access à l'identique. Ils ont été dessinés pour une souris et un écran de bureau, souvent par empilement. Le web permet de repenser le parcours de chaque métier.
• Chiffrer sur le nombre de tables. Ce qui coûte, ce sont les écrans, les états et les règles réellement utilisés.
• Oublier les utilisateurs occasionnels. La comptable qui lance un export une fois par mois a souvent la règle la plus critique.
• Choisir l'outil avant d'avoir l'inventaire. Power Apps ou sur mesure, la réponse sort des points précédents, pas d'une préférence.
• Négliger l'hébergement. Une base sortie du réseau local doit être hébergée, sauvegardée et surveillée. Notre article sur l'hébergement d'une application métier en France détaille les choix possibles.

Quand ne PAS migrer

Une base Access utilisée par deux personnes, sur le même réseau, pour un usage stable et non critique, peut très bien continuer à vivre. Mettez-la à jour sur une version supportée, sauvegardez-la automatiquement, documentez ses tables, et gardez votre budget pour un sujet qui rapporte davantage.

La migration devient utile quand l'outil limite l'activité : accès à distance impossible, erreurs de saisie qui coûtent, dépendance à une personne, ou envie d'ouvrir le service à vos clients.

Par où commencer

Commencez par l'inventaire ci-dessus, même sommaire. Ensuite, le plus efficace est de voir le futur outil avant d'engager un budget : nous construisons un prototype visuel gratuit à partir de votre base existante, présenté en visio sous 5 jours ouvrés, comme nous l'expliquons dans voir son logiciel avant de le payer. Vos utilisateurs comparent leurs écrans Access avec les écrans web, sur leurs propres cas, avant que quoi que ce soit ne soit développé.