Migration ou évolution d’une application Access existante
Evolution ou migration ?
Faut-il faire évoluer ou migrer une application Access® existante quand cette dernière présente des signes inquiétants de dysfonctionnements (lenteur, plantage, etc.) ? L’architecture mise en place offre-t-elle les garanties suffisantes de robustesse, pérennité et sécurité ? La décision d’une évolution ou migration doit tenir compte de différents paramètres de natures différentes.Etude de l'existant
- La structure de la base de données
L’intégrité référentielle est-elle respectée ?, la structure des tables et des champs définis est-elle cohérente ?, le nommage est-il respectueux ?, etc. - La taille des données de la base
Quels sont les volumes des tables de la base ? Une base trop volumineuse pourra notamment rapidement présenter des problèmes de performance. - L’écriture des requêtes
La performance de restitution des données par requêtes/procédures est parfois (souvent) sujette à la qualité de l’écriture de ces dernières. Une optimisation des requêtes peut radicalement augmenter les performances d’une base. - Analyse du code
Le code VBA est-il « propre » ? Le VBA n’est pas un langage objet, aussi, ce dernier peut parfois être difficilement lisible pour un tiers développeur et un code mal structuré, peu commenté peut s’avérer non maintenable. - Les états / graphes
L’application dispose-t-elle de nombreux états/graphes et ces derniers sont-ils élaborés ? L’une des grandes forces d’Access est de pouvoir restituer des sorties papier ou reports de grande qualité. Toute migration ne devra pas négliger cet aspect. - Les écrans/formulaires
L’ergonomie des écrans est-elle bien étudiée ? Les formulaires permettent-ils de rapidement obtenir/renseigner les informations désirées ? Access offre la possibilité de générer rapidement des écrans de recherche, saisie, d’affichage, etc., mais ces derniers peuvent présenter des désavantages : esthétisme peu soigné, synoptique mal pensée, etc. - Multiutilisateurs
L’application Access est-elle fonctionnelle en cas de connexion simultanée de plusieurs utilisateurs ? L’application fonctionne-t-elle avec un fichier de données séparé du fichier des écrans ? - Interaction avec poste client
L’application communique-t-elle avec des composants / logiciels du poste client (ex : Outlook, Word, etc.) ? Certaines fonctions peuvent difficilement être migrées dans un environnement client léger (web). - Sécurité
L’application présente-t-elle toutes les garanties de sécurité d’accès ? Est-il possible à un tiers de copier/manipuler la base facilement ? Des groupes de sécurité (.mdw) ont-ils été mis en place ? Etc. - Déploiement
L’application se déploie-t-elle facilement ? Plusieurs versions d’Access (ou runtimes Access) sur des postes aux environnements différents peuvent constituer des difficultés dans les démarches d’installations ou mises à jour de l’application
Moyens et nouvelles fonctionnalités
Ensuite, les moyens à disposition et les évolutions souhaitées auront un impact dans la décision finale :- Les évolutions souhaitées sont-elles possibles avec Access ?
Ex : la mise en place d’un Web Service sera très difficile dans un environnement VBA / Access. - Une compétence en interne permet-elle la maintenance de l’application Access ou de l’architecture cible ?
La migration vers un nouvel environnement ne va-t-elle pas limiter la réactivité et la flexibilité possible avec Access ? - Les coûts engendrés pour une migration à « iso fonctionnalités » sont-ils pertinents ?
- Etc.
Cibles possibles
Enfin, techniquement, plusieurs architectures cibles sont possibles :- 1. L’application est maintenue dans un environnement Access mais est optimisée dans les secteurs défaillants.
Cette solution peut être intéressante pour son faible coût, si l’application actuelle présente des gages de pérennité et robustesse. - 2. Les écrans Access sont maintenus et seule la base de donnes est migrée (vers SQL Server par exemple). La liaison vers la base devra être établie (plusieurs procédés sont possibles).
Cette architecture est intéressante pour sécuriser et rendre plus robuste la base de données, et ce à un coût moindre qu’une migration complète. - 3. Les écrans et la base sont migrés dans un nouvel environnement multiutilisateur.
Cette architecture est généralement la plus onéreuse (temps de réalisation/migration des données plus important) mais elle permet de bénéficier d’avantages liés à l’architecture cible choisie : refonte de l’ergonomie, ajouts de fonctionnalités, performance accrue, etc. Conclusion : La technique doit se mettre au service du métier car un projet informatique est avant tout un projet d’entreprise. Migrer « techniquement » une application vers une nouvelle architecture sans ajout fonctionnel ne présente pas -ou peu- d’intérêts pour le besoin métier d’une entreprise. Aussi, la première question à poser, avant toute considération technique, est sans doute la suivante : Quels sont les gains que peuvent apporter le nouvel outil ?
L’expertise Need Solutions
Need Solutions a effectué par le passé de nombreux projets de refonte, d’amélioration et de migration d’application Access vers de nouveaux environnements. Notre expertise Access comprend notamment- l’audit d’applications existantes,
- le développement VBA,
- la maintenance évolutive d'applications existantes,
- la formation,
- la migration Access vers les environnements ASP.NET/SQL Server notamment (base et écrans) : il est à noter qu’une migration ne se limite pas à retranscrire les écrans et la base dans le nouvel environnement. L'ensemble des écrans (formulaire de saisie, recherche, consultation, statistiques) doit être repensé avec les composants adaptés au besoin : synoptique de navigation optimisée avec lisibilité accrue, formulaire de saisie avec composants de recherche de saisie contextuelle, liste de recherche multicritères contextuelle, export générique vers différents formats de sortie, graphiques de statistiques, etc. L’IHM doit être conviviale et intuitive, la base robuste et pérenne.
