Scraping Planity : comment reprendre le contrôle sur ses données business

Planity, c’est un très bon outil. Le client l’ouvre tous les jours. Il voit ses rendez-vous, ses collabs, ses centres, une partie du chiffre.

Et pourtant, dès qu’il veut vraiment piloter (croiser avec le CRM, historiser, comparer trois locaux, caler un budget Ads), ça bloque.

Voir une donnée dans Planity, ce n’est pas la posséder.

Voici comment j’ai monté un pipeline pour un multi-centres beauty / bien-être à Paris. Pas un export one-shot. Un truc qui tourne.

Le brief, sans jargon

Le client a plusieurs centres. Planity gère l’opérationnel. Il lui manquait deux choses.

D’abord, récupérer les leads (surtout les sessions découverte) et les envoyer proprement dans le CRM, sans copier-coller. Chez lui c’était Go High Level.

Ensuite, piloter le business : CA, LTV, occupation, no-show, perf collabs. En vue globale et par local. Avec un historique.

L’export CSV manuel ? Ça marche une fois. Au bout de deux semaines, plus personne ne le fait. Pour piloter, il ne faut pas un fichier. Il faut un flux.

Côté éditeur : pas d’API ouverte utile pour ce besoin. Une API privée a été évoquée. En pratique, trop lent pour un business qui doit avancer maintenant.

Comment on en est arrivés là

Je ne suis pas arrivé un jour avec « je vais scraper Planity » en tête.

Au départ, je bossais déjà pour ce client sur du scraping divers : d’autres plateformes, d’autres extractions, des besoins ponctuels. La relation s’est construite comme ça. Confiance, itérations, livraisons qui servent.

Progressivement, le vrai trou s’est clarifié : Planity, tous les jours, mais aucune façon propre de sortir la data pour le CRM et le pilotage multi-centres. Le scraper RDV est venu en premier. Puis les métriques. Puis le dashboard. Chaque couche parce que la précédente tenait.

C’est souvent comme ça en freelance scraping. Tu ne vends pas un produit. Tu suis le besoin jusqu’à ce qu’il devienne un système.

Ce que j’ai construit

Deux actors Apify. Chacun un job.

1) Leads et sessions vers le CRM

Le Planity Client Scraper regarde les rendez-vous à venir sur plusieurs centres. Il détecte le new / modified / deleted, enrichit, et pousse vers :

les webhooks CRM (GHL par défaut, extensible HubSpot / Pipedrive)
Google Sheets pour l’historique
le dataset Apify

Anti-doublons inclus. Personne ne veut le même lead trois fois.

Sur le Store, cet actor reste niche (auth + marché FR). Normal. Sa vraie valeur, c’est le pipeline client, pas le ranking Apify.

2) Métriques business vers un dashboard

Un second actor, privé : planity-business-metrics-scraper. Il alimente les indicateurs. Pas besoin qu’il soit public. C’est de l’infra métier.

Au-dessus : un dashboard (login, filtres centre / période, synchro Apify). Les screens ci-dessous sont anonymisés. On montre l’UI et le système, pas le P&L du client.

Vue d’ensemble, tous les centres. La pill « Données à jour (API) » et le rappel de synchro Apify sont dans la sidebar. Ce n’est plus un export oublié dans un Drive.

Côté clients (base, actifs, LTV, CAC max pour un ROAS cible) :

Il y a aussi occupation par local et perf collaborateurs. Même logique : une source, plusieurs vues, historique.

Ce que ça change concrètement

Quatre gains. Pas vingt.

Un historique indépendant de l’UI Planity
Une seule vérité multi-centres (global ou local, même source)
Des leads qui arrivent dans le CRM (new / mod / cancel)
Des décisions plus nettes sur le staffing, les créneaux, l’acquisition

En clair : la base (Sheets au départ, option base ensuite) devient la couche de propriété entre l’outil métier et le pilotage.

Ça marche vraiment

Le client est récurrent. On n’a pas livré un script et disparu. D’abord d’autres scrapers, puis le scraper RDV Planity, puis les métriques et le dashboard. Il revient parce que ça sert.

L’UI est utilisée. Personne ne pilote longtemps dans un CSV de 40 colonnes. Le dashboard, oui.

Et le flux leads vers CRM tient dans la durée. Ce n’est pas un dump. C’est de la détection de changements.

Les imperfections, honnêtement

Ce n’est pas magique.

Les sources Planity ne sont pas toujours aussi propres qu’on le voudrait. Parfois on arbitre le calcul d’un indicateur. L’auth et le front évoluent, donc il faut maintenir. Et un actor authentifié FR ne va pas exploser sur le Store comme un Airbnb scraper.

Le client est satisfait malgré ça. Pas parce que c’est parfait. Parce que ça tourne, et que ça décide mieux qu’avant.

Planity a réagi en mode « hold on »

Quand la data sort du silo, l’éditeur n’est pas toujours fan.

Dans ce dossier, Planity a contacté le client. Call direct, en mode : on voit que vous utilisez un scraper.

Ils ont tenté la conciliation. Proposition de détailler le besoin, puis de basculer sur leur solution in-house (API privée / outil interne). Sur le papier, ça peut sonner rassurant. En pratique, le client n’était pas convaincu : trop lent, trop flou sur le timing, pas au niveau de ce qu’il avait déjà en production avec le pipeline + dashboard.

Haut niveau : on travaille avec le compte du client, sur ses centres, pour son usage métier. L’objectif n’est pas de piller Planity. C’est de rendre le client autonome sur une data qu’il génère déjà.

Ils protègent leur silo. Mon job, c’est de rendre le client propriétaire de son pilotage.

Ce frottement, pour moi, confirme le besoin. Si tout était ouvert et branchable, cette mission n’existerait pas.

Ce que je ne fais pas ici

Je ne scrappe pas la concurrence à l’aveugle dans ce setup. C’est le compte client.

Je ne promets pas zéro maintenance. Si Planity change l’écran, on adapte.

Et je ne vends pas le Store comme le succès principal de ce dossier. La valeur, c’est le pipeline plus le dashboard.

Ce que je retiens

Planity reste utile. Mais un outil métier n’est pas un système de pilotage.

Dès que tu as plusieurs locaux, un CRM, de la pub, une équipe à arbitrer, tu as besoin d’une couche au-dessus : extraction régulière, stockage, UI.

Et souvent, ça ne démarre pas par un grand projet nommé. Ça démarre par une relation de scraping, mission après mission, jusqu’à ce que le vrai système apparaisse.

C’est exactement ce genre de mission que je prends en freelance : reconnecter un outil fermé à l’écosystème du client. Avec des aspérités. Et un client qui continue.

Pour aller plus loin

Si tu es dans le même cas (outil métier où tu vois tout, mais tu ne peux rien sortir proprement), on peut regarder ensemble si un connecteur a du sens. 20 min ici.

Sinon, dans le même fil :

L’actor public : Planity Client Scraper
Actor vs presta : Du script freelance à l’API
Les chiffres Apify : bilan après 8 mois
Le parcours plateformes : Malt et Fiverr après 3 ans