La base de connaissances publique (Public KB) est la partie de votre base de connaissances accessible sans connexion via un lien direct, un widget ou une iframe. Les articles que vous avez explicitement marqués comme publics y figurent.

Pourquoi :

  • Self-service client — les clients trouvent les réponses par eux-mêmes, sans contacter le support
  • SEO — les articles publics sont indexés par Google et les autres moteurs de recherche
  • Démo — les prospects lisent la documentation avant l'achat
  • Partenaires — accès à la documentation technique sans avoir à créer de comptes

#Comment un article devient public

La publicité d'un article s'active via deux réglages — l'un au niveau de l'article, l'autre au niveau de l'organisation. Tant que les deux ne sont pas en place, les visiteurs anonymes ne verront pas l'article.

Niveau article
publish_state = public
L'accès anonyme reçoit les articles au statut public et les articles inherit situés dans un dossier public ; internal et draft restent masqués. Un article ne peut être marqué public que dans un espace corporate — dans les espaces privés, la publication est bloquée.
Niveau organisation
Mode d'accès = « Public »
Dans Paramètres → Organisation → Mode d'accès. Si l'organisation est en mode « Entreprise », l'adresse publique est fermée et les utilisateurs anonymes ne voient rien — même les articles au statut public.

Il n'existe pas de TYPE d'espace « public ». Les espaces sont uniquement Corporate / Private. Un article devient visible non pas en le déplaçant dans un espace spécial, mais via le drapeau publish_state=public (dans un espace corporate) combiné à l'activation du mode d'accès public de l'organisation.

#États de publish_state (ADR 0029)

