Avec des modèles comme GPT-5.5, Claude Opus 4 ou Gemini 3.5, 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
#1. 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.
Anthropic eux-mêmes formulent le problème ainsi dans un retour d'expérience publié sur leur propre blog : brancher Claude sur un entrepôt de données sans couche intermédiaire « crée une fausse impression de précision ». Pour mesurer l'ampleur du problème, leurs équipes ont mené un test révélateur : elles ont donné à Claude un accès direct à des milliers de données historiques (dashboards, notebooks, analyses passées). Résultat : la précision n'a pas progressé.
Les données étaient là, l'agent les voyait, et il ne savait toujours pas les utiliser correctement. Ce n'est pas un problème d'accès. C'est un problème de structure. Et pour construire cette structure, leurs équipes ont dû bâtir quatre couches d'infrastructure distinctes : des fondations de données, des sources de vérité, des fichiers de contexte métier, et un système de validation multi-niveaux. C'est précisément ce qu'une CSP fournit nativement.
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.
Pour conclure sur ce point, Eleanor Dorfman, Head of Industries chez Anthropic, l'a présenté à SaaStr AI 2026 : Anthropic s'appuie sur des outils marché (Clay, LeanData, Salesforce, Gong, Ironclad, Slack) avec Claude comme couche de cohérence entre eux. Pas en remplacement. Si les créateurs de Claude estiment que ça ne vaut pas le coup de vibe-coder sa propre stack, pourquoi serait-ce différent pour vous ?
#2. 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, et le batch processing (l'équivalent du tarif heures creuses) pour les traitements qui peuvent attendre : résumés de comptes, scoring nocturne, génération de rapports. Les API proposent des remises allant jusqu'à 50 % en échange d'un traitement différé. Sur des volumes significatifs, l'économie est substantielle. Mais pour en tirer parti, il faut avoir conçu dès le départ une architecture qui distingue ce qui est urgent de ce qui peut attendre. C'est une optimisation que les plateformes CS gèrent nativement ; en build interne, c'est une couche d'architecture supplémentaire à concevoir, tester et maintenir. 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.
#3. 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.
Il y a une raison supplémentaire pour laquelle ce défi est plus complexe en Customer Success qu'ailleurs. Les données sales s'alignent naturellement sur un pipeline : chaque deal a une étape, une valeur, une date de closing. Les données CS sont ambiguës par nature : signaux d'usage produit, volume de tickets, sentiment des échanges, tendances NPS, potentiel d'expansion : toutes pointant dans des directions différentes, aucune ne racontant une histoire lisible seule. Construire une IA qui tire des conclusions fiables à partir de cette complexité n'est pas chose aisée.
#4. 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 a son IA, son modèle ou son Agent dédié. Le LLM n'est pas la meilleure réponse à tous les besoins.
Le chiffre est éloquent : dans leur propre retour d'expérience, les équipes d'Anthropic mesurent qu'en l'absence de contexte métier structuré, Claude ne dépasse pas 21 % de réponses correctes sur leurs évaluations analytiques. Avec une couche de contexte bien construite, ils atteignent 95 % (et même 99 % sur certains domaines). Ce delta n'est pas une question de modèle. C'est une question de fondation.
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.
#5. Collaborer autour d'un compte : l'angle mort du LLM
Le Customer Success n'est pas un sport individuel. Un CSM partage un plan d'action avec son manager, commente un risque de churn avec l'équipe commerciale, assigne une tâche à un collègue avant un renouvellement, documente un projet d'expansion pour qu'il soit repris si le portefeuille change de main. Toute cette dimension collaborative est invisible dans un setup LLM.
Un agent peut générer une recommandation. Il ne crée pas un espace partagé où l'équipe travaille ensemble autour d'un compte, suit l'avancement d'un projet, consulte l'historique des échanges ou reprend un dossier là où quelqu'un d'autre l'a laissé. Ce travail-là finit dans des e-mails, des fils Slack, des Google Docs éparpillés : exactement ce qu'une plateforme CS est censée remplacer.
Une CSP centralise naturellement cette couche collaborative : tâches assignées, commentaires contextualisés sur un compte, projets de renouvellement ou d'expansion partagés entre interlocuteurs, documents attachés à l'historique client. Rien à brancher, rien à synchroniser. L'information existe là où le travail se fait, visible par toute l'équipe, dans le bon contexte.
#6. De l'analyse à l'action : le chaînon manquant
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.
Un setup Claude bien pensé peut générer des résumés, des analyses, voire des plans d'action. Et il faut être honnête : avec les agents IA, la barrière du passage à l'action commence à tomber. Un agent peut aujourd'hui surveiller un flux de données, détecter un signal, et déclencher une action sans intervention humaine. Mais c'est précisément là que la question devient sérieuse.
Un agent autonome qui agit sur des données client (qui envoie un e-mail, qui escalade un compte, qui modifie un statut) ne peut pas se permettre d'halluciner, de varier dans ses réponses, ou de prendre une décision non traçable. Plus l'IA prend de l'initiative, plus les exigences sur la fondation en dessous deviennent critiques : fiabilité des données en entrée, règles métier explicites, traçabilité des décisions, capacité à auditer ce qui s'est passé et pourquoi.
Un agent branché sur un CRM sans modèle de données structuré, sans logique métier encodée, sans historique fiable, c'est de l'autonomie construite sur du sable. Ce n'est pas l'agent le problème, c'est ce qu'il y a en dessous. Et c'est exactement ce que fournit une CSP.
#7. Quand l'imprévisible vous empêche de travailler
À cela s'ajoute une question d'infrastructure souvent négligée : que se passe-t-il quand le fournisseur d'IA est indisponible ? Les APIs connaissent des incidents : Claude, GPT, Gemini, aucun n'est à l'abri d'une panne ou d'une dégradation de service.
Le circuit breaker est le mécanisme qui permet, en cas d'indisponibilité du modèle par défaut, de basculer automatiquement vers un modèle de secours.
Sans lui, un build entièrement fondé sur une seule API s'arrête quand cette API s'arrête. Une CSP qui gère ce basculement multi-fournisseurs nativement garantit une continuité de service que peu d'équipes pensent à anticiper, jusqu'au jour où elles en ont besoin.
#8. 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 ? Un CSM ne devrait pas pouvoir interroger le modèle sur des comptes qui ne lui appartiennent pas (row-level security).
- Données personnelles, informations clients confidentielles, mots de passe... Que transmet-on exactement au modèle ?
- Est-ce que mes données (parfois confidentielles) servent à entraîner les modèles ?
- Mes données sont-elles hébergées en zone européenne ?
- Quelle version du prompt a généré quelle décision, quand, sur quelles données ?
- Finalement, est-ce que tout cela est en conformité avec la réglementation RGPD ?
Les plus avisés répondront : "on peut faire tourner un modèle en local, sans rien envoyer à personne." C'est vrai. Les modèles open source progressent vite, et un déploiement sur serveur interne règle effectivement une partie des problèmes de conformité.
Mais cette solution a ses propres contraintes, qu'il vaut mieux avoir en tête avant de s'y engager. Les modèles locaux travaillent en vase clos : pas d'enrichissement avec des données externes, pas de signaux frais sur la santé d'un compte client, pas d'actualités société, pas d'informations issues de sources tierces. La qualité des modèles open source sur des tâches métier complexes reste en retrait par rapport aux modèles de premier rang. Et en mode équipe, la charge infrastructure est réelle : un serveur dédié, maintenu, dimensionné pour des requêtes concurrentes, ce n'est pas un coût marginal.
C'est un choix valide pour certaines organisations. Mais il déplace le problème plutôt qu'il ne le résout : on gagne en souveraineté des données, on perd en fraîcheur, en qualité et en richesse contextuelle. Une CSP hébergée en Europe, avec anonymisation des données avant envoi, absence d'entraînement sur vos données, chiffrement des échanges et traçabilité complète des traitements, offre un équilibre que peu d'équipes parviennent à reproduire en interne, sans y passer des mois.
#9. 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
L'équipe data d'Anthropic en a fait l'expérience directement : leur précision est passée de 95 % au lancement à 65 % en l'espace d'un mois, avant qu'ils ne traitent la maintenance du contexte métier comme un vrai problème d'ingénierie à part entière. Si cela arrive chez le créateur du modèle, avec une équipe dédiée, la question mérite d'être posée pour toute équipe CS qui envisage un build interne.
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.
#10. 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.
Bonus : quand le builder part
Il y a un risque que les discussions sur le build interne évacuent systématiquement : que se passe-t-il quand la personne qui a tout construit part ?
Le CSM ou le RevOps qui a vibe codé la solution connaît chaque prompt, chaque connexion, chaque bidouille qui fait tenir l'ensemble. Si cette personne quitte l'équipe, l'outil ne disparaît pas, mais la connaissance pour le maintenir, si.
Avec une CSP, quand quelque chose ne fonctionne pas, on ouvre un ticket. Avec un build interne, on espère que la documentation est à jour et que la personne qui sait est encore joignable.
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-5.5 ou Claude Opus 4, 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 :
