Lightning Knowledge est la bibliothèque d'articles de Salesforce pour Service Cloud : les agents rédigent les articles, les record types séparent les FAQ des politiques, les data categories décident qui trouve quoi, et un agent doit toujours cliquer sur Publish même après l'approbation. L'activation est à sens unique, elle nécessite une licence Knowledge User pour quiconque rédige, et la limite qui se heurte en premier, ce sont les article versions, pas les articles. Planifiez les categories avant le premier article. Une fois la bibliothèque en place, un agent IA comme eesel pour Salesforce peut lire ces articles quand il rédige la réponse à un case.
Qu'est-ce que Lightning Knowledge ?
Je travaille sur la file de support chez eesel, et la question qu'on me pose le plus souvent sur Salesforce Knowledge est : « d'où vient vraiment la réponse quand un agent est en plein milieu d'un case ? » Lightning Knowledge, c'est cet endroit. Avec la eesel CLI, un agent IA de code peut importer le texte de vos articles approuvés, comme des articles Knowledge exportés et des politiques, lui poser des questions de test et vérifier les réponses avant que quoi que ce soit passe en ligne, même si un admin Salesforce doit toujours approuver la connexion elle-même.
L'aperçu de Knowledge de Salesforce indique que votre base de connaissances se construit à partir d'articles, c'est-à-dire des documents d'information comme la façon de réinitialiser un produit ou la capacité de stockage qu'il prend en charge. Des agents expérimentés et des rédacteurs internes les écrivent, et les articles peuvent être publiés en interne ou en externe, sur des sites clients et partenaires, des sites web publics, ou dans des publications sur les réseaux sociaux et des e-mails. Selon la même page, les organisations nouvelles sur Knowledge utilisent Lightning Knowledge.
Deux choses le distinguent d'un dossier de Google Docs. Les articles sont de vrais enregistrements Salesforce, vous pouvez donc faire des rapports dessus, les joindre à des cases et les contrôler avec les mêmes permissions que n'importe quel autre objet. Et chaque article traverse un cycle de vie de versions draft, published et archivées, c'est là que se concentre la majeure partie du travail admin. Si vous cartographiez le reste du produit, mes guides sur l'aperçu de Service Cloud et le système de tickets complètent bien celui-ci.
En quoi Lightning Knowledge diffère-t-il de Classic Knowledge ?
Lightning Knowledge remplace les article types personnalisés par des record types standards, et change qui peut faire quoi. La page des limitations de Salesforce indique que l'activation fait passer votre modèle de données aux record types plutôt qu'aux article types, et que vous ne pouvez plus le désactiver ensuite. Les permissions de Classic venaient des groupes publics et des article actions. Dans Lightning, les permissions de profil utilisateur ou les permission sets les remplacent.
La même page signale une instruction datée que je ne sauterais pas : elle indique que les organisations devaient exécuter l'outil de migration avant le 1er juin 2025 pour conserver l'accès à Knowledge. Si vous lisez ceci sur une organisation Classic, demandez à votre admin Salesforce où cela en est. La page de migration de Salesforce indique qu'il faut ouvrir une demande auprès du Support, prévoir 1 à 2 semaines de délai, et tester d'abord dans une sandbox.
La page des limitations liste aussi ce qui n'a pas fait le saut, et certains points surprennent :
- Les notes en étoiles ont disparu. Il ne reste que thumbs up et thumbs down, et les anciennes notes de 3, 4 et 5 étoiles deviennent des thumbs up.
- Lightning Knowledge ne prend pas en charge la recherche fédérée, et le package Public Knowledge Base ne peut pas être utilisé.
- L'archivage ne peut pas être planifié pour une date future. Salesforce suggère un Flow qui archive les articles selon un champ de date.
- L'action Printable View n'est pas disponible.
- Après activation, le champ Article Type n'est plus accessible via SOQL ni l'API, ce qui casse le code personnalisé qui l'interroge.
Comment configurer Lightning Knowledge ?
En cinq mouvements, et le premier n'a pas de retour en arrière. La page d'activation et l'aperçu de configuration de Salesforce donnent la séquence.
- Testez dans une sandbox ou une organisation d'essai. Salesforce recommande de le faire avant la production car l'activation est permanente. Selon la page des limitations, supprimez d'abord tout package installé contenant des article types.
- Activez-le. Dans Setup, saisissez Knowledge dans Quick Find, cliquez sur Knowledge Settings, puis sur Edit, sélectionnez Enable Lightning Knowledge et enregistrez. Il vous faut un article type pour l'activer, et la licence Knowledge User pour voir la page.
- Donnez l'accès aux utilisateurs. La page d'accès utilisateurs de Salesforce indique que tous les utilisateurs internes avec la permission Read peuvent lire les articles publiés par défaut. Pour faire plus que lire, les agents ont besoin de la licence Knowledge User, cochée sur leur fiche utilisateur.
- Créez les record types et les page layouts. Un record type par type de contenu, chacun avec son propre layout.
- Planifiez les categories, puis publiez. Configurez les data category groups, décidez vers quels channels va chaque type, et rédigez les premiers articles.
Un détail de permissions qui fait gagner un après-midi à un admin support : pour voir les categories sur des articles draft, les utilisateurs standards ont besoin à la fois de Knowledge User et de Manage Article, et supprimer des articles archivés nécessite Modify All Records. Mon guide sur les macros donne la même leçon pour une autre fonctionnalité : testez en tant qu'agent, pas en tant qu'admin.
Salesforce propose aussi un flux de configuration guidé qui active Lightning Knowledge, choisit les auteurs d'articles et crée les data category groups, et qui active automatiquement un record type et un layout FAQ par défaut, selon sa page de flux de configuration.
Comment fonctionnent les record types, les page layouts et les data categories ?
Les record types décident de ce que contient un article, et les data categories décident où il peut être trouvé. La page des record types de Salesforce le dit sans détour : vos pages FAQ diffèrent des tutoriels, qui diffèrent eux-mêmes des énoncés de politique, et un record type contrôle le contenu et le layout d'un article. Un page layout décide ensuite quels champs les agents voient et modifient, selon le record type et le profil.
Les data categories sont la couche de filtrage. L'article de bonnes pratiques de Salesforce liste les limites :
| Limite de data category | Valeur |
|---|---|
| Category groups | Jusqu'à 3 |
| Niveaux de hiérarchie par groupe | Jusqu'à 5 |
| Categories par groupe | Jusqu'à 100 |
| Categories sur un article, d'un même groupe | Jusqu'à 8 |
| Paramètres de visibilité | Rôles, permission sets ou profils, réglés sur All, None ou Custom |
L'exemple de cette page mérite d'être retenu. Un article sans category n'apparaît pas quand un filtre produit est actif, tandis qu'un article marqué All Products apparaît aussi bien avec que sans le filtre. La page de création de Salesforce ajoute que les utilisateurs ne trouvent un article que via sa category appliquée, la category parente de celle-ci ou l'une de ses enfants, choisissez donc des categories qu'une personne chercherait naturellement. Elle avertit aussi que les data categories n'apparaissent pas dans les vues de liste Knowledge, construisez donc plutôt un rapport qui filtre par category.
Mon conseil, du côté de la file : limitez le premier category group à une seule question, comme « de quel produit s'agit-il ? » Trois groupes dès le premier jour, c'est la raison pour laquelle les articles finissent dans aucun d'eux. La page de planification de Salesforce est d'accord sur l'ordre du travail, en disant aux admins de planifier les hiérarchies de categories et la façon dont elles correspondent à la hiérarchie des rôles avant de les configurer.
Comment les channels décident-ils qui voit un article ?
Les channels sont des interrupteurs de visibilité sur chaque article. Salesforce documente quatre champs dans Lightning Knowledge : Visible in Internal App, Visible to Customer, Visible to Partner et Visible in Public Knowledge Base, et son article sur les channels indique qu'ils sont masqués par défaut et doivent être ajoutés au page layout avant que les auteurs puissent les modifier. Publier rend un article visible sur tous les channels sélectionnés, et publier un article avec des traductions publie aussi les traductions, selon la page de publication.
Pour les lecteurs externes, la page des limitations de Salesforce indique que vous pouvez partager des articles Lightning Knowledge dans Experience Cloud et Salesforce Sites, et utiliser Help Center pour partager avec des utilisateurs non authentifiés. Comme Title et URL Name sont obligatoires, ils ne peuvent pas être retirés d'un layout, ce qui s'applique aussi aux sites Experience Cloud.
Si vous comparez cela à d'autres help centers, mes articles sur la base de connaissances Gorgias, la base de connaissances HubSpot et la base de connaissances Freshservice montrent le même travail accompli avec moins de rouages.
Comment fonctionnent les approbations et la publication ?
L'approbation conditionne le contenu, mais ne le publie jamais. La page d'approbation de Salesforce indique que les articles ne sont pas publiés automatiquement à la fin d'un approval process, un agent doit donc cliquer sur Publish. Elle indique aussi qu'il faut régler l'action d'approbation finale sur « Unlock the record for editing » pour que cela soit possible.
D'autres règles de cette page et de la page de publication :
- Les approbateurs peuvent être choisis manuellement, assignés depuis un champ de hiérarchie, envoyés à une queue, ou fixés sur des utilisateurs précis, avec jusqu'à
25par étape. - Les approval processes ne couvrent que l'étape du draft jusqu'à la publication. Salesforce indique qu'ils ne sont pas disponibles pour la traduction ni l'archivage.
- Un agent avec l'action Publish Articles voit à la fois Publish et Submit for Approval, limitez donc cette action à un petit groupe si vous voulez que l'approbation signifie quelque chose.
- Vous ne pouvez pas déverrouiller un article en cours d'approval process, et les articles programmés pour publication avant l'approbation passent en ligne quel que soit le statut d'approbation.
- La publication programmée s'exécute par intervalles de 15 minutes, la minute exacte n'est donc pas garantie.
Il y a un point où les pages de Salesforce se contredisent : la page de publication dit de cliquer sur Cancel Publication pour annuler une publication programmée, mais indique aussi que le bouton n'est pas disponible depuis un draft dans Lightning Experience, et la page des limitations dit qu'on ne peut pas du tout annuler une publication programmée. Testez-le dans une sandbox avant de promettre aux auteurs qu'ils peuvent retirer un article programmé.
Les workflow rules sont autre chose. Elles peuvent envoyer des alertes e-mail, mettre à jour des champs ou envoyer des outbound messages quand un article remplit des critères, mais Salesforce précise que les tasks ne sont pas prises en charge pour le workflow d'articles. Si votre problème est un article obsolète plutôt qu'un article lent, mes guides sur un audit de base de connaissances par IA et la détection de contenu d'aide obsolète sont les vérifications que je ferais.
Comment fonctionnent les versions d'article ?
Chaque article peut avoir une version draft, une version published et plusieurs versions archivées. La page des versions de Salesforce indique que pour conserver la version précédente, vous cochez Flag as new version lors de la publication, et la nouvelle version reçoit le numéro séquentiel suivant.
Le lien avec le case est la partie astucieuse. Quand un article est joint à un case et qu'une nouvelle version est publiée, la version jointe est marquée comme obsolète, Version 2 devient alors « Version 2 (outdated) » et le case garde une trace permanente de ce que l'agent a réellement lu. Par défaut, le système stocke jusqu'à 10 versions par article, plus celles jointes à des cases, et ces versions liées à des cases ne comptent pas dans la limite par article.
Deux particularités de Lightning : vous ne pouvez supprimer que les versions archivées et draft, et pour les articles ayant plus de 30 versions, celles au-delà de 30 apparaissent dans Classic mais pas dans Lightning, selon la page des limitations. Plusieurs agents peuvent aussi modifier le même article en même temps et s'écraser mutuellement sans avertissement, Salesforce recommande donc de dire aux auteurs de ne modifier que les articles qui leur sont assignés.
Combien coûte Lightning Knowledge et qui a besoin d'une licence ?
Salesforce ne liste pas de prix autonome pour Knowledge sur sa page tarifaire Service. Cela apparaît comme une ligne de fonctionnalité « Knowledge Management » dans la comparaison des éditions, et je n'ai pas pu confirmer à partir du texte de la page quelles colonnes d'édition l'incluent, vérifiez donc auprès de votre interlocuteur. Les prix catalogue par utilisateur sur cette page sont :
| Édition | Prix catalogue par utilisateur et par mois |
|---|---|
| Starter Suite | 25 $ |
| Pro Suite | 100 $ |
| Core | 195 $ |
| Advanced | 395 $ |
| Max | 550 $ |
Deux add-ons IA concernent directement les articles : la page affiche Knowledge Creation et Enterprise Knowledge comme « Available for purchase » sous Core et Advanced. Pour les rédacteurs, la licence qui compte est Knowledge User, nécessaire selon Salesforce pour faire plus que lire des articles. Les tarifs actuels de Service Cloud de Salesforce sont détaillés dans mon guide tarifaire, et l'usage de l'IA est mesuré séparément en Flex Credits.
Quelles limites les admins doivent-ils prévoir ?
La limite qui surprend, ce sont les versions, pas les articles. La page de scalabilité de Salesforce indique que le total des versions est égal aux articles multipliés par les versions conservées par article multipliées par les traductions par version, et donne l'exemple de 100 000 articles avec 5 versions et 5 traductions chacun, soit 2 500 000 versions.
Allocations par défaut selon l'édition, sur la même page :
| Édition | Articles | Versions par article | Langues |
|---|---|---|---|
| Essentials | 500 | 10 | 1 |
| Professional | 500 | 10 | 1 |
| Enterprise | 50 000 | 10 | 5 |
| Developer | 50 000 | 10 | 5 |
| Unlimited | 150 000 | 10 | 10 |
Une réserve honnête : ce tableau utilise les anciens noms d'édition, tandis que la page tarifaire montre désormais Core, Advanced et Max, et aucune des deux pages ne fait le lien entre les deux. Vous pouvez demander à Salesforce Support de relever les limites, et les organisations créées avant Spring '18 ont par défaut 16 langues. Classic Knowledge autorisait 25 article types, tandis que Lightning Knowledge autorise jusqu'à 200 record types par objet.
Autres limites de cette page qui concernent les équipes support : un champ texte enrichi peut contenir jusqu'à 100 liens vers d'autres articles, le pied de page Knowledge n'est pas dans la Lightning Service Console (ajoutez plutôt le composant Knowledge à une page d'enregistrement), et l'option de créer un article en fermant un case n'existe que dans Classic. Et comme promis dans la FAQ, vous ne pouvez pas utiliser de macros avec les articles de Knowledge ni insérer d'articles dans des macros, mon guide sur les macros et celui-ci décrivent donc deux bibliothèques distinctes.
Comment les agents IA utilisent-ils Lightning Knowledge ?
Les articles alimentent les fonctionnalités IA que Salesforce vend pour Service, et des agents tiers les lisent aussi. Trois détails de Salesforce comptent.
Rédaction. Einstein Knowledge Creation de Salesforce permet aux agents de rédiger des articles à partir d'un case, d'un incident ou d'un work order à l'aide de prompt templates, puis de relire, modifier et enregistrer. Salesforce indique ne facturer que les articles que vous générez.
Grounding. Dans Ground with Knowledge, les champs title et summary sont obligatoires. Salesforce indique que l'indexation peut prendre plusieurs heures, que les nouveaux articles sont indexés une fois toutes les 24 heures, et que les utilisateurs ne voient que des réponses fondées sur des champs et versions auxquels ils ont accès. Seuls les champs String et Text Area sont pris en charge, pas les champs chiffrés.
Sources externes. La page Unified Knowledge de Salesforce indique que son retrait est prévu avec la version Summer '27, avec Enterprise Knowledge propulsé par Data 360 comme remplacement.
Mon avis : le niveau de qualité exigé d'un agent IA est le même que pour un agent humain, en moins indulgent. Title et summary sont les champs de grounding obligatoires, un summary vague comme « Returns info » vous coûtera donc plus cher que n'importe quelle mise à niveau de modèle. Mes guides sur les hallucinations IA en support et l'entraînement de base de connaissances vont plus loin.
smava montre l'autre côté de la chose, sur Zendesk plutôt que Salesforce. Entre le 8 août et le 8 septembre 2026, eesel a traité environ 27 000 tickets pour smava et sa marque sœur, a effectué environ 14 400 recherches dans les macros et le help center, et a préparé environ 15 300 réponses en brouillon à faire approuver. SaunaSpace fait la même chose sur Gorgias, en rédigeant à partir de son help center et des tickets passés dans une voix calme et directe, avec toujours une personne qui envoie. Dans les deux cas, l'agent travaille à partir d'un contenu d'aide qu'une personne a déjà écrit. C'est pourquoi je commencerais par réparer les articles avant d'acheter la moindre IA.
Sur Salesforce lui-même, l'intégration d'eesel fonctionne comme un agent sur les Cases : elle lit le case avec le contexte du contact et du compte, rédige ou envoie des réponses, ajoute des notes internes, met à jour des champs et route vers des queues, et sa page indique qu'elle apprend des cases passés et des articles de knowledge. Les tarifs sont sur la page tarifaire d'eesel : des plans de crédits fixes où un ticket ou un chat coûte 1 crédit, à partir de 500 crédits pour 299 $ par mois, avec 100 crédits gratuits pendant 7 jours. Si vous préférez que Salesforce gère l'IA lui-même, voyez Agentforce agents, le comparatif des alternatives à Agentforce et meilleure IA pour Service Cloud.
Que ferais-je avant d'écrire le premier article ?
Voici la checklist que je donnerais à un admin support :
- Faites-le d'abord dans une sandbox. L'activation est permanente, et Salesforce répète cet avertissement sur plusieurs de ses pages.
- Choisissez au maximum trois record types : FAQ, how-to et policy. N'en ajoutez que lorsqu'un layout diffère vraiment.
- Commencez avec un seul category group et planifiez-le en fonction de votre hiérarchie de rôles.
- Ajoutez les champs de channel au layout dès le premier jour, sinon les auteurs ne pourront pas les définir.
- Décidez qui peut publier. Si les approbations comptent, restreignez l'action Publish Articles et réglez la dernière étape d'approbation pour qu'elle déverrouille le record.
- Rédigez le champ summary pour un agent, pas seulement pour une personne. Title et summary sont les deux champs obligatoires pour le grounding.
- Passez en revue les versions et les liens avec les cases chaque mois, et archivez ce que personne ne lit. Mon guide sur la gestion des connaissances par l'IA propose un rythme de revue.
Si vos articles alimentent un bot, mes articles sur rédiger des articles avec l'IA, connecter l'IA aux connaissances de l'entreprise et la recherche dans le help center se complètent bien avec celui-ci. Guides voisins sur Service Cloud : fusion de cases, routage Omni-Channel, Enhanced Messaging et résumés de case. Pour les bibliothèques multilingues, voyez le support multilingue et la traduction Salesforce, et pour un regard extérieur, le meilleur logiciel de gestion des connaissances.
Essayer eesel pour Salesforce Service Cloud
Si vos agents ont déjà les articles mais retapent quand même la réponse, eesel fonctionne comme une nouvelle recrue qui se branche sur votre organisation Service Cloud, lit chaque nouveau case avec l'historique du compte et vos articles de knowledge, et laisse une réponse en brouillon comme commentaire interne à faire approuver par votre agent. Votre admin contrôle ce qu'elle peut voir, et vous pouvez la simuler sur des cases passés avant qu'elle ne touche un cas réel. Gratuit à essayer avec 100 crédits.
Comment activer Lightning Knowledge dans Salesforce ?