Base de connaissances publique

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. Seuls 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.

Il n'existe pas de TYPE d'espace « public ». Les espaces sont uniquement Corporate / Private / Personal. 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 :

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

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 tous les articles avec publish_state='public' des espaces corporate de l'organisation
• 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 et personnels, 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). À la création d'un espace, les types disponibles sont Corporate et Private ; « Personal » est un espace système.

#É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 bouton « Publier » dans l'en-tête

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.

#É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 : uniquement lors de la publication (passage à public, accès anonyme). Cela ne s'exécute pas pour internal, draft ou inherit. Cela s'applique à tous les chemins de publication : le bouton « Publier » dans l'éditeur, « Rendre public » dans la liste/l'arborescence, les changements de visibilité en lot, et la publication d'une collection/d'un espace.

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.

Ce que la boîte de dialogue 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 (Propriétaire et Administrateur toujours). 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 → Widgets :

#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 :

• Une liste d'URL autorisées (allowed paths) — là où cette clé api est valide. Par exemple, https://votresite.com/* et https://docs.votresite.com/*. Les requêtes provenant d'autres domaines sont rejetées (CORS + vérification).
• 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 → Widgets et API et widget pour les détails.

#Ce que voient les visiteurs anonymes

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 → Propriétés
2. Le champ publish_state de la collection :
   • inherit — hérite de l'espace (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 :

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) — 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.