Tutoriel, Data et intégrations

Réunir Stripe, Shopify et Pipedrive dans un dashboard

Comment réconcilier trois outils qui racontent trois histoires différentes : ce que chacun mesure réellement, les clés de rapprochement à utiliser, la vue unifiée qui en sort et la maintenance à prévoir.

Par Yanis Zedira. Publié le 30 août 2026. 12 min de lecture.

Réunir Stripe, Shopify et Pipedrive dans un seul tableau de bord consiste d'abord à accepter que les trois outils ne mesurent pas la même chose, puis à choisir une seule source de vérité par question. Stripe voit l'argent encaissé, Shopify voit les commandes passées, Pipedrive voit les opportunités avant qu'elles n'existent commercialement. Additionner leurs totaux ne produit pas un chiffre, cela produit une confusion.

Ce tutoriel décrit la marche à suivre : comprendre ce que chaque outil observe réellement, partir des questions auxquelles le tableau de bord doit répondre, définir les clés de rapprochement, construire la vue unifiée, puis assurer la maintenance dans le temps. La roadmap digitale d'une PME sur douze mois situe le chantier data dans une séquence plus large, cet article se concentre sur le cas précis de trois outils qui racontent trois histoires différentes.

Pourquoi les totaux de Stripe, Shopify et Pipedrive ne tombent-ils jamais juste ?

Parce que chaque outil observe un moment différent du cycle et applique ses propres règles de comptage. L'écart n'est pas une anomalie à corriger, c'est une propriété du système.

Stripe voit les mouvements d'argent : paiements réussis, échecs, remboursements, litiges, frais prélevés, virements vers votre compte. Son total est net de certaines choses et brut d'autres, et il inclut les paiements qui ne viennent pas de Shopify. Shopify voit les commandes : une commande passée existe même si le paiement échoue, une commande annulée reste dans l'historique, les taxes et les frais de port entrent ou non dans le total selon la vue choisie. Pipedrive voit l'intention : des opportunités avec un montant estimé, saisi par un humain, souvent arrondi et parfois jamais mis à jour après la vente.

Quatre sources d'écart reviennent systématiquement. Le décalage temporel d'abord : une commande de fin de mois est encaissée le mois suivant, et un virement Stripe arrive plusieurs jours après le paiement. Le périmètre ensuite : Stripe encaisse aussi des abonnements ou des factures créés hors Shopify. Les corrections ensuite : remboursements partiels, avoirs et litiges se rattachent à une commande ancienne. Et enfin les frais : Shopify affiche un montant client, Stripe affiche ce montant moins la commission.

La conclusion pratique est simple. On ne cherche pas à faire coïncider trois totaux, on décide quelle source fait foi pour quelle question. L'argent encaissé vient de Stripe, le volume de commandes vient de Shopify, le pipeline commercial vient de Pipedrive. Aucune de ces réponses ne se discute ensuite.

Par quelles questions faut-il commencer avant de connecter quoi que ce soit ?

Par trois à cinq questions écrites, formulées par ceux qui décident, et validées avant toute connexion technique. C'est l'étape que l'on saute et qui coûte le plus cher.

Les questions qui reviennent dans un contexte mêlant vente en ligne et vente accompagnée sont assez stables. Combien d'argent est réellement entré ce mois-ci, net des remboursements ? Quels canaux d'acquisition amènent les clients qui achètent, et pas seulement ceux qui visitent ? Combien de temps s'écoule entre la première interaction et le premier paiement ? Quelle part du chiffre d'affaires vient de clients déjà connus ? Quelles opportunités commerciales sont bloquées et depuis combien de temps ?

Chaque question détermine une source, un niveau de détail et une fréquence. La question de l'argent encaissé se répond avec Stripe, au mois, et n'a besoin d'aucun rapprochement. La question du parcours d'acquisition, elle, exige de relier une personne dans Pipedrive à une commande dans Shopify puis à un paiement dans Stripe : c'est la question la plus utile et la plus coûteuse, il faut le savoir avant de la promettre.

Quelles données tirer de chaque outil et avec quelle clé de jointure ?

Que faire quand la clé de rapprochement est absente ?

On admet la non-correspondance plutôt que de deviner, et on crée une catégorie explicite pour ces cas.

Trois traitements existent, à utiliser dans cet ordre. Le rapprochement exact d'abord, sur la référence de commande ou l'identifiant client, qui ne se discute pas. Le rapprochement probable ensuite, sur adresse normalisée, avec une fenêtre de temps raisonnable, par exemple un paiement survenu dans les jours qui suivent la commande. Et enfin la catégorie des non rapprochés, qui doit apparaître dans le tableau de bord et non disparaître silencieusement.

Cette dernière règle est la plus importante. Un rapprochement qui masque ses échecs produit un tableau de bord faux avec une apparence de propreté. Affichez le nombre de lignes non rapprochées et leur montant total : c'est l'indicateur de qualité de votre chaîne, et sa dérive vous prévient d'un changement en amont.

