La plupart des programmes d'IA générative en entreprise ont commencé par une démo qui a impressionné le comité de direction, puis se sont éteints discrètement. Les exceptions partagent un point commun : elles ont arrêté de vouloir construire « un assistant IA » pour construire quelque chose de beaucoup plus étroit — un chatbot documentaire qui répond sur la base de connaissance interne, à l'intérieur de l'outil que les collaborateurs ont déjà ouvert toute la journée. C'est-à-dire Slack ou Microsoft Teams, avec du RAG (retrieval-augmented generation) derrière.
Cet article passe en revue les cas d'usage qui atteignent réellement la production, la manière d'intégrer proprement un assistant RAG dans Slack et Teams, le problème de droits d'accès qui tue la majorité des pilotes, et le calcul d'un ROI défendable devant une direction financière.
Les cas d'usage qui survivent au passage en production
Un chatbot documentaire fonctionne quand trois conditions sont réunies : les questions sont répétitives, les réponses existent quelque part à l'écrit, et se tromper est agaçant mais pas catastrophique. Passez votre backlog à ce filtre, une short-list apparaît.
- Support IT interne de niveau 1. « Comment demander un token VPN ? », « Quelle procédure pour un portable perdu ? ». Fort volume, réponses documentées, déviation de tickets mesurable.
- RH et administration du personnel. Congés, notes de frais, mobilité, avantages sociaux. Même profil, et cela soulage une équipe structurellement interrompue.
- Avant-vente et réponse à appels d'offres. Réutilisation des propositions passées, questionnaires sécurité, architectures de référence. Ici le gain est en délai de cycle, pas en ETP.
- Onboarding technique et runbooks. Ancré sur le wiki interne, les ADR, les modules Terraform et les post-mortems. C'est le cas d'usage avec la meilleure adoption spontanée : les ingénieurs vivent déjà dans Slack.
- Qualité, conformité et procédures réglementées. ISO, contrôle interne, documentation qualité. Les réponses doivent être sourcées — exactement ce que le RAG apporte et qu'un modèle fine-tuné n'apporte pas.
À l'inverse, méfiez-vous des périmètres « posez n'importe quelle question sur l'entreprise », des chatbots censés calculer des chiffres depuis des tableurs, et du bot client externe en premier projet. Le coût d'une erreur hors du pare-feu est d'un autre ordre.
RAG, fine-tuning ou très grand contexte ?
La question revient à chaque comité. Réponse honnête : ces approches ne traitent pas le même problème.
| Approche | Points forts | Limites | Coût d'exploitation |
|---|---|---|---|
| RAG | Réponses fraîches, sourcées, filtrables par droits, sur un corpus qui bouge chaque semaine | Raisonnement multi-sauts complexe sur de nombreux documents | Continu : pipeline d'ingestion, index, évaluation |
| Fine-tuning | Ton, format de sortie, vocabulaire métier, extraction structurée | Fraîcheur factuelle, citations, contrôle d'accès par utilisateur | Réentraînement à chaque évolution du savoir : intenable pour un wiki |
| Grand contexte (documents entiers dans le prompt) | Petits corpus stables, analyse fine d'un document | Coût et latence proportionnels au corpus ; qualité d'extraction qui se dégrade au milieu des très longs contextes | Faible à construire, élevé par requête |
Pour un assistant sur base de connaissance, le RAG est le choix par défaut. Le grand contexte devient un complément utile une fois le retriever passé : on récupère large, puis on envoie au modèle des sections entières plutôt que des fragments de 300 tokens.
Anatomie d'un pipeline RAG qui tient la route
La version démo — on vectorise tout, similarité cosinus, top-5, prompt — plafonne autour de 60 % de réponses utiles, soit sous le seuil de confiance à partir duquel les utilisateurs reviennent. La version production ajoute quatre choses.
Un découpage qui respecte la structure. On découpe sur les titres, pas sur un nombre fixe de caractères. On réinjecte le titre du document et le chemin de rubrique dans le texte de chaque chunk, pour qu'un paragraphe isolé dise encore de quoi il parle. Et on ne coupe jamais un tableau en deux.
Une recherche hybride. Les vecteurs denses ratent les identifiants exacts : codes d'erreur, références produit, acronymes maison. Combinez BM25 et recherche vectorielle, puis fusionnez les deux classements (la reciprocal rank fusion marche bien et ne demande aucun réglage). C'est généralement le plus gros gain de qualité en une seule action.
Un reranker. On récupère 30 à 50 candidats, on les rescore avec un cross-encoder, on garde les 5 à 8 meilleurs. Quelques dizaines de millisecondes, et une chute spectaculaire du contexte hors-sujet envoyé au modèle.
Citations obligatoires et droit à l'abstention. Le prompt système doit imposer de répondre uniquement à partir des passages fournis, de citer la source de chaque affirmation, et de dire explicitement « je ne sais pas » sinon. Un chatbot qui répond « je n'ai pas trouvé cela dans la documentation » inspire plus confiance qu'un chatbot qui improvise.
Le problème que personne n'anticipe : les droits d'accès
Votre wiki, votre drive et votre outil de ticketing ont des permissions. Votre index vectoriel, par défaut, non. Partez en production sans traiter ce point et, la première fois que le bot cite une revue salariale à un stagiaire, le projet est terminé.
Le motif qui fonctionne : propager les ACL à l'ingestion dans le payload vectoriel, puis filtrer à la requête avec l'identité de l'utilisateur — résolue côté serveur depuis Slack ou Entra ID, jamais depuis ce que l'utilisateur a tapé.
from qdrant_client.models import Filter, FieldCondition, MatchAny
# groupes résolus côté serveur depuis l'IdP, jamais depuis le message
user_groups = directory.groups_for(slack_user_id)
acl = Filter(must=[FieldCondition(
key="acl_groups",
match=MatchAny(any=user_groups + ["tous-collaborateurs"]),
)])
hits = qdrant.query_points(
collection_name="kb",
query=embedding,
query_filter=acl,
limit=40,
)Deux conséquences opérationnelles. D'abord, il faut réindexer quand les droits changent, pas seulement quand le contenu change : un document déplacé dans un espace restreint doit disparaître de l'index en quelques minutes. Ensuite, journalisez chaque réponse avec l'utilisateur, les identifiants de chunks récupérés et les citations. Cette piste d'audit servira à la revue sécurité — et au débogage quotidien.
Slack ou Teams : deux projets d'intégration différents
Le backend de recherche est identique ; la couche de surface ne l'est pas.
| Slack | Microsoft Teams | |
|---|---|---|
| SDK | Bolt (Python/JS), Events API, Socket Mode en dev | Bot Framework SDK + Azure Bot Service, ou Teams AI Library |
| Identité | Slack user ID à mapper sur l'IdP | Entra ID nativement, SSO on-behalf-of disponible |
| Primitives UX | Threads, Block Kit, slash commands, panneau Assistant | Adaptive Cards, message extensions, onglets, contexte réunion |
| Délai jusqu'à la v1 | Rapide : un prototype fonctionnel en une journée | Plus long : manifeste d'application, ressources Azure, validation admin du tenant |
| Friction principale | Fenêtre d'accusé de réception de 3 s, réponses asynchrones obligatoires | Gouvernance et circuit de publication par la DSI |
from slack_bolt import App
app = App(token=os.environ["SLACK_BOT_TOKEN"])
@app.event("app_mention")
def on_mention(event, client, ack):
ack() # répondre en moins de 3 s, puis travailler en asynchrone
thread = event.get("thread_ts", event["ts"])
placeholder = client.chat_postMessage(
channel=event["channel"], thread_ts=thread,
text="Recherche dans la base de connaissance…"
)
result = rag.answer(
question=strip_mention(event["text"]),
user_id=event["user"],
history=load_thread(client, event["channel"], thread),
)
client.chat_update(
channel=event["channel"], ts=placeholder["ts"],
blocks=render_answer_with_citations(result),
)Quelle que soit la plateforme : répondez toujours dans un fil, affichez systématiquement les citations sous forme de liens cliquables vers le document source, et attachez des boutons 👍/👎. Ce retour utilisateur est votre seule source d'évaluation à coût quasi nul.
Calculer un ROI défendable
Oubliez la slide fournisseur qui multiplie un effectif par un pourcentage de productivité. Construisez le chiffre par le bas, et mesurez une baseline avant le lancement.
Gain brut mensuel =
Q (questions traitées par le bot par mois)
× d (taux de déviation : part réellement résolue sans humain)
× t (temps humain moyen économisé par question, en heures)
× c (coût horaire chargé de la personne qui aurait répondu)
Gain net mensuel = gain brut − (inférence + base vectorielle + hébergement
+ run du pipeline d'ingestion
+ build amorti + product ownership)Trois disciplines rendent ce calcul crédible. Mesurez Q et t sur l'existant : volumétrie de tickets par catégorie avant la mise en service, et temps médian de résolution des tickets que vous visez. Ne postulez pas d : déduisez-le des taux de pouce levé et de la baisse de tickets sur les catégories ciblées, et attendez-vous à ce qu'il soit nettement inférieur à votre estimation initiale. Comptez honnêtement le run : les tokens d'inférence sont rarement la ligne dominante. Un product owner à temps partiel qui cure le contenu et analyse les échecs, si — et c'est cette ligne qui détermine réellement le succès.
Les bénéfices secondaires sont réels mais plus difficiles à comptabiliser : onboarding accéléré, moins d'interruptions des experts seniors, et — largement sous-estimé — le fait qu'un chatbot révèle précisément quelle documentation est manquante ou contradictoire. Plusieurs équipes tirent davantage de valeur de ce diagnostic que des réponses elles-mêmes.
Évaluation et observabilité
Traitez l'assistant comme n'importe quel service en production, avec deux couches en plus. Côté recherche, maintenez un golden set de 100 à 200 questions réelles avec les documents sources attendus, et suivez le recall@k en CI dès que le chunking, les embeddings ou le reranker changent. Côté génération, mesurez la groundedness — chaque affirmation est-elle appuyée par un passage récupéré — via un LLM-as-judge sur échantillon, plus une relecture humaine de tous les pouces baissés.
Instrumentez aussi les classiques : percentiles de latence bout en bout, coût en tokens par conversation, taux d'abstention, part de questions sans aucun document au-dessus du seuil (votre indicateur de trou documentaire), et utilisateurs actifs hebdomadaires par équipe. Les courbes d'adoption par équipe en disent plus long sur la valeur que n'importe quel score de satisfaction agrégé.
Un plan réaliste à 90 jours
Semaines 1 à 3 : choisir un domaine et un responsable, inventorier les sources, collecter 150 questions réelles avec les réponses attendues, construire le pipeline d'ingestion et l'index hybride. Semaines 4 à 7 : API RAG avec filtrage ACL, reranking, citations et abstention ; itérer sur le golden set jusqu'à dépasser nettement ce que rendrait une recherche par mots-clés. Semaines 8 à 10 : intégration Slack ou Teams, boutons de feedback, journalisation complète, revue sécurité et DPO. Semaines 11 à 13 : pilote sur 30 à 80 utilisateurs, triage hebdomadaire des échecs, correction de la documentation que le bot révèle défaillante, puis décision d'extension avec des chiffres réels en main.
Un dernier point qui compte pour les organisations européennes : rien dans cette architecture n'oblige à envoyer votre savoir interne hors de l'UE. Des modèles ouverts ou européens servis sur une infrastructure GPU hébergée en Europe, une base vectorielle auto-hébergée et un pipeline d'ingestion dans votre propre VPC produisent un système dont la qualité dépend d'abord du retrieval — pas de la taille du modèle. Travaillez la recherche d'abord, et le choix du modèle redevient un détail interchangeable.