Migrer un logiciel Access : reprendre, porter ou réécrire ?

Les 13 annonces Access relevées sur codeur.com le 14 octobre 2026 justifient de préparer une consultation précise, mais ne donnent ni budget ni délai pour votre migration. Le relevé fourni ne détaille pas suffisamment les demandes pour attribuer aux PME une préférence entre maintien, portage et réécriture. Vous pouvez constater une demande autour de cette technologie ; vous ne pouvez pas en déduire la solution adaptée à votre base partagée.

Pour remplacer une base Access utilisée par plusieurs services, partez donc des opérations réellement effectuées. Qui crée les dossiers ? Qui les corrige ? Qui utilise les états pour prendre une décision ? Une demande limitée à « refaire notre application » laisse ces différences dans l’ombre. Le prestataire risque alors de chiffrer les écrans visibles sans identifier les règles cachées dans les requêtes, les macros ou les manipulations manuelles.

Exemple hypothétique : votre service commercial saisit une commande, puis votre service administratif complète le dossier et prépare un état. La demande utile décrit ce passage de relais, les informations attendues et les corrections autorisées. Elle précise aussi ce qui se passe lorsqu’un dossier reste incomplet. Cet exemple constitue un scénario de consultation, pas une référence client documentée.

• Décrivez les tâches qui doivent continuer pendant les travaux.
• Recensez les fichiers et traitements qui alimentent la base.
• Distinguez les difficultés actuelles des fonctions que vous souhaitez ajouter.
• Signalez les usages dont personne ne connaît encore le fonctionnement exact.

Vous obtenez ainsi une demande exploitable par les prestataires qui publient une offre Access. Le volume d’annonces sert de contexte ; votre inventaire métier devient la base de comparaison des propositions.

La fin du support impose de traiter votre environnement Office, sans imposer une réécriture complète : Microsoft Learn indique que le support d’Office 2016 et d’Office 2019 a pris fin le 14 octobre 2025, fait vérifié le 13 octobre 2026. Pour décider, séparez la version installée du fonctionnement de votre application. Une suite sans correctif pose un problème de maintien ; elle ne prouve pas que vos formulaires ou vos règles métier doivent être abandonnés.

Demandez d’abord au prestataire de relever les versions réellement utilisées dans chaque service. Faites ensuite examiner les macros, les composants nécessaires au fonctionnement et les échanges avec les autres fichiers. Le passage à une version maintenue doit inclure des essais sur vos usages. Une ouverture réussie du fichier ne démontre pas que les calculs, les impressions et les traitements se comportent comme attendu.

Le maintien convient comme trajectoire lorsque les usages restent satisfaisants et que les vérifications permettent de poursuivre l’exploitation. Le portage devient pertinent lorsque le problème porte surtout sur le stockage ou le partage des données. La réécriture mérite d’être étudiée lorsque les parcours eux-mêmes ne correspondent plus au travail des services. Demandez que chaque recommandation s’appuie sur un constat identifié dans votre application.

Exemple hypothétique : vos utilisateurs apprécient les formulaires existants, mais votre environnement Office n’est plus maintenu. Le devis doit alors distinguer la remise à niveau de cet environnement, les adaptations nécessaires et une éventuelle transformation plus large. Vous pourrez décider sans confondre urgence de maintenance et souhait de refonte.

Le comparatif entre réécriture et modernisation vous aide à formuler cet arbitrage. Exigez surtout une explication des éléments conservés, modifiés et retirés, avec les conséquences sur le travail quotidien.

Déplacer les données mérite un examen prioritaire lorsque votre base approche 2 gigaoctets, limite comprenant les objets système selon les spécifications Microsoft Support vérifiées le 13 octobre 2026. Cette contrainte concerne le fichier Access. Elle invite à examiner le stockage avant de conclure que tous les écrans doivent être remplacés. Microsoft cite notamment la liaison à des tables d’autres bases comme moyen de contourner la limite de taille.

Dans votre consultation, demandez au prestataire de distinguer les données, les traitements et l’interface. Cette séparation permet de comprendre ce qui doit changer pour résoudre le problème observé. Une proposition de déplacement des tables doit expliquer ce que deviennent les requêtes, comment les formulaires retrouvent les informations et quels traitements nécessitent une adaptation. Le choix du serveur doit être justifié dans votre contexte.

Ce tableau présente des options à instruire, sans attribuer aux agences des compétences absentes du dossier. Pour chaque cible proposée, faites nommer les composants retenus et les raisons du choix.

Exemple hypothétique : les états répondent toujours aux besoins, tandis que le fichier partagé devient contraignant. Un déplacement des données peut être étudié en conservant les états. La décision dépend alors des essais de liaison et des adaptations relevées, pas d’une préférence générale pour une technologie récente.

Demandez enfin comment vous récupérerez les données et leur description après la migration. La cible doit rester compréhensible et exploitable par votre organisation.

Une application web mérite d’être étudiée pour des usages partagés à distance, mais le plafond de 255 utilisateurs simultanés publié par Microsoft Support, vérifié le 13 octobre 2026, ne suffit pas à décider du remplacement. Ce maximum technique ne constitue pas une garantie de fonctionnement pour votre organisation. Votre choix doit partir des conditions d’accès, des tâches concurrentes et des passages de relais entre services.

