Migrer une base Access vers le web, méthode et options

Migrer une base Access vers le web, c'est reprendre vos données et vos règles métier dans une application accessible depuis un simple navigateur, au bureau comme à distance. Trois options existent : déplacer seulement les données sur un serveur, passer sur un outil no-code, ou faire développer une application sur-mesure. Le vrai risque d'une migration n'est pas technique : ce sont les règles de fonctionnement que personne n'a jamais documentées.

Pourquoi migrer une base Access vers le web ?

Microsoft Access est un logiciel de base de données de bureau. Il a permis à des milliers de PME de construire leurs propres outils de gestion sans faire appel à un développeur. Beaucoup de ces bases tournent encore, parfois depuis plus de dix ans.

Le problème n'est pas qu'Access fonctionne mal. C'est qu'il a été conçu pour un usage de bureau, alors que les entreprises travaillent désormais à distance, sur plusieurs sites et sur mobile.

Voici les signaux qui indiquent qu'il est temps d'y réfléchir :

• l'accès à distance est laborieux : il faut un VPN, un bureau à distance ou une copie du fichier, avec le risque de travailler sur une version périmée ;
• une seule personne sait maintenir la base : si elle part, plus personne ne peut corriger un bug ou ajouter un champ ;
• les incidents se multiplient : lenteurs, verrous, fichier à réparer après une coupure réseau ;
• la base approche de sa taille maximale : un fichier Access est limité à 2 Go, données et objets compris (spécifications Access, Microsoft) ;
• les postes utilisent une version hors support : Access 2016 et Access 2019 ne reçoivent plus de correctifs de sécurité depuis le 14 octobre 2025 (cycle de vie Microsoft).

Un seul de ces signaux ne justifie pas forcément une migration. Plusieurs à la fois indiquent que l'outil freine l'activité plus qu'il ne la sert.

Faut-il vraiment quitter Access ?

Pas toujours. Access reste disponible et maintenu dans les abonnements Microsoft 365. Une base utilisée par deux ou trois personnes, au même endroit, sur des données peu sensibles, peut continuer à rendre service pendant des années.

La question à se poser est plutôt celle de la dépendance. Si la base porte une part importante de votre activité (devis, stocks, planning, facturation), son arrêt bloquerait l'entreprise. Dans ce cas, la migration relève de la gestion du risque, et il vaut mieux la préparer avant d'y être contraint par une panne ou un départ.

Le bon moment pour migrer est celui où vous pouvez encore choisir le rythme. Une migration menée dans l'urgence, base cassée et personne pour la réparer, coûte plus cher et laisse moins de place à l'amélioration des processus.

Les 3 façons de migrer une base Access vers le web

