Dolibarr est moche. Et c'est exactement pour ça qu'on le met sous une app UX.

"On prend pas ça, c'est trop moche." Le préjugé Dolibarr.

Je l'entends dans presque toutes les missions. On parle ERP, on parle structuration de la gestion, on explore les options — et à un moment quelqu'un ouvre Dolibarr sur un navigateur. Et là, la réaction est immédiate, physique même : les épaules qui tombent, la grimace. "Non mais ça, c'est pas possible. On peut pas mettre ça entre les mains de nos équipes."

La réaction est légitime. Dolibarr n'est pas beau. L'interface principale n'a pas été pensée par une équipe de designers produit avec six semaines de tests utilisateurs et trois rounds de retours UX. Elle a été pensée par des développeurs qui voulaient couvrir des cas métier réels, et qui y sont parvenus — solidement, durablement. Mais visuellement, on est loin des standards 2026.

Le problème, c'est que ce préjugé emmène les équipes vers une mauvaise question. La question qu'on se pose après "c'est moche" c'est "alors on prend quoi à la place ?" Et là on part chercher un SaaS tout-en-un propre, moderne, avec une bonne UI — Pennylane, Axonaut, Whatever-la-nouvelle-pépite-du-moment. Et on se retrouve piégé dans quelque chose que je connais bien après vingt-cinq ans de terrain.

Le vrai préjugé

Le préjugé Dolibarr n'est pas "c'est moche". C'est "moche = inutilisable". C'est cette équation-là qui est fausse. Et c'est elle qui coûte cher aux structures qui la croient.

Le vrai problème, c'est l'UX au quotidien des équipes — pas l'UI de l'ERP.

Il faut séparer deux choses qui sont souvent confondues dans ce genre de conversation : l'interface de l'outil de gestion, et l'expérience quotidienne des équipes dans leur travail.

L'interface de l'ERP — les menus, les formulaires, les listes de données — c'est ce que voit le comptable, la personne qui fait la facturation, celle qui gère les congés et les notes de frais. Dans une PME bien structurée, c'est un ou deux profils qui vivent dans ces écrans à temps partiel. Pas toute l'équipe. Pas le commercial qui fait des devis. Pas le chef de projet qui suit l'avancement. Pas la personne qui accueille les clients. Eux, ils ont besoin d'autre chose.

Ce dont ils ont besoin, c'est une interface pensée pour leur usage réel, avec leur vocabulaire, leurs raccourcis, leur flux de travail. Pas un formulaire générique avec douze champs dont la moitié ne s'applique pas à leur cas. Pas une page de liste avec des colonnes dans le mauvais ordre. Pas une navigation pensée pour un administrateur système.

C'est là que la distinction devient utile : ce n'est pas parce que l'ERP est moche que l'expérience des équipes doit l'être. Ce sont deux couches différentes. Et elles peuvent — doivent — être traitées séparément.

L'architecture qui tient : socle légal en bas, app UX au-dessus.

Voilà ce qu'on met en place chez ComiPi, structurellement, dans les missions où la gestion est en jeu.

En bas : Dolibarr. Il porte tout ce qui relève des obligations légales — la comptabilité, la facturation aux normes, les contrats, la gestion RH, les règles TVA, les journaux comptables. C'est la fondation. Elle est solide, auditable, auto-hébergeable, et documentée par une communauté active depuis vingt ans. Si un expert-comptable ou un contrôleur fiscal arrive demain, il sait lire Dolibarr. Ce n'est pas rien.

Au-dessus : le SaaS ERP ComiPi, développé sur mesure pour les équipes. C'est ce SaaS qui porte l'UX et l'UI — formulaires, dashboards, écrans métier, parcours utilisateur. En Next.js, en React, avec un backend qui consomme Dolibarr via son API REST. L'utilisateur saisit dans le SaaS, l'information est persistée dans Dolibarr en arrière-plan. Devis, contacts, interventions, factures — tout passe par une interface conçue pour la façon dont les équipes travaillent vraiment. Pas pour un cas générique.

En coulisses, N8N orchestre. N8N n'est pas une interface utilisateur — l'utilisateur final ne le voit jamais, il ne clique jamais dedans. C'est un moteur de workflows back-office, déclenché par les événements qui partent du SaaS ou de Dolibarr : une relance client qui part toute seule trois jours après une livraison, un bon de commande qui se génère automatiquement depuis une validation dans l'app, une alerte qui arrive dans Mattermost quand un devis reste sans réponse depuis sept jours, une notification Nextcloud quand un dossier est complet. La plomberie invisible qui fait que les gens ne ressaisissent pas les mêmes données trois fois.

Pourquoi pas un SaaS tout-en-un propriétaire ?

