Comment nous avons ajouté un assistant IA à une plateforme SaaS — sans la casser

Toutes les équipes SaaS avec qui nous discutons finissent par prononcer la même phrase à voix haute : « On devrait mettre un assistant IA là-dedans. » Parfois c'est la pression du conseil, parfois le lancement d'un concurrent, parfois une conviction sincère. L'intéressant n'est jamais l'idée — presque tout le monde l'a. L'intéressant, c'est l'écart entre cette phrase et une fonctionnalité sur laquelle de vrais utilisateurs comptent réellement. Voici l'histoire d'une équipe qui a franchi cet écart, et des décisions peu glamour qui l'y ont menée.

Une remarque avant de commencer : nous avons anonymisé le client et arrondi les chiffres. Il s'agit d'une petite entreprise SaaS B2B rentable — moins de vingt personnes — qui vend un outil de flux de travail à des équipes opérationnelles. Nous avons modifié assez de détails pour que vous ne la reconnaissiez pas, mais la forme du projet est exactement telle qu'elle s'est déroulée. Les chiffres sont illustratifs, non audités ; nous préférons vous montrer le schéma plutôt que d'embellir un graphique.

Nous rédigeons ceci parce que le projet est un exemple presque parfait de la façon dont ces choses se passent réellement. Cela ne s'est pas déroulé comme le prévoyait la présentation de lancement. Cela s'est mieux passé — mais seulement parce que nous étions prêts à supprimer la première version.

La situation : deux problèmes sous un même costume

Lorsque le fondateur nous a contactés pour la première fois, la demande était simple : « Nous voulons un chatbot IA dans l'application. » C'est là que démarrent la plupart des projets, et c'est aussi là que la plupart déraillent en silence. « Chatbot IA » n'est pas un objectif, c'est une forme. Notre première tâche a donc été de déterminer quel problème le chatbot était censé résoudre — et s'il s'agissait seulement d'un seul problème.

Ce n'en était pas un. Sous cette unique demande se cachaient deux douleurs totalement différentes. La première, la charge de support : une équipe customer success de deux personnes se noyait sous les tickets répétitifs — « comment exporter ceci », « où est le réglage pour cela », « pourquoi mon rapport n'a-t-il pas tourné ». Environ 60 % des tickets entrants étaient des questions déjà traitées quelque part dans leur documentation d'aide. La seconde douleur était plus discrète et plus coûteuse : l'activation. Leur produit possédait une fonctionnalité vraiment puissante enfouie à trois clics de profondeur que presque personne ne découvrait seul. Les utilisateurs qui la trouvaient restaient des années. Ceux qui ne la trouvaient pas partaient dans les deux premiers mois.

Même costume, deux problèmes. Et ils tiraient dans des directions opposées. Un bot de support veut détourner les questions et s'effacer. Un assistant d'activation veut lancer des conversations et pousser les gens vers des choses qu'ils n'ont pas demandées. Si nous avions construit « un chatbot IA » sans séparer ces deux volets, nous aurions bâti quelque chose qui faisait mal les deux métiers.

Réduire le périmètre à quelque chose que nous pouvions terminer

Face à deux problèmes, la tentation est de bâtir un grand assistant qui gère les deux dès le premier jour. Nous avons dissuadé l'équipe. Non parce que la vision était mauvaise, mais parce qu'un « assistant à tout faire » de six mois est exactement le genre de projet livré en retard, qui fait pschitt et rend tout le monde nerveux vis-à-vis de l'IA pendant les deux années suivantes.

Nous en avons donc choisi un. Nous avons opté d'abord pour le détournement de support, pour trois raisons ennuyeuses mais décisives. Il avait une cible claire et mesurable — le volume de tickets. Il exploitait du contenu déjà existant — leur documentation d'aide et les anciens tickets. Et s'il sous-performait, l'inconvénient était minime : un utilisateur qui n'obtenait pas de bonne réponse faisait simplement ce qu'il faisait déjà et ouvrait un ticket. Faible risque, retour rapide, métrique honnête. C'est une bonne première fonctionnalité IA, à chaque fois.

L'assistant d'activation n'a pas disparu — nous l'avons mis de côté, sur le papier, avec une note claire : phase deux, une fois la couche de récupération éprouvée. Cette seule décision a probablement sauvé le projet. Elle a donné à l'équipe une ligne d'arrivée réellement atteignable en semaines plutôt qu'en trimestres.

Le premier prototype que nous avons construit — et supprimé

Voici la partie que la plupart des études de cas passent sous silence. Notre premier prototype fonctionnel était, pour rester poli, mauvais. Nous avons fait l'évidence : brancher les articles d'aide du produit sur un grand modèle de langage, ajouter une zone de chat et laisser les utilisateurs poser des questions. En démo, cela paraissait magique. En test réel, cela s'est effondré d'une manière très précise et très instructive.

Le modèle se trompait avec assurance. Interrogé sur un réglage renommé six mois plus tôt, il inventait joyeusement l'ancien chemin de menu. Interrogé sur une fonctionnalité d'un forfait supérieur, il expliquait comment l'utiliser — à un client qui n'y avait pas accès. Chaque réponse sonnait autoritaire, ce qui rendait les mauvaises pires qu'une absence de réponse. Un bot de support qui ment poliment ne réduit pas les tickets ; il en crée de plus furieux.

Nous aurions pu masquer cela avec des ajustements de prompt. À la place, nous avons fait quelque chose qui ressemblait à un pas en arrière et s'est révélé être tout l'enjeu : nous avons jeté le premier prototype et l'avons reconstruit autour d'une règle stricte — l'assistant ne peut répondre qu'à partir de sources qu'il peut citer, et doit sinon dire « Je ne sais pas ».

