À propos du projet
Un ERP couvrant finance, vente, achat, stock et structure, bâti sur les règles avec lesquelles la distribution tunisienne travaille réellement. Déployé d'abord pour remplacer une installation Sage devenue trop étroite, sans interrompre l'activité.
Mon rôle: Analyste fonctionnel et développeur full stack. J'ai rédigé le cahier des charges de chaque module avant de le construire, puis mené la migration depuis l'ancien système.
J'ai construit cet ERP pour remplacer une installation Sage devenue trop étroite chez un distributeur tunisien d'électronique. L'entreprise fait à la fois de la distribution, du détail et de l'installation, et chaque contournement de l'ancien système, tableurs pour l'encours client, rapprochement bancaire manuel, stock compté à part, était devenu un coût quotidien. J'ai rédigé le cahier des charges de chaque module avant de le construire, ce qui explique que le système implémente les règles avec lesquelles le métier travaille vraiment plutôt que celles qu'un progiciel générique présuppose.
Le système couvre cinq domaines fonctionnels. La finance gère factures, encaissements et décaissements, lettrage, chèques et traites, retenue à la source, notes de frais, rapprochement bancaire et blocage de crédit. La vente déroule toute la chaîne devis, commande, bon de livraison, facture, avec avoirs, règles de tarification et pipeline CRM. L'achat ajoute le rapprochement à trois voies entre commande, réception et facture fournisseur. Le stock porte plusieurs entrepôts, le suivi des lots et péremptions, la valorisation CMUP et FIFO, les réservations et les nomenclatures.
Ces règles appartiennent à la distribution tunisienne, pas à une entreprise en particulier : retenue à la source, lettrage, rapprochement à trois voies et double valorisation du stock sont les mêmes partout où le secteur opère, et c'est ce qui rend le socle digne d'être redéployé plutôt que réécrit. La stack repose sur React et TypeScript avec Vite, une API Firebase Functions et PostgreSQL sur Cloud SQL. J'ai soigné la bascule autant que les fonctionnalités : une analyse d'écart avec l'ancien système, un plan de migration et un runbook de bascule permettent de quitter Sage sans perdre son historique. L'ERP ingère aussi les commandes d'une boutique en ligne, si bien que le site et le back office partagent un seul stock et une seule fiche client.
Fonctionnalités principales
- 💰 Module finance : Factures, encaissements, décaissements, lettrage, chèques et traites, retenue à la source et rapprochement bancaire dans un seul journal.
- 🧾 Chaîne devis vers facture : Devis, commande, bon de livraison et facture s'enchaînent, avoirs et retours compris de bout en bout.
- 🔍 Achat avec rapprochement à trois voies : Commande, réception et facture fournisseur sont rapprochées avant tout paiement.
- 📦 Double valorisation du stock : CMUP et FIFO coexistent, avec suivi des lots, dates de péremption, réservations et transferts multi entrepôts.
- 🏗️ Nomenclatures : Les produits assemblés consomment leurs composants, si bien que les kits d'installation restent justes face au stock réel.
- 🚦 Contrôle de crédit automatique : Les plafonds clients bloquent les commandes d'eux mêmes, remplaçant le tableur qu'une équipe tient sinon à la main.
- 🔁 Kit de migration Sage : Une analyse d'écart, un plan de migration et un runbook de bascule permettent de quitter l'ancien système sans perdre l'historique.
- 🌐 Ingestion des commandes web : Les commandes passées sur une boutique en ligne arrivent directement dans l'ERP, avec un stock et une fiche client uniques.
- 🔐 Matrice de statuts et permissions : Chaque module définit qui peut valider, modifier ou seulement consulter chaque type de document.
- 🚦 État actuel : Un distributeur l'exploite en production. Le socle fonctionnel relève du secteur et non d'une entreprise, si bien qu'un second déploiement est un travail de cadrage sur le plan comptable et les règles de tarification, pas une reconstruction.
Problèmes et solutions
Problème: Un distributeur qui tourne sur une installation Sage vieillissante finit entouré de tableurs. Encours client, rapprochement bancaire et inventaires vivent hors du système, si bien que le même chiffre existe à trois endroits sans jamais concorder.
Solution: J'ai rédigé le cahier des charges de chaque module avant d'écrire la moindre ligne, puis bâti l'ERP autour des vraies règles de gestion. Plafonds de crédit, lettrage et valorisation se font désormais dans le système, et un runbook de bascule documenté fait quitter Sage sans perte d'historique.
Problème: Les progiciels ERP génériques sont bâtis sur des règles qui ne correspondent pas à la distribution tunisienne, si bien que retenue à la source, lettrage et double valorisation sont rajoutés localement jusqu'à ce que les rajouts deviennent le vrai système. Et repartir sur du sur mesure, c'est ainsi que chaque distributeur finit par payer deux fois les mêmes modules.
Solution: Les modules encodent les règles du secteur plutôt que les habitudes d'une entreprise, ce qui permet au même socle de servir un autre distributeur. Ce qui reste propre à chaque déploiement, c'est le plan comptable, les règles de tarification et les données de l'ancien système, et cela se cadre par projet au lieu de se réécrire.