La question revient tout le temps — et elle est légitime. Les SaaS tout-en-un modernes ont de belles interfaces, un bon onboarding, un support réactif. Mais ils ont trois problèmes que je vois se matérialiser régulièrement sur le terrain.

Premier problème : le lock-in. Dans trois ans, l'éditeur lève ses prix, change son modèle, se fait racheter, ou simplement arrête le service. L'entreprise n'a nulle part où aller, ou part avec des données dans un format propriétaire qu'il faut faire parser par quelqu'un.

Deuxième problème : l'interface est standard, pas la vôtre. L'éditeur a conçu l'UX pour un persona type — souvent une startup en croissance rapide ou une PME américaine. Si vos usages s'écartent de ce persona, vous vous adaptez à l'outil. C'est l'inverse de ce qu'on cherche.

Troisième problème : la data n'est pas chez vous. Elle est dans un datacenter que vous ne connaissez pas, sous une politique de confidentialité qui peut changer, accessible à des équipes tierces dans des conditions que vous ne contrôlez pas. En 2026, ça devrait être un point de départ de la conversation — pas une note de bas de page dans les CGU.

Ce que ComiPi fait concrètement dans ce type de mission.

La méthode est en quatre étapes, dans cet ordre — et l'ordre compte.

Étape 1 — Écouter. Pas "récolter des besoins" au sens froid du terme. Vraiment comprendre comment les équipes travaillent aujourd'hui, ce qui frotte, ce qui prend du temps, ce qui est fait deux fois, ce qui est oublié. Je passe du temps avec les personnes qui font le travail — pas uniquement avec la direction. La façon dont une assistante administrative gère les relances ou une commerciale renseigne un nouveau contact en dit souvent beaucoup plus que le diagnostic macro.

Étape 2 — Concevoir. À partir de ce qu'on a écouté : quels modules Dolibarr sont pertinents pour ce cas précis, quels écrans métier construire dans ComiPi ERP, quels workflows back-office coder pour faire disparaître les frictions les plus douloureuses. On ne conçoit pas pour une perfection théorique — on conçoit pour ce qui va fonctionner avec les contraintes réelles de la structure (temps, budget, maturité tech des équipes).

Étape 3 — Intégrer progressivement. Pas de grand déploiement en une nuit. On met en production par petits blocs, en validant avec les équipes à chaque étape. Si quelque chose ne marche pas comme prévu, on le voit tôt et on corrige tôt. Les systèmes qui démarrent en big bang finissent souvent dans les tiroirs.

Étape 4 — Transmettre. L'objectif à la fin d'une mission n'est pas que ComiPi soit indispensable en maintenance. C'est que la structure comprenne ce qu'elle a mis en place, pourquoi, et soit capable de le faire évoluer sans moi dans deux ou trois ans. La documentation et la formation ne sont pas des livrables optionnels — elles sont l'essentiel.

Ce qui change pour les équipes.

Le premier changement est souvent celui qu'on n'attendait pas : les équipes arrêtent de faire semblant d'utiliser l'ERP. Dans beaucoup de structures où Dolibarr avait été installé "comme ça" sans couche applicative au-dessus, j'arrive et je trouve des données à moitié saisies, des champs vides parce que "personne sait à quoi ça sert", des relances qui se font encore par email manuel parce que "le module de relance c'est trop compliqué". L'ERP est là, il coûte rien à maintenir, mais personne ne s'en sert vraiment.

Une fois que l'app métier est en place — avec l'interface adaptée aux vraies journées des équipes — quelque chose se débloque. Les données commencent à entrer correctement, parce que le formulaire est simple et fait sens. Les automatisations se déclenchent, parce que les données sont là. La comptabilité devient une conséquence automatique du travail commercial, pas un travail administratif supplémentaire.

« Avant, je ressaisissais le bon de commande dans le tableau Excel, puis dans Dolibarr, puis dans l'email au client. Là, c'est fait une fois. Je peux pas croire que c'était comme ça depuis cinq ans. » — [VERBATIM PLAUSIBLE À VALIDER] Stéphanie, assistante administrative, structure cliente anonymisée

Sur le plan économique, l'arbitrage se voit à l'année. Un abonnement SaaS ERP complet pour une PME de dix personnes tourne souvent entre 150 et 400 euros par mois [CHIFFRE INDICATIF — À VALIDER SELON CONTEXTE CLIENT]. Dolibarr auto-hébergé sur un VPS dédié, c'est moins de 20 euros par mois. La différence finance largement le développement de l'app sur mesure en deux à trois ans. Et après : indépendance totale. Pas d'augmentation tarifaire annuelle. Pas de migration forcée. Pas de fonctionnalité qui disparaît d'une version à l'autre parce que l'éditeur a décidé de revoir sa roadmap.

