Il existe une version de la gestion des connaissances que la plupart des gens connaissent bien. Elle consiste à ouvrir cinq onglets de navigateur, à recouper de nombreux documents, à rechercher manuellement dans un help center des articles dont on se souvient à moitié, et à passer un mardi après-midi à mettre à jour un paragraphe de tarification dans 12 articles différents, un par un.
C'était mon travail il n'y a pas longtemps. J'avais construit une carte mentale presque encyclopédique de l'emplacement du contenu, de ce qu'il disait, et de ce qui pourrait entrer en conflit si quelque chose changeait. Cette connaissance vivait dans ma tête. Ce qui signifiait qu'au moment où j'étais hors du bureau, ou dès qu'un changement survenait plus vite que je ne pouvais le suivre, les fissures commençaient à apparaître.
Puis j'ai commencé à utiliser Fin Operator comme partie centrale de mon flux de travail. Ce qui prenait auparavant quelques heures prend maintenant quelques minutes. Cet article s'adresse aux gestionnaires de connaissances et aux coéquipiers de contenu maintenant un help center. Utilisez-le pour configurer Operator pour votre flux de travail, effectuer des analyses d'impact des changements lors des mises à jour produit, combler les lacunes de contenu et valider chaque contenu selon un cadre de préparation à 14 facteurs.
Note : Fin Operator est actuellement en version bêta. Toutes les modifications de contenu proposées par Operator nécessitent votre révision et approbation avant publication, rien n'est publié automatiquement.
Avant : la réalité de la gestion des connaissances manuelle
Lorsqu'un changement produit survenait, par exemple une mise à jour des tarifs, une nouvelle fonctionnalité déployée sur tous les plans, ou une intégration obsolète, mon processus ressemblait à ceci :
Rechercher manuellement dans le help center tout ce qui pourrait en faire mention.
Ouvrir chaque article, le lire en entier, décider s'il devait être mis à jour.
Faire la modification, enregistrer en brouillon, puis passer au suivant. Le jour du lancement, je republiais ces articles mis à jour.
Espérer ne rien avoir oublié.
Le problème ne venait d'aucune étape en particulier. C'était le poids cumulatif. Un changement produit de taille moyenne pouvait toucher 8 à 10 articles. Un changement important pouvait en toucher davantage. Et comme ma collègue Beth et moi étions les seules à savoir où tout se trouvait, le système ne fonctionnait que tant que nous étions là.
Après : à quoi ressemble le même processus avec Operator
Maintenant, lorsqu'un changement produit survient, j'ouvre une conversation avec Operator et décris ce qui a changé. Operator recherche dans la knowledge base, met en avant le contenu pertinent et propose les mises à jour, directement dans la même conversation, prêt à être examiné par moi.
Je n'ai pas besoin de savoir où se trouve le contenu. Je n'ai pas besoin d'ouvrir 10 onglets. Je révise les propositions, approuve ce qui est correct, rejette ce qui ne l'est pas, et nous itérons. Le tout, pour un changement qui m'aurait pris deux à trois heures, prend moins de 10 minutes.
Mais la rapidité n'est pas la chose la plus précieuse. La chose la plus précieuse est la cohérence. Lorsqu'on met à jour manuellement des articles, l'incohérence s'installe. On en oublie un. On formule légèrement différemment deux articles. On met à jour l'extrait mais pas l'article public. Avec Operator, la recherche est systématique. Les propositions sont basées sur ce qui existe réellement. Rien n'est oublié.
Ce que ce rôle est réellement maintenant
Mon titre est Gestionnaire de connaissances IA. Le rôle a toujours eu deux facettes : la rédaction de contenu, et le travail opérationnel de maintien d'une knowledge base à jour, cohérente et précise à travers des milliers d'articles.
Ce qu'Operator a changé, c'est la seconde moitié. Le travail manuel de récupération a presque disparu : la recherche, le recoupement, la chasse à ce qui existe avant même que je puisse commencer à écrire. Cela libère plus de temps pour la partie qui nécessite vraiment du jugement : décider ce que le contenu doit couvrir, à quelle norme il doit répondre, ce qui doit être mis à jour, et ce qui doit être créé.
La configuration : mémoire et guide de style
La différence entre utiliser un assistant IA et travailler avec un assistant IA est la configuration. Dès la sortie de la boîte, tout outil IA est générique. Il ne connaît pas la voix de votre marque, votre terminologie, vos standards de contenu, ni votre audience. Il produit un résultat raisonnable, mais raisonnable ne suffit pas lorsque le contenu qu'il vous aide à créer est utilisé par Fin (l'agent IA d'Intercom) pour répondre aux vraies questions des clients.
Mémoire : donner à Operator un cerveau qui persiste
Operator dispose d'une fonction mémoire qui persiste à travers les conversations. Cela semble être une petite chose. Ce ne l'est pas.
Sans mémoire persistante, chaque conversation commence à zéro. Vous réexpliquez votre guide de style. Vous redécrivez votre cadre. Vous rétablissez le contexte que vous aviez établi la semaine dernière, le mois dernier, il y a un an. C'est l'équivalent IA d'intégrer un nouveau collègue chaque matin.
Avec la mémoire persistante, Operator transporte les connaissances de votre espace de travail. Il connaît votre terminologie. Il connaît vos standards. Il connaît les cadres que vous lui avez demandé d'appliquer. Vous construisez ce contexte une fois, et il se cumule avec le temps.
Ajouter quelque chose à la mémoire est simple : dans n'importe quelle conversation avec Operator, dites-lui simplement ce que vous voulez qu'il retienne. Quelque chose comme « Enregistre ceci dans ta mémoire » suivi du contenu suffit. Operator confirme que c'est enregistré, et cette information est disponible dans chaque conversation à partir de ce moment.
Voici ce que j'ai enregistré dans la mémoire d'Operator en ce moment :
Le guide de style — couvrant le ton, la mise en forme, la capitalisation, les conventions de liens, l'orthographe américaine et les règles de terminologie.
Le cadre de préparation du contenu — 14 facteurs contre lesquels chaque contenu est évalué avant publication.
Le prompt de vérification de préparation du contenu — le prompt exact que j'utilise après chaque création ou modification.
Les conventions de nommage — comment les articles, articles internes et macros sont intitulés dans cet espace de travail.
Le contexte de l'espace de travail — qui possède quoi, quelles équipes sont responsables de quels domaines.
L'effet pratique : lorsque je demande à Operator de rédiger ou de mettre à jour du contenu, il sait déjà comment il doit sonner, quelle terminologie utiliser, et quel standard il doit respecter. Je ne lui demande pas cela à chaque fois. C'est la base.
Le guide de style : pourquoi l'intégrer est important
Un guide de style ne fonctionne que s'il est appliqué de manière cohérente. Le problème des guides de style appliqués par des humains est que la cohérence dépend de la personne : à quel point elle l'a lu récemment, la charge cognitive qu'elle porte ce jour-là, si elle a remarqué le paragraphe qui retombe en anglais britannique.
Lorsque le guide de style est dans la mémoire d'Operator, il est appliqué à chaque fois. Chaque brouillon utilise la casse de phrase pour les titres. Chaque article utilise « teammate » et non « agent ». Chaque liste numérotée suit la même structure. Le guide de style cesse d'être une aspiration et devient le résultat réel.
Cela signifie aussi que je peux confier la rédaction en toute confiance. Lorsque je demande à Operator de créer un article de zéro, je ne le révise pas pour l'alignement de la marque en plus de tout le reste. C'est déjà pris en charge.
Comment enregistrer votre guide de style dans la mémoire d'Operator
Faites cela en premier. Une fois enregistré, Operator applique votre guide de style à chaque article qu'il crée ou modifie dans votre espace de travail.
Allez à Fin AI Agent > Operator.
Dans le composeur (le champ de texte en bas de la fenêtre Operator), entrez le texte suivant : « Ceci est notre guide de style de knowledge base. Lors de la génération de nouveaux articles ou de la modification de contenu existant, vous devez toujours respecter ce guide. » Puis collez votre texte de guide de style juste en dessous et appuyez sur Envoyer pour soumettre le message à Operator.
Lorsque Operator enregistre le guide de style, vous verrez une confirmation comme : « Enregistré pour les conversations futures. J'appliquerai ce guide de style chaque fois que je créerai ou modifierai du contenu de knowledge base dans votre espace de travail. » Si vous ne voyez pas de confirmation, essayez de renvoyer le message.
Pour vérifier que la configuration a fonctionné, demandez à Operator de vérifier si un des articles de votre help center est conforme aux règles de votre guide de style. Operator devrait signaler toute déviation et suggérer des corrections. Voici un exemple d'Operator confirmant que le guide de style a été enregistré et passant à un audit :
Note : Pour mettre à jour votre guide de style en mémoire, envoyez à Operator la version mise à jour avec le même texte d'instruction et il enregistrera la nouvelle version. Si Operator cesse d'appliquer le guide de manière cohérente, renvoyez-le au début de votre prochaine conversation en rappel.
Laissez Operator vous poser des questions
Une chose que j'ai mis du temps à comprendre : qu'Operator me pose des questions est une fonctionnalité, pas un problème.
Au début, j'étais frustré quand Operator demandait des clarifications au lieu de simplement générer quelque chose. Je voulais de la rapidité. Ce que j'ai appris, c'est que les questions de clarification sont un signal. Elles m'indiquent où ma demande était ambiguë, où le contenu a des lacunes, ou où je ne lui ai pas donné assez d'éléments pour travailler.
Maintenant, je l'invite activement. Quand je commence une tâche complexe, j'ajoute souvent : « Si quelque chose n'est pas clair ou si vous avez besoin de plus d'informations pour bien faire cela, demandez-moi avant de rédiger. » Le résultat est meilleur. L'itération est plus rapide. Et les questions qu'Operator pose font souvent remonter des choses que je n'avais pas consciemment remarquées comme manquantes.
Les prompts que j'utilise le plus
Un bon prompt est un outil. Voici ceux que j'utilise régulièrement. Chaque prompt est envoyé à Operator dans une conversation — Operator recherche dans votre knowledge base, récupère le contenu pertinent, et répond avec des propositions à examiner. Copiez-les et adaptez-les à votre propre flux de travail.
Vérification de la préparation du contenu
Utilisez ceci après avoir créé ou modifié un article pour le vérifier selon les 14 facteurs de préparation du contenu :
« Comment cet article se mesure-t-il par rapport au cadre de préparation du contenu enregistré dans votre mémoire ? Pour chacun des 14 facteurs, dites-moi si ce contenu passe ou nécessite une amélioration, et expliquez pourquoi. Fournissez des suggestions spécifiques de réécriture pour toute section insuffisante, et ajoutez un texte alternatif descriptif à toute image. Considérez deux publics : (1) un client lisant directement l'article, et (2) Fin récupérant ce contenu pour répondre à une question client. Signalez tout ce qui pourrait causer de la confusion ou une mauvaise expérience pour l'un ou l'autre. »
Analyse d'impact des changements
Utilisez ceci lorsqu'un changement produit, une mise à jour de politique ou une modification de tarification survient :
« Nous venons de faire le changement suivant : [décrivez le changement]. Recherchez dans la knowledge base tout contenu pouvant entrer en conflit ou être affecté par cela, récupérez les articles les plus pertinents, et proposez les mises à jour spécifiques nécessaires. »
Identification des lacunes
Utilisez ceci lorsque vous suspectez un manque de contenu sur un sujet :
« Nous n'avons pas suffisamment de contenu sur [sujet]. Recherchez tout ce qui s'y rapporte pour comprendre ce qui existe déjà, puis rédigez un nouvel article qui comble la lacune. Signalez tout ce dont vous avez besoin de ma part avant de rédiger, comme des valeurs spécifiques, des chemins UI ou la disponibilité des plans, plutôt que de deviner. »
Vérification de la cohérence
Utilisez ceci lorsque vous avez remarqué une dérive terminologique dans la knowledge base :
« Nous utilisons le terme [X] dans certains articles et [Y] dans d'autres pour désigner la même chose. Trouvez toutes les occurrences dans la knowledge base et proposez des mises à jour pour les aligner sur [terme préféré]. »
Vérification de la clarté pour le public
Utilisez ceci sur tout article destiné à des clients nouveaux ou moins techniques :
« Lisez cet article comme quelqu'un qui n'a jamais utilisé cette fonctionnalité auparavant. Signalez toute étape qui suppose une connaissance préalable, tout terme non défini, et toute instruction ambiguë sur ce qui se passe ensuite. Suggérez des réécritures spécifiques. »
Enquête sur les échecs de Fin
Utilisez ceci lorsque Fin n'a pas pu répondre précisément à une question client :
« Fin n'a pas réussi à répondre à une question sur [sujet] dans la conversation [lien]. Recherchez dans la knowledge base le contenu lié à ce sujet, récupérez les résultats les plus pertinents, et dites-moi : le contenu existe-t-il et est-il exact, existe-t-il mais est mal structuré pour que Fin le récupère, ou y a-t-il une véritable lacune nécessitant un nouveau contenu ? »
Le cadre de préparation du contenu à 14 facteurs
Les prompts ci-dessus sont construits autour d'un cadre de préparation du contenu à 14 facteurs — un ensemble de critères qui détermine si le contenu est prêt pour que Fin l'utilise pour répondre aux questions des clients. Pour le cadre complet, incluant des exemples de bonnes et mauvaises pratiques pour chaque facteur et une liste de contrôle complète, voir Optimizing content for Fin.
Voici le cadre complet de préparation du contenu que vous pouvez enregistrer dans la mémoire d'Operator :
Content Readiness is an Intercom feature that scores knowledge base content across 14 factors.
These factors must be applied as a checklist whenever creating or updating articles, snippets, or internal articles.
## Content Readiness Factors — Apply to all content
1. **disambiguation** — Avoid vague references like "this screen" or "the field shown above." Every reference must be self-descriptive. Don't use emoji (👇☝️) to point to visual content.
2. **visual_content_text** — Every image must have descriptive alt text explaining what the screenshot or diagram shows. A trailing colon followed by an image (with no alt text) is not acceptable — describe the visual in text too.
3. **undefined_terms** — Define abbreviations and product-specific terms on first use. Examples: CSV (comma-separated values), GDPR (General Data Protection Regulation), 2FA (two-factor authentication), Elasticsearch, UserMessage. Don't assume the reader knows internal terminology.
4. **structured_enumeration** — Multi-step processes must use numbered lists. Lists of items must use bullet points. Never describe steps or enumerations in flowing prose. If a sentence says "the following:" it must be followed by an actual list.
5. **query_answer_symmetry** — Headings should mirror how a customer would phrase a question. Avoid bare noun phrases ("Invite reminder emails") or bare imperatives ("Add a teammate"). Prefer "How to…" or question-form headings.
6. **self_contained_sections** — Every section must make sense if retrieved independently by Fin, without surrounding context. Avoid "as described above," "the field shown above," "Then…" as an opener, or references to prior steps without restating them.
7. **audience_specification** — State who the content is for and what permissions or plan access is required. Don't assume the reader knows their own role or access level.
8. **entity_distribution** — Repeat key entities (product names, feature names, the article's core topic) throughout the article — not just in the opening. Sections retrieved in isolation should still be identifiable as belonging to the right topic.
9. **semantic_chunk_boundaries** — Each section should cover one focused topic. Avoid mixing unrelated information in the same block. Long sections should be broken up with meaningful subheadings.
10. **restate_questions** — Tables and standalone blocks must include enough context to be understood without the heading hierarchy. Add an intro sentence before tables that states what the table covers and where it applies.
11. **overview_jtbd** — The opening paragraph must state the job(s) the reader will accomplish — not just the topic. "This article covers X" is weaker than "Use this article to do Y, troubleshoot Z, or understand W." 12. **instruction_completeness** — Step-by-step instructions must be complete end-to-end. Include what happens after the final step (confirmation dialogs, what to expect, next actions). Don't stop at "click Remove" without describing what follows.
13. **limitations_workarounds** — If a feature has known limitations, gaps, or workarounds, document them explicitly. Don't just say "some things aren't supported" — say which ones and what to do instead.
14. **numerical_clarity** — All numbers, thresholds, limits, durations, and quantities must be stated precisely. Avoid "some," "a few," "shortly," or vague ranges. Use exact values where known; ask the user if unknown.
## When to apply these Apply all 14 factors as a quality checklist when:- Creating a new article, snippet, or internal article - Proposing updates to existing content - Reviewing content for accuracy or completeness Flag any factor that would fail before submitting a proposal. If information needed to fix a factor (e.g. exact limits for numerical_clarity, or which plans are affected for audience_specification) is not available, ask the user rather than leaving it vague or fabricating it.
Comment exécuter la vérification de préparation du contenu
Après avoir créé ou modifié un article, j'exécute le prompt « Content readiness check ». Operator renvoie une analyse selon les 14 facteurs : un verdict de réussite ou d'amélioration nécessaire, et des suggestions spécifiques de réécriture pour tout ce qui est insuffisant. Il ne se contente pas de signaler le problème, il rédige la correction.
Je révise la réponse d'Operator, approuve les propositions avec lesquelles je suis d'accord, rejette celles que je formulerais différemment, et j'itère.
Cela prend plus d'une passe, et c'est normal
Le contenu réussit rarement les 14 facteurs dès la première vérification. Parfois, une correction pour un facteur crée une lacune dans un autre. Parfois, une section nécessite un changement structurel qui ne devient apparent qu'une fois les problèmes de surface résolus.
Ce n'est pas un échec du cadre ou de l'outil. C'est ainsi que fonctionne réellement la qualité. Un premier brouillon qui réussit 10 des 14 facteurs est un bon premier brouillon. Une troisième passe qui corrige les quatre restants est un excellent contenu pour Fin et vos clients.
Ce que le cadre vous offre n'est pas la perfection du premier coup ; c'est un système fiable pour y parvenir. Avant de l'utiliser, je n'avais pas de méthode cohérente pour savoir quand un article était terminé. Maintenant, j'en ai une. Quand les 14 facteurs sont validés, c'est terminé.