01. Contexte & problématique
L'entreprise cliente gère une flotte de véhicules de transport avec un logiciel Access développé en interne depuis plusieurs années. Cette base de données — environ 233 Mo, ~60 tables — centralise l'ensemble du cycle de vie opérationnel : offres de prix, ordres de course, décomptes chauffeurs et véhicules, facturation.
Le problème principal : Access atteint ses limites de scalabilité, bloque le travail multi-utilisateurs simultané, et rend impossible toute évolution vers une interface web moderne. L'objectif est de migrer vers une stack ouverte, pérenne, et d'y greffer une application web accessible depuis n'importe quel poste.
Contraintes héritées
- Export CSV Access : délimiteur
;, encodage Windows-1252 - ~25 tables avec données métier réelles
- ~25 000 enregistrements à migrer
- Noms de champs en français, parfois avec accents
- Types de données Access non standards (Yes/No, Memo)
Objectifs techniques
- Zéro perte de données lors de la migration
- Schéma normalisé et typé proprement
- Base hébergée sur infra auto-gérée (NAS Synology)
- API REST consommable par un frontend React
- Compatibilité Swiss/Swissdec pour la facturation
02. Stratégie de migration
La migration est découpée en deux bases MariaDB distinctes, avec une philosophie progressive : d'abord tout faire rentrer, ensuite tout nettoyer.
cbus_staging
Base intermédiaire "fourre-tout". Tous les champs en TEXT large pour absorber les incohérences des exports Access sans erreur d'insertion. Sert de filet de sécurité.
cbus_app
Base de production avec schéma tightened : types précis (DATE, DECIMAL, TINYINT(1)), clés étrangères, contraintes NOT NULL là où applicable.
Leçons apprises
- Toujours utiliser le sélecteur graphique de base dans DBeaver plutôt que
USE db;dans les scripts — les scripts multi-fichiers perdent le contexte de base facilement. - Les exports Access en CSV nécessitent un recodage UTF-8 explicite avant import (iconv ou pandas).
- Les champs booléens Access (
Yes/No) exportent en-1 / 0, pas1 / 0— gérer la transformation avant l'insert.
Exemple — transformation d'un enregistrement
# Recodage + nettoyage avant import MariaDB
import pandas as pd
df = pd.read_csv('export_access.csv',
sep=';',
encoding='windows-1252',
quotechar='"'
)
# Normaliser les booléens Access (-1/0 → 1/0)
for col in df.select_dtypes(include='object').columns:
df[col] = df[col].replace({'-1': '1', '-1.0': '1'})
# Sauvegarder en UTF-8 pour l'import MariaDB
df.to_csv('clean_export.csv',
sep=';',
encoding='utf-8',
index=False
)État d'avancement — tables migrées
| Table | Enregistrements | Staging | Production |
|---|---|---|---|
| Clients | ~800 | ✔ DONE | ✔ DONE |
| Véhicules | ~120 | ✔ DONE | ✔ DONE |
| Chauffeurs | ~80 | ✔ DONE | ✔ DONE |
| Offres | ~3 500 | ✔ DONE | ✔ DONE |
| Ordres de course | ~8 000 | ✔ DONE | ⟳ EN COURS |
| Décomptes | ~6 000 | ✔ DONE | ⟳ EN COURS |
| Factures | ~4 500 | ✔ DONE | — À FAIRE |
| Contacts / Prestataires | ~2 000 | ✔ DONE | — À FAIRE |
03. Architecture technique
L'application est découpée en trois couches distinctes, hébergées sur l'infrastructure privée du client (NAS Synology + Proxmox).
Base de données — MariaDB DONE
Deux bases (cbus_staging + cbus_app), 15 tables, 3 vues SQL. Hébergée sur conteneur Docker sur NAS Synology. Administration via DBeaver.
API Backend — Node.js + Express WIP
API REST exposant les entités métier (Offres, Ordres, Chauffeurs, Véhicules, Factures). Authentification JWT. Déployée via Docker Compose.
Frontend — React + Vite + Tailwind WIP
Interface web couvrant : dashboard opérationnel, pipeline Kanban des offres, gestion des décomptes, suivi de facturation.
Mise en production & formation À VENIR
Déploiement final sur infra client, documentation utilisateur, formation des opérateurs.
Stack résumée
Infrastructure
- Proxmox VE — hyperviseur
- Docker / Compose — conteneurisation
- Synology NAS — stockage & DB host
- Nginx — reverse proxy
Applicatif
- MariaDB — base de données
- Node.js + Express — API REST
- React + Vite — frontend
- Tailwind CSS — styling
04. Objectif à terme — SaaS multi-entreprises
Au-delà de la migration, l'ambition est de transformer cette application en un produit SaaS générique, déployable pour n'importe quelle petite ou moyenne entreprise de transport par autocar en Suisse.
Le marché cible : les PME de transport qui s'appuient encore sur Excel, Access ou des solutions papier, et qui n'ont pas les moyens d'investir dans un ERP lourd. L'outil couvre l'intégralité du flux métier, de la demande client à la facturation.
Ce projet est en cours de développement et n'est pas encore disponible publiquement. Aucune donnée client réelle n'est exposée dans cette documentation.