Migration Access : inventorier ce qui fait fonctionner l’outil
Ouvrez la base avec les personnes qui l’utilisent. Listez les tables locales et les tables liées, puis les formulaires qui servent réellement. Un bouton peut déclencher une requête, produire un état et enregistrer un fichier ailleurs. La base seule ne contient donc pas toujours tout le fonctionnement. Demandez aussi comment se passent la clôture, les corrections et les absences de la personne qui connaît le code.
| Objet | Question métier | Livrable de cadrage |
|---|---|---|
| Tables et relations | Quelle donnée fait autorité ? | Dictionnaire, clés et liens |
| Requêtes | Quel résultat attend-on et sur quelle période ? | Règles de sélection et cas d’essai |
| Formulaires | Qui saisit et qui valide ? | Parcours et profils |
| États | Quel document doit rester comparable ? | Gabarits et règles de calcul |
| Macros et modules VBA | Que se passe-t-il derrière le bouton ? | Fiches de règles et dépendances |
L’audit logiciel de l’existant permet de réunir ces éléments. Pour les calculs et traitements, le guide sur la reprise des macros VBA précise comment transformer le code en règles lisibles.
Migrer les tables ou reconstruire l’application ?
Microsoft Access migration vers SQL Server et migration Access vers application web désignent deux périmètres différents. Déplacer les tables vers SQL Server peut laisser les écrans dans Access. Une interface web demande un travail supplémentaire sur les parcours, les validations et les documents. Il faut les chiffrer séparément.
- Conserver Access comme interface si ses usages et son exploitation conviennent.
- Reprendre la base de données et reconstruire seulement les écrans nécessaires.
- Remplacer progressivement l’ensemble en définissant les points de bascule.
Une application low-code peut aussi être examinée. La comparaison Power Apps ou application sur mesure doit porter sur les connecteurs, les licences à vérifier et les règles à reproduire. Aucun choix n’élimine le besoin d’essais sur vos données et vos parcours.
Préparer la reprise des données
Le plan de correspondance indique où va chaque champ. Relevez les numéros automatiques, les valeurs vides, les pièces jointes et les références enregistrées en texte libre. Deux noms de client proches ne sont pas forcément un doublon. Décidez avec le métier ce qui sera rapproché et ce qui restera distinct.
- Extraire un inventaire sur une copie maîtrisée de la base.
- Choisir les dossiers et périodes à reprendre.
- Écrire les règles de transformation et les cas rejetés.
- Faire un import d’essai et contrôler les résultats.
- Rejouer la procédure de bascule avec les responsables du métier.
Le guide de reprise des données métier détaille les contrôles. Ne vous limitez pas au nombre de lignes : comparez les sommes utiles, les relations et les documents produits. Un historique conservé pour consultation n’a pas forcément besoin de toutes les fonctions de modification de l’ancien outil.
Valider les usages et organiser la bascule
Une migration Access vers web se reçoit par des parcours complets : créer un dossier, le corriger, le valider puis produire le document attendu. Faites essayer aussi le refus d’une saisie, un doublon et une opération annulée. Le critère de réussite doit être convenu avant les essais, avec la personne qui accepte le résultat.
La recette de l’application après migration documente chaque écart. Le plan de bascule et de retour arrière fixe ensuite l’outil qui fait autorité, la manière de reprendre les changements récents et la consultation des archives. Évitez une période de double saisie sans responsable ni rapprochement prévu.
Ce que la demande de devis doit décrire
Indiquez la version d’Access, le nombre d’utilisateurs que vous constatez, les objets connus et les logiciels reliés. Décrivez un incident précis plutôt qu’une appréciation générale comme « la base est trop ancienne ». Distinguez la reprise à l’identique des changements souhaités : ces deux travaux ne se valident pas avec les mêmes résultats attendus.
La comparaison des prix de développement repose sur les mêmes hypothèses de données, d’écrans et d’exploitation. Le cahier des charges logiciel permet de joindre une liste de règles, des gabarits anonymisés et les exclusions. Conservez les fichiers de base et les identifiants pour un échange sécurisé convenu avec le spécialiste.
Questions pratiques
Peut-on garder SQL Server derrière l’application web ?
Cette option peut être étudiée si la base est adaptée. Il faut vérifier ses relations, les procédures utilisées et la compatibilité des échanges. Le projet peut porter sur la nouvelle interface plutôt que sur le remplacement du moteur.
Les anciens états seront-ils reproduits ?
Inventoriez les états indispensables, les calculs, la numérotation et la mise en page. Leur reprise doit figurer au devis avec des documents attendus pour la recette. Ne la déduisez pas du seul intitulé « migration de la base ».
Sources
Sources officielles consultées le 1er octobre 2026.