Dolibarr couvre déjà beaucoup de besoins dès l'installation : facturation, stocks, CRM, projets... Mais tôt ou tard, une PME a besoin d'un ajustement que le logiciel ne propose pas nativement : un champ en plus sur une fiche client, un email automatique quand un devis est signé, une synchronisation avec un outil externe. C'est exactement à cela que servent les hooks et les triggers, deux mécanismes qui permettent d'adapter Dolibarr sans toucher à son code d'origine.

Hooks et triggers : deux outils, deux usages

Les deux mots reviennent souvent dans la bouche d'un développeur Dolibarr, mais ils ne servent pas du tout à la même chose.

Un hook s'accroche à un endroit précis de l'affichage ou d'un traitement : il permet d'ajouter un bouton, une colonne dans une liste, un champ dans un formulaire, ou une vérification avant l'enregistrement d'un document. On peut le voir comme un point d'ancrage que Dolibarr laisse volontairement disponible pour qu'un module vienne s'y greffer proprement.

Un trigger, lui, réagit à un événement métier : la validation d'une facture, la signature d'un devis, le changement de statut d'une commande. Il ne modifie pas ce que l'utilisateur voit à l'écran, il déclenche une action en arrière-plan dès que l'événement se produit.

En résumé, le hook agit sur ce que l'utilisateur voit ou saisit, le trigger agit sur ce qui se passe automatiquement une fois l'action validée.

Les hooks : ajouter sans réécrire le cœur du logiciel

L'intérêt des hooks est simple : ils évitent de modifier directement les fichiers de Dolibarr. Toute personnalisation vit dans un module séparé, ce qui veut dire que la prochaine mise à jour du logiciel ne l'effacera pas.

Quelques exemples concrets rencontrés chez des PME : un champ « référence chantier » ajouté sur la fiche commande, une colonne « marge » affichée uniquement pour les commerciaux dans la liste des devis, ou un contrôle qui bloque la validation d'une facture tant qu'une pièce jointe obligatoire n'est pas présente.

Le point de vigilance à connaître : un hook mal isolé, écrit directement dans les fichiers du cœur plutôt que dans un module dédié, disparaît à la première mise à jour. C'est l'erreur la plus fréquente sur les installations bricolées en interne, sans méthode.

Les triggers : automatiser les actions métier

Les triggers prennent tout leur sens dès qu'on veut automatiser une tâche répétitive. Quelques usages courants : envoyer un email de bienvenue à la création d'un nouveau client, générer une tâche de suivi quand une commande passe au statut « expédiée », ou transmettre les données d'une facture validée vers un outil comptable externe.

L'avantage pour une PME est direct : moins de ressaisie manuelle, moins d'oublis, et des processus qui se déclenchent au bon moment sans intervention humaine. C'est souvent ce type d'automatisation discrète, mais bien pensée, qui fait gagner le plus de temps au quotidien à une équipe, bien plus qu'une fonctionnalité visible et spectaculaire.

Bonnes pratiques pour que ça reste fiable dans la durée

Un hook ou un trigger mal conçu peut vite devenir un point fragile du système. Quelques règles simples permettent d'éviter les mauvaises surprises :

  • Toujours passer par un module dédié, jamais par une modification directe des fichiers du cœur de Dolibarr
  • Donner des noms clairs aux hooks et triggers utilisés, pour qu'un autre développeur comprenne le fonctionnement sans tout relire
  • Tester sur un environnement de préproduction avant chaque mise en production, surtout après une montée de version
  • Prévoir des journaux (logs) pour savoir précisément ce qu'a fait une automatisation en cas de résultat inattendu
  • Documenter brièvement chaque ajout : à quoi il sert, dans quel module il se trouve, qui l'a demandé et pourquoi
  • Éviter d'empiler les automatisations sans vue d'ensemble : mieux vaut trois triggers bien pensés qu'une dizaine dont plus personne ne sait exactement ce qu'ils font

Cadrer les personnalisations dès le départ

La vraie différence se joue rarement sur la technique pure : elle se joue sur la façon dont la personnalisation est cadrée en amont. Un besoin bien formulé, avec l'événement déclencheur, l'action attendue et les limites du périmètre, se traduit en général par un développement simple et stable. Un besoin flou, ajouté au fil de l'eau sans réflexion d'ensemble, finit par produire un empilement de correctifs difficile à maintenir. C'est particulièrement vrai quand plusieurs personnes interviennent sur l'ERP au fil des années, chacune avec sa propre méthode et ses propres habitudes. Nous accompagnons régulièrement des PME sur ce type de développement de modules Dolibarr sur mesure, justement pour éviter cet écueil et garder un système facile à faire évoluer dans le temps.

Vous avez un besoin précis à automatiser dans Dolibarr, ou une personnalisation existante qui devient difficile à maintenir ? Parlons-en ensemble : nous pourrons évaluer la solution la plus simple et la plus durable pour votre organisation.