À moyen terme, la vraie correction est en amont, pas dans le tableau de bord. Faire écrire la référence de commande dans les métadonnées du paiement Stripe, imposer un champ de référence dans Pipedrive au moment de la clôture, dédupliquer les contacts : trois actions simples qui suppriment la plupart des cas ambigus. Les principes de fiabilisation des flux sont détaillés dans notre approche de l'automatisation IA.

À quoi ressemble la vue unifiée qui en sort ?

À trois blocs, pas plus, chacun répondant à une famille de questions. La hiérarchie est la même que pour tout tableau de bord Power BI : une page de synthèse courte, des vues de détail séparées, la source affichée sous chaque chiffre.

Le premier bloc suit le parcours, de la première interaction à l'encaissement. Il montre combien de contacts entrent, combien deviennent des affaires, combien de commandes sont passées, combien sont réellement encaissées, avec les délais moyens entre chaque étape. C'est la vue qui révèle les décrochages : une conversion correcte jusqu'à la commande mais un taux d'échec de paiement élevé désigne un problème technique, pas commercial.

Le deuxième bloc traite la performance par canal. Il rapproche l'origine enregistrée dans Pipedrive ou dans Shopify du chiffre d'affaires encaissé dans Stripe, ce qui permet de comparer les canaux sur l'argent réellement entré et non sur le volume de contacts. C'est souvent le bloc qui change le plus les décisions, parce que le canal qui amène le plus de contacts est rarement celui qui amène le plus de marge.

Le troisième bloc porte sur les cohortes et la récurrence. Il regroupe les clients par mois de première commande et suit ce qu'ils dépensent ensuite. C'est la seule vue qui dit si votre activité se construit ou si elle recommence chaque mois à zéro, et elle demande peu de données supplémentaires une fois les clients rapprochés.

Comment maintenir ce dashboard dans la durée ?

En considérant dès le départ que les trois outils vont changer sans vous prévenir, et en préparant la détection plutôt que la réaction.

Les interfaces de programmation évoluent : des versions sont retirées, des champs sont renommés, des limites de débit changent. Épinglez une version d'interface quand l'outil le permet, notez la date de fin de support annoncée, et prévoyez une revue technique deux fois par an. Un flux qui s'arrête silencieusement est plus dangereux qu'un flux qui échoue bruyamment : configurez une alerte sur l'absence de données plutôt que sur l'erreur seule.

La documentation est le second pilier, et elle tient en une page par source. Elle indique ce que l'on extrait, à quelle fréquence, avec quel compte, quelle clé de jointure, et quel est le comportement attendu en cas d'échec. Cette page permet à quelqu'un d'autre de reprendre la chaîne. Sans elle, la connaissance vit dans la tête de la personne qui a construit le flux, et l'outil devient fragile le jour où elle part.

Ce que nous voyons le plus souvent chez un client

La demande arrive presque toujours formulée de la même manière : les chiffres ne correspondent pas, il faut que tout tombe juste. La première chose que nous faisons est de dire qu'un écart résiduel subsistera, quel que soit le travail fourni. Décalages temporels, remboursements rattachés à des périodes antérieures, commissions, arrondis de change, paiements hors périmètre : ces causes ne disparaissent pas. L'objectif d'un tableau de bord de pilotage est une vue assez fiable pour décider, pas une exactitude comptable. La comptabilité, elle, se fait dans un outil comptable, avec un expert-comptable, et sur des règles différentes.

Le deuxième constat récurrent concerne Pipedrive. Les montants d'affaires y sont saisis à l'ouverture, estimés, et presque jamais corrigés après la vente. Utiliser ces montants comme mesure du chiffre d'affaires produit un écart durable avec Stripe et fait douter de l'ensemble. Notre règle est nette : Pipedrive sert à mesurer l'activité commerciale, les volumes et les délais, jamais l'argent. L'argent vient de Stripe.

Passer à l'action

Faites un test de cohérence aujourd'hui, il prend une heure. Prenez le mois dernier, relevez le chiffre d'affaires affiché par Shopify, le total encaissé affiché par Stripe et la somme des affaires gagnées dans Pipedrive. Notez les trois chiffres et l'écart entre eux. Puis listez les causes possibles que vous connaissez déjà : commandes non payées, remboursements, commissions, ventes hors Shopify. Vous saurez immédiatement si votre écart s'explique ou s'il cache un problème réel.

Pour construire la vue unifiée sur vos comptes, réservez un appel de trente minutes ou passez par le calendrier de YZ Automation. Nous regardons vos trois sources, vos clés disponibles et vos questions de pilotage, et vous repartez avec une architecture de rapprochement écrite. Le contexte de développement sur mesure est décrit sur la page développement SaaS et applications métier.