Moderniser une application Access

Access : l’outil qui a bien servi, mais qui montre ses limites

Microsoft Access a permis à des milliers de PME de créer des applications métier sans budget informatique. Un formulaire, quelques requêtes, une macro, et vous aviez un outil de gestion fonctionnel.

Le problème, c’est que ces bases Access ont grandi. Ce qui était un prototype est devenu le système de production. Et Access n’a pas été conçu pour tenir ce rôle sur la durée.

Les signaux qui ne trompent pas

• Le fichier .accdb dépasse 1 Go. Access a une limite théorique de 2 Go par fichier .accdb. En pratique, les performances se dégradent dès 500-700 Mo, notamment sur les requêtes avec jointures multiples et les formulaires liés à de gros jeux de données. Les requêtes qui prenaient 2 secondes en prennent 30.
• Le multi-utilisateurs rame. Le verrouillage de fichier d’Access sur un partage réseau crée des conflits, des corruptions, des “l’application ne répond plus”. En VPN, c’est inutilisable.
• Le code VBA est devenu un sac de nœuds. Des dizaines de formulaires qui s’appellent mutuellement, des requêtes avec 8 jointures, des modules VBA jamais commentés. La personne qui a écrit tout ça est partie il y a 5 ans.
• Access reste mal adapté aux usages actuels. Pas d’accès web natif, pas de mobile, multi-utilisateurs fragile. Les nouveaux développeurs ne connaissent pas Access. Trouver un prestataire compétent devient de plus en plus difficile.

Notre approche de migration

On ne fait pas de “lift and shift” (Access → Power Apps ou Access → web en copiant la structure). On reprend le problème métier à la racine.

Phase 1 : Première lecture de faisabilité. Après l’échange découverte, si vous nous transmettez votre .accdb, on inventorie les tables, les relations, les requêtes, le code VBA. On identifie les tables mortes (données de 2012 jamais consultées), les requêtes orphelines, le code dupliqué. Ça donne une vision claire de ce qui doit vraiment être migré.

Phase 2 : Modélisation. On redessine le modèle de données proprement. Les relations spaghetti d’Access deviennent un schéma relationnel normalisé. Les formulaires VBA deviennent des interfaces web avec validation côté serveur.

Phase 3 : Migration des données. Script de migration automatisé, exécutable plusieurs fois (on ne fait pas un import “one shot” la veille du go-live). Vérification des comptages, des totaux, des références croisées.

Phase 4 : Période de double-run. Les deux systèmes tournent en parallèle. L’équipe bascule progressivement. On corrige les écarts au fur et à mesure.

Power Apps : parfois pertinent, parfois piège

Microsoft pousse Power Apps comme successeur naturel d’Access. Power Apps peut convenir si votre besoin est simple : quelques formulaires, peu de logique métier, équipe déjà sur Microsoft 365 avec les licences qui vont bien.

En revanche, dès qu’il y a des connecteurs personnalisés, des flux complexes ou de la logique métier poussée, les limites arrivent vite : licence premium nécessaire (20 à 40 euros par utilisateur et par mois), performances variables sur les gros volumes, et vous ne possédez pas le code. Si vous quittez l’écosystème Microsoft, vous repartez de zéro. Pour 15 utilisateurs sur 3 ans, les licences seules représentent 10 800 à 21 600 euros, sans compter le développement.

Mini-cas : un cabinet comptable migre sa gestion des dossiers

Un cabinet de 12 personnes à Rouen utilisait une base Access depuis 2009 pour suivre ses dossiers clients : échéances fiscales, pièces reçues, état d’avancement. Deux problèmes : les collaborateurs en télétravail ne pouvaient pas y accéder (VPN trop lent), et le fichier corrompait environ une fois par mois.

Migration réalisée en 6 semaines. L’application web reprend les mêmes écrans (les habitudes sont préservées), ajoute l’accès mobile et les notifications d’échéance. La base Access originale a été archivée, et les données historiques de 15 ans restent consultables.