La base maison devenue critique
Elle a été construite il y a quinze ans par un collaborateur passionné, un soir après le travail. Un fichier .accdb ou une solution FileMaker sur le serveur du bureau, des formulaires gris, des boutons qui lancent des macros, des états imprimés tous les matins. Aujourd'hui toute l'activité passe par elle : dossiers clients, suivi de production, planning, facturation parfois. Son auteur est parti, ou il est le seul à oser la modifier.
Les symptômes reviennent d'une entreprise à l'autre :
- la base ne fonctionne bien que sur le réseau du bureau, et le télétravail passe par une prise de main à distance laborieuse ;
- les techniciens ou commerciaux n'y ont pas accès depuis le terrain ;
- la base « se corrompt » de temps en temps et il faut la compacter ou restaurer la sauvegarde de la veille ;
- une mise à jour de la suite bureautique ou du système fait planter une macro ;
- les droits se limitent à « tout le monde voit tout ».
Le coût le plus lourd est le risque : une base unique, sans documentation, dont dépend toute l'activité, et que personne en interne ne sait réparer.
Pourquoi Access, FileMaker et Excel atteignent leurs limites
Ces outils sont conçus pour des bases de bureau, pas pour une application d'entreprise ouverte sur l'extérieur. Pour Access, Microsoft documente lui-même les plafonds : 2 gigaoctets par fichier de base, objets système compris, et 255 utilisateurs simultanés au maximum, bien au-delà de ce que tolère en pratique un fichier partagé sur le réseau. Les limites qui comptent le plus pour une PME sont ailleurs :
| Limite | Conséquence |
|---|---|
| Fichier partagé sur un réseau local | Accès distant difficile, lenteurs dès que la connexion faiblit, risque de corruption |
| Logique dans les formulaires et macros | Les règles métier sont dispersées, difficiles à lire et à tester |
| Interface de bureau | Inutilisable sur téléphone ou tablette |
| Droits sommaires | Impossible de donner un accès limité à un partenaire ou à un client |
| Compétences rares | Peu de développeurs disponibles pour maintenir du VBA ou des scripts FileMaker |
FileMaker propose son propre hébergement (FileMaker Server ou FileMaker Cloud) et un accès par navigateur avec FileMaker WebDirect, et Access peut être relié à une base SQL Server. Ces passerelles prolongent la vie de la base sans changer sa nature : la logique reste dans l'outil bureautique, et la dépendance à une compétence rare demeure. Le cas du tableur partagé, plus simple, est traité sur notre page pour remplacer Excel par un logiciel de gestion.
Que reprend-on, et que repense-t-on ?
Une migration n'est pas une copie écran pour écran. On reprend ce qui a de la valeur, on corrige ce qui gênait :
- Les données : toutes, avec leur historique. C'est non négociable.
- Le modèle de données : les tables sont analysées, les champs détournés de leur usage remis à plat, les doublons et les listes de valeurs normalisés. La cible est PostgreSQL, base serveur standard et robuste.
- Les règles métier : extraites des requêtes, des macros, des formules de calcul et des procédures VBA ou des scripts FileMaker, puis réécrites dans le serveur de l'application où elles sont testées.
- Les écrans : repensés pour le navigateur et le téléphone, en suivant l'ordre de travail réel des utilisateurs plutôt que la structure des tables.
- Les états imprimés : devis, bons, fiches, étiquettes, générés en PDF à l'identique ou améliorés.
Ce que l'on gagne au passage : droits par profil, historique de chaque modification, accès sécurisé depuis l'extérieur, sauvegardes automatiques, et la possibilité de brancher d'autres outils par API.
Comment se déroule la migration sans arrêter l'activité ?
- Cadrage : copie de la base, inventaire des tables, requêtes, formulaires, états et macros, entretiens avec les utilisateurs pour savoir ce qui sert vraiment. Beaucoup de bases contiennent des écrans abandonnés depuis des années. Le chiffrage suit cet inventaire.
- Maquettes des écrans principaux, validées par ceux qui utilisent la base chaque jour.
- Construction par cycles courts, avec une version testable alimentée par une copie récente des vraies données, pour que les utilisateurs comparent avec l'ancien outil.
- Répétitions de migration : le script de reprise est rejoué plusieurs fois sur des copies, et chaque passage produit un rapport de contrôle (nombre d'enregistrements, totaux, cas rejetés).
- Bascule un vendredi soir ou un jour creux : dernière reprise, contrôle, ouverture de l'application web. L'ancienne base passe en lecture seule et reste consultable.
- Évolution : application mobile, portail client, connexions vers la comptabilité.
La méthode complète est décrite sur la page processus.
Les pièges d'une migration de base bureautique
- Les règles cachées : une requête qui exclut silencieusement les clients d'un département, une macro qui arrondit les prix. Elles ne figurent dans aucun document. On les retrouve en comparant les résultats de l'ancienne et de la nouvelle application sur les mêmes données.
- Les champs à tout faire : un champ « Commentaire » qui contient en réalité une date, un code et un statut. Il faut le découper avant de migrer.
- Les tables liées externes : fichiers Excel ou autres bases reliés à la base principale, oubliés lors de l'inventaire.
- La reproduction à l'identique : refaire exactement les écrans de 2009 dans un navigateur, c'est payer une migration sans en tirer le bénéfice.
Si la base Access est en réalité un logiciel ancien à part entière, avec une architecture complexe et plusieurs modules, la page moderniser un logiciel ancien décrit l'approche progressive, module par module.
Quand migrer n'est pas la bonne réponse
- Un seul utilisateur, au bureau : si la base fonctionne, n'est utilisée que par une personne et ne contient rien de critique, une bonne sauvegarde et une documentation suffisent.
- Un logiciel du marché couvre désormais le besoin : la base a été créée faute d'outil adapté. Si un logiciel standard existe aujourd'hui pour votre métier, migrez les données vers lui.
- Besoin d'accès distant uniquement : relier Access à une base serveur ou héberger la solution FileMaker peut suffire temporairement, le temps de préparer une migration plus complète.
- Usage en déclin : si l'activité portée par la base doit s'arrêter, exportez et archivez.
La migration se justifie dès que la base est critique, partagée, consultée hors du bureau ou impossible à maintenir faute de compétences. Notre page sur le logiciel métier sur mesure détaille ce que devient l'outil une fois sur le web.
Questions fréquentes
- Peut-on migrer une base Access vers le web sans perdre de données ?
- Oui. La migration d'une base Access vers une application web reprend l'intégralité des tables et de leur historique. Le script de reprise est répété plusieurs fois sur des copies, avec un rapport de contrôle à chaque passage : nombre d'enregistrements, totaux, lignes rejetées. L'ancienne base reste consultable en lecture seule après la bascule.
- Combien d'utilisateurs une base Access supporte-t-elle ?
- Microsoft indique pour une base Access une limite de 255 utilisateurs simultanés et une taille maximale de 2 gigaoctets par fichier, objets système compris. En pratique, une base partagée sur un réseau devient lente et fragile bien avant ces seuils, surtout avec des accès à distance. C'est souvent ce qui motive la migration vers une application web.
- Que deviennent les macros et le code VBA lors de la migration ?
- Les macros et le code VBA ne sont pas convertis automatiquement : ils sont lus, compris, puis réécrits comme règles métier dans le serveur de la nouvelle application, où ils peuvent être testés. C'est souvent l'occasion de découvrir des règles oubliées, de supprimer celles qui ne servent plus et de documenter celles qui restent.
- Faut-il migrer une base FileMaker vers une autre technologie ?
- Pas toujours. Une base FileMaker peut rester sur FileMaker, qui propose un hébergement (FileMaker Server ou FileMaker Cloud) et un accès par navigateur avec WebDirect, suffisants pour de petites équipes. La migration vers une application web standard se justifie quand la base devient critique, quand il faut ouvrir l'accès à des clients ou partenaires, connecter d'autres logiciels, ou quand plus personne ne sait maintenir les scripts FileMaker.
- Les utilisateurs peuvent-ils garder l'ancienne base pendant la transition ?
- Oui. Pendant le développement, les utilisateurs travaillent dans l'ancienne base tout en testant la version web alimentée par une copie récente des données. À la bascule, une dernière reprise est faite et l'ancienne base passe en lecture seule. Elle reste consultable aussi longtemps que nécessaire pour retrouver un ancien dossier.