Faut-il vraiment remplacer Microsoft Access ?
Pas nécessairement, et surtout pas avant d’avoir sécurisé l’existant. Si l’application fonctionne, que sa version est maintenue, que les droits sont maîtrisés et qu’une restauration a été réellement testée, la conserver peut être une décision rationnelle.
Si un incident est actif — corruption, perte, accès compromis ou fichier indisponible — arrêtez le projet de migration. Traitez d’abord l’incident : une refonte n’est pas une procédure de secours.
Microsoft commercialise encore Access pour PC dans Microsoft 365 et en version perpétuelle Access 2024. Dans les fiches Lifecycle, le champ anglais « Retirement Date » indique le 13 octobre 2026 pour Access 2021 et le 9 octobre 2029 pour Access 2024. Il s’agit des dates de retrait publiées, pas d’une promesse autonome de « support garanti jusqu’à ». Sous la politique de cycle moderne, le produit doit rester à jour selon les exigences de service et système publiées. L’utilisateur doit disposer d’une licence ou d’un droit d’usage. Enfin, il faut que Microsoft propose encore la prise en charge.
La fiche Microsoft 365 Apps est actuellement « In Support » sans date fixe de retrait. La phrase « Access est mort » ne permet donc aucune décision. Relevez le produit exact, sa version, son mode de licence et les postes qui l’utilisent.
La technologie vient plus tard. Pour l’instant, demandez : quelles tâches doivent continuer, avec quelles données, quelles règles, quelles personnes et quelle preuve de reprise ? Cette « preuve » est un résultat observable : par exemple, retrouver à l’identique trois factures choisies pour le test, avec les mêmes droits. Elle vaut mieux qu’une case « migré ».
Application web, logiciel standard, plateforme avec peu de code (low-code), serveur de données ou maintien d’Access : toutes ces pistes restent à comparer.
Urgence avant modernisation
Les cinq vérifications qui précèdent tout devis
- Créer une copie saine sans modifier l’original de production.
- Tester la restauration sur un emplacement et un poste séparés.
- Noter la version d’Access, le format du fichier et les licences.
- Identifier le propriétaire du fichier et le responsable métier.
- Écrire le fonctionnement dégradé si l’application s’arrête.
Deux raccourcis à éviter
Le plafond publié est de 2 Go par base, moins l’espace nécessaire aux objets système ; 255 est le maximum publié d’utilisateurs simultanés. Ces deux valeurs restent des plafonds techniques. Elles ne décrivent pas une capacité pratique promise et ne fixent ni seuil de confort ni déclencheur universel. La taille ne dit donc pas tout : certains petits fichiers sont critiques et opaques, alors qu’une base plus volumineuse reste parfois maîtrisée. Pour décider s’il faut remplacer Access, partez plutôt des usages réels, des incidents, de la croissance, des dépendances et des résultats que les utilisateurs devront retrouver.
Où se cache le vrai travail dans une base Access ?
Les tables ne suffisent pas pour savoir quoi préserver. Une base Access combine souvent quatre familles d’objets visibles : tables pour conserver les données, requêtes pour les filtrer ou les transformer, formulaires pour travailler et rapports pour imprimer ou restituer. Des macros, des modules VBA, des tables liées et des connexions extérieures peuvent ajouter des règles qui ne se voient pas dans la liste des colonnes.
Le fichier n’est pourtant pas la spécification. L’habitude d’une assistante ou le nom d’une pièce jointe peuvent faire partie de la règle. Même chose pour un modèle Word appelé depuis VBA, un dossier réseau ou une correction faite chaque vendredi avant l’export comptable. Interrogez la personne qui réalise le travail et celle qui utilise le résultat.
Exemple fictif 1 · devis
Le bouton « Envoyer » fait plus qu’un envoi
Le formulaire valide une remise et crée un numéro. Il génère aussi un PDF, choisit un modèle selon le client et ouvre Outlook. Migrer seulement la table des devis conserverait les lignes, mais pas la tâche complète ni ses exceptions.
Exemple fictif 2 · planning
La couleur du planning encode une décision
La requête calcule le retard, puis le formulaire applique une couleur. C’est ce signal qui conduit le responsable à appeler les dossiers rouges. La couleur traduit donc une règle et déclenche une action humaine à documenter ; elle n’est pas décorative.
Exemple fictif 3 · clôture
Le rapport mensuel dépend d’un chemin local
Un état lit une table liée et charge un taux depuis un classeur placé sur un lecteur réseau. Il dépose ensuite un export dans un dossier surveillé. Une conversion automatisée peut repérer la requête.
En revanche, son résultat n’indique ni qui fournit le taux, ni qui surveille le dossier, ni comment corriger un échec.
Ce qu’il faut documenter au-delà des objets Access
- Élément
- Tâche métier
- Questions
- Qui déclenche, qui décide, quel résultat est utilisé ?
- Résultat à conserver
- Trois cas réels, dont une exception et un échec
- Élément
- Données
- Questions
- Clés, doublons, valeurs manquantes, pièces jointes, historiques ?
- Résultat à conserver
- État des données et échantillon comparé à la source
- Élément
- Règles
- Questions
- Requêtes action, paramètres, calculs, validations, macros, VBA ?
- Résultat à conserver
- Règle expliquée par son responsable et scénario associé
- Élément
- Sorties
- Questions
- Rapports, impressions, PDF, Excel, courriels, dossiers surveillés ?
- Résultat à conserver
- Résultat de référence et destinataire nommé
- Élément
- Connexions
- Questions
- ODBC, API, Outlook, Word, fichiers, lecteurs, tâches planifiées ?
- Résultat à conserver
- Compte, droits, fréquence, erreur et reprise documentés
La technologie viendra plus tard. Pour l’instant, le dossier de sortie réunit des tâches observables, les objets qui les servent et les personnes capables d’expliquer le résultat attendu.
Construisez un dossier de sortie, pas une simple liste de tables
Commencez par les tâches que l’équipe devra continuer à accomplir, quelle que soit l’option retenue. Reliez ensuite les objets techniques à ces tâches. Une ligne peut désigner un formulaire, une requête, un rapport, une macro, un module VBA, une connexion, une tâche planifiée, une pièce jointe, un lien hypertexte ou un chemin local. Si vous ignorez le type, gardez « à vérifier ».
Pour chaque ligne, nommez le responsable, la fréquence, les dépendances et la nature des données. Notez aussi la criticité, c’est-à-dire ce qui arrive à l’activité si cet élément s’arrête. Si vous avez déjà une option en tête, notez-la comme une hypothèse, pas comme une décision.
Gardez surtout une colonne pour la preuve de reprise. Elle répond à une question concrète : quel résultat observable l’utilisateur devra-t-il retrouver pour confirmer que la tâche fonctionne encore après le changement ?
Outil local · dossier de sortie Access
Recensez ce qui doit survivre avant de choisir la cible
Décrivez une tâche métier ou un objet Access par fiche. Les champs restent dans cette page : aucun envoi, aucune sauvegarde automatique et aucune génération de faux fichier. « À vérifier » reste une inconnue, jamais un zéro ni un accord implicite.
Éléments
2
Complets
0
Avec inconnues
2
Points bloquants
0
Fiche 1
À compléter : objet ou tâche, type, responsable métier, fréquence, criticité, dépendances, nature des données, cible pressentie, preuve de reprise.
Fiche 2
À compléter : objet ou tâche, type, responsable métier, fréquence, criticité, dépendances, nature des données, cible pressentie, preuve de reprise.
Conseil de confidentialité : utilisez des rôles et des identifiants internes neutres. Ne collez ni mot de passe, ni secret, ni donnée personnelle dans cet outil.
DOSSIER DE SORTIE MICROSOFT ACCESS Document de travail local — aucune recommandation automatique Éléments recensés : 2 Éléments complets : 0 Éléments avec inconnues : 2 Points bloquants : 0 1. Objet ou tâche à nommer Type : À vérifier Responsable : À vérifier Fréquence : À vérifier Criticité : À vérifier Dépendances : À vérifier Données personnelles, confidentielles ou réglementées : À vérifier Cible pressentie : À décider Preuve de reprise : À vérifier Champs à compléter : objet ou tâche, type, responsable métier, fréquence, criticité, dépendances, nature des données, cible pressentie, preuve de reprise Points bloquants : Aucun détecté par ce formulaire 2. Objet ou tâche à nommer Type : À vérifier Responsable : À vérifier Fréquence : À vérifier Criticité : À vérifier Dépendances : À vérifier Données personnelles, confidentielles ou réglementées : À vérifier Cible pressentie : À décider Preuve de reprise : À vérifier Champs à compléter : objet ou tâche, type, responsable métier, fréquence, criticité, dépendances, nature des données, cible pressentie, preuve de reprise Points bloquants : Aucun détecté par ce formulaire Ce dossier ne choisit pas une architecture, un produit, un budget ou une date de bascule. Faites vérifier les dépendances, les droits, les licences et les preuves de reprise avant tout pilote.
Même une fiche complète ne choisit rien à votre place : elle sert seulement à ouvrir la discussion. Avant de basculer un élément critique, désignez son responsable, précisez le résultat à retrouver et vérifiez que ses dépendances sont comprises.
Sauvegarde et restauration ne sont pas synonymes
La CNIL recommande des sauvegardes fréquentes, protégées au même niveau que les données, dont une séparée géographiquement et une hors ligne, ainsi que des tests réguliers d’intégrité et de restauration. Le périmètre principal est la protection des données personnelles. Pour les autres données critiques de l’entreprise, adaptez l’organisation avec les responsables compétents.
Que voient les outils de migration — et que manquent-ils ?
Les outils automatiques inventorient ce qu’ils peuvent lire ou convertir et signalent certaines incompatibilités. Pour savoir ce que l’équipe devra continuer à accomplir, quelle que soit l’option retenue, complétez cette analyse par l’étude des usages. Il reste nécessaire d’interroger les utilisateurs, d’analyser la sécurité et d’organiser les tests d’acceptation — parfois appelés « recette ».
Portée réelle de quatre outils Microsoft utiles autour d’Access
- Outil
- Database Documenter
- Ce qu’il aide à voir
- Détails des tables, requêtes, formulaires, contrôles, rapports, macros et modules selon la sélection.
- Limite décisive
- Un rapport volumineux n’explique pas la priorité métier ni les habitudes hors Access.
- Usage prudent
- Produire un inventaire de départ, puis relier chaque objet à une tâche et un responsable.
- Outil
- Object Dependencies
- Ce qu’il aide à voir
- Objets qui utilisent ou sont utilisés par un objet, jusqu’à quatre niveaux.
- Limite décisive
- Object Dependencies ne couvre ni les macros ni les modules. Des limites subsistent pour les requêtes UNION, de définition de données ou pass-through, pour les sous-requêtes et pour les droits de conception.
- Usage prudent
- Repérer des liens visibles sans qualifier la carte d’exhaustive.
- Outil
- SSMA for Access
- Ce qu’il aide à voir
- Évaluation, tables, colonnes, index, clés étrangères et conversion de plusieurs requêtes SELECT vers SQL Server.
- Limite décisive
- Pas les formulaires, rapports, macros ou modules : ces éléments restent hors conversion. SSMA ne convertit pas non plus les requêtes UPDATE, les requêtes SELECT paramétrées ou les requêtes croisées.
- Usage prudent
- Lire erreurs et avertissements, estimer le travail technique puis valider les données et requêtes source/cible.
- Outil
- Export vers Dataverse
- Ce qu’il aide à voir
- Tables et données, relations compatibles et tables Dataverse liées pour conserver temporairement le frontal Access.
- Limite décisive
- Types et limites diffèrent ; certaines lignes restent en erreur. Une interface Power Apps ne résulte pas de l’export et les licences varient.
- Usage prudent
- Sauvegarder, examiner les tables d’erreurs, tester les rôles ; valider le frontal Access hybride ou construire et tester séparément l’interface Power Apps.
Le rapport d’évaluation SSMA fournit notamment un pourcentage de conversion et une estimation du temps de migration ou de correction. Le pourcentage et l’estimation décrivent uniquement la conversion technique reconnue par l’outil. Pour juger l’importance des objets, leur adoption, les droits, le nettoyage des données et les travaux menés hors Access, complétez ce rapport par une analyse métier.
Pendant une transition, Access peut conserver les formulaires et rapports tout en se reliant à des tables SQL Server. Microsoft avertit toutefois que certaines requêtes peuvent ralentir, que des mises à jour peuvent devenir ligne par ligne et que des types ou comportements changent.
Avec l’authentification SQL, le mot de passe peut être stocké en clair dans la table liée ; Microsoft recommande l’authentification Windows quand elle est possible. Le test ne doit pas s’arrêter à la connexion : faites aussi vérifier l’architecture et les droits.
OneDrive, WAN et partages Azure : trois cas à traiter avec prudence
Microsoft déconseille d’ouvrir un fichier Access depuis OneDrive ou une bibliothèque SharePoint, car plusieurs copies locales et des comportements inattendus peuvent apparaître. Microsoft avertit aussi qu’une base Access scindée sur un WAN ou des partages de fichiers Azure peut devenir lente et se corrompre. Ces avertissements visent ces configurations précises. Ils ne s’étendent pas automatiquement à tous les réseaux, à tous les services cloud ni à toute séparation des données.
Quelle option choisir pour remplacer Access ?
Pour chaque option, posez les trois mêmes questions : dans quel cas convient-elle, quel test doit-elle passer et quel risque nouveau crée-t-elle ? Cette base commune évite de favoriser la solution la plus séduisante ou la plus chère.
Avec une plateforme low-code — une plateforme qui réduit la quantité de code à écrire — vous configurez une grande partie de l’application. Certaines fonctions exigent malgré tout du développement. Évaluez les sept trajectoires à partir des mêmes tâches du quotidien : la comparaison portera sur l’usage réel, avec la même règle pour toutes.
La réponse peut différer selon la partie de l’application. Conserver les rapports historiques, migrer le stockage et reconstruire seulement la saisie terrain réduit le périmètre à refaire. Cette combinaison doit néanmoins passer les mêmes contrôles que les autres trajectoires.
- 1
Conserver et stabiliser Access
- Quand l’examiner
- Le besoin reste local ou limité, l’application est comprise et la version utilisée peut être maintenue.
- Contrôle à réussir
- Copie saine et restaurable, responsable nommé, droits revus, copies locales de l’interface maîtrisées et procédure de reprise jouée.
- Risque à surveiller
- Reporter une dépendance humaine, une version en fin de support ou un usage réseau mal conçu.
- 2
Séparer l’interface et les données
- Quand l’examiner
- Les formulaires et rapports Access restent utiles, mais plusieurs personnes doivent travailler sur une base mieux organisée.
- Contrôle à réussir
- Copie locale de l’interface distribuée à chaque utilisateur, fichier de données protégé, versions maîtrisées et test depuis chaque poste représentatif.
- Risque à surveiller
- Une base Access scindée n’est pas une architecture web et ne doit pas être étirée sans test sur un réseau reliant plusieurs sites (WAN).
- 3
Migrer seulement le stockage
- Quand l’examiner
- Le modèle de données ou la concurrence d’accès pose problème, tandis que l’interface Access peut rester transitoirement utile.
- Contrôle à réussir
- Requêtes mesurées, types et clés vérifiés, mode de connexion choisi, liens recréés et résultats source/cible comparés.
- Risque à surveiller
- Les requêtes peuvent devenir lentes ou fonctionner ligne par ligne ; certains types et comportements changent.
- 4
Adopter un logiciel standard
- Quand l’examiner
- Le travail est courant et une solution du marché couvre les cas importants sans adaptations permanentes.
- Contrôle à réussir
- Essai sur des scénarios réels, export testé, droits et coût au volume confirmés, contrat de sortie lu.
- Risque à surveiller
- Choisir sur une démonstration préparée ou sous-estimer la reprise des historiques et des rapports.
- 5
Utiliser une plateforme avec peu de code (low-code)
- Quand l’examiner
- La plateforme est déjà connue de l’équipe, ses règles d’administration sont assumées et le besoin s’y prête.
- Contrôle à réussir
- Prototype des règles difficiles, licences réelles, environnements, comptes de service, export et maintenance vérifiés.
- Risque à surveiller
- Déplacer la dépendance vers une plateforme, ses licences, ses limites et ses compétences rares.
- 6
Reconstruire progressivement une application web dédiée
- Quand l’examiner
- L’accès navigateur, les parcours, les intégrations ou la durée de vie justifient un produit maintenu comme tel.
- Contrôle à réussir
- Premier parcours représentatif, résultats attendus pour le valider, migration répétable, retour arrière et responsabilités d’exploitation.
- Risque à surveiller
- Copier les écrans sans comprendre le métier, élargir le chantier et oublier rapports, tâches planifiées ou exceptions.
- 7
Ne pas migrer maintenant
- Quand l’examiner
- L’urgence est corrigée, le besoin futur n’est pas stable ou aucune option n’a encore démontré sa valeur.
- Contrôle à réussir
- Risque accepté explicitement, surveillance, version et sauvegarde maîtrisées, date de réexamen fixée.
- Risque à surveiller
- Confondre décision documentée et abandon silencieux jusqu’au prochain incident.
Attention au nom : les anciennes « Access Web Apps » de SharePoint ne sont ni Access de bureau ni l’équivalent d’une application web actuelle. Microsoft a annoncé le retrait des Access Services 2010/2013 des versions futures de SharePoint et déconseille de créer de nouvelles Access Web Apps. Ce retrait ne signifie donc pas qu’il faut réécrire toutes les bases Access de bureau.
Verdict possible
« Ne pas migrer maintenant » est une décision, pas une absence de décision
- Une personne clairement désignée accepte par écrit le risque résiduel.
- La sauvegarde et la restauration restent testées.
- Consignez la version en service, vérifiez les droits et identifiez la personne responsable.
- Un événement et une date déclenchent le réexamen.
Comment migrer par étapes sans promettre zéro interruption ?
Le bon objectif n’est pas de promettre zéro risque : c’est de réduire l’incertitude à chaque étape. L’ANSSI recommande de tenir à jour les cartographies, les inventaires et l’analyse de risques pendant la transition. Elle recommande aussi d’adapter la continuité et la reprise, de protéger les exports et de rester capable de restaurer les anciennes sauvegardes jusqu’à leur échéance.
- Limiter le premier essai. Choisissez une tâche représentative avec un responsable, une exception et un résultat précis à retrouver. Pendant ce premier essai, évitez de lancer en parallèle un autre changement important.
- Créer une extraction répétable. Documentez la source, l’heure, les filtres, les types, les rejets et les contrôles. Un export manuel unique n’est pas encore un processus de migration.
- Nettoyer sans falsifier l’historique. Classez doublons, valeurs manquantes, relations cassées et champs détournés. Pour chaque règle de correction, désignez la personne qui la valide et gardez-en la trace.
- Rejouer les mêmes scénarios. Comparez les lignes, totaux, documents, droits, délais et erreurs entre source et cible. Incluez un cas normal, une exception, un échec et un retour arrière.
- Ouvrir à un groupe limité. Décidez qui saisit où, comment éviter les doubles écritures et qui compare les écarts. Sans règle claire, les deux outils peuvent contenir des données différentes sans que l’équipe sache laquelle fait référence.
- Décider la bascule. Avant la bascule, notez la fenêtre d’indisponibilité probable et le mode dégradé. Fixez aussi le moment limite du retour arrière et désignez la personne qui décidera de poursuivre, de reporter ou d’annuler.
- Retirer l’ancien système sans effacer l’historique. Supprimez les comptes, tâches et accès devenus inutiles, archivez ce qui doit l’être et conservez les moyens de lire les anciennes sauvegardes pendant leur durée de conservation.
Pour une migration Access vers SQL Server, le guide Microsoft recommande de construire des requêtes de validation, puis de les exécuter sur la source et la cible dans un environnement isolé. Il demande aussi de comparer les performances. Cette méthode ne garantit pas le résultat et ne couvre pas à elle seule les écrans ou les règles métier, mais elle fournit une base de contrôle reproductible.
Contrôle minimal d’un parcours migré
- Scénario
- Cas normal
- Source attendue
- Résultat de référence horodaté
- Cible attendue
- Même résultat ou écart expliqué
- Décision
- Accepter seulement si le responsable métier valide
- Scénario
- Exception connue
- Source attendue
- Contournement et raison documentés
- Cible attendue
- Exception traitée explicitement, sans perte inexpliquée
- Décision
- Corriger, accepter l’écart ou exclure du premier essai
- Scénario
- Échec de connexion
- Source attendue
- Message, journal et reprise actuelle
- Cible attendue
- Alerte, trace et reprise testée
- Décision
- Bloquer la bascule si l’erreur reste invisible
- Scénario
- Retour arrière
- Source attendue
- Dernier état cohérent identifié
- Cible attendue
- Écritures réconciliées ou annulées
- Décision
- Poursuivre seulement si le retour est exécutable
Que doit contenir un devis de sortie d’Access ?
Compter les tables ne suffit pas pour comparer deux offres. Le devis doit chiffrer la découverte, le nettoyage, le modèle cible, les écrans, les requêtes, les rapports, les automatismes et les connexions.
Il doit aussi décrire la migration répétable, les tests, la formation, l’éventuelle période de double fonctionnement, la bascule, le support, la maintenance et la sortie future. Les inconnues sont des postes à confirmer, pas des zéros.
Les mêmes questions pour comparer les devis
- Sujet
- Travail couvert
- À écrire dans le devis
- Tâches, objets, volumes, exceptions, historiques et exclusions
- Contrôle de fin
- Dossier de sortie versionné et signé par le responsable métier
- Sujet
- Données
- À écrire dans le devis
- Nettoyage, rejets, pièces jointes, liens, conservation et scénarios définis pour tester les données
- Contrôle de fin
- Rapport de migration et réconciliation source/cible
- Sujet
- Droits et sécurité
- À écrire dans le devis
- Rôles, comptes nominatifs, comptes de service, journaux, environnements et sauvegardes
- Contrôle de fin
- Tests d’accès, restauration, révocation et traçabilité définis
- Sujet
- Licences
- À écrire dans le devis
- Access/Runtime, base cible, low-code, connecteurs, BI, stockage et environnements
- Contrôle de fin
- Coût calculé avec le nombre réel d’utilisateurs et les fonctions nécessaires
- Sujet
- Propriété
- À écrire dans le devis
- Code, schéma, scripts de migration, configuration, comptes, documentation et données
- Contrôle de fin
- Accès administrateur transmis et remise de chaque élément contrôlée
- Sujet
- Exploitation
- À écrire dans le devis
- Supervision, alertes, correctifs, support, sauvegarde, restauration et évolutions
- Contrôle de fin
- Responsable, délai de prise en charge et exercice de reprise
- Sujet
- Sortie future
- À écrire dans le devis
- Exports, format, documentation, assistance et coût de sortie
- Contrôle de fin
- Export ouvert et relu, puis procédure de sortie rejouée avant toute dépendance critique
Pour un logiciel standard ou une plateforme low-code, le tarif affiché n’est qu’une partie du coût : ajoutez utilisateurs ou capacité, environnements, connecteurs premium, stockage, automatismes, support et administration. Une application dédiée déplace une partie de ces dépenses vers le développement et l’exploitation. Comparez le coût total sur la même période. Si un poste ne peut pas encore être chiffré, laissez-le « à confirmer » au lieu de lui attribuer un coût nul.
Deux plateformes reviennent systématiquement dans cette comparaison, et chacune a son guide dédié : Power Apps face à une application sur mesure lorsque l’entreprise est déjà équipée Microsoft 365, et Airtable ou Notion face à une application métier lorsque l’équipe a déjà commencé à reconstruire ailleurs. Le calcul du retour sur investissement fournit la méthode pour comparer ces coûts totaux sans forcer le résultat.
Le remplacement lui-même se prépare avec trois autres dossiers : la migration sans interruption de service pour la bascule et son retour arrière, le plan de recette pour prouver que les règles métier survivent au changement, et la gestion des droits d’accès pour remplacer un fichier partagé par des rôles explicites. Si l’application Access a été écrite par une personne partie depuis, la reprise d’un logiciel métier existant précise ce qu’il faut obtenir avant d’y toucher.
Ce qu’il faut réunir avant de solliciter Hagnéré Code
L’étude est utile lorsqu’un responsable métier est disponible, que les tâches sont observables, qu’une copie est exploitable et qu’une personne peut arrêter le premier essai. Elle ne peut pas être menée sérieusement sans accès à l’application, sans utilisateurs, sans données de test ou pendant un incident actif. Vous pouvez présenter le dossier de sortie et les trois tâches prioritaires ; le premier résultat attendu est une liste de vérifications, pas une promesse de développement.
Que faire lundi matin, avant de chercher une agence ?
Prenez une heure avec la personne qui utilise réellement Access. Avant de parler d’écran cible ou de technologies, préservez la capacité de l’équipe à travailler et à expliquer le fonctionnement actuel.
- Notez la version exacte d’Access, le format et les postes concernés.
- Faites créer et restaurer une copie saine sans toucher à l’original.
- Choisissez trois tâches : une fréquente, une critique et une qui comporte beaucoup d’exceptions.
- Reliez leurs formulaires, requêtes, rapports, macros, VBA et connexions.
- Dans le dossier local, notez pour chaque tâche le résultat à retrouver après toute évolution du système.
- Comparez au moins trois pistes : stabiliser Access, choisir un outil standard ou étudier une transformation adaptée au besoin.
- Repérez l’inconnue la plus risquée, puis organisez un essai limité pour obtenir la réponse manquante.
À la fin, vous ne saurez peut-être pas encore quelle technologie choisir. C’est normal. Vous saurez ce qui ne doit pas disparaître, ce qui reste inconnu et quel résultat exiger avant d’engager la suite. Le fichier Access seul ne suffit pas : ce dossier rassemble ce qu’il faut préserver pour décider de la suite et, si vous migrez, ne pas perdre le travail réel.