Comment créer un wiki d'équipe IA privé pour les employés

Créez un nouvel assistant et donnez-lui un nom interne clair comme “Internal Team Wiki”. Dans Configuration, choisissez l'anglais comme langue par défaut pour cette démonstration, renseignez un nom de service et de canal interne, puis rédigez des instructions système (system role) indiquant de répondre à partir des sources approuvées, de reconnaître les informations manquantes et de rediriger les employés vers le responsable adéquat.

Commencez avec un modèle rapide à usage général et une température modérée. Un modèle plus grand ne pourra pas corriger des documents de politique interne dupliqués, obsolètes ou contradictoires. Ne publiez pas cet assistant sur le site web public et désignez un responsable opérationnel avant d'ajouter des sources sensibles.

Démarrez avec un seul service et un sujet précis. Par exemple, un wiki informatique peut couvrir les procédures d'escalade et le dépannage approuvé, tandis que les politiques RH restent dans un assistant géré séparément jusqu'à confirmation des exigences d'accès.

Ouvrez Data Sources et ajoutez uniquement des sites web, des fichiers, des espaces Confluence ou des bases Notion tenus à jour et autorisés à la lecture pour ce public. Consignez hors du chatbot le responsable de la source, la date de révision et le niveau de confidentialité. Donnez à chaque source un nom descriptif et une catégorie pour repérer facilement les doublons.

Préparez les documents pour l'extraction : utilisez des titres clairs, un sujet par section, des dates explicites et des phrases complètes. Supprimez les versions obsolètes, les pages scannées sans texte et les copies multiples avant l'indexation. Attendez l'état Completed au lieu de faire des tests pendant que l'indexation est en cours.

L'exemple vérifié utilise le fichier fictif `internal-demo-knowledge-base.pdf` contenant un fait unique : “The internal escalation code for urgent service incidents is NORDSTERN-42.” Cette valeur est sécurisée, facile à retenir et suffisamment spécifique pour prouver que la source prévue a bien été exploitée.

Restez dans l'assistant dédié, ouvrez Integrations et sélectionnez AI Team Wiki. La carte indique si un wiki existe déjà et propose le bouton Create Team Wiki. Vérifiez le nom de l'assistant en haut afin de ne jamais lier un wiki interne au mauvais ensemble de sources.