Décrivez les parcours que la cible web devrait prendre en charge. Précisez les informations visibles par chaque fonction, les modifications autorisées et les documents produits. Faites aussi identifier les usages qui reposent aujourd’hui sur une manipulation locale. Une consultation qui demande seulement de rendre la base accessible dans un navigateur laisse ouvertes des questions essentielles sur les responsabilités et les résultats attendus.

Exemple hypothétique : un service prépare un dossier pendant qu’un autre vérifie ses pièces. Votre scénario doit préciser si ces interventions peuvent se dérouler ensemble, quelle modification doit être signalée et qui peut clôturer le dossier. L’agence doit expliquer comment sa proposition traite ce fonctionnement. Une démonstration sur un écran isolé ne permet pas de réceptionner ce passage de relais.

• Faites montrer un parcours complet entre les services concernés.
• Vérifiez les droits avec des profils représentant vos utilisateurs.
• Demandez le comportement prévu lorsqu’une saisie reste incomplète.
• Identifiez les impressions, exports et échanges à préserver.

Le web devient une cible défendable lorsque ces besoins sont décrits et que la proposition y répond. Il ne dispense pas de reprendre les règles métier ni de contrôler les données. Inscrivez les parcours attendus dans votre cahier des charges, avec les résultats qui permettront de les accepter.

L’audit doit examiner les objets et traitements autant que les tables, car la limite de 2 gigaoctets inclut les objets système selon Microsoft Support, vérifié le 13 octobre 2026. Le volume du fichier ne décrit donc pas à lui seul le contenu à reprendre. Pour préparer les travaux, faites inventorier les formulaires, requêtes, états, macros et dépendances qui participent réellement au service rendu.

Associez cet inventaire à des entretiens avec les utilisateurs. Une requête rarement exécutée peut servir à une opération indispensable. Un export peut être repris manuellement par un autre service sans que cette dépendance apparaisse dans la base. Demandez que l’audit relie chaque élément conservé à un usage identifié, et qu’il signale les objets dont le rôle reste à confirmer.

Exemple hypothétique : un état semble inutilisé parce qu’il n’apparaît pas dans le parcours courant. Le service administratif explique pourtant qu’il s’en sert pour contrôler une clôture. Avant de le retirer, faites préciser les informations qu’il rapproche et le résultat attendu. Vous pourrez ensuite décider de conserver cet état, de le transformer ou d’intégrer son contrôle dans un autre parcours.

L’examen des macros doit également tenir compte de leur provenance et de leur circulation. Le dossier documente le blocage par défaut des macros VBA issues d’Internet dans Office. Demandez donc comment les fichiers sont reçus, transmis et utilisés. Le comportement d’un fichier ouvert depuis un emplacement habituel ne suffit pas à valider tous les modes de distribution.

Le livrable attendu est une cartographie exploitable : éléments identifiés, usages associés, dépendances connues et questions à résoudre. Faites-la joindre au devis. Elle permettra de comprendre pourquoi un traitement demande une adaptation et de discuter une découverte ultérieure sur une base documentée.

Vous devez demander un chiffrage propre à votre application, car les 13 annonces Access relevées sur codeur.com le 14 octobre 2026 ne fournissent aucun budget dans le dossier. Elles ne permettent pas davantage d’annoncer un délai. Une proposition commerciale exploitable doit donc expliquer son périmètre, ses hypothèses et les validations nécessaires avant de fixer les engagements de réalisation.

Faites distinguer le diagnostic, la préparation des données, l’adaptation des traitements, les écrans, la recette et la bascule. Le devis doit indiquer ce qui est inclus dans chaque poste et ce qui dépend encore d’une vérification. Demandez notamment comment seront traitées les dépendances découvertes pendant les travaux. Une ligne globale de migration vous laisse sans explication lorsque le périmètre évolue.

Le calendrier doit faire apparaître les interventions de vos services. La disponibilité d’un utilisateur pour expliquer une règle ou valider un état conditionne la progression du projet. Faites préciser les documents attendus, les décisions à prendre et les conséquences d’une validation tardive. Vous disposez alors d’un calendrier de travail, accompagné de responsabilités identifiées.

• Demandez les livrables qui déclenchent une validation.
• Faites décrire la gestion des demandes ajoutées après le cadrage.
• Précisez qui prépare les données et qui les contrôle.
• Identifiez le contenu de l’assistance après la bascule.

Exemple hypothétique : votre base contient des dossiers incomplets que les utilisateurs corrigent au fil de l’eau. Le devis doit dire si le prestataire les importe tels quels, vous remet une liste à traiter ou réalise un nettoyage défini avec vous. Ces prestations ne répondent pas au même besoin.

Pour comparer les offres, rapprochez les mêmes livrables et les mêmes obligations. Le cadrage du coût d’une refonte doit servir à structurer vos questions, sans transformer un prix d’entrée publié en coût de migration garanti.

