Intégrer un copilote IA dans un produit SaaS, c'est ajouter une brique qui lit le contexte de l'utilisateur, propose une réponse ou une action, et l'exécute via les API du produit avec un niveau de validation que chaque client règle lui-même. Ce n'est pas un chatbot posé à côté de l'interface. Pour un éditeur, quatre décisions comptent plus que le modèle : l'isolation des données entre clients, la validation humaine configurable, la latence sous trois secondes, et le modèle économique de la brique. Elles sont détaillées à partir de deux missions JUWA chez un même éditeur de gestion locative, un copilote conversationnel livré en quatre semaines et quatre agents internes livrés en douze jours.
Ce qu'un copilote change dans un produit SaaS
Un SaaS vend une capacité à ses clients ; le copilote en vend une nouvelle sans changer l'écran. Il lit l'historique de la conversation ou du dossier affiché, identifie l'intention réelle de l'utilisateur, qui demande rarement les choses dans les termes du métier, et propose une réponse ou une action que les API internes exécutent. La différence avec un assistant générique tient à ce dernier point : il agit dans le produit, ce que l'article sur la différence entre agent, copilote et chatbot détaille.
Chez un éditeur SaaS de location courte durée, le volume de messages voyageurs croissait plus vite que la capacité à y répondre. JUWA a remplacé l'assistant existant par un copilote adossé à un moteur RAG contextualisé, greffé dans l'architecture existante plutôt que posé à côté. Résultat en quatre semaines : 95 % de deux millions de messages mensuels traités sans intervention humaine, latence sous trois secondes, contexte conversationnel compris.
Résumé de la vidéo (en anglais) : Anthropic explique quand un flux prédéfini suffit et quand l'autonomie d'un agent se justifie, une grille qui s'applique directement au réglage de validation d'un copilote produit.
Décision 1 : isoler les données de chaque client
Un SaaS sert des dizaines ou des centaines de clients sur la même infrastructure. Le copilote doit lire les documents et les données du client A sans jamais voir ceux du client B. Concrètement : un index vectoriel par client ou un filtrage strict par identifiant de tenant à chaque requête, des garde-fous qui interdisent au modèle de sortir du périmètre autorisé, et un journal qui trace quel client a déclenché quelle lecture. Sur les quatre agents livrés en douze jours pour le même éditeur, le RAG métier disposait d'un index dédié et isolé, avec des garde-fous stricts pour ne jamais répondre avec les données du modèle générique. Les fiches pratiques IA de la CNIL ajoutent la minimisation et la durée de conservation, que le journal permet de prouver.
Décision 2 : rendre la validation humaine configurable
Un gestionnaire qui supervise trente annonces et un autre qui en supervise trois cents n'accordent pas la même autonomie à une IA. Imposer un niveau unique de délégation, c'est perdre l'un ou l'autre. Dans le copilote de l'éditeur, la validation humaine est un réglage par client : proposer seulement, exécuter les actions simples, exécuter tout sauf une liste d'exceptions. Ce curseur est une décision d'architecture, pas une option de confort : il doit exister dès la première version, sinon il faut réécrire l'orchestration pour l'ajouter.
Décision 3 : tenir la latence sous trois secondes
Un copilote qui met six secondes à proposer une réponse n'est pas utilisé, quelle que soit sa qualité. La latence se pilote sur trois postes : la récupération (index bien découpé, filtres avant la recherche vectorielle), le modèle (un modèle léger pour les réponses courtes, un modèle plus riche pour les synthèses, sélectionnés par tâche comme sur les quatre agents de l'éditeur, répartis entre plusieurs modèles hébergés), et l'affichage en flux, qui montre les premiers mots avant la fin de la génération. L'article sur l'optimisation du coût des LLM traite le lien entre latence et coût par requête.
Décision 4 : choisir le modèle économique de la brique
| Modèle | Comment ça marche | Quand le retenir | Risque |
|---|---|---|---|
| Inclus dans l'abonnement | Le copilote fait partie de l'offre, le coût d'inférence est absorbé | Usage modéré par client, argument commercial fort | Un client très actif coûte plus qu'il ne paie |
| Option payante | Module activable, prix fixe par mois | Usage prévisible, clients segmentés | Adoption plus lente, effet réseau réduit |
| Facturation à l'usage | Prix par message, par action ou par crédit | Volumes très variables, coût d'inférence significatif | Complexité de facturation, frein psychologique |
| Mixte : quota inclus puis usage | Un volume dans l'abonnement, l'excédent facturé | La plupart des SaaS B2B | Demande une mesure fine par client dès le premier jour |
Quel que soit le modèle, la mesure par client du nombre de requêtes, du coût d'inférence et du taux d'actions validées doit exister dès la première version. Sans elle, l'éditeur découvre le coût réel de la brique sur sa facture de modèle trois mois plus tard.
Le calendrier qui tient : cadrage sans zone grise
Quatre semaines pour un copilote branché sur une plateforme en production, ce n'est pas un délai qu'on rattrape en cours de route. Le cadrage a fixé des critères de succès mesurables avant la première ligne de code (95 % des interactions sans humain, moins de trois secondes) et une priorisation sans zone grise. Le pilotage a suivi le même régime : point hebdomadaire avec démonstration, reporting quotidien, validation technique continue côté client. Sur la seconde mission, le cadrage des quatre agents a tenu en une journée avec la direction produit, et l'orchestrateur a été écrit en Laravel, la stack du client, pour que l'équipe interne reprenne la main sans dépendance.
Ce que l'éditeur doit avoir avant de commencer
Des API internes qui exposent les actions métier, ou la capacité d'en écrire ; une base de connaissances par client, à jour, avec une source unique ; un jeu de test de cinquante à deux cents conversations réelles avec la réponse attendue, pour mesurer avant et après ; et une décision sur le curseur de validation par défaut. Un éditeur qui n'a pas ces quatre éléments passe les deux premières semaines à les construire, ce qui n'est pas perdu mais doit être compté dans le calendrier. Les métriques d'évaluation d'un RAG décrivent le jeu de test.
L'erreur de l'éditeur pressé
Livrer le copilote comme une fenêtre de discussion séparée, branchée sur une base de connaissances générale, pour aller vite. Il répond, il impressionne en démonstration, et les clients ne l'utilisent pas, parce qu'il ne voit pas leur dossier et n'exécute rien. La version suivante, intégrée aux API, repart presque de zéro. Le surcoût d'une intégration dès la première version est faible à côté du coût d'une brique que personne n'adopte.
Le sprint JUWA pour un éditeur
Cadrage en une journée avec la direction produit, critères de succès chiffrés, puis un sprint de deux à quatre semaines qui livre un copilote intégré dans la stack existante, avec isolation par client, validation configurable, mesure par client et documentation pour le handover. Les modules web et mobile sont livrés dans les technologies déjà utilisées par l'équipe. C'est le périmètre de l'accompagnement JUWA pour les éditeurs SaaS, de la brique démontrable en comité à la fonctionnalité vendue.
