Intégrer Pipedrive et Dolibarr
Dolibarr est l'ERP open source français le plus utilisé : plus de 700 000 installations dans le monde en 2026. Si vous êtes une PME industrielle, artisanale ou associative avec un besoin ERP complet, c'est probablement votre choix. Mais son intégration avec Pipedrive est techniquement plus exigeante qu'avec Pennylane ou Sellsy, parce qu'il n'y a pas de module Make.com natif. Ce chapitre couvre les 5 pièges terrain uniques de Dolibarr, basés sur mon expérience chez Guilbert Signalétique, et 5 scénarios Make.com qui marchent.
Pourquoi Dolibarr est un cas particulier
Contrairement à Pennylane ou Sellsy qui sont SaaS avec APIs modernes, Dolibarr est une application PHP que vous hébergez vous-même (ou via DoliCloud). Conséquences :
- Pas de module Make.com dédié : tout passe par HTTP générique + API REST Dolibarr
- Pas de webhooks natifs (!) : Dolibarr ne vous notifie pas quand un paiement arrive, il faut poller
- Comportements API non-standards : certains endpoints renvoient 404 sur résultat vide au lieu de 200 avec tableau vide
- Champs personnalisés préfixés : si vous ajoutez un champ custom "Code client", l'API l'expose sous le nom
options_code_client - Pagination par défaut à 100 : si vous avez plus de 100 factures à récupérer, vous devez paginer explicitement
Malgré ces spécificités, Dolibarr reste une excellente option économique, surtout en version self-hosted. Le jeu en vaut la chandelle.
Les 5 pièges terrain à connaître avant de commencer
🚫 Piège 1 : le 404 sur résultat vide
Quand vous faites un GET /customers?sqlfilter=... et qu'aucun client ne correspond, Dolibarr renvoie un HTTP 404 Not Found. La plupart des outils interprètent ça comme une erreur. Dans Make.com, vous devez configurer votre module HTTP pour traiter le 404 comme "résultat vide" normal, sinon votre scénario casse dès que la recherche ne trouve rien.
🚫 Piège 2 : le préfixe options_ sur les champs custom
Si vous avez créé un champ personnalisé "SIRET" dans Dolibarr, son nom technique en base est siret. Mais pour le lire ou l'écrire via API, le nom devient options_siret. Idem pour l'écriture : votre POST doit envoyer options_siret, pas siret. Cette convention n'est pas documentée clairement.
🚫 Piège 3 : la pagination obligatoire
Tous les GET de listes sont paginés à 100 par défaut. Si votre scénario liste les factures impayées et que vous en avez 250, vous ne voyez que les 100 premières. Ajoutez ?limit=500 ou itérez avec &page=1, &page=2... jusqu'à recevoir moins de 100 résultats.
🚫 Piège 4 : pas de webhooks natifs
Pour détecter un nouveau paiement dans Dolibarr, il n'y a pas de webhook. Vous devez soit : installer le module "Webhook" externe (payant ~50€), soit faire un polling Make.com toutes les X minutes (coûteux en opérations). La 3e option : développer un déclencheur PHP custom côté Dolibarr qui appelle une URL Make.com.
🚫 Piège 5 : les IDs ne sont pas stables entre environnements
Si vous avez un Dolibarr dev et un Dolibarr prod, les IDs de produits/clients/factures seront différents. N'hardcodez jamais un ID dans Make.com. Utilisez toujours les références métier (SIRET, code produit, référence facture).
Les 5 scénarios Make.com qui marchent
Scénario 1 — Création de facture Dolibarr au deal gagné
Flux scénario 1
Module Make à utiliser : "HTTP - Make a Request" avec authentification par header DOLAPIKEY. Attention au piège 2 si vous avez des champs custom à remplir.
Scénario 2 — Poll des paiements reçus (workaround webhook manquant)
Flux scénario 2
Stocker "dernier_check" dans une variable Make (Data Store) pour éviter de re-traiter les paiements déjà vus. Coût : ~48 opérations/jour, tenable sur le plan Core.
Scénario 3 — Liste des impayés à J+7, J+15, J+30
Flux scénario 3
Le commercial reçoit la tâche dans son Pipedrive avec le contexte du deal. Pas besoin d'aller chercher dans Dolibarr.
Scénario 4 — Synchronisation bidirectionnelle des clients
Flux scénario 4
Point critique : utilisez le SIRET comme clé unique. Le nom d'entreprise n'est pas fiable (variations d'orthographe, SARL/SAS, etc.).
Scénario 5 — Export reporting mensuel CA Dolibarr → Google Sheet partagé
Flux scénario 5
Permet de calculer les commissions commerciales automatiquement depuis les données réelles de Dolibarr, pas des déclaratifs.
Configuration API Dolibarr : les étapes exactes
- Activer le module REST API dans Configuration → Modules → REST API
- Créer un utilisateur dédié Make avec permissions strictement nécessaires (Factures : lire/écrire, Clients : lire/écrire, Paiements : lire)
- Générer une clé API pour cet utilisateur (Profil → Informations personnelles → DOLAPIKEY)
- Tester avec Postman avant de configurer Make :
GET https://votre-dolibarr.fr/api/index.php/statusdoit répondre 200 - Dans Make : module HTTP avec header
DOLAPIKEY: votre_clesur chaque requête
Budget et complexité
| Poste | Coût |
|---|---|
| Dolibarr (self-hosted sur serveur dédié) | 0€ licence + ~15€/mois hébergement |
| Dolibarr DoliCloud (hébergé) | ~16€/user/mois |
| Make.com Core | 9€/mois |
| Setup initial (5 scénarios) | 4 500-6 500€ (5-7 jours) |
| Maintenance annuelle | 800-1 500€ |
Pour plus de détails sur l'intégration, voir notre article Pipedrive + Dolibarr.
Ce que vous devez faire maintenant
- Activer l'API REST dans votre Dolibarr et créer un utilisateur Make dédié
- Tester les endpoints critiques avec Postman avant Make
- Démarrer par le Scénario 1 uniquement et valider 2 semaines
- Anticiper les 5 pièges dès le design des scénarios
Vous voulez qu'on branche votre Pipedrive à votre outil compta ?
Je configure la stack complète en 3 à 5 jours. Premier échange gratuit pour cadrer votre cas.
Se faire rappeler →