Ce que nous avons réellement construit

La version mise en production était délibérément modeste dans ce qu'elle tentait et stricte dans son comportement. Sous le capot, c'était un assistant ancré sur la récupération : quand un utilisateur demandait quelque chose, le système commençait par chercher dans une base de connaissances soignée et à jour, puis demandait au modèle de répondre uniquement à partir de ce qu'il avait trouvé, avec un lien vers la source. Pas de source, pas de réponse assurée — juste un passage de relais propre vers un humain.

Trois choix de conception ont fait l'essentiel du travail, et aucun n'est excitant. C'est justement le propos — les choix ennuyeux sont généralement ceux qui décident si l'on fait confiance à une fonctionnalité IA ou si on la désactive en silence.

L'ancrage plutôt que l'astuce

Chaque réponse était liée à un document réel et à jour. Nous avons passé plus de temps à nettoyer et structurer la base de connaissances qu'à régler le modèle. Peu glamour, et de loin le travail au plus fort effet de levier du projet. Un modèle médiocre sur un contenu excellent et bien entretenu l'emporte sur un modèle brillant sur un fatras périmé.

Un passage de relais élégant

Quand l'assistant n'était pas sûr, il ne devinait pas. Il le disait et proposait un accès en un clic vers un humain — en emportant le contexte de la conversation pour que l'utilisateur n'ait jamais à se répéter. De façon contre-intuitive, cela a fait davantage confiance au bot : un assistant qui admet ses limites paraît honnête, et les gens s'appuyaient sur lui pour les 60 % faciles précisément parce qu'il s'effaçait sur les 40 % difficiles.

Conscient de qui pose la question

Parce qu'il vivait dans le produit, l'assistant connaissait le forfait, le rôle de l'utilisateur et sa position dans l'application. Il n'expliquait donc jamais une fonctionnalité inaccessible, et pouvait dire : « Le bouton que vous cherchez se trouve sur l'écran où vous êtes déjà. » Cette conscience du produit est le véritable avantage d'un assistant intégré à l'application face à un chatbot générique vissé sur un site marketing.

1. 1
   Nettoyage et structuration de la base de connaissances

   Nous avons audité chaque document d'aide, supprimé les obsolètes et étiqueté le reste par forfait et par fonctionnalité. C'était la semaine un, et ce fut la semaine la plus importante.
2. 2
   Construction de la couche de récupération

   Chercher d'abord, répondre ensuite. Le modèle ne voyait que du contenu vérifié et à jour — et avait pour consigne de refuser tout ce qu'il ne pouvait ancrer dans une source.
3. 3
   Branchement du contexte produit

   Nous avons relié l'assistant au forfait, au rôle et à l'écran courant de l'utilisateur, pour que les réponses soient adaptées et ne pointent jamais vers des fonctionnalités inaccessibles.
4. 4
   Conception du repli honnête

   Nous avons bâti le chemin « Je ne suis pas sûr — voici un humain » comme une fonctionnalité de premier plan, avec tout le contexte de la conversation remis à l'équipe de support.
5. 5
   Déploiement à 10 % des utilisateurs derrière un flag

   Déploiement discret sur une partie des comptes, observation des conversations réelles pendant deux semaines, correction de ce qui cassait, puis élargissement du déploiement.

Les résultats — et celui qui nous a surpris

Après environ trois mois de mise en service pour tout le monde, le tableau était clair. Nous vous donnons des chiffres arrondis et illustratifs — la tendance compte plus que les décimales.

Le chiffre de support était celui que nous avions promis, et il a tenu : un peu plus de la moitié des tickets répétitifs a tout simplement cessé d'arriver, et l'équipe de deux personnes a retrouvé sa semaine pour traiter les cas qui nécessitaient vraiment un humain. Bon résultat, exactement comme cadré.

Mais le résultat qui a réellement surpris le fondateur, nous ne l'avions pas du tout optimisé. Parce que l'assistant répondait toute la journée à des questions « comment faire X », il orientait naturellement les utilisateurs vers cette fonctionnalité enfouie et fidélisante — celle liée à la rétention. Nous n'avions pas encore construit l'assistant d'activation. Le bot de support faisait en silence une partie de son travail, en effet secondaire, simplement en étant utile et conscient du produit. Les nouveaux utilisateurs trouvaient la fonctionnalité des semaines plus tôt qu'avant.

Ce que nous dirions à la prochaine équipe

Si vous êtes une équipe SaaS fixant la même phrase « on devrait ajouter un assistant IA », plusieurs enseignements de ce projet se généralisent bien au-delà de lui.

• Séparez les problèmes avant de construire. « Chatbot IA » cache presque toujours deux ou trois métiers distincts qui réclament des conceptions différentes.
• Commencez par le cas d'usage où une mauvaise réponse coûte le moins. Le détournement de support est un premier pas quasi parfait ; le repli, c'est le statu quo.
• Consacrez l'essentiel de vos efforts au contenu, pas au modèle. L'ancrage sur des données propres et à jour est ce qui rend un assistant digne de confiance.
• Faites du « Je ne sais pas » une fonctionnalité, pas un échec. Un passage de relais honnête bâtit la confiance qui fait que les utilisateurs s'appuient sur ce que le bot fait bien.
• Livrez d'abord derrière un flag à une petite portion. Les vraies conversations vous apprendront ce qu'aucune démo n'enseignera jamais.

Questions fréquentes