Remplacer Microsoft Access par Power Apps et Dataverse

Il y a dans beaucoup de PME une base Access qui tourne depuis quinze ans. Elle gère les devis, le parc de matériel ou les dossiers clients. Elle marche, et c'est bien le problème : personne n'ose y toucher. La personne qui l'a construite est partie ou part bientôt, le fichier vit sur un lecteur réseau, et l'ouvrir à deux en même temps est une aventure.

Si vous vous reconnaissez, vous n'êtes pas en retard : vous avez une base qui a rendu service. Mais elle a des limites que vous payez déjà. Voici ce que signifie remplacer Access par Power Apps et Dataverse, ce qu'on migre, les pièges connus, et une démarche qui ne bloque pas l'activité.

Pourquoi remplacer Access maintenant

• Le partage. Access est conçu pour un poste, ou quelques postes sur le même réseau. Pas de mobile, pas d'accès depuis un autre site, pas de collaborateur en télétravail sans bricolage.
• La dépendance à une personne. Formulaires, requêtes et macros VBA ne sont documentés que dans la tête de leur auteur.
• La fragilité. Un fichier sur un partage réseau, ouvert par plusieurs personnes, finit par se corrompre. Et un fichier .accdb plafonne à 2 Go.
• L'isolement. Access ne parle ni à Teams, ni à Outlook, ni à Power BI sans exports manuels.

Power Apps et Dataverse vivent dans votre Microsoft 365. Vos données restent dans votre tenant, accessibles depuis un navigateur ou un téléphone, avec les droits des comptes que vous avez déjà.

Ce qu'on migre, et vers quoi

Une base Access mélange quatre couches. Chacune a un équivalent dans Power Platform :

1. Les tables vont dans Dataverse. Pour une base très simple, quelques tables sans relations, une liste SharePoint peut suffire. Mais dès qu'il y a des liens entre tables (clients, commandes, lignes de commande), Dataverse est le bon choix : il gère les relations nativement.
2. Les formulaires deviennent des écrans Power Apps. On ne les recopie pas : on les redessine pour le navigateur et le mobile, souvent avec moins de champs.
3. Les requêtes et les états deviennent des vues Dataverse, des écrans de liste, ou des rapports Power BI pour la partie analyse.
4. Les macros et le VBA deviennent des flux Power Automate (envoi de mail, relance, calcul de statut) ou des règles dans l'application.

Access pour Microsoft 365 propose un outil d'export des tables vers Dataverse, qui migre les données et peut relier l'ancien frontal Access aux nouvelles tables. C'est pratique pour une transition progressive. Vérifiez qu'il est présent dans votre version d'Access.

Les pièges connus d'une migration Access

Les relations et les identifiants. Access numérote ses enregistrements avec des champs NuméroAuto. Dataverse a ses propres identifiants. Il faut donc une table de correspondance pour que les commandes retrouvent leurs clients après la migration. Ça se prépare, ça ne s'improvise pas.

Les pièces jointes. Les champs « pièce jointe » et les objets OLE d'Access pèsent lourd et ne se migrent pas d'un clic. On les sort vers SharePoint ou vers des colonnes fichier Dataverse, avec un lien depuis l'enregistrement. Comptez-les avant : cent PDF, ce n'est pas dix mille.

Les volumes et le stockage. La capacité Dataverse se compte à part de vos licences Microsoft 365. Une base de 50 000 lignes ne pose aucun problème. Une base qui contient vingt ans d'historique mérite un tri : que garde-t-on actif, qu'archive-t-on ?

Le VBA. Il n'existe pas de convertisseur. Chaque macro se relit, et on se demande d'abord si elle sert encore. Souvent, la moitié du code répond à un besoin de 2012.

Les licences. Dataverse est une brique premium. Comptez une licence Power Apps par utilisateur, de l'ordre de 20 euros par utilisateur et par mois pour la licence complète, moins pour une licence limitée à une seule application, à vérifier sur la grille Microsoft du moment. Notre article sur ce qui est inclus et ce qui est premium détaille le sujet.

Une démarche par étapes, sans arrêter l'activité

La bonne nouvelle : on ne bascule pas tout un lundi matin. Voici l'ordre qui marche.

1. Inventaire. Lister tables, formulaires, requêtes, macros. Marquer ce qui est encore utilisé. Cette étape seule fait souvent tomber un tiers de la base.
2. Cadrage. Redessiner le processus cible, pas la base actuelle. Un cadrage de deux à trois jours suffit pour figer le périmètre et chiffrer la suite.
3. Modèle de données. Créer les tables Dataverse, les relations, les droits. Migrer un extrait de données pour tester.
4. Écrans et automatisations. Construire l'application, brancher Outlook, Teams, SharePoint.
5. Migration réelle et tests. Charger toutes les données, faire tester les utilisateurs sur des cas réels, corriger, mettre en service.
6. Access en lecture seule. Garder l'ancienne base quelques semaines, verrouillée, le temps de vérifier que rien ne manque.

Le résultat n'est pas « Access dans le navigateur ». C'est une application qui fait la même chose, en mieux : accessible à tous ceux qui en ont besoin, sur mobile, avec un historique, et des données prêtes pour vos tableaux de bord. Les étapes, les livrables et la garantie sont décrits dans notre méthode.