$ ▋
ERP de gestion pour restaurant multi-sites
« Le système nerveux digital d'une enseigne de fast-food. Un back-office unique qui réunit caisse, stocks, paie/RH, planning et pointage sur 3 établissements. Conçu et développé seul, en alternance. »
Où j'en suis, en ce moment.
Industrialisation & déploiement en production
Mise en ligne de la v1 sur mon serveur (nom de domaine acquis) + mise en place du CI/CD
« v1 en juin 2026 »
Cette page est mise à jour à chaque sprint. Si elle date, je code probablement plutôt que je documente — les deux ne sont pas faciles à faire en même temps.
Mon Krousty est l'ERP que j'ai conçu et développé seul pour piloter une enseigne de restauration rapide sur 3 établissements. Un back-office unique qui relie la caisse, les stocks, la paie/RH, le planning et le pointage des employés — là où on trouve habituellement 4 ou 5 outils qui ne se parlent pas. L'objectif : donner au gérant une vision claire et chiffrée de son activité, et rendre visibles les pertes invisibles en cuisine.
Un fast-food multi-sites pilote sa marge à l'aveugle, avec des outils éclatés qui ne communiquent pas.
- On ne sait pas où partent les marges : vol, gaspillage et erreurs de portions restent invisibles.
- Le coût réel d'un plat est incalculable à la main — le prix des ingrédients change à chaque livraison.
- Caisse, stocks, plannings et paie vivent dans des logiciels séparés qui ne se synchronisent pas.
- Le suivi des heures et des données RH (contrats, RIB) se fait manuellement, sans traçabilité.
La stack, et pourquoi.
Cliquez sur une carte pour voir le pourquoi du choix.
La démarche, en checkpoints.
Cliquez sur une étape pour ouvrir ce qui s'y est passé.
Ce qui me freine, en ce moment.
Pas de honte à les afficher — c'est ce qui rend un projet en cours, en cours.
Déploiement en production
Serveur monté et nom de domaine acquis. Reste à conteneuriser proprement et mettre la v1 en ligne (Docker + reverse proxy / Cloudflare Tunnel).
Secrets commités dans le repo
Un .env et la clé de chiffrement des données RH sont présents dans l'historique git. À régénérer et retirer de l'historique avant toute ouverture du code.
Pas de pipeline CI/CD
Le déploiement est encore manuel. À automatiser : build, tests et mise en ligne déclenchés à chaque push.
Couverture de tests partielle
La logique critique (coût FIFO/WAC, chiffrement RH, pointage) n'est pas encore couverte par des tests automatisés.
Cloisonnement multi-site à durcir
Trois endpoints à filtrer explicitement par établissement (risque limité tant qu'un manager est lié à un seul site).