Avec des modèles comme GPT-4o, Claude 3.5 ou leurs successeurs récents (GPT-5.x, Claude 4.x, Gemini 3), il est désormais possible de connecter un LLM à ses données clients, d’analyser des tickets support, de résumer des comptes ou de générer des recommandations en quelques lignes de code. Mais attention à ne pas confondre capacité d’analyse et capacité opérationnelle.
"Brancher Claude sur HubSpot" est devenu l'affaire d'un week-end. Les LLM sont de plus en plus performants, les API de plus en plus accessibles, les résultats parfois bluffants, notamment sur l'exploitation de données non structurées comme les tickets ou les transcriptions d'appels. Dans ce contexte, une question s'impose naturellement dans les équipes : est-ce qu'investir dans une Customer Success Platform est justifié, ou est-ce qu'un bon setup LLM suffit ?
C'est une question légitime. Et pour y répondre honnêtement, il faut comprendre ce que les LLM font bien, ce qu'ils ne font pas, et ce que les équipes qui ont tenté l'expérience ont appris à leurs dépens.
Ce que les équipes sous-estiment systématiquement
Un LLM n'est pas un système, c'est une couche d'interprétation
C'est le malentendu fondamental. Un LLM lit, analyse, génère. Mais il ne structure pas nativement des données, ne garantit pas leur qualité, et ne maintient pas d'état fiable dans le temps.
Claude ne comprend pas naturellement ce que signifient vos données. Il faut lui expliquer chaque champ, chaque métrique : que signifie ce champ ? est-ce qu'il faut l'interpréter positivement s'il augmente ou s'il baisse ? Une Customer Success Platform embarque nativement ces informations dans des bases de données structurées et explicites : le modèle comprend déjà comment associer la bonne donnée au bon contexte et l'interpréter correctement.
C’est cette fondation qui permet de transformer des données en décisions fiables. Sans elle, un LLM reste une couche d’interprétation puissante, mais instable.
Le mythe du "LLM moins cher"
L'API Claude à 3$ le million de tokens a l'air imbattable sur le papier. Cela donne l’impression qu’il suffit de brancher une API pour remplacer un logiciel entier.
En pratique, ce coût ne représente qu’une fraction du problème. Ce qu'un éditeur SaaS absorbe et qu'un client devra reconstruire de zéro :
- Le prompt engineering et son évolution continue (un bon prompt Customer Success, c'est des semaines d'itération)
- Le routing entre modèles selon la tâche (par exemple utiliser Sonnet pour la majorité des cas, Opus pour les analyses critiques, un Agent IA spécifique pour une tâche précise). Les modèles actuels varient entre 0,25$ et 15$ le million de tokens. Un rapport de 1 à 60x ! Autant dire que choisir le bon modèle par rapport à l'usage voulu n'est pas une coquetterie.
- Le prompt caching pour éviter de payer plusieurs fois la même requête, le batch API pour ce qui peut attendre. Sans optimisation, la facture peut être 5 à 10× ce qu'elle devrait
- La gestion des erreurs, rate limits, retries et fallbacks
- Les évaluations : comment savoir que la v2 du prompt est meilleure que la v1 ?
Le prix d'une plateforme inclut l'optimisation continue des coûts d'inférence. En branchant l'API directement, on paye au prix catalogue et on découvre la facture à la fin du mois.
À cela s’ajoute un coût souvent sous-estimé : le temps humain. Construire un bon prompt de Customer Success, le tester sur des milliers de cas, mesurer sa qualité, l’améliorer… cela prend des semaines, parfois des mois.
Ce que vous payez dans une plateforme, ce n’est pas seulement l’accès à un modèle. C’est l’optimisation continue de son usage.
Le piège du CRM comme source unique de vérité
Un des raccourcis les plus fréquents consiste à connecter un LLM uniquement au CRM. C’est un bon point de départ, mais une mauvaise stratégie à long terme.
Le signal Customer Success ne vit pas dans un seul outil. Il est fragmenté entre le CRM, le ticketing (Zendesk, Intercom), les données produit (Segment, Mixpanel), les appels (Gong, Fathom), les conversations internes, la facturation.
Brancher Claude sur son CRM, c'est un premier pas, pas une vision complète. Pour que cela ait vraiment du sens, il faut connecter le CRM, le ticketing, un data warehouse ou un analytics produit, et l'outil de facturation. Dans une Customer Success Platform, ces intégrations sont natives, souvent en quelques clics. En autonome, ce sont cinq intégrations supplémentaires à écrire, maintenir, et réconcilier dans le temps.
Le LLM ne sait rien de votre métier
Un CRM + Claude nu, c'est un LLM qui ignore tout du Customer Success. Une plateforme comme Skalin embarque des modèles qui analysent en temps réel les conversations, des modèles de forecasting pour prédire l'usage futur, des modèles prédictifs de churn, des prompts prêts à l'emploi calibrés selon des besoins précis. La différence : "Claude résume un échange" vs. "Skalin détecte qu'un compte entre en zone rouge parce que la fréquence d'usage baisse et que le sentiment des derniers échanges se dégrade". Chaque fonction à son IA, son modèle ou son Agent dédié. Le LLM n'est pas la meilleure réponse à tous les besoins.
Avec une Customer Success Platform les contextes sont enrichis pour permettre à l'IA de prendre les bonnes décisions : domaine d'activité, tiering, taille du portefeuille client, etc. Une IA qui génère un plan d'action sans connaître la taille du portefeuille du CSM calibre nécessairement mal sa réponse et le niveau d'effort associé.
Enfin, une Customer Success Platform bien pensée c'est aussi des templates de Playbooks, des alertes pré-paramétrées, des reportings actifs dès le premier jour. Un client qui bricole son intégration met six à douze mois à recréer ça. Et encore, s'il a l'équipe pour.
De l'analyse à l'action : le chaînon manquant
Un setup Claude bien pensé peut générer des résumés, des analyses, voire des plans d'action. Mais il ne déclenche pas d'alertes automatiques. Il n'active pas des playbooks. Il n'envoie pas les bons e-mails. Il ne centralise pas les informations sur un outil unique : c'est une couche supplémentaire dans une stack d'outils qui grandit.
La différence fondamentale : un LLM fonctionne quand quelqu'un pose une question. Une CSP fonctionne même quand personne ne regarde : monitoring continu, alertes automatiques, triggers. Sans ça, vous risquez de passer à côté de signaux critiques.
Gouvernance, sécurité et conformité : le mur invisible
Les questions qui s'accumulent dès qu'une DSI ou un DPO s'implique :
- Qui a accès à quel contexte client ? (row-level security sur les données passées au LLM)
- Données personnelles, information client confidentielles, mots de passe... Que transmet-on exactement au modèle ?
- Les données sont-elles stockées ou réutilisées ?
- Mes données sont-elles hébergées en zone européenne ?
- Est-ce que mes données client (parfois confidentielles) servent à entraîner les modèles ?
- Finalement, est-ce que tout cela est en conformité avec la réglementation RGPD ?
Ces problèmes ont une solution, mais chacun prend du temps et de l'expertise à résoudre correctement. C'est souvent là que le projet de build interne s'arrête.
Les plateformes comme Skalin intègrent ces enjeux de sécurité dès la conception :
- Les données sont minimisées et anonymisées, aucune information sensible n’est exposée inutilement, et elles ne sont jamais utilisées pour entraîner les modèles.
- L’ensemble des traitements est réalisé dans un environnement sécurisé, localisé en Europe, sans transfert vers des infrastructures externes.
- Les échanges sont chiffrés, les accès sont strictement contrôlés, et chaque action est tracée pour garantir auditabilité et conformité RGPD.
Autrement dit, la sécurité et la gouvernance ne sont pas ajoutées a posteriori, elles sont intégrées nativement dans l’architecture du produit.
Une dette technique liée à l’évolution des modèles
Claude Opus 4 aujourd'hui, une nouvelle version dans six mois, une autre l'an prochain. Les modèles changent littéralement tous les 3 à 6 mois. Chaque migration peut casser des prompts finement calibrés.
Chaque changement de modèle implique :
- des ajustements
- des tests
- des recalibrages
Dans une approche interne, cette dette est entièrement à la charge de l’équipe. Un éditeur SaaS absorbe cette dette en continu. Un client qui a construit son intégration en interne la subit à chaque évolution - y compris les changements tarifaires, dont on a vu un exemple concret en avril dernier.
Time-to-value : un facteur souvent décisif
Il y a un écart important entre un prototype fonctionnel et un outil réellement utilisable par une équipe Customer Success. Un POC peut être livré en quelques semaines. Un système robuste, adopté et intégré aux processus prend souvent plusieurs mois.
Pour un VP Customer Success, cet écart est critique. Une plateforme permet d’être opérationnel rapidement, là où une approche interne retarde la création de valeur. Pour un VP Customer Success qui doit montrer des résultats sur le trimestre, ce n'est pas un détail.
Moins de licence, plus d'ingénierie
Remplacer une Customer Success Platform ne supprime pas la complexité. Cela la déplace. Il faut reconstruire des pipelines de données, des modèles de segmentation, de la logique métier, de l'orchestration. Résultat : moins de coûts visibles, mais plus d'ingénierie. Et une dette technique croissante.
Des analyses brillantes, une exécution chaotique
Les équipes ont aussi besoin d'un cadre, pas seulement d'intelligence. Un LLM donne des réponses. Une Customer Success Platform apporte :
- des processus
- des standards
- des rituels
- une organisation
Sans ça, on peut se retrouver avec des analyses brillantes et une exécution chaotique. Le risque est de produire des analyses pertinentes… sans capacité à les transformer en exécution cohérente à l’échelle.
Pourquoi une Customer Success Platform reste le meilleur choix
La vraie évolution, ce n'est pas choisir entre une CSP et un LLM. C'est une CSP qui tire parti des LLM pour combiner ce qu'aucun des deux ne peut offrir seul : la structure des données, la capacité d'action, et la souplesse de l'analyse. La puissance d’analyse des modèles comme GPT-4o ou Claude 3.5 Sonnet, et la robustesse d’un système conçu pour le Customer Success.
Une plateforme CS moderne permet d'interroger vos données, de générer des actions, de déclencher des workflows, sans naviguer entre cinq outils. Elle interprète les signaux faibles, croise des données hétérogènes, adapte l'analyse en temps réel - et le fait de manière fiable, traçable, conforme, même quand personne ne regarde. Le LLM est devenu une commodité. Ce qui a de la valeur, c'est tout ce qu'il y a autour.
Construire une CSP via LLM est techniquement possible. Mais il faut avoir les reins solides, des équipes dédiées, et ne pas être pressé. Pour la grande majorité des équipes Customer Success, le rapport effort/résultat ne tient pas face à une plateforme prête à l'emploi, intégrée, et en amélioration continue.
Dans la majorité des cas, les entreprises ne cherchent pas à construire une plateforme.
Elles cherchent à améliorer leur Customer Success. Et c'est là tout l'enjeu.
Pour aller plus loin :
