Développement de modules
Dolibarr sur-mesure
Là où Dolibarr s'arrête, votre métier continue.
Modèles de documents, objets métier, automatisations, connecteurs : je développe en PHP les fonctionnalités que Dolibarr ne couvre pas nativement — en respectant son architecture, pour que vos mises à jour continuent de passer.
Un module sur-mesure est rarement la première réponse
Ça peut sembler étrange de commencer par là sur une page qui vend du développement. Mais un module inutile, c'est du code à maintenir pour toujours, et c'est votre argent. Trois questions passent avant.
Est-ce qu'un simple réglage suffit ?
Dolibarr arrive avec énormément d'options désactivées par défaut, et une bonne partie des demandes que je reçois se règlent en cochant la bonne case. Les champs complémentaires — les extrafields — permettent par exemple d'ajouter vos propres informations sur un client, un produit ou une commande sans écrire une ligne de code. Beaucoup de « il faudrait développer » s'arrêtent là, et c'est très bien ainsi.
Est-ce qu'un module existant le fait déjà ?
L'écosystème Dolibarr est vaste, et une partie des modules y sont gratuits. Si un module publié couvre 90 % du besoin, l'installer et l'ajuster coûte toujours moins cher que repartir de zéro — et il continuera d'être maintenu par son auteur. Je regarde systématiquement, y compris quand ça me retire du travail.
Est-ce que c'est le logiciel ou le processus ?
Il arrive qu'on me demande de reproduire dans Dolibarr une manipulation héritée d'un ancien outil, que plus personne ne sait justifier. Développer un module pour figer une habitude discutable, c'est payer pour conserver un problème. On regarde d'abord à quoi sert vraiment l'étape ; parfois la réponse est qu'elle ne sert plus.
Ce tri fait partie de l'intégration Dolibarr et n'est pas facturé comme du développement. Ce n'est qu'une fois ces trois questions écartées qu'un module se justifie.
Les cinq familles de développements Dolibarr
Presque toutes les demandes que je reçois entrent dans l'une de ces catégories. Elles n'ont ni la même complexité ni le même coût.
1. Les documents à votre image
Les modèles de devis et de factures livrés avec Dolibarr sont fonctionnels mais génériques. Un modèle PDF développé sur-mesure reprend votre identité visuelle, affiche exactement les mentions dont votre secteur a besoin, et peut inclure des informations que le modèle standard ignore : numéro de chantier, référence de commande client, échéancier détaillé, conditions particulières. Vos documents commerciaux sont ce que vos clients voient de vous : c'est rarement l'endroit où économiser. C'est aussi la famille sur laquelle on me sollicite le plus, et celle que je maîtrise le mieux.
2. Les objets métier qui n'existent pas dans Dolibarr
Dolibarr connaît les clients, les devis, les factures, les produits. Il ne connaît pas vos contrats d'entretien, vos parcelles, vos machines en location, vos dossiers de sinistre ou vos sessions de formation. Créer un objet métier, c'est lui apprendre un nouveau type de fiche : avec sa liste, ses filtres, ses droits d'accès, ses documents joints et son lien vers les clients existants. C'est le développement le plus structurant, et celui qui transforme vraiment l'ERP en outil de votre métier.
3. Les automatisations qui tournent sans vous
Relancer les factures impayées à échéance, générer les factures récurrentes du mois, alerter quand un stock passe sous un seuil, produire un rapport hebdomadaire et l'envoyer par mail. Ces tâches planifiées s'exécutent toutes seules, la nuit, sans que personne y pense. C'est souvent le développement le plus rentable : quelques heures de code contre plusieurs heures récupérées chaque mois, indéfiniment.
4. Les connecteurs vers vos autres outils
Faire descendre les commandes de votre boutique en ligne dans Dolibarr, remonter le catalogue et les stocks dans l'autre sens, transmettre les écritures au cabinet comptable, envoyer les expéditions au transporteur, rapprocher les paiements encaissés. Chaque fois qu'une donnée est saisie deux fois par un humain, il y a un connecteur à écrire — et une source d'erreurs à supprimer. C'est le lien naturel entre votre ERP et votre site web.
5. Les ajustements de comportement
Interdire la validation d'une commande sans bon de commande client, imposer une marge minimale sur un devis, pré-remplir un champ selon le client, bloquer une suppression une fois la facture partie. Ces règles se greffent sur les événements déjà émis par Dolibarr, sans toucher à son code. C'est peu spectaculaire et souvent très rentable : le logiciel finit par empêcher les erreurs au lieu de les enregistrer.
Un module qui survit aux mises à jour
C'est le seul critère qui distingue vraiment un développement Dolibarr sérieux d'un bricolage. Il existe deux façons d'ajouter une fonctionnalité : modifier le cœur du logiciel, ou passer par les points d'extension prévus pour ça.
La première marche immédiatement et coûte moins cher. Elle a un défaut : à la première mise à jour de Dolibarr, vos modifications sont écrasées. Vous vous retrouvez alors devant un choix désagréable — ne plus jamais mettre à jour, et accumuler les failles de sécurité non corrigées ; ou mettre à jour, et repayer le développement. J'ai vu ce piège se refermer sur des entreprises restées bloquées des années sur une version obsolète.
La seconde consiste à écrire un module séparé, qui se branche sur les extensions officielles de Dolibarr sans jamais toucher aux fichiers d'origine. Votre fonctionnalité vit dans son propre dossier, s'active et se désactive comme n'importe quel module, et survit aux montées de version. C'est ainsi que je travaille, sans exception.
Cette exigence vient de l'expérience du cœur du logiciel : une année d'alternance passée dedans et des contributions au projet lui-même apprennent vite ce qui résiste à une mise à jour et ce qui ne résiste pas. Le détail est sur la page de mon parcours.
Comment se déroule un développement
1. Cadrage écrit
On décrit précisément ce que le module doit faire : les écrans, les champs, qui a le droit de quoi, et surtout ce qu'il ne fera pas. Ce document sert de référence commune : c'est lui qui évite le désaccord de fin de projet où chacun avait compris autre chose. Le devis découle de ce cadrage, pas d'une conversation.
2. Développement sur une copie
Le module est écrit et testé sur une instance de test contenant une copie de vos données, jamais directement sur votre Dolibarr de production. Votre activité continue sans risque pendant ce temps, et le code est versionné sous Git à chaque étape : toute modification est traçable et réversible.
3. Recette par vous
Vous essayez le module sur l'instance de test, avec vos propres cas, y compris les tordus — c'est en général vous qui les connaissez. Les ajustements se font là, avant la mise en production, où ils coûtent le moins cher. Cette étape n'est pas une formalité : c'est elle qui fait la différence entre un module correct et un module réellement utilisé.
4. Mise en production et documentation
Installation sur votre instance après sauvegarde, vérification, et une note écrite expliquant ce que fait le module et comment le paramétrer. Le code source vous est remis : vous en êtes propriétaire, et un autre développeur peut reprendre derrière moi. C'est votre garantie, et le prolongement de ma méthode de travail.
Ce qui fait varier le coût
- Le nombre d'écrans : une automatisation qui tourne en arrière-plan n'a aucune interface. Un objet métier complet en demande plusieurs, avec leurs filtres et leurs droits. L'écart est considérable.
- Les échanges avec l'extérieur : un connecteur dépend d'un service tiers, de sa documentation et de sa fiabilité. Une API bien documentée se branche vite ; une API capricieuse demande de gérer les erreurs, les rejeux et les cas limites.
- Les règles de gestion : « sauf pour ce client-là », « sauf en fin d'exercice », « sauf si le stock est négatif ». Chaque exception est du code, des tests et de la maintenance. Les lister au cadrage évite les surprises.
- La reprise de l'existant : alimenter le nouveau module avec vos données actuelles est un travail à part entière, souvent sous-estimé.
Comment je chiffre
Sur la base du cadrage écrit, jamais avant. Un chiffrage donné au téléphone sur une description en deux phrases est un chiffrage qui sera révisé — et ces révisions sont la principale source de tension dans un projet informatique.
Quand un besoin est trop large pour être chiffré d'un bloc, je le découpe : on développe d'abord la partie qui rapporte le plus, vous l'utilisez réellement, et on décide de la suite avec l'expérience de l'usage. C'est plus sûr que de tout spécifier à l'avance, parce qu'un besoin se précise toujours en s'en servant.
À l'inverse, si le besoin ne justifie pas un développement, je le dis. Une automatisation qui vous fait gagner dix minutes par an ne vaut pas le code qu'elle demande.
Ce qu'on me demande le plus souvent
Mon module survivra-t-il aux mises à jour de Dolibarr ?
Oui, parce qu'il est écrit comme un module séparé qui utilise les points d'extension officiels, sans jamais modifier les fichiers d'origine. C'est le critère décisif : un développement fait en modifiant le cœur du logiciel est effacé à la première mise à jour, et vous enferme dans une version qui vieillit. Aucun de mes développements ne fonctionne comme ça.
Suis-je propriétaire du module développé ?
Oui. Le code source vous est remis avec sa documentation, et rien n'est verrouillé ni chiffré. Vous pouvez le faire reprendre, modifier ou auditer par n'importe quel autre développeur PHP. Je considère qu'un prestataire qui retient le code se protège de sa propre concurrence, pas de vos risques.
Il arrive qu'un module écrit pour un besoin précis ait un intérêt bien plus large. Dans ce cas, je peux proposer de le publier sur le DoliStore, la place de marché officielle des modules Dolibarr. Cela ne se fait jamais sans votre accord explicite, et la question se pose au moment du cadrage — pas une fois le module livré. Si vous préférez qu'il reste strictement chez vous, il reste strictement chez vous.
Pouvez-vous reprendre un module développé par quelqu'un d'autre ?
Souvent oui, mais je regarde le code avant de m'engager. S'il respecte l'architecture de Dolibarr, la reprise est simple. S'il modifie le cœur du logiciel, je vous dirai franchement ce que coûte la remise en état par rapport à une réécriture propre : parfois la réécriture est moins chère, et il vaut mieux l'apprendre au début qu'au milieu.
Faut-il que vous hébergiez mon Dolibarr pour développer dessus ?
Non. Je développe sur une copie de votre instance, quel que soit l'endroit où elle est hébergée : chez vous, chez un autre prestataire, ou sur un VPS que j'infogère. Il me faut simplement un accès technique et une sauvegarde récente avant toute mise en production.
Un module peut-il me mettre en conformité avec la facture électronique ?
Ce n'est pas un développement sur-mesure qu'il vous faut : le raccordement à une plateforme agréée passe par un module existant et gratuit, et l'essentiel du travail est du paramétrage. Développer quelque chose de spécifique ici serait vous faire payer pour rien. Tout est détaillé sur la page consacrée à la facture électronique 2026.
Je ne sais pas si mon besoin justifie un développement : comment savoir ?
Décrivez-moi la tâche telle que vous la faites aujourd'hui, avec sa fréquence et le temps qu'elle vous prend. C'est suffisant pour que je vous dise si c'est un réglage, un module existant, un développement, ou rien du tout. Cet échange ne coûte rien, et il arrive régulièrement qu'il se conclue par « n'y touchez pas ». Si vous découvrez Dolibarr, commencez plutôt par la page qui l'explique.
Une tâche que Dolibarr ne sait pas faire ?
Décrivez-la simplement, avec le temps qu'elle vous prend. Je vous dis s'il faut un réglage, un module existant ou du développement — et parfois qu'il ne faut rien faire.
Décrire mon besoin