« On avait peur que ce soit fragile, que si Filipe n'était plus là on soit coincés. En fait c'est l'inverse — maintenant on est propriétaires de notre setup. » — [VERBATIM PLAUSIBLE À VALIDER] David, dirigeant PME, région Centre-Val de Loire

Le filet de sécurité juridique qu'on n'a pas à retisser.

Il y a un point que j'insiste à mettre sur la table dès le début d'une mission, et qui convainc souvent ceux que l'architecture en deux couches laissait sceptiques.

Quand l'app métier change — parce que les usages évoluent, parce qu'on veut refaire l'interface, parce qu'un développeur propose quelque chose de mieux — Dolibarr reste intact en dessous. Toute la mémoire comptable, tous les documents légaux, tous les journaux fiscaux, tout l'historique des contrats : rien de tout ça ne bouge quand on retouche la couche applicative. C'est la séparation des préoccupations en architecture logicielle — un principe ancien, solide, et particulièrement utile ici.

Concrètement : si dans trois ans la structure veut changer d'interface complètement — adopter un nouveau framework, confier ça à un autre développeur, réécrire l'app avec des contraintes différentes — elle le fait sans toucher à sa comptabilité. Les données légales sont dans Dolibarr, dans un format standard, accessible via une API documentée. La base légale est inattaquable. Seule l'interface change.

C'est l'inverse d'un SaaS propriétaire, où les données légales et l'interface sont dans le même silo. Si vous voulez partir, vous partez avec quoi ? Un export CSV que votre nouvel outil devra réinterpréter. Avec toutes les erreurs de migration que ça implique.

Pourquoi cette architecture tient dans le temps.

Je travaille avec cette logique depuis que j'ai commencé à structurer sérieusement des missions chez ComiPi. Ce qui me convainc de sa robustesse, c'est qu'elle tient à des principes qui ne datent pas d'hier.

La séparation entre socle de données structurelles et interface applicative, c'est exactement ce qu'on fait depuis des décennies dans les architectures logicielles qui durent. Une base de données bien conçue doit survivre aux interfaces qui la lisent. Les interfaces changent — les usages évoluent, les standards visuels bougent, les équipes ont de nouveaux besoins. La donnée, elle, doit rester stable, cohérente, accessible.

Ce que cette architecture apporte de spécifique en 2026, c'est qu'elle rend les petites structures aussi agiles que les grandes sur ce point — sans le budget des grandes. Dolibarr est gratuit. Next.js, Node, PostgreSQL, Redis, Docker — tout est open source. L'investissement est dans la conception et l'intégration — pas dans des licences récurrentes qui augmentent chaque année.

« Ce qui m'a décidé c'est simple : dans cinq ans, si j'en ai besoin, je peux faire évoluer l'interface sans tout recommencer depuis zéro. Avec le SaaS qu'on avait avant, c'était pas possible. » — [VERBATIM PLAUSIBLE À VALIDER] Marc, fondateur, TPE services aux entreprises

Et il y a quelque chose de plus profond que la technique. Cette approche force une conversation utile dès le départ : qu'est-ce qui doit être stable dans le temps (les obligations légales, la mémoire comptable, la structure des données) et qu'est-ce qui doit pouvoir changer (l'interface, les flux de travail, les automatisations) ? Cette conversation-là, dans une petite structure, on la fait rarement. On installe un outil et on s'adapte à lui. Ici, on commence par répondre à cette question — et l'architecture suit.

C'est ce que j'ai mis en pratique chez Blanc sur Noir, où Fabienne gère maintenant son cycle de vente entier depuis une interface qui lui ressemble, avec Dolibarr qui fait la comptabilité en silence. Et c'est ce qu'on a structuré chez EVEIA, où les réponses aux appels d'offres s'enchaînent sans ressaisie d'une étape à l'autre. Dans les deux cas : zéro lock-in éditeur, données maîtrisées, architecture qui leur appartient.

Dolibarr reste moche. C'est prévu. Ce n'est pas son rôle d'être beau. Son rôle, c'est d'être là dans dix ans, avec toutes les données comptables intactes, pendant que l'app au-dessus aura évolué trois fois. C'est exactement ce qu'on lui demande.

Parlons architecture.

ERP qui coûte cher et que personne n'utilise vraiment, SaaS qui monte ses tarifs, données chez un éditeur que vous ne contrôlez pas — on peut regarder ça ensemble, sans engagement.

La suite de la série méthode

Cyber, open source, IA, N8N.

Les prochains articles vont sur la cyber comme point de départ architectural, l'open source en 2026, l'IA comme collègue agentique, et un tuto pour installer N8N en local sur son PC (l'auto-empowerment).