19 % du temps perdu à chercher des informations internes
Selon une étude McKinsey reprise par l'IDC, les salariés consacrent en moyenne 19 % de leur temps de travail à chercher des informations internes — procédures, politiques RH, fiches produits, contacts, documentation IT. Pour un employé à 40 heures par semaine, cela représente 7h36 perdues chaque semaine.
Ramenée à une équipe, l'équation devient brutale :
Le problème n'est pas que vos collaborateurs manquent d'informations — au contraire. SharePoint, Confluence, Notion, Google Drive, emails, wikis internes : les entreprises croulent sous la documentation. Le problème est que cette information est introuvable en pratique. Les moteurs de recherche internes reposent sur des mots-clés exacts, nécessitent de savoir où chercher, et retournent des listes de documents plutôt que des réponses.
Un chatbot interne RAG (Retrieval-Augmented Generation) résout ce problème à la racine : l'employé pose sa question en langage naturel, le système retrouve les passages pertinents dans l'ensemble de votre base documentaire, et formule une réponse directe, sourcée, contextuelle — en moins de 5 secondes.
Comment fonctionne le RAG : Retrieval-Augmented Generation
Le problème des LLM sans contexte
Un LLM (Large Language Model) comme GPT-4 ou Mistral connaît le monde jusqu'à sa date de coupure d'entraînement. Il ne connaît pas vos procédures internes, vos produits, votre organigramme, vos tarifs, vos contrats-types. Si vous lui posez une question sur votre politique de congés, il va halluciner — inventer une réponse plausible mais fausse.
Le RAG résout ce problème en deux temps : d'abord retrouver les informations pertinentes dans votre base documentaire, puis générer une réponse ancrée dans ces informations réelles. Le modèle ne peut répondre qu'avec ce qu'on lui a fourni comme contexte — plus d'hallucinations sur vos données internes.
Architecture RAG — schéma du flux
INGESTION (une fois, puis synchronisation continue)
┌─────────────────────────────────────────────────────┐
│ Documents sources │
│ (SharePoint / Notion / PDF / Confluence / Drive) │
│ │ │
│ ▼ │
│ Découpage en chunks │
│ (paragraphes de 200-500 tokens) │
│ │ │
│ ▼ │
│ Modèle d'embeddings │
│ (text-embedding-3-small / nomic-embed) │
│ │ │
│ ▼ │
│ Base vectorielle │
│ (Chroma / Pinecone / Weaviate / pgvector) │
└─────────────────────────────────────────────────────┘
REQUÊTE (temps réel, <2 secondes)
┌─────────────────────────────────────────────────────┐
│ Question employé │
│ "Comment déclarer une note de frais ?" │
│ │ │
│ ▼ │
│ Embedding de la question │
│ │ │
│ ▼ │
│ Recherche sémantique dans la base vectorielle │
│ → top 5 chunks les plus proches │
│ │ │
│ ▼ │
│ Construction du prompt enrichi │
│ [Contexte: chunks 1 à 5] + [Question] │
│ │ │
│ ▼ │
│ LLM génère la réponse │
│ (ancrée dans les chunks fournis) │
│ │ │
│ ▼ │
│ Réponse + sources citées │
│ "Selon la procédure RH v3.2 (oct. 2025)..." │
└─────────────────────────────────────────────────────┘
Concepts clés à comprendre
| Concept | Définition simple | Analogie |
|---|---|---|
| Chunk | Morceau de document découpé (200-500 tokens) | Paragraphe d'un livre |
| Embedding | Représentation numérique du sens d'un texte (vecteur de 1536 dimensions) | Coordonnées GPS du sens d'une phrase |
| Base vectorielle | Base de données spécialisée pour stocker et comparer des embeddings | Google Maps sémantique |
| Retrieval | Récupération des chunks les plus proches sémantiquement de la question | Recherche des pages les plus pertinentes |
| Augmented Generation | Génération de réponse par le LLM enrichie du contexte récupéré | Réponse basée sur les pages trouvées |
Pourquoi la recherche sémantique change tout
Un moteur de recherche classique cherche des mots-clés exacts. Si votre procédure parle de "remboursement des frais de déplacement" et que l'employé tape "note de frais trajet", il ne trouvera rien. La recherche sémantique comprend que les deux phrases veulent dire la même chose — parce qu'elles ont des embeddings proches dans l'espace vectoriel. C'est cette capacité à comprendre le sens, indépendamment des mots exacts utilisés, qui rend les chatbots RAG radicalement plus utiles que les wikis et les moteurs de recherche internes.
Cas d'usage par département : RH, IT, commercial, juridique, finance
Un chatbot interne n'est pas un outil généraliste — sa valeur se concentre sur des flux d'information très spécifiques à chaque département. Voici les cas d'usage les plus impactants, département par département.
Ressources Humaines
Les RH répondent aux mêmes questions des centaines de fois par an. Un chatbot RAG formé sur vos documents RH peut traiter 80 % de ces questions sans intervention humaine :
- Congés et absences : "Combien de jours de congés me reste-t-il ?" / "Comment poser un congé maternité ?" / "Quel est le délai de prévenance pour un congé sans solde ?"
- Mutuelle et prévoyance : "Quels soins sont remboursés par notre mutuelle ?" / "Comment déclarer un sinistre prévoyance ?"
- Onboarding : Nouveaux arrivants qui posent les 50 questions classiques de leur première semaine — le chatbot répond 24h/24 sans mobiliser le manager ou les RH
- Procédures administratives : Notes de frais, badges, accès, tickets restaurant, participation, intéressement
- Organigramme et contacts : "Qui est le responsable de la compta ?" / "Quel est le contact RH pour la région Bretagne ?"
IT et Support Technique
Le support IT est le cas d'usage ROI le plus rapide. Les questions de niveau 1 représentent 60 à 75 % des tickets IT, et la grande majorité ont des réponses dans votre base de connaissance existante :
- Résolution d'incidents courants : "Mon imprimante ne répond plus" / "Comment configurer le VPN depuis chez moi ?" / "Mon accès SharePoint est refusé"
- Procédures IT : Réinitialisation de mot de passe, installation logiciels autorisés, paramétrage email sur mobile
- Inventaire matériel et logiciels : "Quel antivirus est installé sur nos postes ?" / "Où trouver la licence Office ?"
- Sécurité et bonnes pratiques : Que faire si je clique sur un lien suspect ? Comment reconnaître un phishing ?
Commercial et Avant-Vente
- Fiches produits et services : Caractéristiques techniques, compatibilités, disponibilités, délais de livraison
- Tarifs et conditions commerciales : Grilles tarifaires, remises autorisées par profil client, conditions de paiement
- Références clients : "Avons-nous des clients dans le secteur pharmaceutique ?" / "Quels cas clients dans l'industrie agroalimentaire ?"
- Objections fréquentes : Réponses aux objections clients les plus courantes, arguments de vente, comparatifs concurrents
Juridique et Conformité
- Modèles de contrats : Trouver le bon modèle de NDA, CGV, contrat de prestation selon le contexte
- Clauses standard : "Quelle clause RGPD utiliser pour un contrat de sous-traitance ?" / "Notre clause de responsabilité est-elle dans le modèle standard ?"
- DPA et conformité RGPD : Quels fournisseurs ont un DPA signé ? Quel traitement nécessite une DPIA ?
- Veille réglementaire interne : Questions sur les obligations sectorielles, certifications, normes applicables
Finance et Comptabilité
- Procédures notes de frais : Plafonds par catégorie, justificatifs requis, délai de remboursement, outil de saisie
- Budgets et centres de coûts : Qui peut engager quelle dépense jusqu'à quel montant ?
- Fournisseurs et paiements : Coordonnées fournisseurs, délais de paiement habituels, processus de validation des factures
- Clôture mensuelle : Checklist des tâches de clôture, dates limites, interlocuteurs
| Département | Volume questions traitables | Économie temps estimée | ROI délai |
|---|---|---|---|
| IT Support | 65–75 % des tickets N1 | 10–20 h/semaine (équipe 5 IT) | 2–4 mois |
| RH | 70–80 % des questions courantes | 5–15 h/semaine (équipe 3 RH) | 3–5 mois |
| Commercial | 50–60 % des questions produit/tarif | 2–6 h/semaine/commercial | 2–3 mois |
| Juridique | 40–55 % des demandes de modèles | 3–8 h/semaine (service juridique) | 4–6 mois |
| Finance | 55–65 % des questions procédurales | 3–7 h/semaine (équipe compta) | 3–5 mois |
Connecter vos sources documentaires : SharePoint, Notion, Confluence, Google Drive, PDF
La force d'un chatbot RAG réside dans sa capacité à agréger l'ensemble de votre patrimoine documentaire, quelle que soit sa localisation. Voici comment connecter chaque source majeure.
SharePoint et OneDrive (Office 365)
C'est la source la plus courante dans les entreprises françaises utilisant Microsoft 365. La connexion s'effectue via l'API Microsoft Graph :
- Authentification : App Registration Azure AD avec permissions
Sites.Read.AlletFiles.Read.All - Formats supportés : Word (.docx), Excel (.xlsx), PowerPoint (.pptx), PDF, OneNote
- Synchronisation : Webhook sur les modifications ou polling toutes les heures — les documents mis à jour sont re-vectorisés automatiquement
- RBAC : Les permissions SharePoint peuvent être répliquées dans le chatbot — un utilisateur ne voit que les documents auxquels il a accès dans SharePoint
Notion
- Connexion : API officielle Notion (notion.so/my-integrations) — token d'intégration avec accès en lecture sur les pages concernées
- Granularité : Notion exporte page par page — prévoir un script d'ingestion récursif pour parcourir les bases de données et les sous-pages
- Limites : L'API Notion est soumise à des rate limits (3 req/s) — pour de grandes bases Notion (plus de 1000 pages), l'ingestion initiale prend 2 à 6 heures
- Synchronisation : Polling quotidien sur
last_edited_time— les pages modifiées sont re-indexées
Confluence (Atlassian)
- Connexion : API REST Confluence avec token API Atlassian ou OAuth 2.0
- Structuration : L'arborescence Confluence (espaces → pages → sous-pages) se mappe bien aux namespaces de la base vectorielle pour le RBAC par espace
- Formats : Pages Confluence (HTML → texte), attachements PDF et Word
- Avantage : Confluence étant structuré pour la documentation technique, la qualité des chunks est généralement meilleure que pour des documents Office non structurés
Google Drive et Google Workspace
- Connexion : Google Drive API v3 avec Service Account — permissions en lecture sur les dossiers partagés concernés
- Formats : Google Docs (export texte), Sheets (export CSV), Slides (export texte), PDF, Word, Excel
- Synchronisation : Push notifications via Google Drive webhooks ou polling sur
modifiedTime - RBAC : Répliquer les permissions de partage Drive est plus complexe qu'avec SharePoint — prévoir un mapping manuel des groupes Google Workspace vers les rôles du chatbot
Documents locaux et PDF
| Format | Méthode d'extraction | Qualité extraction | Notes |
|---|---|---|---|
| PDF texte natif | PyPDF2, pdfplumber | Excellente | PDF exportés depuis Word/InDesign |
| PDF scanné | OCR (Tesseract, Azure AI Document Intelligence) | Bonne à variable | Qualité dépend du scan original |
| Word (.docx) | python-docx | Excellente | Préserve les titres et la structure |
| Excel (.xlsx) | openpyxl + conversion texte | Moyenne | Les tableaux complexes perdent leur structure |
| PowerPoint (.pptx) | python-pptx | Bonne | Texte des slides uniquement — pas les images |
| Emails (Outlook/Gmail) | Graph API / Gmail API | Bonne | Attention au volume — filtrer par dossier/label |
Sécurité et contrôle d'accès : qui voit quoi
Le problème du chatbot sans RBAC
Un chatbot interne sans contrôle d'accès est un risque majeur de fuite d'information interne. Sans RBAC (Role-Based Access Control), un commercial pourrait demander "quels sont les salaires des managers ?" et obtenir une réponse puisée dans les documents RH confidentiels. Un prestataire externe pourrait accéder aux stratégies commerciales internes. Un junior pourrait consulter des documents réservés à la direction.
La sécurité d'un chatbot RAG se joue à deux niveaux :
Niveau 1 — RBAC au niveau de l'ingestion (recommandé)
Chaque chunk ingéré dans la base vectorielle est taggé avec les permissions requises pour y accéder :
{
"chunk_id": "rh-salaires-2025-p3",
"content": "La grille salariale 2025 prévoit...",
"metadata": {
"source": "SharePoint/RH/Confidentiel/grille-salariale-2025.docx",
"allowed_roles": ["rh-manager", "drh", "direction"],
"department": "rh",
"classification": "confidentiel"
}
}
Au moment de la requête, le système filtre les chunks récupérables selon le rôle de l'utilisateur authentifié. Un commercial avec le rôle commercial ne verra jamais les chunks taggés rh-manager.
Niveau 2 — Isolation par namespace (alternative)
Pour les architectures plus simples ou les petites équipes, on crée des collections séparées dans la base vectorielle : une collection par département ou par niveau de confidentialité. Chaque utilisateur n'a accès qu'aux collections correspondant à son rôle. Plus simple à implémenter, mais moins granulaire.
| Méthode RBAC | Granularité | Complexité | Recommandé pour |
|---|---|---|---|
| RBAC par chunk (metadata filter) | Document par document | Élevée | ETI, entreprises avec données sensibles mixtes |
| RBAC par namespace/collection | Département entier | Moyenne | PME avec séparation claire par service |
| Chatbots séparés par département | Département entier | Faible (mais coût x N) | Déploiements pilotes, budgets limités |
Authentification et SSO
- SSO via Active Directory / Azure AD : L'utilisateur s'authentifie avec ses identifiants d'entreprise — les rôles RBAC sont récupérés depuis ses groupes AD
- SAML 2.0 / OpenID Connect : Pour les intégrations avec les portails intranet et les applications métier
- JWT tokens : Pour les interfaces web dédiées — chaque session porte les permissions de l'utilisateur connecté
Audit logs et traçabilité
Tout chatbot interne d'entreprise doit logger les requêtes (sans en compromettre la confidentialité) :
- Qui a demandé quoi : user_id, timestamp, question (éventuellement anonymisée), sources citées dans la réponse
- Détection d'abus : Alertes si un utilisateur interroge massivement des documents hors de son périmètre habituel
- Amélioration continue : Les questions sans bonne réponse (thumbs down des utilisateurs) alimentent la liste des documents manquants à ajouter
- Conformité RGPD : Les questions des employés peuvent contenir des données personnelles — définir la politique de rétention des logs (30 à 90 jours recommandés)
Déploiement : Teams, Slack, intranet, ou interface dédiée
Le choix de l'interface de déploiement est stratégique : le meilleur chatbot du monde ne sera pas adopté s'il nécessite d'ouvrir une nouvelle application. L'objectif est de s'intégrer dans les outils que vos équipes utilisent déjà.
Microsoft Teams Bot
Si votre entreprise utilise Microsoft 365, Teams est l'interface idéale. Le taux d'adoption est maximal car les employés sont déjà dans Teams toute la journée :
- Déploiement : Azure Bot Service + Teams App Manifest — le chatbot apparaît comme un contact dans Teams
- Authentification : SSO automatique via Azure AD — l'identité de l'utilisateur est transmise sans login supplémentaire
- Canaux : Chat privé avec le bot, ou ajout du bot dans des canaux d'équipe thématiques ("Canal IT-Support", "Canal RH-Questions")
- Adaptive Cards : Affichage enrichi des réponses avec boutons, tableaux, liens directs vers les documents sources
- Limitations : L'API Teams Bot a des quotas de débit — pour de grandes entreprises (1000+ utilisateurs simultanés), prévoir un système de queue
Slack Bot
- Déploiement : Slack App avec OAuth 2.0 — installation en quelques minutes via le Slack App Directory ou en privé pour votre workspace
- Interactions : Mentions (@bot), messages directs, commandes slash (/askhr, /askit)
- Intégrations Slack : Le bot peut poster des résumés dans des canaux, envoyer des notifications proactives ("Nouvelle procédure IT publiée")
- Blocks : Interface riche avec boutons de feedback, liens cliquables, formatage Markdown
Widget Intranet
- Principe : Un widget JavaScript intégré dans votre intranet existant (SharePoint, Confluence, portail custom)
- Avantage : Contextuel — un widget sur la page "Procédures RH" peut être configuré pour interroger uniquement la base documentaire RH
- Implémentation : Quelques lignes de JavaScript + une API REST exposée par votre backend RAG
- Authentication : Le cookie de session intranet est transmis pour l'authentification SSO
Interface Web Dédiée (Open WebUI)
- Open WebUI : Interface open-source, similaire à ChatGPT, self-hostée sur votre infrastructure. Supporte nativement Ollama et les API OpenAI-compatibles.
- Avantage : Interface familière (similaire à ChatGPT), historique des conversations, multi-modèles, gestion des utilisateurs intégrée
- Déploiement : Docker en quelques minutes — un reverse proxy nginx devant pour l'authentification LDAP/SAML
- Adapté pour : Les entreprises qui veulent une interface IA centralisée pour tous les usages, pas seulement la recherche documentaire
API REST interne
Pour les entreprises avec des développeurs internes, exposer le chatbot RAG via une API REST permet de l'intégrer dans n'importe quel outil existant :
- ERP (SAP, Sage) : répondre à des questions directement depuis les fiches clients ou fournisseurs
- CRM (Salesforce, HubSpot) : accès aux fiches produits et arguments commerciaux depuis la fiche prospect
- ITSM (Jira, ServiceNow) : suggestion automatique de résolution au premier contact, alimentée par la base de connaissance
| Interface | Adoption utilisateur | Complexité déploiement | SSO natif | Idéal pour |
|---|---|---|---|---|
| Teams Bot | Très haute (M365) | Moyenne | Oui (Azure AD) | Entreprises Microsoft 365 |
| Slack Bot | Très haute (Slack) | Faible | Oui (Slack OAuth) | Startups, scale-ups Slack-first |
| Widget Intranet | Haute (contextuel) | Faible | Via intranet | Intranet actif avec trafic |
| Open WebUI | Moyenne | Très faible | LDAP/SAML | Déploiement rapide, budget limité |
| API REST | Via intégrations | Faible | Via app hôte | Intégration ERP/CRM/ITSM |
Solutions du marché vs. custom : Open WebUI, Flowise, Langchain
Le marché des outils RAG a explosé en 2024-2025. Entre les solutions no-code, les frameworks open-source et les plateformes SaaS enterprise, le choix peut être déstabilisant. Voici un panorama structuré.
Solutions no-code / low-code
Flowise
- Principe : Éditeur visuel no-code pour construire des pipelines RAG par drag-and-drop
- Forces : Déploiement en 30 minutes, connecteurs natifs pour toutes les bases vectorielles, support des LLM locaux et cloud, self-hostable
- Limites : Moins flexible pour des logiques métier complexes, RBAC limité dans la version communautaire
- Idéal pour : PME sans développeurs, preuves de concept rapides, départements pilotes
- Licence : Open-source (Apache 2.0) + version cloud payante
Botpress
- Principe : Plateforme no-code de chatbots avec module RAG intégré
- Forces : Interface de gestion des conversations, analytics, multi-canal (Teams, Slack, Web), RBAC
- Limites : Coût plus élevé, hébergement cloud par défaut (Botpress Cloud)
- Idéal pour : Entreprises voulant une solution clé en main managée, sans équipe technique
- Prix : À partir de 495 $/mois (équipes)
Frameworks open-source
LangChain
- Principe : Framework Python pour orchestrer des pipelines LLM, RAG, agents
- Forces : Écosystème très riche, intégrations natives avec tous les LLM et bases vectorielles, contrôle total
- Limites : Courbe d'apprentissage significative, abstraction parfois contre-productive pour des cas simples
- Idéal pour : Équipes avec développeurs Python, besoins complexes (agents multi-étapes, logique métier avancée)
LlamaIndex
- Principe : Framework Python spécialisé RAG (plus centré "data" que LangChain)
- Forces : Excellent pour l'ingestion de sources hétérogènes, stratégies de chunking avancées, retrieval hybride (sémantique + keyword)
- Idéal pour : Bases documentaires volumineuses ou structurées complexement (PDF techniques, documents légaux)
Open WebUI
- Principe : Interface web open-source compatible Ollama / API OpenAI, avec gestion RAG intégrée
- Forces : Installation Docker en 5 minutes, interface familière ChatGPT, gestion des utilisateurs, support des documents (RAG natif)
- Limites : RAG moins avancé que LangChain/LlamaIndex — adapté pour des cas simples
- Idéal pour : Déploiement rapide, LLM locaux avec Ollama, PME sans besoins RAG complexes
Solutions enterprise
| Solution | Type | Hébergement | Prix indicatif | Point fort |
|---|---|---|---|---|
| Microsoft Copilot for M365 | SaaS intégré | Azure (EU possible) | 30 $/user/mois | Intégration native SharePoint/Teams/Outlook |
| Glean | SaaS enterprise | Cloud multi-région | ~15–25 $/user/mois | Connecteurs 100+ sources, RBAC automatique |
| Guru | Knowledge base + IA | Cloud (USA) | 10–20 $/user/mois | Vérification humaine des réponses intégrée |
| Flowise self-hosted | Open-source | Vos serveurs | Infrastructure seulement | Contrôle total, données sur site |
| Custom LangChain/LlamaIndex | Sur mesure | Vos serveurs / VPC | Développement 8–30k€ | Flexibilité maximale, RBAC custom |
Notre recommandation selon le profil
- PME 10-50 salariés, sans IT : Microsoft Copilot for M365 si déjà sur Office 365, sinon Flowise self-hosted + Ollama
- PME 50-200 salariés, avec IT : Flowise self-hosted ou solution custom LangChain selon la complexité du RBAC requis
- ETI 200-1000 salariés : Glean ou solution custom sur Azure/AWS — le budget justifie une solution intégrée et le RBAC avancé
- Données ultra-sensibles (santé, défense, juridique) : LLM on-premise obligatoire (Ollama + Mistral Large ou Llama 3.3) + LlamaIndex custom
Cas Groupama et grandes entreprises : résultats mesurés
Groupama — 5 000 employés, 70 % de requêtes IT résolues sans ticket
Groupama, groupe d'assurance mutuelle français, a déployé un chatbot interne RAG pour son support IT en 2024. Le contexte : un support IT centralisé recevant des milliers de tickets par mois, dont la grande majorité concernait des questions récurrentes avec des réponses dans la base de connaissance ITSM existante.
Architecture déployée :
- Base documentaire : 2 800 articles de base de connaissance ServiceNow + 400 procédures IT internes
- Modèle LLM : GPT-4 via Azure OpenAI Service (région EU Ouest, conformité données assurée)
- Base vectorielle : Azure AI Search (Cognitive Search) avec indexation hybride sémantique + keyword
- Interface : Bot Teams déployé sur tous les postes via Microsoft 365
- RBAC : intégration Active Directory — accès aux procédures selon le périmètre géographique et le rôle
Résultats après 6 mois :
Autres cas documentés dans les grandes entreprises
| Entreprise | Secteur | Usage | Résultat clé |
|---|---|---|---|
| SNCF | Transport | Chatbot RH interne (65 000 agents) | –60 % appels RH pour questions administratives |
| Société Générale | Finance | Assistant conformité réglementaire | –70 % du temps de recherche réglementaire pour les juristes |
| Airbus | Aérospatial | Accès documentation technique ingénierie | Économie de 2,5h/semaine par ingénieur |
| Accor Hotels | Hôtellerie | Onboarding et procédures opérationnelles | Réduction de 40 % du temps d'onboarding nouveaux employés |
Transposition PME : ce qui change à plus petite échelle
Les grandes entreprises ont des budgets IT conséquents et des équipes dédiées. Mais le ratio coût/bénéfice d'un chatbot interne RAG est souvent meilleur dans les PME qu'en grande entreprise, pour deux raisons :
- La base documentaire est plus petite et maîtrisable : une PME de 50 personnes a rarement plus de 500 documents actifs — le déploiement est plus rapide et la qualité des réponses est plus facile à maintenir
- L'impact par personne est plus élevé : dans une PME, chaque heure gagnée par un expert est précieuse — les experts sont rares et ne peuvent pas se permettre de répondre 10 fois par jour aux mêmes questions
Plan de déploiement en 6 semaines
Un plan de déploiement structuré pour une PME de 50 à 300 salariés, avec un département pilote. Budget estimé : 8 000 à 20 000 € selon la complexité de l'architecture choisie.
Semaine 1 — Audit des sources documentaires et définition du périmètre
- Inventaire documentaire complet
Lister toutes les sources d'information internes : SharePoint, Confluence, Notion, G-Drive, répertoires réseau, wikis, etc. Volume, format, fréquence de mise à jour, responsable de chaque source. - Audit qualité documentaire
Identifier les doublons, les documents obsolètes (plus de 2 ans sans modification), les contradictions entre versions. Nettoyer avant d'ingérer — c'est la condition sine qua non de la qualité des réponses. - Définition du département pilote
Choisir un département avec : (a) un volume élevé de questions répétitives, (b) une base documentaire propre et structurée, (c) un responsable sponsor du projet. IT Support ou RH sont les meilleurs candidats pour un premier déploiement. - Définition des rôles RBAC et des niveaux d'accès
Cartographier qui doit avoir accès à quoi. Documenter les règles avant de les implémenter — cette étape est souvent sous-estimée.
Semaine 2 — Ingestion et vectorisation
- Mise en place de l'infrastructure
Déploiement de la base vectorielle (Chroma, pgvector ou Azure AI Search selon l'architecture choisie). Configuration du modèle d'embeddings. Mise en place de l'environnement de développement. - Développement des connecteurs de sources
Scripts d'ingestion pour chaque source : SharePoint API, Notion API, extraction PDF/Word. Tests sur un sous-ensemble de documents. - Ingestion initiale et tagging RBAC
Ingestion complète de la base documentaire du département pilote. Application des métadonnées RBAC sur chaque chunk. Vérification de la couverture (tous les documents ont bien été ingérés). - Tests de retrieval
Tester manuellement 20 à 30 questions types pour vérifier que les bons chunks sont récupérés. Ajuster la stratégie de chunking si nécessaire (taille des chunks, overlap).
Semaine 3 — Chatbot v1 et département pilote
- Développement du chatbot
Intégration LLM (OpenAI API, Azure OpenAI, ou Ollama local). Développement du prompt système (persona, instructions de citation des sources, gestion des questions hors périmètre). Interface : Teams Bot, Slack Bot, ou Open WebUI selon l'environnement. - Déploiement sur le groupe pilote
10 à 20 utilisateurs du département pilote. Session de démonstration de 30 minutes + guide utilisateur d'une page. - Collecte des retours
Feedback 👍/👎 sur chaque réponse. Log des questions sans bonne réponse. Entretiens informels avec 3 à 5 utilisateurs pilotes après 5 jours d'usage.
Semaine 4 — Ajustements et RBAC complet
- Analyse des retours pilote
Questions mal répondues → identifier les documents manquants ou à améliorer. Ajustement du prompt système si la formulation des réponses ne convient pas aux utilisateurs. - Enrichissement de la base documentaire
Ajout des documents manquants identifiés lors du pilote. Harmonisation des documents contradictoires. Re-ingestion des documents mis à jour. - Implémentation RBAC complète
Intégration SSO (Azure AD, LDAP). Tests de non-régression RBAC : vérifier que chaque profil utilisateur ne peut accéder qu'aux documents autorisés. Audit log en place.
Semaine 5 — Déploiement à l'ensemble des équipes
- Communication interne
Email de lancement, message sur le canal Teams/Slack de l'entreprise. Courte vidéo de démonstration (2 minutes). FAQ sur les données et la confidentialité. - Formation des administrateurs documentaires
Formation de 1h pour les responsables de chaque source documentaire : comment ajouter de nouveaux documents, comment signaler un document obsolète, comment consulter les statistiques d'usage. - Déploiement progressif
Si possible, déployer par vague : département IT puis RH puis commercial. Cela permet de gérer la charge et de corriger les problèmes avant le déploiement global.
Semaine 6 — Monitoring et enrichissement continu
- Mise en place du tableau de bord
Métriques clés à suivre : nombre de requêtes/jour, taux de satisfaction (👍/👎), questions sans réponse satisfaisante, documents les plus consultés, utilisateurs actifs. - Synchronisation automatique des sources
Configuration des webhooks ou des tâches de synchronisation planifiées pour chaque source documentaire. Alertes si une source n'est plus accessible. - Processus d'amélioration continue
Revue hebdomadaire des questions mal répondues. Processus pour les équipes de signaler des informations manquantes. Revue mensuelle de la satisfaction globale.
| Semaine | Livrable principal | Responsable | Critère de succès |
|---|---|---|---|
| S1 | Audit documentaire + périmètre défini | Chef de projet + métier | Base documentaire nettoyée, RBAC cartographié |
| S2 | Base vectorielle alimentée | Technique | 100 % documents ingérés, retrieval testé sur 30 questions |
| S3 | Chatbot v1 en pilote (20 users) | Technique + métier | Satisfaction pilote ≥ 3,5/5 après 5 jours |
| S4 | RBAC complet + base enrichie | Technique | 0 accès non autorisé dans les tests RBAC |
| S5 | Déploiement général | Chef de projet + communication | Taux d'adoption ≥ 40 % après 1 semaine |
| S6 | Monitoring opérationnel | Technique + admin docs | Synchronisation auto active, dashboard en place |