Un CRM sert d’abord à tenir des fiches et des affaires. Il devient vraiment utile quand il cesse d’être une île. Sur le plan Pro de CRM by Le Beau Digital, nous avons prévu des connexions avec Qonto, Airtable, Stripe et Google. Voici comment nous les concevons, autour du pipeline, sans tout automatiser au premier jour, et sans demander à l’outil de remplacer un jugement commercial.
Le pipeline d’abord, les branchements ensuite
Dans notre CRM, le pipeline suit les opportunités. Une affaire entre, elle avance d’étape en étape, elle se gagne ou s’arrête. Les campagnes partent depuis la même base. Tant que ce socle n’est pas tenu — des fiches à jour, des étapes qui veulent dire quelque chose, des droits clairs — brancher un autre outil n’apporte pas grand-chose. On ne fait que déplacer le désordre.
C’est pourquoi les connexions arrivent avec le plan Pro, aux côtés de la prospection, de l’API, du MCP et de l’enrichissement. Le plan gratuit reste centré sur l’essentiel : contacts, entreprises, affaires, utilisateurs, sans plafond sur ces volumes. On peut donc commencer simple, puis ouvrir les flux quand un besoin réel apparaît.
Un branchement n’est pas une décoration de fiche produit. Il doit répondre à une question précise. Quand un paiement est reçu, que doit-on voir sur l’affaire ? Quand une écriture passe dans la banque, qui la rapproche ? Quand un rendez-vous est posé, où vit-il ? Si la question n’existe pas, le connecteur attend.
Stripe, pour le paiement qui parle à l’affaire
Stripe intervient quand une encaissement, un abonnement ou un paiement en ligne doit laisser une trace utile dans le CRM, pas seulement dans le tableau de bord du prestataire de paiement. L’intérêt, pour une équipe commerciale ou un dirigeant de PME, est de relier un fait de paiement à une affaire, à un contact, à une entreprise, sans recopier un identifiant d’une interface à l’autre.
Nous ne décrivons pas ici chaque événement technique de l’API Stripe. Le principe suffit : un paiement confirmé, un échec, un abonnement qui change d’état, doivent pouvoir mettre à jour le bon objet dans le pipeline, ou créer une alerte pour un humain. La décision — relancer, clôturer, ouvrir un avoir — reste dans l’équipe. L’outil prépare l’information.
Deux précautions. Premièrement, les clés d’API et les webhooks se configurent avec le plus petit périmètre possible. Une clé trop large, partagée dans un canal, est un risque. Deuxièmement, on ne synchronise pas « tout l’historique » par curiosité. On part des événements utiles au pipeline. Le reste peut rester dans Stripe, qui reste le système de vérité pour le paiement.
Qonto, pour le mouvement bancaire
Qonto entre en jeu quand le compte de l’entreprise doit éclairer le suivi commercial, ou inversement. Un encaissement reçu, un prélèvement, un libellé que l’on peut rapprocher d’une affaire : autant d’informations que l’on a trop souvent dans la banque, et nulle part sur la fiche.
Là encore, le CRM n’a pas vocation à devenir un logiciel de comptabilité. La comptabilité a ses règles, ses exports, ses clôtures. La connexion sert à réduire les allers-retours, à signaler qu’un règlement est arrivé, à éviter une relance pour une facture déjà payée. Quand le rapprochement est ambigu, on le laisse à un humain. Un libellé bancaire n’est pas toujours un identifiant d’affaire.
Nous demandons, avant d’activer ce type de flux, qui a le droit de voir les mouvements, et lesquels. Toutes les personnes qui entrent dans le CRM n’ont pas besoin de lire la banque. Les droits se règlent dans l’outil, pas dans un export envoyé par e-mail.
Google et Airtable, pour l’agenda et les bases déjà là
Google, dans ce contexte, sert surtout à relier le travail quotidien : un agenda, une boîte, parfois une feuille. Un rendez-vous commercial qui n’existe que dans une tête, ou que dans un calendrier personnel jamais partagé, n’aide pas le pipeline. Une connexion bien cadrée évite la double saisie, à condition de savoir quel calendrier fait foi, et ce que l’on a le droit d’y écrire.
Airtable, lui, apparaît quand une équipe a déjà une base qui vit : un suivi de projet, un inventaire, une liste métier que l’on ne va pas jeter du jour au lendemain. Le CRM n’a pas à tout absorber. Parfois, il doit seulement s’y relier : créer une fiche quand une ligne apparaît, mettre à jour un statut, éviter que deux outils racontent deux histoires.
Dans les deux cas, on écrit le sens du flux. Est-ce le CRM qui pousse, ou l’autre outil ? Que se passe-t-il en cas de conflit ? Qui corrige ? Une synchronisation bidirectionnelle mal définie est une source classique de doublons. Nous préférons un sens clair, même s’il paraît plus pauvre sur le papier, à un « tout se met à jour tout seul » que plus personne ne sait expliquer.
API et MCP : le même principe, d’autres portes
Le plan Pro ouvre aussi une API et un accès MCP. L’idée est la même que pour les connecteurs nommés : laisser un autre outil, ou un assistant, interroger et éventuellement mettre à jour le CRM, dans le cadre des droits accordés. Ce n’est pas une invitation à tout déléguer à un modèle de langage.
Une API sert un développement, une automatisation n8n, un script interne. Le MCP sert un assistant capable d’appeler des outils. Dans les deux cas, une clé, un périmètre, une personne responsable. L’IA, si elle intervient, prépare : un résumé d’affaires, une suggestion de relance, une recherche. La décision d’envoyer, de modifier un montant, de changer une étape sensible, reste humaine.
Nous reviendrons plus tard sur le MCP en tant que protocole. Pour le CRM, il suffit de retenir ceci : ce n’est pas un cerveau posé sur le pipeline. C’est une porte, que l’on ouvre volontairement.
La même prudence vaut pour les campagnes. Une connexion n’autorise pas à tout envoyer à toute la base parce que le bouton existe. On segmente, on relit un échantillon, on vérifie les désinscriptions et les adresses douteuses. Le pipeline et les campagnes partagent la base : c’est un avantage, à condition de respecter les personnes qui s’y trouvent, et les règles applicables aux envois.
Nous testons aussi le cas d’échec. Que se passe-t-il si Stripe ne renvoie pas l’événement, si Qonto est indisponible, si un agenda Google refuse l’écriture ? Le commercial doit encore pouvoir avancer, même à la main, le temps que le flux reparte. Un branchement qui bloque tout le métier dès qu’il tousse est mal conçu. L’automatisation s’ajoute au travail, elle ne doit pas le rendre fragile.
Enfin, chaque connexion se documente en quelques lignes : le déclencheur, la donnée échangée, le responsable, la marche à suivre en cas d’incident. Ce n’est pas de la bureaucratie. C’est ce qui permet à quelqu’un d’autre, dans six mois, de comprendre pourquoi ce flux existe encore, et s’il doit être conservé, corrigé ou retiré.
Brancher peu, brancher juste
Qonto, Stripe, Google, Airtable : quatre portes, pas une obligation d’en ouvrir quatre le même jour. On commence par le flux qui évite une ressaisie réelle, ou une erreur réelle. On documente. On relit quelques cas. Ensuite seulement, on ajoute le suivant.
Si vous vous demandez quel branchement vaut la peine dans votre équipe, nous pouvons le regarder à partir de votre pipeline, pas à partir d’un schéma universel. La page contact ou un rendez-vous suffisent pour poser le besoin.