LiKE utilise le champ publish_state (il remplace l'ancien champ visibility). Quatre états :

État Qui le voit Remarque
draft Uniquement l'auteur et les éditeurs de l'espace Un brouillon — non visible par l'équipe et non inclus dans la recherche
inherit Suit le dossier parent le plus proche ayant un état explicite ; s'il n'y en a pas — comme internal ADR 0029
internal Tous les membres autorisés de l'espace Visible par l'équipe (la valeur par défaut des nouveaux articles)
public Tout le monde, y compris les utilisateurs anonymes via la base de connaissances publique Le badge d'accès à côté du titre de l'article — uniquement dans un espace corporate

Dans l'interface, la couleur de l'état est indiquée par un point indicateur :

Draft — visible uniquement par l'auteur et les éditeurs
Internal — pour l'équipe autorisée
Public — accès anonyme via la base de connaissances publique
Modifications non publiées — la recherche affiche encore la version précédente, la nouvelle y arrivera à la sortie de l'éditeur

Les mêmes badges sont visibles dans la liste des articles dans Gestion des articles.

#L'espace virtuel __public__

Lorsqu'un utilisateur anonyme ouvre la base de connaissances publique via un lien direct ou un widget, techniquement il ne se trouve dans aucun de vos espaces. À la place, LiKE utilise un « espace » virtuel __public__ — une valeur sentinelle qui :

  • N'existe pas dans la base de données en tant que véritable ArticleCollection.type='public'
  • Inclut les articles publics par eux-mêmes ou par héritage depuis un dossier public
  • Sert au filtrage dans la recherche RAG de l'utilisateur anonyme
  • Est affichée dans le SpaceSwitcher comme « Articles publics » (si l'utilisateur possède aussi des espaces privés)

Si vous êtes un membre autorisé, passez à __public__ dans le SpaceSwitcher pour voir exactement le même ensemble d'articles qu'un visiteur anonyme — c'est pratique pour vérifier « ce que j'ai publié par inadvertance ».

#Configuration (étape par étape)

#Étape 1 — Placer les articles dans un espace corporate

Vous ne pouvez publier vers l'extérieur qu'à partir d'un espace corporate (dans les espaces privés, la publication est bloquée). Si vos articles se trouvent dans un autre espace, déplacez-les vers un espace corporate : un par un via le menu contextuel de l'article → Déplacer, ou en masse (cases à cocher → Déplacer). Les types d'espace sont Corporate et Private ; il n'existe pas de type « Personal » distinct — un espace reste privé tant que vous n'invitez personne.

#Étape 2 — Rendre les articles publics

Basculez les articles voulus sur publish_state = public (voir Gestion des articles) :

  • En masse — sélectionnez avec les cases à cocher → le bouton globe () de la barre d'actions → Public
  • Un seul article — le menu « ⋮ » → « Visibilité : … » → Public ; en mode « Arborescence » — le menu contextuel → « Rendre public »
  • Dans l'éditeur — le badge d'accès à côté du titre de l'article

Après cela, l'indicateur de statut passe au vert et un badge Public apparaît. Si l'article contient des données personnelles, une boîte de dialogue de confirmation s'ouvre — voir « Vérification des données personnelles avant publication » ci-dessous.

#Étape 3 — Activer le mode public de l'organisation

Paramètres → Organisation → Mode d'accès → choisissez « Public ».

  • Public — les utilisateurs anonymes voient, à l'adresse publique, les articles marqués comme publics ; les espaces privés restent accessibles uniquement sur invitation.
  • Entreprise — tout est accessible uniquement aux membres connectés ; les utilisateurs externes sans connexion ne voient rien, même les articles marqués publics.

Sans le mode « Public » activé, l'adresse publique est fermée — cette étape est obligatoire.

Le mode public ne fonctionne que sur les offres où il est inclus. Si l'accès public ne fait pas partie de l'offre, le bouton « Public » est indisponible avec l'indication « L'accès public n'est pas inclus dans votre offre : les visiteurs anonymes ne voient pas le portail. ». Lors d'un passage à une offre inférieure, le portail se ferme automatiquement pour les visiteurs anonymes, et il se rouvre au retour sur une offre adaptée — le mode choisi n'est pas réinitialisé.

#Étape 4 — Adresse publique et canaux

Il existe trois façons d'ouvrir la base de connaissances publique prête à l'emploi :

  • Portail public — la racine de votre adresse https://<votre-slug>.lynkora.pro : recherche, réponses IA et lecture d'articles sans connexion. Un article individuel se trouve à /kb/<article-slug>.
  • Widget JS — intégré sur votre site web ; le code du widget se récupère dans Intégrations → Canaux (la carte « Widget JS »).
  • iframe — intégration de l'interface de recherche complète dans une page.

Il n'y a plus d'onglet « Public KB » distinct dans les paramètres (ADR 0029) : la publicité se définit désormais par le drapeau de l'article + le mode de l'organisation, plutôt que par une liste blanche de sources. Les widgets se gèrent dans Intégrations → Canaux.

#Vérification des données personnelles avant publication

Lorsque vous passez un article en Public, LiKE l'analyse automatiquement à la recherche de données personnelles (PII). Si des données sont détectées, la publication est suspendue et une boîte de dialogue « Données personnelles détectées » s'affiche — avant que l'article ne devienne accessible à tous sans connexion.

Quand cela se déclenche : lorsque l'article devient accessible de façon anonyme — par le passage à public ou via inherit à l'intérieur d'un dossier public. Cela ne s'exécute pas pour internal et draft. Cela fonctionne sur tous les chemins, et pas seulement sur le bouton « Publier » : le badge d'accès dans l'éditeur, « Rendre publique » dans la liste et dans l'arborescence, le changement de visibilité en lot, la publication d'un dossier (y compris avec son contenu), le déplacement d'un article ou d'un dossier dans un dossier public, la copie, la restauration depuis la corbeille et l'activation d'un article.

Ce qui est détecté (déterministe, basé sur des motifs) :

  • E-mail
  • Téléphone
  • Carte de paiement (somme de contrôle Luhn)
  • IBAN (validé par somme de contrôle)
  • Adresse IP
  • Date de naissance

Les catégories particulières (santé, données biométriques, etc., RGPD Art. 9) ne sont pas détectées automatiquement pour l'instant — la boîte de dialogue affiche uniquement un avertissement concernant la responsabilité accrue liée à leur publication.

Un groupe d'articles n'est demandé qu'une seule fois. Le changement de visibilité en lot, la publication d'un dossier, le déplacement et la restauration affichent une seule boîte de dialogue « Données personnelles dans les articles à publier » : un récapitulatif par type de données (combien d'occurrences et dans combien d'articles), la liste des articles avec une recherche par titre, « Tout cocher » / « Tout décocher » et le compteur des articles cochés.

  • Les articles cochés sont publiés. À l'ouverture, tous sont cochés — décochez ceux qu'il ne faut pas publier : ils resteront internes et ne suivront pas le dossier.
  • Les boutons sont « Publier N » et « Annuler ». En cas d'annulation, rien ne se passe, et LiKE le dit explicitement.
  • La confirmation donnée dans la boîte de dialogue groupée est enregistrée dans le journal séparément pour chaque article.

Les articles récupérés par le connecteur de site web ne nécessitent pas de confirmation article par article : lors de la connexion, le propriétaire confirme ses droits sur le site et la licéité de la publication des données personnelles qui en proviennent. Reconnectez le site en répondant « Internes » — le consentement est retiré et la vérification fonctionne de nouveau normalement.

Les actions en arrière-plan — la synchronisation d'un connecteur, l'import, la reconstruction de la structure — ne peuvent rien demander à personne : elles ne publient donc pas un article dont les données personnelles n'ont pas été confirmées. Il reste interne et une entrée à ce sujet apparaît dans le journal. Vous pouvez le publier manuellement en passant la vérification habituelle.

Ce que la boîte de dialogue d'un seul article affiche :

  • Le titre « Données personnelles détectées » et une liste des types détectés avec leur nombre (agrégés sur l'ensemble des articles en cours de publication).
  • Une case de confirmation obligatoire : l'outil aide à détecter les PII mais ne garantit pas l'exhaustivité ; en tant que responsable du traitement, vous restez responsable de la licéité de la publication et de disposer d'une base légale ou d'un consentement.
  • Les boutons Annuler et Publier (Publier n'est activé qu'une fois la case cochée).

Après confirmation : l'article est publié, et la confirmation est enregistrée dans le journal d'activité (pii_public_ack) avec les types de données détectés — sans stocker le texte des PII lui-même (privacy-by-design). La confirmation est liée à la version actuelle de l'article : si vous modifiez le texte par la suite, vous devrez confirmer à nouveau.

Qui peut confirmer : les mêmes rôles qui peuvent publier — Éditeur et au-dessus dans l'espace de l'article. Le Propriétaire de l'organisation — toujours ; l'Administrateur de l'organisation — dans les espaces corporate et dans les espaces privés dont il est membre avec le rôle Éditeur ou Administrateur. La publication en lot de tous les articles d'une source est réservée au Propriétaire/Administrateur.

#Widgets pour la base de connaissances publique (dual-auth, ADR 0032)

LiKE prend en charge deux modes d'authentification pour les widgets — choisis lors de la création d'un widget dans Intégrations → Canaux → JS Widget :

#Mode 1 — Chemins autorisés (pour les sites publics)

Un widget intégré sur le site public de l'entreprise (une landing page, des pages marketing, un centre d'aide). Aucune authentification n'est requise — le widget est disponible pour tout visiteur.

Protection contre les abus :

  • Adresses du site — là où le widget fonctionne. Par exemple, votresite.com, docs.votresite.com (une adresse sans schéma reçoit https://). L'astérisque n'est pas acceptée ; les requêtes provenant d'autres adresses sont rejetées.
  • Public umbrella scope — le widget n'a accès qu'à l'espace __public__ + des collections spécifiques de cet espace, définies à la création.
  • Rate limit sur la clé api — protection contre les bots.

#Mode 2 — JWT de session (pour un site corporate avec authentification)

Un widget intégré sur le portail interne de l'entreprise, où les utilisateurs disposent déjà d'une authentification. Le widget accepte un JWT de session et voit exactement ce que cet utilisateur voit.

Cas d'usage :

  • Un widget sur un intranet corporate → chaque collaborateur voit ses propres espaces
  • Intégration dans une application SaaS (par exemple, dans un CRM) — l'utilisateur voit la documentation correspondant à son rôle

#Multi-widget par tenant (ADR 0029 Stage 4)

Au sein d'une organisation, vous pouvez créer plusieurs widgets avec des scopes différents :

  • L'un — public, pour le site marketing (allowed paths)
  • Un autre — corporate, pour l'intranet (JWT de session)
  • Un troisième — pour une collection spécifique (par exemple, uniquement la FAQ pour le centre de support)

Chaque widget possède sa propre clé api, son scope et son mode d'authentification. Voir Intégrations et API et widget pour les détails.

#Ce que voient les visiteurs anonymes

Élément Visible ?
Articles avec publish_state=public et articles inherit dans des dossiers publics Oui
Recherche IA sur ces articles Oui (si le volume IA de l'organisation est épuisé — recherche d'articles par le sens, sans réponse IA)
Le catalogue de collections publiques Oui
Un court lien de partage / d'intégration (s'il est activé pour l'article) Oui
La bannière « Connectez-vous pour un accès complet » (si le widget est anonyme) Oui
Articles internal, draft et articles inherit hors des dossiers publics Non
Articles issus d'espaces privés Non
Historique des requêtes / Recommandations (personnelles) Non
Panneau d'administration, Corbeille, Journal, Analytique Non

La recherche anonyme utilise par défaut un cookie d'empreinte client (client-fingerprint) pour un rate limiting basique, mais n'associe pas la requête à un compte utilisateur.

#Masquer des collections individuelles

Dans un espace corporate, toutes les collections ne doivent pas nécessairement être visibles par les utilisateurs anonymes. Vous pouvez masquer des collections précises :

  1. Le menu contextuel de la collection → « Rendre publique » / « Rendre interne »
  2. L'état de la collection :
    • inherit — suit le dossier parent le plus proche ayant un état explicite ; s'il n'y en a pas — interne (par défaut)
    • internal — masquée des utilisateurs anonymes, visible par l'équipe
    • public — explicitement publique (uniquement dans un espace corporate, sinon bloqué)

Cela offre de la flexibilité : par exemple, dans un espace corporate « Documentation », vous pouvez conserver les brouillons dans une collection Internal Drafts avec publish_state=internal — ils sont invisibles pour l'extérieur mais accessibles à vos éditeurs.

#Intégration sur un site web

La base de connaissances publique peut être intégrée à un site web de trois façons :

Méthode Description
Lien direct https://<slug>.lynkora.pro — un site portail à part entière avec liste d'articles, recherche IA et navigation
Widget JS Un bouton flottant dans le coin de n'importe quelle page ; il se déploie en un chat IA et une recherche ; le comportement est configurable, et sur les forfaits avec white-label, le branding aussi
iframe Un bloc intégré (par exemple, une page « Aide » à l'intérieur de votre application) — l'interface LiKE complète dans un cadre
REST API Requêtes directes depuis votre backend via une clé api — pour l'intégration dans vos propres interfaces

Détails sur chacune — API et widget et Intégrations.

#White-label et domaine personnalisé

La base de connaissances publique est disponible à l'adresse par défaut slug.lynkora.pro. Les fonctionnalités avancées du portail — le white-label (sans le branding LiKE) et la connexion d'un domaine personnalisé (Paramètres → Domaine; en développement) — sont incluses dans les forfaits où le white-label est activé. Il n'existe pas d'option payante distincte pour cela.

Quelles fonctionnalités sont disponibles sur quels forfaits et à quel prix — voir la page Tarifs et votre panneau d'administration.