La plateforme facturation et comptabilité d'IMS-BCV, livrée en 35 jours

IMS-BCV, enseigne Open-Bar, est le premier réseau national français d'installateurs professionnels indépendants spécialisés en tirage pression (systèmes de distribution de boissons à la pression) et autres équipements d'espace bar — machines à café, froid, matériel de back-bar et mobilier CHR (Café-Hôtellerie-Restauration). Fondé en juin 2015, le réseau fédère des entreprises installatrices indépendantes sous une charte qualité commune. Couverture nationale ; chaque adhérent est une entreprise à part entière, pas une succursale d'un opérateur unique.

Le système que nous avons construit sert le back-office propre d'IMS-BCV — pas un restaurant ni un bar. Les opérations financières couvrent les adhérents du réseau en tant que clients et des fournisseurs d'équipements comme LENNE CRÉATION. Factures, paiements et rapprochements avaient dépassé les outils qui les portaient.

Trois problèmes concrets en découlent.

Le rapprochement était rétrospectif. Les exports bancaires arrivent en CSV français à entrées multi-lignes, délimiteur point-virgule et dates au format jj/MM/aaaa. Quelqu'un devait classer les types de transaction et faire correspondre les libellés de paiement aux références de facture à la main — un travail qui n'avait lieu que lors de la mise à jour d'un tableur, plusieurs jours après qu'un paiement soit entré ou sorti.

Les données de facture étaient ressaisies. Les factures fournisseurs arrivaient en PDF par email et sur disque. Montants, échéances et références étaient tapés dans des feuilles de suivi — lent, et propice aux erreurs de frappe jusqu'à la clôture du mois.

Personne ne possédait le calendrier de relance. Les factures clients en retard n'avaient pas de parcours de relance structuré rattaché au grand livre. Échéances, relances à +20 et +30 jours, et drapeaux de suivi téléphonique vivaient dans les têtes ou des listes séparées — pas dans un système qui se nettoie quand un paiement est enregistré.

Ce n'était pas un échec comptable, mais un écart d'outillage : un réseau fédéré d'installateurs avait dépassé ce que des tableurs et un connecteur ERP générique pouvaient honnêtement relier — exports bancaires, boîtes Outlook, archives SharePoint et le processus réel de relance du réseau.

Le premier réflexe évident, c'est un ERP du marché ou un câblage d'outils SaaS. Pour beaucoup de problèmes finance, c'est la bonne réponse — nous construisons régulièrement sur n8n et Make pour nos clients quand le fit est là. Pour IMS-BCV, ce n'était pas le cas, pour des raisons qui valent autant pour les ERP type Sage que pour Make/Airtable/Zapier.

Parsing CSV bancaire français intégré. Les ERP génériques exigent un mapping manuel ou des connecteurs payants pour les flux bancaires. Les exports d'IMS-BCV utilisent le format CSV français multi-lignes — point-virgule, dates jj/MM/aaaa, motifs comme « DE », « POUR », « VIR RECU » et « FRAIS » qui encodent paiements clients vs fournisseurs. Ce système parse ce format nativement et rapproche automatiquement les paiements aux factures depuis le libellé. Pas d'abonnement connecteur.

Microsoft 365 sans module GED. L'intégration Outlook/SharePoint dans un ERP générique est limitée ou coûteuse. Ici, Microsoft Graph interroge la boîte Outlook du réseau toutes les dix minutes pour les pièces jointes de factures (OAuth2 avec renouvellement automatique des jetons) et classe les documents traités sur SharePoint par année fiscale et mois en français — sans système de gestion documentaire séparé à maintenir.

OCR double moteur en standard. L'OCR en ERP est en général un module payant en option. Ici, Mindee API v2 est le moteur principal, avec un repli OpenAI pour les mises en page que Mindee gère mal — découpage et fusion de PDF multi-pages sur les deux chemins.

Relances calées sur le processus du réseau. Les outils génériques proposent des règles de relance configurables mais rigides. Ici, des contrôles planifiés toutes les douze heures : échéance, +20 jours, +30 jours, puis drapeau de suivi téléphonique — avec effacement automatique dès qu'une facture est marquée payée.

Coût et maîtrise. Licence ERP par utilisateur vs développement ponctuel sur une infrastructure que le réseau contrôle déjà. Les données financières restent sur un serveur privé dans l'hébergement choisi — pas sur la politique de rétention d'un SaaS tiers.

Backend : NestJS 11, TypeScript 5.7, Fastify 5 (via @nestjs/platform-fastify, avec support upload multipart 50 Mo pour les PDF de factures). Base de données : MySQL via TypeORM 0.3, schéma géré en externe (synchronize: false). Auth : JWT avec bcrypt et AuthMiddleware custom. Recherche : Meilisearch avec index séparés par entité. Déploiement : PM2 en mode cluster (trois instances), production liée à 127.0.0.1. Une application frontend séparée consomme l'API REST du backend.

Les données vivent sur un serveur privé, pour que les enregistrements financiers restent sous le contrôle du client. Même famille de développement d'applications web sur mesure que nous livrons quand les opérations dépassent plugins et tableurs.

La conception est délibérément modulaire : ingestion CSV bancaire, OCR factures, sync Microsoft 365, relances, exports et recherche sont des préoccupations séparées reliées par des interfaces définies. L'accès est limité par rôle au niveau module ; la logique de relance est rattachée à l'état des factures plutôt qu'à un produit d'alerting séparé.

Périmètre fixe, prix fixe, paiements échelonnés. La formation faisait partie du build plutôt qu'un après-coup — un outil interne que personne n'a jamais pris en main, c'est un tableur avec des étapes en plus. La passation comprenait la configuration des rôles, des relances et un court runbook pour les deux chemins d'exception les plus fréquents (ligne bancaire non rapprochée et écart de facture fournisseur).

Cette section repose sur un retour client qualitatif, pas sur un tableau de métriques. IMS-BCV a confirmé des résultats en usage courant plutôt que des chiffres avant/après audités. Contrairement à d’autres études de cas de ce site où des données dures sont publiables — l’engagement ROAS Meca Express, par exemple — il n’existe ici ni volume d’heures, ni pourcentages, ni effectifs utilisateurs, et nous n’en inventerons pas.

Trois points ressortent clairement de leurs retours. L’import et le rapprochement du grand livre fonctionnent exactement comme ils le souhaitaient — les fiches clients se recoupent avec les données bancaires et de facturation comme leur back-office l’attendait. Le workflow de relance automatique repère de façon fiable chaque adhérent qui n’a pas réglé à l’échéance, avec l’escalade prévue dans le parcours de relance intégré à la plateforme ; ils le décrivent comme parfaitement opérationnel. Globalement, le réseau a gagné du temps et les opérations finance sont structurées là où elles étaient auparavant éclatées entre tableurs, exports manuels et relances au cas par cas.

Ce retour est en régime de croisière — usage continu depuis la mise en production, sans fenêtre de mesure figée. Aucune citation client n’est publiée sur cette page.

Modules séparables : la plateforme grandit sans reconstruction. Gestion fournisseurs et partenaires, processus métier additionnels, reporting KPI, intégrations CRM ou facturation, gestion de contrats — chaque brique s'ajoute au code existant plutôt qu'à un nouvel outil et un nouveau silo. Le réseau peut prioriser par douleur opérationnelle, pas par la roadmap d'un éditeur ERP.