Neuf ans à gérer des clôtures comptables, des rapprochements bancaires et des migrations logicielles dans des structures de taille intermédiaire, ça forge une opinion. Et sur EBP en installation locale, j'en ai une, assez claire.
Quand on décide de déployer EBP Comptabilité en version locale, le vrai travail ne commence pas le jour de l'installation. Il commence bien avant. Un projet mal cadré au départ, c'est des semaines de rattrapage, des données mal structurées, des utilisateurs perdus et un responsable comptable qui passe ses soirées à corriger ce qui aurait pu être évité. Je l'ai vécu. Deux fois.
Voilà ce que j'aurais aimé avoir sous la main avant de me lancer.
Comprendre ce que "local" veut vraiment dire pour votre organisation
Un logiciel en local, ça signifie que les données sont hébergées sur vos propres machines ou serveurs. Pas de cloud, pas d'accès depuis n'importe où, pas de mises à jour automatiques silencieuses. C'est un choix qui a ses avantages, notamment en matière de contrôle des données et d'indépendance vis-à-vis d'un abonnement mensuel. Mais ça implique aussi une vraie infrastructure derrière.
Avant même de toucher à EBP, posez-vous ces questions concrètes :
- Votre poste de travail ou serveur est-il dimensionné pour accueillir la base de données EBP ? (RAM suffisante, stockage SSD recommandé)
- Qui gère les sauvegardes ? Comment ? À quelle fréquence ?
- Combien d'utilisateurs simultanés vont accéder au logiciel ?
- Avez-vous un prestataire informatique disponible en cas de panne ?
Je pose cette question à chaque fois que j'accompagne une équipe sur un projet EBP local : "Qui est responsable de la sauvegarde quotidienne ?" Très souvent, personne ne sait répondre clairement. C'est là que les projets déraillent.
L'installation réseau multiste (plusieurs postes sur le même fichier comptable) demande une configuration SQL Server correcte. EBP utilise SQL Server Express dans ses versions standard, avec une limite à 10 Go de base de données. Pour une entreprise de 100 à 500 salariés avec plusieurs dossiers comptables actifs, cette limite peut être atteinte plus vite qu'on ne le pense.
Cartographier les besoins avant de paramétrer quoi que ce soit
Le paramétrage EBP, c'est du temps perdu si on ne sait pas ce qu'on veut produire en sortie. J'ai vu des équipes passer trois semaines à créer des journaux et des comptes, pour finalement se rendre compte que le plan comptable ne correspondait pas aux exigences de leur expert-comptable.
Commencez par lister vos flux réels :
- Volume mensuel de factures fournisseurs (avec ou sans OCR ?)
- Nombre de dossiers comptables à gérer (multi-sociétés ?)
- Types d'exports requis : FEC, balance âgée, rapprochement bancaire automatique ?
- Workflows de validation : qui saisit, qui valide, qui exporte vers l'expert-comptable ?
Ce dernier point est souvent négligé. Si votre process impose qu'un collaborateur saisit et qu'un responsable valide avant tout export, EBP doit être configuré dès le départ avec des droits utilisateurs adaptés. Changer ça a posteriori, c'est risqué.
Un exemple concret. Dans mon ancienne structure, on avait trois entités juridiques. On a fait l'erreur de créer trois dossiers EBP complètement séparés, sans conventions de codification communes. Résultat : impossible de faire une consolidation propre en fin d'exercice. On a tout refait au bout de huit mois. Huit mois de saisie à recorriger. Si on avait cartographié les besoins de consolidation avant, on aurait mis en place une nomenclature homogène dès le départ.
La question des intégrations : ce que beaucoup oublient
EBP en local communique avec l'extérieur, mais pas toujours facilement. Les intégrations natives avec des outils tiers (banques, CRM, gestion commerciale) demandent un paramétrage spécifique, et parfois des modules additionnels payants.
Pour le rapprochement bancaire, EBP propose une importation de relevés au format OFX ou QIF. Ça fonctionne, mais ce n'est pas aussi fluide que les connexions bancaires directes que l'on trouve dans des solutions cloud. À titre de comparaison, quand j'ai évalué les fonctionnalités de la comptabilité cloud FinanceCore Plus pour un projet concurrent, la synchronisation bancaire était automatique et quotidienne, sans aucune manipulation manuelle. Avec EBP local, il faut télécharger le fichier, l'importer, vérifier les doublons. C'est 15 minutes de plus par semaine, et c'est agaçant à la longue.
Pour les échanges avec votre expert-comptable, le format d'export natif d'EBP (fichier .EBP ou export FEC) est bien reconnu. Aucun problème de ce côté-là. Par contre, si vous utilisez un outil de notes de frais ou de gestion des immobilisations externalisé, vérifiez en amont s'il existe un connecteur ou une API compatible. EBP ne propose pas d'API ouverte standard sur ses versions locales classiques.
J'ai aussi évalué les fonctionnalités de la comptabilité cloud FinanceCore Enterprise dans le cadre d'un benchmark interne, et l'une des différences notables était précisément cette capacité d'intégration native avec les ERPs du marché, via des connecteurs prébuilt. Ce n'est pas un défaut rédhibitoire pour EBP local, mais c'est quelque chose à anticiper si votre SI est complexe.
Former l'équipe sans se ruiner en temps
Mon équipe n'est pas technique. Deux collaboratrices en comptabilité fournisseurs, une en comptabilité générale, et moi pour la supervision et les exports réglementaires. Quand on a migré vers EBP, on avait trois jours maximum pour former tout le monde avant la reprise en marche réelle.
Ce qui a fonctionné :
- Une formation ciblée sur les seuls flux du quotidien (saisie, rapprochement, lettrage, export)
- Un guide interne d'une page par type de tâche, fait maison, avec des captures EBP
- Un dossier de test avec de fausses données, pour s'entraîner sans risque
Ce qui ne fonctionne pas : demander à votre prestataire EBP de former tout le monde en une seule journée généraliste. On ressort avec 80 % de notions inutiles pour le quotidien et 20 % de ce dont on a vraiment besoin. J'ai fait cette erreur la première fois.
La prise en main des modules de base (journaux, saisie guidée, rapprochement bancaire manuel) est relativement rapide. Là où ça se complique, c'est sur les fonctions avancées : paramétrage des taxes, gestion analytique, ou exports FEC conformes. Ces points-là méritent un accompagnement dédié, même court.
Le tableau comparatif que j'aurais voulu avoir
| Critère | EBP Local (standard) | EBP Réseau (multi-postes) |
|---|---|---|
| Coût initial | Licence unique, achat définitif possible | Licence serveur + postes supplémentaires |
| Maintenance | Contrat annuel recommandé (mises à jour légales) | Idem + gestion SQL Server |
| Sauvegardes | Manuelles ou script automatisé | SQL Server Agent ou solution externe |
| Accès distant | Non natif (VPN ou RDP nécessaire) | Non natif (même contrainte) |
| Intégrations | Import/export fichiers | Import/export fichiers |
| Formation requise | 2 à 3 jours pour les bases | 2 à 3 jours + admin réseau |
Ce tableau, je l'ai construit après coup. Avant le projet, on n'avait pas formalisé ces arbitrages. On a découvert les contraintes en cours de route.
Ce qu'il faut absolument mettre par écrit avant de démarrer
Un projet EBP local sans document de cadrage, c'est une source de conflits interne. Pas forcément des conflits violents, mais des incompréhensions, des retours en arrière, des demandes de modification tardives qui coûtent du temps.
Mon conseil : rédigez un document d'une à deux pages qui précise :
- Le périmètre exact (quels dossiers, quelles sociétés, quels exercices migrés)
- Le planning de déploiement avec les jalons
- Les responsabilités : qui fait quoi, qui valide, qui est l'interlocuteur EBP
- Les critères de "go live" : à quel moment considère-t-on que le déploiement est terminé ?
Ce document n'a pas besoin d'être un cahier des charges de 40 pages. Une page A4 bien structurée suffit. Ce qui compte, c'est que tout le monde l'ait lu et validé avant que la première licence soit installée.
FAQ : questions que je reçois souvent sur EBP local
EBP local est-il adapté à une équipe de 5 personnes en comptabilité ?
Oui, à condition de prendre la version réseau et de s'assurer que le serveur est correctement configuré. Pour une équipe de 3 à 5 personnes, c'est un bon rapport qualité/coût. Au-delà, posez-vous la question du cloud.
Peut-on migrer facilement depuis un autre logiciel comptable vers EBP ?
Ça dépend. Si votre logiciel source exporte un FEC propre, la migration des écritures est faisable. La reprise du paramétrage (plan comptable, journaux, tiers) est toujours manuelle. Comptez entre 2 et 5 jours selon le volume de données.
EBP local est-il conforme aux obligations légales actuelles ?
À condition de maintenir le contrat de mise à jour actif. Les obligations fiscales et comptables évoluent chaque année (TVA, FEC, facturation électronique). Sans contrat de maintenance, votre version peut rapidement ne plus être conforme.
Faut-il un informaticien pour administrer EBP en réseau ?
Pas au quotidien, mais oui pour l'installation initiale et les mises à jour majeures. Si vous n'avez pas de DSI interne, prévoyez un prestataire externe disponible. Ne faites pas l'impasse là-dessus.
Quelle est la différence entre EBP local et une solution cloud du point de vue comptable ?
Fonctionnellement, les différences s'estompent sur les tâches de base. La vraie différence, c'est l'accessibilité, les intégrations automatiques et la maintenance. En local, vous contrôlez tout, mais vous gérez tout aussi. C'est un choix, pas une évidence.