Microsoft a longtemps proposé sa propre solution web, les Access Web Apps, hébergées sur SharePoint. Leur abandon a été annoncé en 2017 (blog de l'équipe support Access, Microsoft) et elles ne sont plus disponibles. Il n'existe donc pas de bouton "mettre en ligne" : il faut choisir une autre voie.

Critère	Données sur serveur	Outil no-code	Application sur-mesure
Accès depuis un navigateur	Non, Access reste nécessaire sur chaque poste	Oui	Oui
Effort de départ	Faible	Moyen	Plus élevé
Adaptation à vos processus	Identique à l'existant	Limitée aux possibilités de l'outil	Complète
Dépendance	Access et Microsoft	L'éditeur de l'outil, son modèle de prix	Aucune, le code vous appartient
Horizon	Solution de transition	Moyen terme	Long terme

Garder Access et déplacer les données sur un serveur

Les tables sont transférées vers une vraie base de données serveur, comme SQL Server ou Azure SQL. Les formulaires et états Access restent en place et se connectent à cette nouvelle base. Microsoft fournit un outil dédié à ce transfert, SQL Server Migration Assistant for Access (documentation SSMA, Microsoft).

Cette option améliore la fiabilité et lève la limite de 2 Go. Elle ne règle pas l'accès depuis un navigateur ni la dépendance au poste Windows équipé d'Access. C'est une bonne étape intermédiaire, rarement une destination.

Passer sur un outil no-code

Plusieurs services en ligne permettent de recréer des tables, des formulaires et des vues sans écrire de code. Pour une base simple, avec peu de règles de calcul, c'est une solution rapide à mettre en place.

Les limites apparaissent avec la complexité. Les calculs métier élaborés, les états imprimés précis ou les traitements automatisés sont difficiles à reproduire. Le coût, souvent facturé par utilisateur, augmente avec l'équipe. Vérifiez aussi où sont hébergées vos données et comment les récupérer si vous changez d'outil.

Développer une application web sur-mesure

L'application est conçue autour de vos processus, avec une base de données serveur, une interface accessible depuis n'importe quel navigateur et des droits d'accès par utilisateur. Le code et les données vous appartiennent.

C'est l'option la plus engageante au départ, et la seule qui permet de repenser l'outil plutôt que de le recopier. Une migration est souvent l'occasion de supprimer les doubles saisies, de connecter l'outil à la comptabilité ou au CRM, et de remplacer les exports Excel manuels par des tableaux de bord à jour.

Les étapes d'une migration Access réussie

Quelle que soit l'option retenue, une migration bien menée suit les mêmes étapes. Elles concernent autant l'organisation que la technique.

1. Faire l'inventaire de la base

Une base Access ne se résume pas à ses tables. Elle contient aussi des requêtes, des formulaires, des états imprimables, des macros et souvent du code VBA, le langage de programmation intégré à Access. Elle peut également être reliée à des fichiers Excel ou à d'autres bases.

L'inventaire consiste à lister tous ces éléments et à identifier ceux qui servent encore. Il est fréquent qu'une partie significative des objets soit devenue inutile au fil des années. Ne pas les migrer simplifie d'autant le projet.

2. Retrouver les règles métier cachées

C'est l'étape la plus importante, et la plus souvent sous-estimée. Une base construite au fil des années contient des règles que personne n'a écrites ailleurs : un calcul de remise dans une requête, un contrôle de saisie dans un formulaire, une numérotation de factures dans une macro.

Ces règles se retrouvent en croisant deux sources : la lecture de la base elle-même et des entretiens avec les personnes qui l'utilisent au quotidien. Les utilisateurs connaissent aussi les contournements, ces manipulations qu'ils font à la main parce que l'outil ne gère pas un cas particulier. Ce sont souvent de bons candidats à l'automatisation.

3. Nettoyer les données avant de les déplacer

Access tolère beaucoup de choses qu'une base serveur refuse : des doublons, des champs texte qui contiennent des dates, des clients saisis sous trois orthographes différentes, des liens vers des enregistrements supprimés.

Le nettoyage se fait avant la migration, pas après. Il faut décider des règles (quel doublon garder, quel format de date imposer), puis les appliquer avec des scripts qui peuvent être rejoués. Une migration de données se répète plusieurs fois avant la bascule finale, et chaque passage doit donner le même résultat.

4. Construire l'application par étapes

Plutôt que de tout reconstruire avant de livrer, commencez par l'usage le plus critique ou le plus pénible : la prise de commande, le planning, le suivi des interventions. Les utilisateurs le testent sur des données réelles, et leurs retours orientent la suite.

Cette approche limite le risque. Un écart de compréhension se corrige en quelques jours au début du projet, alors qu'il coûte cher une fois toute l'application construite dessus.

5. Basculer sans arrêter l'activité

La bascule est le moment où l'entreprise passe de l'ancienne base à la nouvelle. Pour la sécuriser :

1. Faire une dernière migration complète des données, à un moment calme (fin de semaine, période creuse).
2. Comparer les totaux clés entre l'ancienne et la nouvelle base : nombre de clients, chiffre d'affaires par année, stocks.
3. Conserver l'ancienne base en lecture seule, pour vérifier un historique en cas de doute.
4. Prévoir un plan de retour arrière, avec les conditions qui le déclencheraient.

Sur les outils très critiques, une courte période de fonctionnement en parallèle permet de vérifier que les deux systèmes donnent les mêmes résultats. Elle doit rester brève, car la double saisie pèse vite sur les équipes.

6. Former les utilisateurs et documenter

Une nouvelle application change des habitudes installées depuis longtemps. Une formation courte, centrée sur les tâches quotidiennes de chaque profil, est plus efficace qu'une présentation générale de toutes les fonctionnalités.

La documentation, elle, évite de reproduire le problème de départ. Les règles métier retrouvées à l'étape 2 doivent être écrites quelque part, pour que l'outil ne dépende plus jamais d'une seule personne.

C'est la démarche que nous suivons dans notre offre de modernisation de logiciels métier vers une application web, portée par un binôme développement web et data qui couvre tout le projet en interne.

Questions fréquentes

Microsoft abandonne-t-il Access ?

Non. Access reste inclus et maintenu dans les abonnements Microsoft 365. Ce sont certaines versions vendues en licence perpétuelle, comme Access 2016 et Access 2019, qui ne sont plus supportées depuis le 14 octobre 2025. La solution web d'Access, elle, a bien été abandonnée.

Peut-on garder tout l'historique de ses données ?

Oui, dans la grande majorité des cas. L'historique est repris lors de la migration, après nettoyage. Il est aussi recommandé de conserver l'ancienne base en lecture seule pendant une période définie, pour pouvoir vérifier une donnée en cas de doute.

Peut-on mettre une base Access en ligne sans tout refaire ?

Partiellement. On peut placer les données sur un serveur accessible à distance et garder les écrans Access, mais chaque utilisateur aura toujours besoin d'Access installé sur un poste Windows. Pour un accès depuis un navigateur ou un mobile, il faut reconstruire l'interface, avec un outil no-code ou une application sur-mesure.

Combien de temps dure une migration Access ?

Cela dépend surtout de trois facteurs : la quantité de logique métier cachée dans la base (requêtes, macros, VBA), l'état des données et le nombre d'usages à reprendre. L'inventaire et l'audit de la base permettent d'établir un chiffrage fiable avant de s'engager.