LLM, Agent, MCP, Skill… L'IA s'invite dans chaque outil Customer Success — du CRM au helpdesk en passant par les Customer Success Platform. Pour prendre les bonnes décisions, évaluer les options et parler d'égal à égal avec vos équipes produit & tech, vous avez besoin de maîtriser le vocabulaire. Voici le guide de survie du CSM à l'ère de l'IA !
1. LLM — Large Language Model
Un LLM est un modèle d'IA entraîné sur des milliards de textes pour comprendre et générer du langage naturel. C'est le moteur qui propulse des outils comme Claude, ChatGPT ou Gemini. Il ne "pense" pas au sens humain : il prédit statistiquement les mots les plus pertinents en réponse à une entrée.
Exemple CS : une Customer Success Platform comme Skalin intègre un LLM qui synthétise la situation d'un client selon différents signaux et est capable de produire un plan d'action ou le plan de votre prochaine Business Review. Ce qui prenait 30 minutes de préparation avant chaque appel se lit en 30 secondes.
2. Token
Un token est l'unité de base que le LLM utilise pour lire et produire du texte. Ce n'est ni un caractère ni un mot : en français, un token correspond environ à ¾ d'un mot. "Bonjour" est 1 token, "réengagement" en vaut 3. Les coûts d'usage des API IA sont facturés en tokens, et la taille de la context window est exprimée en tokens.
Exemple CS : Vous utilisez une API LLM pour générer automatiquement un compte-rendu structuré après chaque QBR. Une heure d'échanges retranscrite représente environ 8 000 tokens. Multiplié par 50 comptes stratégiques par trimestre, vous pouvez estimer précisément le coût de cette automatisation avant de la déployer.
💡 En pratique : 1 000 tokens ≈ 750 mots ≈ environ 1,5 page Word. Gardez ce repère en tête pour dimensionner vos prompts et vos budgets.
3. Prompt
Un prompt est l'instruction que vous donnez à un LLM pour obtenir une réponse. La qualité du prompt détermine directement la qualité de la réponse. L'art de rédiger des prompts efficaces s'appelle le prompt engineering — une vraie compétence métier, pas réservée aux développeurs.
Exemple CS : Plutôt que d'écrire "analyse ce compte", un CS Manager bien formé écrit : "Tu es un expert CS SaaS B2B. À partir de ces données d'usage et de cet historique de relation, identifie les 3 principaux risques de churn et propose une action concrète pour chacun. Sois factuel et concis." Le résultat est immédiatement exploitable en préparation d'appel.
💡 Un bon prompt comprend : un rôle ("tu es…"), un contexte, une tâche précise et un format de sortie attendu. Plus c'est structuré, plus l'output est fiable.
4. Température
La température est un paramètre qui contrôle le degré de créativité (ou d'aléatoire) dans les réponses d'un LLM. Elle varie généralement de 0 à 1. À 0, le modèle est déterministe et factuel. À 1, il est plus inventif, varié — et potentiellement moins fiable.
Exemple CS : Pour générer des rapports de santé client ou des synthèses de QBR, vous réglez la température à 0 : vous voulez de la précision, pas de la fantaisie. Pour rédiger des messages de réengagement personnalisés ou des plans d'action onboarding adaptés au profil de chaque compte, une température plus élevée produit des formulations plus variées et moins mécaniques.
5. Context Window — Fenêtre de contexte
La context window est la quantité maximale de texte qu'un LLM peut "voir" et traiter en une seule fois : votre prompt, l'historique de conversation, les documents fournis, et sa réponse. Elle se mesure en tokens. Plus elle est grande, plus l'IA peut analyser de données en une seule passe.
Exemple CS : Avec une large context window (200 000 tokens ≈ 150 000 mots), vous pouvez analyser l'historique des échanges avec un client sur 12 mois et demander : "Quels sont les 3 signaux d'alerte que nous aurions dû détecter avant ce churn ?"
6. Embeddings
Un embedding est une représentation mathématique d'un texte sous forme de vecteur numérique (une liste de chiffres). Ce vecteur capture le sens du texte, pas seulement ses mots. Deux phrases proches sémantiquement auront des vecteurs proches — même si elles n'ont pas un mot en commun.
Exemple CS : Votre système transforme en embeddings l'ensemble des notes de compte, comptes-rendus d'appels et plans de succès de vos CSMs. Quand un nouveau CSM reprend un portefeuille, il peut poser une question en langage naturel (ex. "quelles sont les demandes en attente pour ce client") et obtenir instantanément les passages les plus pertinents, même s'ils n'utilisent pas exactement les mêmes mots. C'est la mécanique au cœur du RAG.
💡 Les embeddings sont ce qui rend la recherche sémantique possible : votre outil retrouve l'info pertinente, pas seulement celle qui contient les mêmes mots-clés.
7. Vector Database — Base de données vectorielle
Une vector database est une base de données conçue pour stocker et rechercher des embeddings. Contrairement à une base SQL classique (qui cherche des correspondances exactes), elle retrouve les entrées les plus proches sémantiquement d'une requête. Les solutions courantes : Pinecone, Weaviate, pgvector.
Exemple CS : Vous indexez l'ensemble de vos notes de compte Salesforce, vos transcriptions d'appels et vos emails clients dans une vector database. Quand un CSM prépare un appel, il pose une question en langage naturel — "quels problèmes d'intégration ce compte a-t-il eus ?" — et le système retrouve instantanément les passages pertinents dans des centaines de documents.
8. RAG — Retrieval-Augmented Generation
Le RAG est une technique qui combine une vector database et un LLM : on commence par récupérer les informations pertinentes depuis vos données internes (via embeddings), puis on les injecte dans le contexte du LLM pour qu'il génère une réponse ancrée dans vos données à jour — et non dans ses seules connaissances d'entraînement.
Exemple CS : Un CSM prépare un appel de renouvellement. Il interroge le système en langage naturel : "quels sont les engagements pris lors du dernier QBR et ont-ils été tenus ?" Le RAG récupère les passages pertinents dans les notes de réunion, les emails et le Success Plan, puis le LLM synthétise une réponse claire. Le CSM arrive à l'appel informé en 2 minutes plutôt qu'après 30 minutes de recherche manuelle.
9. Agent IA
Un agent IA est un LLM capable d'agir, pas seulement de répondre. Il peut planifier une séquence d'actions, utiliser des outils (recherche web, écriture de fichiers, appels API) et itérer jusqu'à atteindre un objectif, sans intervention humaine à chaque étape.
Exemple CS : Un agent CS surveille les comptes à risque de churn : il analyse les données d'usage dans votre CRM, détecte une baisse d'activation, rédige un email personnalisé de réengagement, et crée une tâche de suivi dans votre outil de gestion — tout cela sans intervention manuelle.
10. Tool — Outil
Un tool est une fonction spécifique qu'un agent IA peut appeler pour interagir avec le monde extérieur : faire une recherche web, envoyer un email, lire un fichier, interroger une base de données. Les tools transforment un LLM passif en acteur capable de déclencher des actions réelles.
Exemple CS : Votre agent de préparation QBR dispose de 3 tools : get_account_data() (Salesforce), get_usage_metrics() (votre produit), et create_slide() (Google Slides). En une commande, il génère un deck de business review pré-rempli pour chaque compte stratégique.
11. Skill
Dans le contexte IA, une skill est un module prédéfini qui donne à un agent la capacité d'accomplir une tâche spécifique : rédiger un email, analyser un PDF, appeler une API, créer un fichier Excel… C'est une brique fonctionnelle réutilisable qu'on "branche" sur un agent.
Comment crée-t-on une skill ? Une skill se présente sous la forme d'un fichier texte (souvent un SKILL.md) qui contient deux éléments : une description (qui dit à l'agent quand utiliser cette skill) et des instructions (qui lui disent comment l'exécuter). On peut y joindre des ressources complémentaires : des scripts à exécuter, des fichiers de référence à consulter, des templates à utiliser. On rédige une première version de la skill, on la teste sur des cas concrets, on évalue les résultats puis on itère jusqu'à ce que le comportement soit fiable et partageable à l'équipe.
Exemple CS : Votre agent CS dispose d'une skill "Analyse NPS" : il lit les réponses brutes à votre dernière enquête, identifie les thèmes récurrents parmi les détracteurs et produit un rapport structuré avec recommandations — sans qu'un analyste passe 4h sur Excel.
12. MCP — Model Context Protocol
Le MCP est un standard ouvert (créé par Anthropic) qui définit comment un LLM peut se connecter à des outils et sources de données externes de manière sécurisée et standardisée. C'est en quelque sorte l'USB de l'IA : une interface universelle pour brancher des services sur un modèle, sans développement ad hoc pour chaque intégration.
Exemple CS : Une Customer Success Platform compatible MCP permet à Claude de se connecter directement à vos données de compte : consulter le score de santé en temps réel, lire le plan de succès, mettre à jour les objectifs après un appel et déclencher une alerte vers le bon CSM. Le MCP évite de re-développer une intégration spécifique pour chaque outil de votre stack.
MCP ou CLI : lequel choisir ?
MCP est fait pour les workflows interactifs et continus : un utilisateur ou un agent dialogue avec plusieurs outils en temps réel, au fil d'une conversation. C'est fluide, mais chaque aller-retour avec un outil consomme des tokens, ce qui peut devenir coûteux à grande échelle.
💡 Choisissez MCP quand : un CSM interagit en langage naturel avec ses données au quotidien, quand le workflow est conversationnel, ou quand plusieurs outils doivent être orchestrés à la volée.
13. CLI — Command Line Interface
Un CLI est une interface textuelle où l'on tape des commandes pour interagir avec un logiciel, sans interface graphique. Des outils comme Claude Code s'utilisent via CLI. Pour un Customer Success Manager, le comprendre c'est saisir pourquoi certains workflows IA puissants (notamment les plus répétitifs et volumétriques) passent par un terminal plutôt que par une interface cliquable.
Exemple CS : Un CS Ops utilise Claude Code en CLI pour générer automatiquement chaque mois les 80 rapports de santé client au format standardisé de l'entreprise, à partir des données exportées de la Customer Success Platform. La commande tourne la nuit, les rapports sont prêts le matin, sans aucune consommation d'interface interactive, donc à un coût en tokens très faible.
CLI ou MCP : lequel choisir ?
CLI est fait pour les traitements batch, répétitifs et non interactifs : on lance un script, il tourne, il produit un résultat. Pas d'aller-retour conversationnel, pas de tokens gaspillés en contexte d'échange. C'est plus économique à grande échelle et plus facile à planifier (cron jobs, pipelines automatisés).
💡 Choisissez CLI quand : vous traitez un volume élevé de données de façon régulière et prévisible (ex. génération mensuelle de rapports, scoring batch de 500 comptes, extraction et transformation de données), quand le coût par token est un critère, ou quand vous voulez intégrer l'IA dans une chaîne d'automatisation existante sans interface humaine.
En résumé : MCP pour le temps réel et l'interaction, CLI pour le volume et l'automatisation.
14. Orchestration
L'orchestration est la capacité à coordonner plusieurs agents IA spécialisés pour accomplir un objectif complexe. Un agent "chef d'orchestre" décompose une tâche, délègue à des sous-agents et consolide les résultats. C'est l'architecture des systèmes IA les plus puissants du moment.
Exemple CS : Pour préparer votre Business Review, un orchestrateur déclenche simultanément : un agent Data (analyse les KPIs), un agent Risques (détecte les signaux churn), un agent Opportunités (identifie les potentiels d'upsell). Il compile les résultats en un rapport cohérent en moins de 2 minutes.
15. Niveau d'autonomie — Level of Automation
Le niveau d'autonomie décrit jusqu'où un système IA peut agir sans validation humaine. On distingue généralement trois paliers : suggérer (l'humain décide), exécuter avec confirmation (l'humain approuve avant l'action), et exécuter en autonomie complète (l'agent agit seul, l'humain ne voit que le résultat). Plus le niveau est élevé, plus les bénéfices (et les risques) sont importants.
Exemple CS : Niveau 1 — l'IA suggère un plan d'action de renouvellement, le CSM l'adapte et l'envoie. Niveau 2 — l'IA envoie automatiquement des séquences d'onboarding aux nouveaux comptes SMB, le CSM intervient uniquement sur les comptes qui n'activent pas. Niveau 3 — l'IA pilote entièrement le suivi des comptes low-touch sous un certain ARR, sans intervention humaine sauf escalade explicite. Chaque niveau nécessite une maturité opérationnelle et une confiance dans le modèle différentes.
💡 La bonne question n'est pas "jusqu'où peut-on automatiser ?" mais "quel est le coût d'une erreur à ce niveau ?"
16. Human-in-the-loop
Le human-in-the-loop (HITL) est un principe de conception qui maintient un humain dans la boucle de décision d'un système IA, à des points stratégiques du workflow. L'IA traite, propose ou agit — mais certaines décisions restent soumises à validation humaine avant d'être exécutées.
Exemple CS : Votre agent de détection churn identifie un compte à risque et rédige un email de réengagement. Avant envoi, une notification est envoyée au CSM responsable : il peut approuver, modifier ou bloquer. L'IA gagne en vélocité, l'humain conserve la maîtrise des décisions à fort impact relationnel.
17. Guardrails — Garde-fous
Les guardrails sont des règles ou filtres appliqués autour d'un LLM pour encadrer ses réponses : interdire certains sujets, forcer un format de sortie, empêcher la divulgation d'informations sensibles ou bloquer les réponses hors périmètre. Ils s'ajoutent au niveau du prompt, du système ou d'une couche applicative distincte.
Exemple CS : Votre agent IA de préparation de renouvellement est configuré avec des guardrails qui lui interdisent de formuler des engagements contractuels, de mentionner des remises non validées par le management, ou de commenter les failles produit de façon non contrôlée. Si le modèle tente de générer un argument commercial non approuvé, le guardrail bloque la réponse et redirige vers un message neutre. Résultat : l'IA reste un levier d'efficacité, pas un risque juridique ou commercial.
18. Hallucination
On parle d'hallucination quand un LLM génère une information fausse présentée avec assurance, comme si elle était vraie. Ce n'est pas un "bug" au sens traditionnel, c'est une limite structurelle : le modèle optimise la vraisemblance linguistique, pas la vérité factuelle.
Exemple CS : Un agent IA sans RAG génère un résumé de compte en inventant des données d'usage qui ne correspondent pas à la réalité — et le CSM l'utilise tel quel en QBR. La crédibilité en prend un coup. C'est pourquoi tout agent IA manipulant des données client doit être ancré sur une source de vérité (RAG) et inclure une étape de validation humaine avant toute communication externe.
19. Observabilité
L'observabilité désigne la capacité à monitorer en temps réel ce qu'un système IA fait, pourquoi il le fait et où il échoue. Elle couvre les logs de conversations, les traces d'exécution des agents, les métriques de performance et les alertes sur les comportements anormaux. Sans observabilité, un agent en production est une boîte noire.
Exemple CS : Votre dashboard d'observabilité révèle que votre agent de détection churn génère 15% de faux positifs sur les comptes en phase d'expansion — il interprète une baisse d'usage temporaire comme un signal de risque, alors que c'est un creux saisonnier documenté. Vous ajustez le modèle en conséquence. Sans ce monitoring, vos CSMs auraient sur-sollicité des comptes sains, dégradant la relation sans raison.
💡 L'observabilité est le prérequis à toute amélioration continue d'un système IA en production. Déployer sans monitorer, c'est se priver d'améliorer le modèle.
20. Evaluation — Eval
Une eval est un protocole de test qui mesure la qualité des réponses d'un LLM sur un ensemble de cas de référence. On définit des questions types, des réponses attendues et des critères de scoring. Les evals permettent de comparer des modèles, de détecter des régressions après une mise à jour, et de valider un déploiement avant qu'il touche vos clients.
Exemple CS : Avant de déployer votre agent de scoring de santé client, vous construisez un jeu de 150 comptes réels dont vous connaissez l'issue (renouvellement, churn, expansion) et les signaux qui auraient dû le prédire. Vous faites tourner le modèle sur ces cas et mesurez sa précision. En dessous de 80% de concordance avec le jugement de vos meilleurs CSMs, il ne part pas en production.
21. Fine-tuning
Le fine-tuning consiste à ré-entraîner un LLM généraliste sur un jeu de données spécifique à votre domaine, pour qu'il adopte votre vocabulaire, votre ton, vos process. C'est une opération coûteuse, justifiée quand le prompt engineering seul ne suffit plus.
Exemple CS : Une entreprise SaaS B2B fine-tune son modèle de scoring de santé client sur 3 ans d'historique annoté par ses CSMs : données d'usage, signaux relationnels, contexte contractuel, et issue finale (churn ou renouvellement). Le modèle apprend à pondérer les signaux propres à leur marché vertical — une précision impossible à atteindre avec un modèle généraliste et un prompt, aussi bien rédigé soit-il.
💡 Avant de parler fine-tuning, testez le RAG et le prompt engineering : ils couvrent 80% des besoins CS à une fraction du coût et de la complexité.
Pour aller plus loin :