Prenez note de l'avertissement affiché : le chat en direct et la reprise par un conseiller humain (human takeover) ne sont pas disponibles dans Team Wiki. Définissez la marche à suivre pour un employé lorsque l'information est manquante ou urgente (helpdesk informatique, boîte mail RH ou ligne d'urgence) et intégrez ce parcours dans le message de bienvenue ou les sources.

Sélectionnez Create Team Wiki, saisissez un titre reconnaissable comme “Northstar Internal Wiki” et choisissez un sous-domaine neutre qui ne dévoile aucun nom de projet confidentiel. Attendez que le voyant de disponibilité passe au vert avant de poursuivre.

Choisissez le mode d'accès en fonction du public réel et du niveau de risque. Le mode Public permet l'accès à toute personne disposant du lien : réservez-le aux informations déjà publiques. Le mode Password offre une barrière partagée mais une traçabilité limitée. Le mode Login Required réserve l'accès au propriétaire et aux membres d'équipe invités avec des comptes individuels, ce qui est généralement préférable pour la révocation et l'audit.

Pour un pilote, documentez qui peut approuver chaque modification d'accès et comment les anciens employés sont retirés. L'accès au wiki ne rend pas automatiquement chaque document connecté accessible à tous les salariés. Créez des assistants distincts lorsque les services ont des droits d'accès différents sur les sources.

Sélectionnez Password et saisissez un secret de test robuste et unique dans l'interface. Ne réutilisez pas de mot de passe d'employé, d'administrateur ou de production. L'avertissement jaune précise un impact fondamental : un assistant protégé de cette façon devient un assistant dédié au Team Wiki, et son widget de site web classique cesse de fonctionner.

Si un site public utilise actuellement cet assistant, arrêtez-vous ici. Créez un assistant distinct, copiez-y uniquement les sources internes approuvées et reprenez la configuration. Dans le cas contraire, activer le mode mot de passe pourrait remplacer un chat public fonctionnel par une demande de mot de passe.

Un mot de passe partagé ne convient que si votre politique l'autorise et qu'un responsable est chargé de son renouvellement. Conservez-le et distribuez-le via un gestionnaire de mots de passe approuvé, jamais dans le message d'accueil, les documents sources, les captures de tutoriels ou la voix off d'une vidéo.

Importez un logo d'entreprise officiel facultatif et choisissez une couleur de thème lisible avec un contraste suffisant. Le message de bienvenue doit mentionner le service et les thèmes couverts, la date de révision des sources, la solution de secours pour les questions manquantes ou critiques, ainsi qu'un rappel de ne pas transmettre de données secrètes.

N'activez File Upload que si les employés sont autorisés à envoyer des fichiers dans cette conversation et si la conservation, l'accès et la suppression des données sont encadrés. Laisser cette option désactivée reste le choix le plus sûr pour un pilote. “Activate wiki immediately” publie le sous-domaine dès que Create est sélectionné ; désactivez cette option si un contrôle préalable de sécurité ou de contenu est nécessaire.

Avant la création, relisez l'ensemble du formulaire : titre, sous-domaine, protection d'accès, logo, couleur, message de bienvenue, envoi de fichiers et activation. Cliquez ensuite sur Create une seule fois. Des clics répétés peuvent compliquer le diagnostic pendant le provisionnement du service.

Copiez le sous-domaine généré et ouvrez-le dans une nouvelle fenêtre de navigation privée sans être connecté au tableau de bord. Le mode Password doit afficher l'écran Wiki Access avant que le titre, le texte des sources ou l'historique de chat ne dévoilent la moindre information interne. Le mode Login Required doit quant à lui rediriger le visiteur vers le flux de connexion des membres.

Saisissez d'abord un mauvais mot de passe. L'accès doit rester bloqué sans message d'erreur trop explicite. Entrez ensuite le mot de passe de test correct et vérifiez que le wiki s'ouvre. Répétez le test de l'URL directe après déconnexion : masquer le lien dans le tableau de bord ne constitue pas un contrôle d'accès.

Pour la connexion membre, faites le test avec un compte pilote autorisé et un compte non attribué. Consignez uniquement les résultats (succès/échec), jamais les identifiants. Retirez les accès de test une fois la validation terminée.

Posez la question exacte de vérification : “What is the internal escalation code?” Le résultat attendu est NORDSTERN-42, car cette information n'apparaît qu'une fois dans la source fictive approuvée. Lors du test vérifié, le vrai Team Wiki a répondu : “The internal escalation code for urgent service incidents is NORDSTERN-42.”

Posez ensuite une question volontairement inconnue, telle que “What is the 2028 travel-expense limit?” lorsqu'aucun document approuvé ne traite de ce sujet. Le comportement attendu consiste à indiquer que l'information n'est pas disponible et à orienter vers le responsable ou le circuit de secours. Une réponse inventant un montant avec assurance constitue un échec du test.

Répétez ces deux questions avec deux formulations naturelles et, si le wiki est multilingue, dans chaque langue prise en charge. Consignez la question, le fait attendu, la réponse observée, la version de la source, le modèle et la date. Rejouez ce jeu de test après chaque modification de source, de consigne système ou de modèle.

Revenez dans Integrations → AI Team Wiki. La carte active affiche le sous-domaine, la date de création et le statut Active. Vérifiez que l'adresse affichée correspond bien à l'URL privée testée, puis consignez le responsable du service et la prochaine date de révision.

Utilisez Open pour les contrôles de routine et Edit pour les modifications planifiées d'accès, d'apparence ou d'options. Utilisez Disable comme première mesure si un public non autorisé accède au site, si une source confidentielle a été indexée par erreur, si les réponses deviennent incorrectes ou si le responsable est indisponible. L'action Disable est réversible et limite l'exposition pendant l'analyse de l'incident.

Réservez Delete à une suppression définitive décidée après avoir rempli les obligations d'export, de conservation et de communication. Analysez régulièrement les questions sans réponse et la fraîcheur des sources, supprimez les documents dupliqués ou périmés, renouvelez les mots de passe partagés et rejouez le jeu de test connu/inconnu avant d'ouvrir l'outil à un autre service.