Pipedrive
Extension payante. Chaque soumission crée ou met à jour une personne, puis ouvre un lead rattaché à elle.
Ce document décrit ce que le module garantit et ce qu’il refuse. Le guide utilisateur en donne la version courte, dans la section « Envoyer les réponses vers Pipedrive ».
Le pipeline n’existe pas pour un lead
Il faut commencer par là, parce que le plan de ce module demandait « créer un lead dans un pipeline choisi » et que ce n’est pas possible.
Chez Pipedrive, un pipeline est une propriété de l’affaire, pas du lead. Les leads vivent dans la boîte de réception des leads, qui n’a pas de colonnes. Le plan excluait par ailleurs les affaires de la V1 — on ne pouvait donc pas tenir l’un sans franchir l’autre.
Ce que Pipedrive offre réellement pour orienter un lead, ce sont le propriétaire et les étiquettes : à qui il échoit, et comment il se filtre. Ce sont donc eux que le réglage porte. C’est un choix de remplacement assumé, plutôt que la demande rendue approximativement sous un nom qui aurait laissé croire à autre chose.
Chercher avant de créer, et c’est la moitié du module
Pipedrive n’a pas d’upsert : ni « créer ou mettre à jour », ni clé externe, ni rapprochement automatique.
Sans recherche préalable, chaque soumission créerait une personne de plus. Au bout d’un mois, le même client apparaît douze fois dans le fichier — et personne ne s’en aperçoit avant d’essayer de lui écrire. C’est le genre de défaut qui ne fait aucun bruit et qui coûte le fichier client.
La recherche est donc exacte et porte sur l’adresse seule. Une recherche
floue — celle que l’API fait par défaut — rapprocherait camille@exemple.test de
camille@autre-societe.test, et le module écrirait dans la fiche de quelqu’un
d’autre.
C’est pourquoi le champ d’adresse est obligatoire ici alors que l’API ne l’exige pas : sans lui, il n’y a pas de rapprochement possible.
Un envoi en quatre appels, qui reprend où il s’était arrêté
Chercher l’organisation, la créer, chercher la personne, l’écrire, créer le lead : chaque étape peut aboutir pendant que la suivante échoue.
Les identifiants obtenus sont donc consignés dès qu’ils le sont, et une reprise saute ce qui est acquis. Sans cela, une troisième tentative rechercherait une personne qu’elle vient de créer — et si la recherche échouait pour la même raison que la première fois, elle en créerait une seconde.
C’est la différence avec les modules à un seul appel : ici l’état partiel existe, et le nier aurait produit des doublons à chaque panne.
L’écran des soumissions montre donc les trois identifiants, et l’écran de diagnostic indique jusqu’où chaque envoi en échec était allé. « Personne créée, lead refusé » se lit ; un échec nu ne dit pas ce qu’il reste à corriger.
L’organisation est un agrément, pas une condition
Si un champ d’organisation est associé, elle est cherchée par son nom puis créée. Si cela échoue, l’envoi continue : un lead sans organisation reste un lead utilisable, et perdre la soumission pour un nom de société serait un mauvais échange.
Une soumission, un lead
UNIQUE (soumission) sur la table de suivi, et une prise de ligne —
UPDATE … WHERE état <> 'sent' avec un bail de temps — qui décide laquelle de
deux tâches qui se croisent envoie réellement.
Elle compte double ici : deux tâches concurrentes ne créeraient pas seulement deux leads, mais deux personnes — chacune ayant cherché avant que l’autre n’ait écrit.
Elle ne couvre pas le cas rare : l’appel aboutit chez Pipedrive, la réponse se
perd en route. C’est la limite du service, et c’est pourquoi le champ de
référence facultatif existe : la référence slf-<site>-<numéro> écrite sur le
lead ne prévient pas le doublon, elle le rend trouvable par une recherche.
Pipedrive répond 200 en disant non
Chaque réponse porte un booléen success, et une requête refusée pour une valeur
invalide arrive régulièrement avec un code HTTP de succès et
{"success": false, "error": "…"}.
Se fier au code aurait compté comme créées des personnes que Pipedrive a refusées, et le client ne l’aurait vu qu’en comparant ses chiffres.
Les identifiants ne sont pas tous du même genre
Personnes et organisations portent des identifiants numériques ; les leads portent des UUID.
La distinction n’est pas une curiosité : un transtypage nu transformerait une
valeur inattendue en 0, et Pipedrive lit 0 comme un identifiant, pas comme une
absence. Un lead serait parti rattaché à la personne numéro zéro. La vérification
précède donc la conversion, et un identifiant de personne qui n’est pas un nombre
arrête l’envoi plutôt que de produire une fiche fausse.
Le même contrôle porte sur le propriétaire et les étiquettes, saisis au niveau du formulaire : Pipedrive refuse l’enregistrement entier sur une valeur non numérique.
L’adresse de l’API arrive par le réseau
C’est la particularité de Pipedrive. oauth.pipedrive.com porte l’autorisation ;
l’API, elle, vit sur le domaine de l’entreprise — monentreprise.pipedrive.com
—, que Pipedrive rend à l’échange de jetons sous le nom api_domain.
Cette adresse vient donc d’une réponse réseau, et c’est elle qu’on appellera
ensuite avec un jeton d’accès. Une réponse altérée ne doit pas pouvoir
rediriger les soumissions suivantes vers un serveur de son choix : elle est
confrontée au suffixe .pipedrive.com et au schéma https, et refusée sinon.
Le point initial du suffixe est volontaire. Sans lui,
attaquant-pipedrive.com passerait le contrôle — c’est la faute classique de ce
genre de liste, et elle ne se voit pas à la lecture.
Une connexion sans domaine admissible n’est pas tenue pour établie : un jeton qu’on ne sait pas où employer n’est pas une connexion.
Les portées, et celles qu’on n’a pas demandées
contacts:full pour écrire personnes et organisations, leads:full pour créer le
lead, search:read pour retrouver une personne — sans quoi chaque soumission en
créerait une de plus — et users:read pour proposer la liste des propriétaires à
l’écran plutôt que de faire saisir un identifiant numérique.
Pas deals:full, qui aurait donné l’écriture sur toutes les affaires du compte.
Une portée excédentaire ne change rien tant que rien ne tourne mal, et change tout
le jour où quelque chose tourne mal.
Le secret voyage dans l’en-tête
Pipedrive attend l’authentification de l’application en Basic — le couple
identifiant/secret encodé dans Authorization — là où Google, Zoho et HubSpot la
prennent dans le corps du formulaire. Ce n’est pas un détail d’écriture : un
secret placé dans le corps se fait répondre invalid_client sans que rien
n’indique où est l’erreur.
Ce qui n’est pas tenté, et ce qui est rejoué
Rien n’est programmé si la connexion manque, si le champ de nom ou d’adresse n’est pas désigné, ou si la condition du formulaire n’est pas remplie. Une soumission marquée indésirable ne part pas, même si la tâche était déjà en file. Un nom vide est un refus définitif écrit avant tout appel — Pipedrive le refuserait en parlant d’une propriété, pas du champ du formulaire.
Les refus définitifs ne sont pas rejoués. Les 429 et les 5xx le sont, à 1, 5
puis 30 minutes. La distinction compte plus ici qu’ailleurs : un compte Pipedrive
a un budget d’appels journalier en plus de la limite par seconde, et s’acharner
sur un refus définitif le consomme pour rien — quatre appels à chaque fois.
Un 401 donne droit à un renouvellement de session, demandé une fois pour toute
la suite et non à chaque étape.
Une panne Pipedrive ne bloque jamais la soumission. Elle est enregistrée, confirmée au visiteur et notifiée par courriel avant que ce module ne soit sollicité.
Renvoyer ouvre un second lead
Le bouton de renvoi met la personne à jour — elle est retrouvée par son adresse — mais crée un nouveau lead : Pipedrive ne sait ni retrouver ni remplacer le précédent, et l’API n’offre que la création.
L’écran le dit avant le clic plutôt que de le laisser découvrir. Le geste reste utile : un droit rétabli, un propriétaire corrigé, une portée accordée après coup.
Les identifiants déjà acquis sont conservés par le renvoi : la personne existe toujours, et la rechercher serait un appel pour rien.
Ce que le journal ne contient pas
Ni la requête, ni la réponse. Les deux portent les valeurs de la soumission : les consigner ferait du journal une seconde copie, qui s’en irait dans les sauvegardes et les exports — où elle se lirait comme une trace technique alors qu’elle décrit une personne. Restent le code HTTP et le motif.
Schéma
slf_pipedrive_leads : une ligne par soumission, avec les identifiants
d’organisation, de personne et de lead, la référence, l’état, le motif du dernier
problème et le nombre de tentatives. Elle disparaît avec la soumission ; la fiche
chez Pipedrive, elle, reste — elle appartient au CRM.
La connexion vit dans une option, jetons chiffrés avec une clé propre à l’intégration. Le domaine d’API y est conservé en clair : ce n’est pas un secret, et c’est la première chose à regarder quand les envois partent nulle part.
Ce que la V1 ne fait pas
Pas d’affaire, pas d’activité, pas de produit. Pas de lecture du CRM, pas de synchronisation en sens inverse : le flux va du site vers Pipedrive, et l’inverse ferait d’un site WordPress public une porte d’entrée sur le fichier client.
Pas de mise à jour d’un lead existant non plus, puisque l’API n’en offre pas le moyen à partir d’une soumission.