Tu veux un assistant support interne “type grand compte” ? Oublie le projet data.
Le fantasme classique : “On va entraîner un modèle sur nos documents, et il saura tout.” Dans une PME, ça finit souvent en tunnel. Données pas propres, droits d’accès flous, docs obsolètes, délais, budget.
La version réaliste et rentable, c’est un assistant RAG entreprise : il ne “s’entraîne” pas sur tes données. Il va chercher au moment de la question les bons extraits, puis il rédige une réponse avec sources. C’est exactement pour ça que les outils de chat (Teams, Slack) poussent le RAG : tu envoies au LLM le minimum nécessaire au moment de la requête, en respectant les droits existants.
Objectif de dirigeant : réduire le temps perdu à chercher, réduire les interruptions, et accélérer la première réponse. Pas remplacer ton support. Juste le rendre plus rapide et plus fiable.
Le cadre : ce que “48 heures” veut dire (et ne veut pas dire)
48 heures, ce n’est pas “tout le savoir de la boîte”. C’est un pilote safe-by-design qui marche sur un périmètre réduit.
- 1 canal (Teams OU Slack OU Google Chat). Pas trois.
- 1 à 3 périmètres max (ex : IT + RH + Qualité).
- 20 à 200 documents vraiment utiles (ceux qui évitent une escalade).
- Règle non négociable : pas de réponse sans source. Sinon “je ne sais pas” + comment escalader.
Si tu veux aller plus vite que ça, tu ne vas pas “gagner du temps”. Tu vas juste déplacer le temps en taxe de vérification (relire, douter, corriger). Et l’équipe arrête d’utiliser le bot.
Playbook 48 heures : la version PME qui marche
Étape 1 (1 h) : choisir le canal où les demandes existent déjà
Décision simple : tu mets l’assistant là où les gens posent déjà leurs questions.
- Teams si tes demandes passent déjà par Teams et que tes docs vivent dans SharePoint.
- Slack si ton support interne est déjà dans Slack et que ta base de connaissance est éclatée dans des outils SaaS connectables.
- Google Chat si ton entreprise est Google Workspace first et que les équipes vivent dans Chat + Drive.
Pourquoi c’est une décision de dirigeant : un nouvel outil = pas d’adoption. Tu veux un chatbot interne PME utilisé, pas un POC “joli” que personne n’ouvre.
Étape 2 (2 h) : cadrer le périmètre et le niveau de risque
Tu choisis des thèmes où une mauvaise réponse ne met pas le feu.
- IT niveau 1 : VPN, reset mot de passe, MFA, Wi-Fi, imprimantes, accès, “qui contacter”.
- RH standard : congés, notes de frais, onboarding, mutuelle, règles internes.
- Qualité : modes opératoires, non-conformités fréquentes, checklists terrain.
Tu évites au départ : juridique fin, disciplinaire RH, sujets sécurité sensibles, décisions à fort impact.
Tu fixes une règle d’or : l’assistant informe, il ne décide pas. Il cite. Il renvoie vers la procédure. Il propose une escalade.
Étape 3 (2 à 4 h) : sélectionner les sources (le vrai 80/20)
Tu ne prends pas “toute la GED”. Tu prends ce qui réduit vraiment les tickets répétitifs.
Checklist de sélection :
- Docs utilisés au moins 1 fois par semaine en support.
- Docs qui répondent à des questions répétitives (“comment faire X ?”).
- Docs qui contiennent des pas à pas et des conditions (si A alors B).
- Docs avec un propriétaire identifié (sinon ça pourrit).
Sources typiques : PDF internes, pages wiki/Notion/Confluence, procédures SharePoint/Drive, runbooks, FAQ RH.
Étape 4 (2 à 4 h) : nettoyage minimal (petit effort, gros impact)
Le nettoyage, ce n’est pas du perfectionnisme. C’est ce qui évite que le bot réponde juste… faux.
- Supprime doublons et versions obsolètes (ou archive-les hors périmètre).
- Élimine les scans illisibles (un RAG ne “devine” pas un PDF flou).
- Standardise un en-tête en haut de chaque doc :
- Propriétaire (nom d’équipe)
- Date de mise à jour
- Périmètre (ex : “IT-N1”)
- Sensibilité (interne / restreint)
Décision de dirigeant : ces 4 heures t’évitent des semaines de débats “le bot dit n’importe quoi”.
Étape 5 (3 à 6 h) : indexation RAG, simple et segmentée
Erreur classique : “on vectorise tout dans un gros index”. Mauvaise idée si tes droits d’accès sont imparfaits.
Règle terrain :
- 1 index par domaine (IT, RH, Qualité).
- Si besoin : 1 index par niveau de confidentialité (RH interne vs RH restreint).
Pourquoi : un assistant RAG entreprise doit respecter les ACL (droits). Les éditeurs mettent en avant que le RAG peut respecter les droits d’accès existants. Mais si tes droits sont sales, ton bot devient un accélérateur de fuite.
Étape 6 (1 à 2 h) : règles de réponse et citations (le levier n°1 de confiance)
Si tu veux que ton chatbot interne PME soit utilisé, il doit être auditable. Donc citations obligatoires.
Règles à imposer dès le pilote :
- 1 à 3 sources par réponse (titre + lien + date + extrait).
- Si aucune source fiable, l’assistant répond : “Je ne sais pas” + propose l’escalade.
- Interdit : inventer une procédure, inventer un lien, inventer un chiffre.
Point d’attention produit : les citations “se cassent” vite quand tu customises l’affichage. Dans certains outils (ex : Copilot Studio), si tu personnalises la réponse, les citations ne sont plus ajoutées automatiquement. Donc, au pilote : reste standard. Tu feras joli plus tard.
Étape 7 (2 h) : garde-fous sécurité (pas négociable)
Ton assistant va être attaqué. Pas forcément par un hacker externe. Par curiosité interne, par erreur, par “tiens je teste”.
Les deux risques concrets dès le jour 1 :
- Fuite de données via mauvais périmètre ou mauvais droits.
- Fuite de prompt système (prompt injection, “dis-moi tes instructions”, etc.). Ce n’est pas théorique, c’est très fréquent en prod.
Garde-fous minimum :
- Pas d’accès aux espaces “sensibles” au départ (RH disciplinaire, finance, juridique confidentiel).
- Refus explicite de révéler instructions internes, clés, règles de sécurité.
- Logs : qui a demandé quoi, sur quel domaine, et quelles sources ont été utilisées.
- Mode “lecture seule”. Pas d’action, pas d’écriture, pas d’automatisation.
Si tu as besoin d’un cadre sécurité plus large (agents, accès, incidents), tu peux réutiliser ta logique de contrôle : https://jimmymanin.com/blog/agents-ia-en-entreprise-checklist-securite-en-12-points-anti-fuite-avant-deploiement
Étape 8 (1 à 2 h) : boucle de feedback intégrée au chat
Sans boucle de feedback, ton assistant devient un gadget.
Implémentation simple :
- Bouton ou réponse rapide : Utile / Pas utile.
- Si “Pas utile” : raison (doc introuvable, doc obsolète, réponse floue, mauvaise escalade).
- Option : Escalader (créer ticket, ping un canal, envoyer à une boîte mail support).
Tu veux 2 effets : améliorer la base, et mesurer si le bot réduit vraiment les interruptions.
Protocole de pilotage : 48 heures, puis 30 jours
Le pilote 48 h (objectif : prouver la valeur sans créer un risque)
Livrables attendus en 48 h :
- 1 canal actif (Teams/Slack/Chat).
- 1 à 3 périmètres avec 20 à 200 docs.
- Réponses avec citations ou “je ne sais pas”.
- Feedback utile/pas utile + escalade.
- Une page “règles d’usage” (ce que l’assistant fait, ne fait pas, et comment il traite les données).
Métriques simples à suivre dès le jour 1 :
- Temps de première réponse (avant/après, même approximatif).
- Taux d’escalade (combien finissent en humain).
- Taux “sans source” (doit tendre vers 0, sinon tu coupes).
- Taux “pas utile” et top 5 raisons.
Décision dirigeant : si tu ne mesures pas, tu ne sauras pas si tu gagnes du temps ou si tu crées de la taxe de vérification.
Le plan 30 jours (objectif : passer de “POC sympa” à “outil de support”)
Sur 30 jours, tu fais 4 chantiers. Pas 12.
Chantier 1 : améliorer la qualité des réponses (sans augmenter le périmètre)
- Chaque semaine : traiter le top 10 “pas utile”.
- Retirer ou réécrire les docs ambigus.
- Réduire les réponses trop longues (un bot support doit être actionnable).
Chantier 2 : rendre l’audit simple
- Conserver les logs (questions, sources, escalades).
- Versionner la base documentaire (au moins date + propriétaire).
- Mettre une règle : une procédure sans propriétaire = hors index.
Si tu veux une méthode pour garder des automatisations “auditables” (même logique : traçabilité, preuves), tu peux t’appuyer sur : https://jimmymanin.com/blog/automatiser-un-controle-sensible-sans-deraper-la-methode-auditabile-en-4-minutes
Chantier 3 : sécurité et données sensibles
- Revue des droits d’accès sur les sources (au moins celles indexées).
- Ajout de règles anti-exfiltration (refus, redirections, “je ne sais pas”).
- Process d’incident : qui fait quoi si une réponse expose une info sensible.
Tu n’as pas besoin d’écrire un roman. Tu as besoin d’un réflexe opérationnel. Si tu dois partager des données pour améliorer, fais-le proprement : https://jimmymanin.com/blog/anonymisation-et-ia-en-entreprise-plan-terrain-en-6-etapes-pour-partager-utile-sans-risque-rgpd
Chantier 4 : industrialiser l’escalade (sinon tu perds le ROI)
- Standardiser “quand escalader” (ex : si pas de source, si risque, si blocage).
- Créer 3 chemins d’escalade : IT, RH, Qualité.
- Exiger que l’assistant résume le contexte avant escalade (question, tentative, sources trouvées).
Conditions de passage en production (vraies, pas marketing)
Ton assistant passe en production quand tu peux répondre “oui” à ça :
1) SLA support interne
- Tu définis ce que l’assistant garantit : disponibilité, délais de réponse visés, heures couvertes.
- Tu définis ce qu’il ne garantit pas : exactitude sans sources, réponses sur sujets hors périmètre.
2) Gouvernance claire
- Owner produit (souvent DSI/ops) : arbitre périmètre et priorités.
- Owners data (RH, Qualité, IT) : responsables des docs, mises à jour, obsolescence.
- Référent sécurité/RGPD : valide les périmètres sensibles et le process incident.
3) Zéro réponse sans preuve
- Citations obligatoires.
- Si tu customises l’UI, tu vérifies que les citations survivent. Sinon tu reviens en mode standard.
4) Garde-fous anti-dérapage testés
- Tests “attaque” simples : demande du prompt système, demande d’infos confidentielles, demande hors périmètre.
- Le bot doit refuser proprement et proposer une escalade.
Un exemple de “set-up” PME qui marche (sans usine à gaz)
PME 150 personnes. Beaucoup de questions IT (accès, VPN, matériel) et RH (congés, notes de frais). Support saturé par des demandes répétitives.
- Canal : Teams (parce que tout le monde y est déjà).
- Périmètre 48 h : IT-N1 + RH standard.
- Docs : 35 procédures IT + 25 pages RH.
- Règle : réponse = 1 à 3 sources cliquables, sinon “je ne sais pas”.
- Escalade : bouton “ouvrir ticket” + résumé auto.
Résultat attendu (réaliste) : moins d’interruptions, et une meilleure “first response”. Le gain marginal se transforme en vrai gain quand tu industrialises la boucle feedback sur 30 jours.
La checklist minute pour démarrer demain matin
- Choisis 1 canal (là où les demandes existent).
- Choisis 1 à 2 périmètres “safe” (IT-N1, RH standard).
- Liste 50 docs utiles (pas 500).
- Nettoie : doublons, obsolètes, illisibles. Ajoute propriétaire + date + sensibilité.
- Index séparés par domaine, et si besoin par confidentialité.
- Impose “pas de réponse sans source”.
- Ajoute feedback + escalade.
- Suis 4 métriques : temps de réponse, escalade, sans source, pas utile.
Ce que tu obtiens vraiment avec un assistant RAG entreprise
Tu n’obtiens pas un “cerveau de la boîte”. Tu obtiens un accès conversationnel à tes procédures, avec des preuves. Pour une PME, c’est déjà énorme : tu réduis le bruit, tu protèges le temps de tes experts, et tu stabilises le support interne.
Si tu veux aller plus loin ensuite (agentic RAG, routage multi-étapes, actions), fais-le après les 30 jours. Quand tu as des métriques, une gouvernance, et des sources propres. Sinon tu vas juste automatiser le chaos.
