Votre besoin Microsoft Access
Que faut-il créer, corriger ou faire évoluer ?
Choisissez le problème le plus proche du vôtre. Le formulaire sera prérempli sans vous imposer de connaître la solution technique.
Créer une application
Construire une application métier avec tables, formulaires, règles, recherches, contrôles et éditions.
Créer une application AccessCorriger un bug
Reprendre une erreur VBA, une requête, un formulaire, un état ou une liaison devenue instable.
Faire corriger mon applicationFaire évoluer l’existant
Ajouter une fonction, un écran, un workflow, un import, un export ou une nouvelle règle métier.
Développer une évolutionAméliorer les performances
Mesurer les lenteurs, revoir les requêtes, les index, les traitements VBA et les échanges réseau.
Optimiser ma base AccessOrganiser le multi-utilisateur
Séparer l’interface et les données, distribuer un front-end local ou étudier un back-end SQL.
Fiabiliser le travail à plusieursConnecter ou moderniser
Relier Access à Excel, Word, Outlook, SQL Server, une API, Dataverse ou une application web.
Connecter mon applicationPrestations Microsoft Access
Tout le cycle de vie de votre application, avec un seul interlocuteur.
Une intervention peut porter sur une requête précise, un formulaire devenu instable, une application utilisée par plusieurs services ou un nouvel outil complet. Le périmètre part des utilisateurs, des données, des règles et du réseau.
Application Access sur mesure
Une application construite autour du travail réel de l’équipe, avec navigation claire, saisie contrôlée et résultats exploitables.
- clients, dossiers, CRM et référentiels
- devis, commandes, stocks et interventions
- workflows, historiques et tableaux de bord
Access est traité comme une application métier et une base relationnelle, pas comme un simple fichier de saisie.
Tables, relations et requêtes SQL
Des données structurées et des règles de recherche cohérentes, mesurables et compréhensibles.
- modèle relationnel, clés et intégrité
- index, requêtes paramétrées et agrégations
- SQL Access, DAO, ADO et passthrough selon le cas
Formulaires et navigation
Des parcours adaptés aux opérations réelles, avec recherches, filtres, contrôles et messages compréhensibles.
- saisie guidée et sous-formulaires
- écrans de synthèse et recherche multicritère
- contrôles de complétude et états de workflow
Automatisation Access et VBA
Des actions manuelles transformées en traitements reproductibles, contrôlés et journalisés.
- imports, exports et traitements par lots
- génération Word, PDF et préparation Outlook
- gestion des erreurs, transactions et journalisation
États, documents et reporting
Les restitutions nécessaires au travail quotidien, au contrôle et au pilotage.
- états, factures, devis et fiches dossier
- rapports Word/PDF et exports Excel
- indicateurs, regroupements et historique des éditions
Maintenance et optimisation
Reprendre l’existant sans imposer une reconstruction complète : identifier la cause, corriger le risque et préparer la suite.
- VBA, formulaires, états, requêtes et tables liées
- références, dépendances et compatibilité 32/64 bits
- mesure des lenteurs, tests et documentation
Multi-utilisateur et déploiement
Vérifier comment chaque utilisateur ouvre l’application, où résident les données et comment une version est distribuée.
- front-end local et back-end partagé sur LAN
- ACCDE ou Runtime après vérification
- sauvegarde, versionnement et procédure de mise à jour
Connexions, SQL et modernisation
Conserver l’interface Access lorsqu’elle reste utile et déplacer les données ou certaines fonctions quand les contraintes l’exigent.
- ODBC, SQL Server, Azure SQL ou Dataverse
- Excel, Word, Outlook, fichiers et API sécurisée
- coexistence Access, SQL, services et application web
Développement d’application Access
Des données structurées jusqu’au document ou à la décision.
Une application Access complète relie un modèle de données, des règles métier, des écrans, des contrôles et des restitutions. Je conçois l’ensemble comme un parcours cohérent, pas comme une accumulation d’objets difficiles à relire.
Modéliser
Définir les entités, relations, identifiants, statuts et données de référence.
Saisir
Créer des formulaires guidés adaptés aux utilisateurs et aux opérations réelles.
Contrôler
Bloquer ou signaler les données incomplètes, incohérentes ou non autorisées.
Traiter
Appliquer les règles métier, calculs, imports, rapprochements et automatisations.
Restituer
Produire les listes, états, documents, exports et indicateurs nécessaires.
Historiser
Conserver les statuts, dates, décisions, versions et traces utiles au suivi.
Maintenance Access & VBA
Corriger l’urgence sans rendre la prochaine évolution plus risquée.
Une application historique peut encore rendre un service essentiel tout en accumulant des requêtes lentes, du code VBA fragile, des liens cassés ou des dépendances non documentées. L’intervention commence sur une copie, avec des résultats de référence et une mesure des symptômes.
Préserver le fonctionnement connu
Comparer les résultats avant et après modification sur des cas réels ou reconstitués.
Corriger la cause
Éviter les contournements qui déplacent l’erreur vers une autre requête ou un autre formulaire.
Réduire les dépendances invisibles
Identifier les fichiers liés, bibliothèques, chemins réseau, références Office et paramètres locaux.
Rendre la maintenance possible
Documenter les modules, règles, points d’entrée, déploiements et tests.
Travail à plusieurs
Une architecture adaptée au réseau et au nombre d’utilisateurs.
Mettre un fichier Access dans un dossier partagé ne suffit pas toujours. Il faut distinguer l’interface de chaque personne, le stockage des données, les connexions, sauvegardes, droits et modes d’accès distant.
Faites défiler le tableau horizontalement.
| Situation | Architecture à étudier |
|---|---|
| Quelques utilisateurs sur un réseau local stable | Front-end Access local + back-end Access partagé |
| Plus d’utilisateurs ou des traitements plus importants | Front-end Access + SQL Server |
| Accès distant dans un environnement Windows centralisé | Remote Desktop Services ou bureau distant selon l’infrastructure |
| Données partagées dans l’écosystème Power Platform | Dataverse après étude des types, licences et usages |
| Utilisateurs dans un navigateur ou hors Windows | Application web |
| Reporting partagé à grande échelle | Power BI ou application dédiée |
| Fichier dans OneDrive ou SharePoint pour un usage simultané | Revoir l’architecture : ce stockage ne constitue pas un partage multi-utilisateur fiable |
Microsoft Access est une application PC. Le bon choix dépend de la version d’Office, du réseau, des licences, des politiques de sécurité et de l’organisation de l’entreprise. Une base Access partagée sur un WAN, un VPN ou Azure Files demande une autre architecture ; OneDrive ou une bibliothèque SharePoint ne constituent pas un back-end fiable pour une ouverture simultanée.
Exemples de projets
Des applications métier complètes, pas seulement une table et un formulaire.
Exemple de projet · scénario fictif
CRM et gestion commerciale
Direction commerciale, ADV et équipes de vente
- La situation métier
- Prospects, clients, opportunités, devis et relances sont dispersés entre plusieurs fichiers et boîtes e-mail.
- Le périmètre illustré
- Scénario : 25 000 contacts, 8 000 organisations, 12 utilisateurs et cinq années d’historique.
- La réponse proposée
- Une application centralise les fiches, le pipeline, les devis, les relances, les documents et l’historique commercial.
Ce que les utilisateurs obtiennent
- une fiche client et ses contacts
- un pipeline et des relances partagés
- des devis contrôlés et un historique commun
Voir ensuite les contrôles et choix techniques
Contrôles
- doublons probables
- remise au-delà d’un seuil
- statut ou date de relance incohérents
Technologies possibles
- Access, VBA, DAO et SQL Access
- Word/PDF, Outlook et Excel
- SQL Server en option selon les volumes
Exemple de projet · scénario fictif
Gestion de dossiers, documents et rapports
Opérations, qualité et responsables de dossiers
- La situation métier
- Des dossiers associent clients, sites, prestations, contrôles, photos et documents ; les rapports sont assemblés manuellement.
- Le périmètre illustré
- Scénario : 12 000 dossiers, 18 utilisateurs, 25 modèles de rapport et sept années d’historique.
- La réponse proposée
- Une application guide l’ouverture, la saisie, le contrôle des pièces, la validation et la génération du rapport.
Ce que les utilisateurs obtiennent
- une checklist de complétude
- des statuts et versions historisés
- des rapports Word ou PDF reproductibles
Voir ensuite les contrôles et choix techniques
Contrôles
- pièce obligatoire absente
- étape non validée
- statut et date incohérents
Technologies possibles
- Access, VBA, DAO
- automatisation Word et PDF
- stockage documentaire étudié séparément
Exemple de projet · scénario fictif
Stocks, achats et réapprovisionnement
Achats, logistique et responsables de dépôt
- La situation métier
- Articles, fournisseurs, entrées, sorties et inventaires sont répartis dans plusieurs fichiers ; les écarts restent difficiles à expliquer.
- Le périmètre illustré
- Scénario : 8 000 articles, cinq dépôts, 35 fournisseurs et 500 000 mouvements historiques.
- La réponse proposée
- Une application centralise le catalogue, les mouvements, les inventaires, les commandes et les alertes opérationnelles.
Ce que les utilisateurs obtiennent
- un stock par dépôt traçable
- des inventaires et réceptions contrôlés
- des propositions d’achat justifiées
Voir ensuite les contrôles et choix techniques
Contrôles
- stock négatif ou mouvement dupliqué
- unité ou référence incohérente
- réception supérieure à la commande
Technologies possibles
- Access, VBA et SQL Access
- code-barres selon le matériel
- Excel, Power BI ou SQL Server en option
Exemple de projet · scénario fictif
Planning d’interventions et suivi terrain
Planification, équipes de services et responsables d’agence
- La situation métier
- Demandes, techniciens, équipements, comptes rendus et préparation de la facturation suivent des circuits séparés.
- Le périmètre illustré
- Scénario : 50 techniciens, 30 000 interventions annuelles, 15 000 équipements et trois agences.
- La réponse proposée
- Une application organise les demandes, les affectations, les interventions, les comptes rendus et les éléments à facturer.
Ce que les utilisateurs obtiennent
- un planning et des affectations contrôlés
- un compte rendu complet
- un export des éléments validés vers la comptabilité
Voir ensuite les contrôles et choix techniques
Contrôles
- double affectation ou compétence manquante
- compte rendu incomplet
- intervention facturable non validée
Technologies possibles
- Access, VBA et SQL Access
- Outlook et Excel
- web à étudier pour la saisie mobile ou navigateur
Demandes → affectations → comptes rendus → validation
Exemple de projet · scénario fictif
Maintenance d’une application Access/VBA critique
Équipe dépendante d’une application historique
- La situation métier
- Une application ancienne dépend de nombreuses requêtes, formulaires, modules VBA, fichiers liés et bibliothèques installées sur les postes.
- Le périmètre illustré
- Scénario : 90 tables, 220 requêtes, 75 formulaires, 35 états et 45 modules VBA.
- La réponse proposée
- L’analyse se fait sur une copie, avec inventaire des dépendances, mesure des traitements et résultats de référence avant correction.
Ce que les utilisateurs obtiennent
- une application stabilisée
- des cas de test et résultats de référence
- une documentation de reprise et de déploiement
Voir ensuite les contrôles et choix techniques
Contrôles
- références, ActiveX et chemins réseau
- compatibilité 32/64 bits et API Windows
- requêtes lentes, code mort et erreurs silencieuses
Technologies possibles
- inventaire et export des modules
- mesure, journalisation et gestion d’erreurs
- procédure de version et de maintenance
Exemple de projet · scénario fictif
Conserver Access et migrer les données vers SQL Server
Équipe satisfaite de l’interface mais limitée par le stockage fichier
- La situation métier
- L’interface répond encore au besoin, mais le fichier de données partagé devient lent, fragile ou insuffisant.
- Le périmètre illustré
- Scénario : 25 utilisateurs, 40 tables, 1,2 million de lignes et dix années d’historique.
- La réponse proposée
- Le front-end reste sur chaque poste ; les tables migrent vers SQL Server ou Azure SQL et sont reliées par ODBC.
Ce que les utilisateurs obtiennent
- l’interface connue conservée
- un stockage et des sauvegardes centralisés
- une bascule contrôlée avec plan de retour
Voir ensuite les contrôles et choix techniques
Contrôles
- lignes non migrées et clés dupliquées
- écarts de totaux et relations orphelines
- requêtes lentes ou non délégables
Technologies possibles
- Access, VBA, ODBC et SQL Server
- SSMA après évaluation pour tables et données
- adaptation des requêtes et recette complète
Une intervention maîtrisée
L’application est traitée comme un actif métier, pas comme un simple fichier.
Le travail avance par fonctions vérifiables, avec des sauvegardes, des résultats de référence et une transmission adaptée au périmètre.
Cadrer
Définir les utilisateurs, opérations, données, règles, résultats attendus et situations qui provoquent aujourd’hui une erreur ou une perte de temps.
Sécuriser
Travailler sur une copie ou dans un environnement convenu, avec sauvegarde, sans modifier la production avant validation.
Comprendre
Inventorier tables, relations, requêtes, formulaires, états, macros, modules VBA, fichiers liés et interfaces externes.
Construire
Livrer par fonctions vérifiables, avec une séparation claire entre données, règles, interface et restitution.
Tester
Comparer les résultats à des cas connus, inclure les cas limites et faire valider les sorties par les utilisateurs concernés.
Déployer et transmettre
Documenter prérequis, version, dépendances, mise à jour et maintenance afin que l’application ne dépende pas d’une seule personne.
Format d’intervention
Une correction ciblée, un sprint ou une application complète.
Intervention ciblée
Un bug, une requête, un formulaire, un état, un import ou une liaison identifié.
RésultatCorrection, vérification, explication et recommandations de maintien.
Sprint Access / VBA
Une fonction ou une automatisation dans un périmètre limité.
RésultatFonction testée, intégrée, documentée et prête à être utilisée.
Projet Access complet
Une nouvelle application de gestion, de suivi, de contrôle ou de reporting.
RésultatCadrage, modèle, développement, recette, déploiement, documentation et transfert.
Maintenance évolutive
Une application utilisée qui doit rester stable et continuer à évoluer.
RésultatBacklog priorisé, corrections, évolutions, suivi des versions et documentation maintenue.
Le périmètre, les hypothèses, les livrables et le mode de recette sont définis avant le développement.
Le bon niveau de technologie
Je ne force ni Access ni la migration.
Access peut rester pertinent pour une application métier Windows de taille maîtrisée. SQL Server, Dataverse ou une application web sont étudiés lorsque le partage, les droits, les volumes ou l’accès hors Windows le demandent.
Faites défiler le tableau horizontalement.
| Situation | Technologie à étudier |
|---|---|
| Application métier Windows pour une équipe limitée | Microsoft Access |
| Automatisation locale de l’application | VBA |
| Données partagées sur un LAN stable | Front-end Access local + back-end Access |
| Plus d’utilisateurs, de volumes ou de droits | Access + SQL Server |
| Base relationnelle managée dans le cloud | Azure SQL |
| Écosystème Power Platform | Dataverse |
| Postes sans licence Access complète | Access Runtime après test |
| Documents Word, PDF et exports Excel | Automatisation Office ou états Access |
| Reporting partagé | Power BI |
| Accès navigateur, mobile ou externe | Application web |
| Modernisation progressive | Coexistence Access + API, SQL ou web pendant la transition |
La disponibilité des fonctions dépend de la version d’Access, de l’architecture Office 32 ou 64 bits, de Windows, des licences et des politiques administrateur. SSMA peut aider à migrer les tables et les données vers SQL Server ou Azure SQL ; il ne convertit pas les formulaires, états, macros ou modules VBA en application web.
Qualité de développement et maintenance
- modèle relationnel, clés stables, relations et index mesurés ;
- requêtes paramétrées, validation des entrées et transactions lorsque nécessaires ;
- VBA modulaire avec Option Explicit, gestion d’erreurs et configuration centralisée ;
- contrôle des références, dépendances COM, ActiveX et compatibilité 32/64 bits ;
- aucun secret en clair ni activation globale des macros ;
- sauvegarde, cas de test, documentation et procédure de déploiement.
Expérience réelle
Des applications métier, des données historiques et des processus exigeants.
Les preuves réelles sont séparées des exemples précédents. Les interfaces et données visibles dans les démonstrateurs sont reconstituées pour préserver la confidentialité.
Gestion d’actifs et valorisation
Référentiels, positions, valorisations, contrôles et rôles réunis dans une application métier historique, puis repris progressivement dans une application web partagée.
Voir l’étude de cas AccessModerniser un outil de suivi opérationnel sans interrompre l’activité
L’équipe devait rendre son outil de suivi plus accessible et plus simple à maintenir, sans perdre les données historiques, les règles métier ni les exports utilisés au quotidien.
Lire l’étude de casAutomatiser un reporting métier dans Excel
Produire en quelques minutes plus de 100 rapports pouvant atteindre 100 pages chacun ; la solution repose sur Excel, un complément C#/.NET VSTO et une connexion SQL.
Cette référence démontre la maîtrise d’Office, de SQL et de la génération documentaire ; elle n’est pas présentée comme une mission Microsoft Access.
- TotalEnergies
- Stellantis Financial Services
- ENI France
- BNP Paribas
Les organisations citées correspondent à des contextes de mission. Elles ne constituent ni des témoignages ni une recommandation commerciale implicite.
Quand le problème dépasse Access
Une application fragile révèle parfois un problème de données plus large.
Si Access, Excel, le logiciel comptable et le reporting utilisent des définitions différentes, corriger un formulaire ne suffira pas toujours. Je peux cartographier les sources, clarifier les règles, identifier les responsables et mettre en place les contrôles utiles.
Structurer mes données et mon processus- Source de référence
- Règle métier
- Responsable
- Contrôle de qualité
Votre application produit des factures
Préparez le nouveau circuit sans remplacer Access dans l’urgence.
Access peut continuer à gérer clients, prestations, calculs, validations et historiques lorsqu’ils restent fiables. Le raccordement demande ensuite de cartographier les champs, contrôler les données et organiser les retours de statut de la plateforme agréée retenue.
Découvrir InvoiceBridge pour Microsoft Access InvoiceBridge n’est pas une plateforme agréée. Le raccordement dépend de la plateforme retenue, de ses interfaces et des tests.Lorsque le navigateur devient nécessaire
Préparez une migration progressive sans perdre les règles métier.
L’interface, les données et les traitements ne se convertissent pas automatiquement. La démarche cartographie l’existant, reprend l’historique, compare les résultats et organise la transition.
Voir la migration Access vers le webQuestions fréquentes
Ce qu’il faut savoir avant de confier une application Access.
Pouvez-vous corriger une application Access existante sans tout reconstruire ?
Oui. Une intervention peut porter uniquement sur une requête, un formulaire, un état, un import, une liaison, une erreur VBA ou une lenteur. Une reconstruction complète n’est proposée que si l’analyse montre que la structure actuelle empêche une correction durable.
Pouvez-vous créer une application Access complète à partir d’un besoin métier ?
Oui. Le projet peut inclure le modèle de données, les formulaires, les règles, les contrôles, les requêtes, les états, les imports, les exports, le VBA, le déploiement et la documentation. Le développement commence par les utilisateurs, les opérations et le résultat attendu.
Access est-il encore adapté à une entreprise ?
Il peut l’être pour une application métier Windows, un périmètre maîtrisé et une équipe dont les contraintes sont compatibles avec son architecture. Le diagnostic doit vérifier les volumes, le nombre d’utilisateurs, le réseau, les droits, les intégrations et la maintenance.
Peut-on utiliser Access à plusieurs ?
Oui dans certaines architectures. Sur un réseau local stable, une base séparée avec un front-end local par utilisateur peut être adaptée. Lorsque les utilisateurs, volumes, droits ou accès distants augmentent, un back-end SQL ou une autre architecture peut devenir préférable.
Peut-on placer la base dans OneDrive ou SharePoint ?
Ce n’est pas une solution fiable pour ouvrir simultanément un fichier Access. Des copies concurrentes et des comportements inattendus peuvent apparaître. Il faut étudier un back-end partagé, SQL Server, Dataverse, un bureau distant ou une application web selon le contexte.
Access fonctionne-t-il sur Mac ou dans un navigateur ?
Microsoft Access est une application de bureau disponible uniquement sur PC. Un fichier Access actuel ne s’exécute pas nativement sur macOS ni directement dans un navigateur. Pour un usage Mac, navigateur ou mobile, une autre interface ou une migration progressive doit être étudiée.
Pouvez-vous connecter Access à SQL Server, Excel, Word, Outlook ou une API ?
Oui, lorsque les interfaces, droits et documentations nécessaires sont disponibles. La connexion peut passer par ODBC, DAO, ADO, l’automatisation Office, un service intermédiaire ou une API adaptée.
Que devient le VBA si les données passent sur SQL Server ?
Le front-end Access et une partie du VBA peuvent être conservés. Les requêtes et traitements doivent être vérifiés et parfois adaptés pour exploiter correctement le serveur et éviter des transferts inutiles sur le réseau.
Peut-on distribuer l’application à des utilisateurs qui n’ont pas Access ?
Access Runtime peut permettre d’exécuter une application sur certains postes sans version complète d’Access. Le déploiement, les versions 32 ou 64 bits, les dépendances et les fonctions utilisées doivent être testés avant diffusion.
Comment vérifiez-vous une migration ou une correction ?
Je constitue des résultats de référence, contrôle les volumes, les totaux, les relations et les cas limites, puis organise une recette avec les utilisateurs concernés. Une reprise de données importante est répétée avant la bascule.
Faut-il envoyer la base dès le premier contact ?
Non. Une description du besoin, du nombre d’utilisateurs, de la version d’Access, de l’architecture et du blocage suffit. Si la base doit être étudiée, un canal adapté et les conditions d’accès sont définis séparément.
Combien coûte une intervention Access ?
Une correction ciblée, un sprint d’évolution, une application complète et une migration SQL ne représentent pas le même périmètre. Après un premier échange et, si nécessaire, une analyse sur copie, vous recevez un périmètre, des hypothèses, des livrables et une estimation.
Premier échange
Décrivez ce qu’Access doit faire ou ce qui ne fonctionne plus.
Indiquez l’usage, les utilisateurs, l’architecture actuelle et le principal blocage. Ces informations suffisent pour identifier une première intervention possible.
- aucune base ni donnée confidentielle au premier contact ;
- besoin fonctionnel avant le vocabulaire technique ;
- périmètre, hypothèses et mode de recette explicités.