La fin du support d’Office 2016 et d’Office 2019 depuis le 14 octobre 2025, documentée par Microsoft Learn et vérifiée le 13 octobre 2026, justifie de demander une trajectoire argumentée au prestataire. Une page publiée sur la reprise Access établit l’existence d’une offre. Pour choisir, vous devez ensuite vérifier comment l’équipe proposée examine votre application et prépare les décisions de conservation ou de remplacement.

Présentez aux candidats le même parcours métier et les mêmes éléments techniques disponibles. Demandez-leur ce qu’ils souhaitent examiner avant de recommander une cible. Une réponse utile distingue les constats déjà établis, les hypothèses et les essais nécessaires. Elle explique aussi comment les utilisateurs participeront à la compréhension des règles.

Les agences du classement ne présentent pas toutes la même preuve documentaire. Certaines publient une page consacrée à la reprise de bases Access ; l’offre voisine de modernisation d’applications doit être appréciée pour ce qu’elle décrit. Vous pouvez consulter ces profils, puis demander une réponse spécifique à votre besoin. Aucune présentation générale ne remplace l’examen de votre base.

Exemple hypothétique : votre application combine saisies, macros et états utilisés par des services différents. Demandez au candidat de proposer la manière dont il documenterait cette chaîne. Son explication doit identifier les informations à recueillir et les validations attendues, sans promettre une reprise intégrale avant analyse.

Faites enfin préciser les personnes qui conduiront l’audit, les échanges avec vos utilisateurs et le suivi des corrections. Vérifiez les modalités de remise de la documentation et des éléments nécessaires à la maintenance. Les offres de reprise de logiciel deviennent comparables lorsque chaque candidat répond aux mêmes questions sur votre application, avec des engagements écrits et un périmètre explicite.

La recette doit vérifier les résultats et les usages partagés, car le plafond de 255 utilisateurs simultanés indiqué par Microsoft Support, vérifié le 13 octobre 2026, ne prouve aucune équivalence entre votre application actuelle et sa cible. Accepter la migration suppose de constater que les données, les règles et les parcours attendus fonctionnent ensemble. Préparez ces vérifications avant le développement des écrans.

Choisissez avec les services des dossiers représentatifs de leur activité. Pour chacun, décrivez les informations de départ, les actions réalisées et le résultat attendu. Conservez les états ou exports nécessaires à la comparaison. Faites préciser les différences volontaires : une correction de règle demandée doit être identifiable, afin de ne pas être confondue avec une anomalie de reprise.

1. Contrôlez la présence des données utiles et leurs relations.
2. Rejouez les créations, modifications et validations attendues.
3. Comparez les calculs, états et exports retenus pour la recette.
4. Testez les droits et les interventions de services différents.
5. Consignez les écarts, les corrections et leur validation.

Exemple hypothétique : un dossier passe du service commercial au service administratif, puis revient pour correction. La recette doit suivre ce retour, vérifier les informations conservées et constater que chaque intervenant dispose des droits prévus. Le simple affichage du dossier dans la nouvelle interface ne démontre pas que le parcours est repris.

Faites également examiner les comportements lorsque des informations manquent ou qu’une opération est interrompue. Les cas imparfaits font partie de votre activité et doivent figurer dans les critères d’acceptation. Demandez que les résultats de recette restent consultables avec les décisions prises. Vous pourrez ainsi prononcer la réception à partir de constats partagés, et transmettre à la maintenance une description claire des comportements validés.

La bascule doit inclure l’environnement Office conservé, puisque Microsoft Learn documente la fin du support d’Office 2016 et d’Office 2019 au 14 octobre 2025, fait vérifié le 13 octobre 2026. Déplacer les données ne règle pas automatiquement la situation des postes qui continuent à utiliser les anciens écrans. Votre plan doit donc décrire ce qui change pour les utilisateurs et ce qui reste nécessaire à l’exploitation.

Faites préparer une répétition de la migration sur une copie de travail. Elle doit permettre de vérifier les opérations prévues, les contrôles à réaliser et les personnes qui les valident. Demandez ensuite un document de bascule précisant la source des données retenue, le moment où les modifications cessent dans l’ancien outil et les conditions d’ouverture de la cible.

Exemple hypothétique : un service continue à saisir dans la base historique pendant qu’un autre commence à utiliser la nouvelle application. Sans règle définie, votre organisation ne sait plus quel dossier fait référence. Le plan doit indiquer si cette coexistence est autorisée, comment les modifications sont prises en compte et qui tranche lorsqu’un écart apparaît.

Définissez aussi les conditions d’un retour à l’ancien fonctionnement. Faites expliquer quelles données seraient disponibles et comment seraient traitées les opérations réalisées depuis l’ouverture de la cible. Une copie conservée du fichier historique ne décrit pas à elle seule une procédure de retour exploitable.

Enfin, organisez l’assistance après l’ouverture : interlocuteur, signalement des incidents, validation des corrections et remise documentaire. Le contrat doit permettre de distinguer un défaut de reprise d’une demande d’évolution. Reliez ces engagements à votre maintenance applicative, afin que les services sachent comment faire corriger un problème une fois le chantier de migration terminé.