Étude de cas · Application métier
Remplacer une base Access partagée par un vrai outil métier
Un spécialiste de la sécurité incendie pilotait toute son activité sur une base Access partagée. Aujourd'hui : une application web métier en production depuis avril 2026, 60 tables, la chaîne devis → facture → paiement complète, et une application tablette en test chez les techniciens.
Le contexte
One Incendie installe et maintient des équipements de sécurité incendie en Normandie : extincteurs, désenfumage, alarmes, plus les formations et les audits qui vont avec. Des centaines de sites clients, chacun avec son parc de matériel, ses contrats et ses visites périodiques obligatoires.
Toute cette gestion vivait dans une base Access posée sur un partage réseau. Elle avait rendu de grands services pendant des années — et elle était arrivée au bout.
Le diagnostic
Les symptômes d'un Access partagé en fin de vie sont toujours les mêmes :
- L'accès concurrent. Access verrouille. À plusieurs sur le même enregistrement, on attend, on se marche dessus, ou on corrompt.
- La lenteur qui s'installe. Le volume grossit, les requêtes transitent par le réseau, et chaque ouverture de fiche devient une pause.
- Rien en dehors du bureau. Pas d'accès depuis le terrain, pas depuis chez soi, pas depuis une tablette.
- Aucune traçabilité. Impossible de savoir qui a modifié quoi, ni quand.
- La sauvegarde est un copier-coller de fichier. Avec tout ce que ça implique le jour où il faut vraiment restaurer.
Mais le point important est ailleurs : cette base contenait quinze ans de métier. Des règles de facturation, des périodicités de contrôle, des conditions de remise par famille d'article qu'aucun logiciel du marché ne couvre tel quel. C'est précisément pour ça qu'on reconstruit plutôt que d'acheter.
La méthode
- Reprendre le modèle existant, pas le simplifier. Le schéma final compte 60 tables : c'est le métier réel, pas une version allégée qui aurait obligé l'équipe à travailler autrement.
- Migrer l'intégralité des données. Clients, contacts, devis, factures, bons de livraison, articles, planning des contrôles : tout a été importé, pas ressaisi.
- Basculer en parallèle, pas d'un coup. C'est le point qui a rendu la transition acceptable. Pendant plusieurs semaines, Access et le nouveau CRM ont tourné côte à côte : chaque action métier était faite des deux côtés, les PDF générés comparés un à un. Tant que la validation n'était pas faite, l'ancien système restait la référence.
- Maintenance rapprochée au démarrage. Les premières semaines d'utilisation réelle sont celles qui révèlent les cas que personne n'avait décrits. Elles ont été traitées au fil de l'eau.
Ce qui a été livré
La chaîne commerciale complète : prospect, client, devis avec acomptes, bon de livraison, facture, paiement, relance. Chaque document se génère en PDF.
Le catalogue et le stock : articles, familles, fabricants, fournisseurs, prix spécifiques par client, remises par groupe et par famille, mouvements de stock, inventaires.
Le cœur métier : contrats de maintenance, parc de matériel installé chez chaque client, contrôles de visite périodiques avec leur planning, interventions annuelles, découpage par zones.
L'administration : rôles et permissions fines, journal d'audit — on sait enfin qui a fait quoi — et paramétrage des référentiels sans passer par le développeur.
Back-end
NestJS, Prisma, PostgreSQL. Architecture en couches, validation stricte des entrées, génération PDF côté serveur.
Front-end
Next.js 16 et React 19, TanStack Query pour l'état serveur, React Hook Form et Zod pour les formulaires, Recharts pour les indicateurs.
Volume
Environ 72 000 lignes de TypeScript, 60 modèles de données, un portail client séparé.
Exploitation
Serveur dédié, HTTPS, accès SSH par clé uniquement, compte root désactivé, pare-feu, protection anti-force brute sur l'authentification.
La suite : l'application terrain
Les techniciens, eux, travaillaient sur des fichiers Excel. Une application tablette est en test depuis août 2026 pour les remplacer : planning hebdomadaire des interventions assigné depuis le CRM, cartographie zones → sous-zones → produits à inspecter, formulaires d'inspection avec un état par produit, et facturation sur place des pièces détachées.
Comme pour le CRM, le déploiement est progressif : deux tablettes, deux techniciens volontaires, de vraies tournées, et la procédure papier maintenue en parallèle tant que le test n'est pas concluant.
Le résultat
Le CRM est en production depuis fin avril 2026. L'équipe travaille à plusieurs en même temps sans se bloquer, depuis le bureau comme de l'extérieur. Les documents commerciaux sortent de l'application. Les contrôles périodiques sont planifiés et suivis au lieu d'être surveillés à la main. Et les indicateurs que les fichiers Excel ne donnaient pas existent enfin.
Ce qu'on peut en retenir
On ne remplace pas un outil métier d'un coup. La bascule en parallèle coûte quelques semaines de double saisie, et c'est ce qui fait la différence entre une migration acceptée et une migration subie. Personne n'a eu à faire confiance à un système non vérifié.
Une vieille base contient du métier qui a de la valeur. Le réflexe d'acheter un logiciel du marché se heurte toujours au même mur : il faudrait changer les règles de l'entreprise pour entrer dans l'outil. Reconstruire coûte plus cher au départ et moins cher ensuite.
Questions fréquentes
Combien de temps pour remplacer une base Access ?
Ici, environ quatre mois entre les premières maquettes et la mise en production, pour 60 tables et la chaîne commerciale complète. Le délai dépend surtout du nombre de règles métier à reprendre, pas du nombre d'écrans.
Faut-il tout migrer d'un coup ?
Non, et c'est même déconseillé. Faire tourner l'ancien et le nouveau en parallèle pendant quelques semaines permet de comparer les résultats document par document. L'ancien système reste la référence tant que le nouveau n'a pas fait ses preuves.
Pourquoi développer plutôt qu'acheter un logiciel du marché ?
Quand les règles métier sont standards, acheter est plus rapide et moins cher — je le dis quand c'est le cas. Quand l'entreprise a construit sa façon de travailler sur quinze ans, un logiciel générique oblige à la défaire. C'est là que le sur-mesure se justifie.
Une application terrain peut-elle fonctionner sans réseau ?
Oui, et c'est en général indispensable : les interventions ont lieu dans des endroits sans couverture. Les données sont stockées localement de façon chiffrée, puis remontées automatiquement dès que le réseau revient, avec reprise en cas d'échec.
Qui est propriétaire du code ?
Le client. Le code, les accès serveur et les données lui appartiennent, et la documentation administrateur et utilisateur lui a été remise. Aucune dépendance n'est créée envers moi.
Un outil métier à remplacer ?
Base Access à bout de souffle, fichiers Excel qui circulent, logiciel que plus personne ne maintient : je reprends l'existant et je le reconstruis sans interrompre votre activité. Premier retour sous 24 h.