Mettre l'assistant en service, c'est le moment où le prototype quitte le poste de la personne qui l'a construit. Le mardi matin, quelqu'un d'autre pose une vraie question, sur un vrai dossier, et la réponse part dans le travail. Cet article décrit la méthode pour ce passage : un pilote court, un journal, des droits, un refus prévu, un coût tenu comme une ligne à mesurer, un propriétaire nommé, un interrupteur. Il ne donne pas le bilan chiffré d'un déploiement que nous n'avons pas mesuré.
Le mardi où l'auteur n'est plus dans la pièce
Jusque-là, la série a fait deux choses. Le brief en une page a dit à quoi l'assistant sert, et à quoi il ne sert pas. Le tutoriel sur un RAG qui répond juste a dit comment ancrer les réponses dans des documents, au lieu de laisser le modèle inventer. Les deux peuvent être vrais sur l'ordinateur de l'auteur, et faux dès qu'une collègue s'en sert. Elle pose des questions que le jeu d'essai n'avait pas, elle colle un extrait qu'on n'avait pas prévu, elle fait confiance à une phrase parce qu'elle arrive dans l'outil de l'entreprise.
Le pilote sert à voir cela pendant que le cercle est encore petit. On choisit quelques personnes, quelques jours, et trois questions posées à chacune à la fin : qu'est-ce que l'assistant a répondu de juste, qu'est-ce qu'il a répondu de faux, qu'est-ce qu'il a refusé et qui vous a manqué. On ne fixe pas ici un effectif ni une durée types. Un pilote trop large n'apprend plus, parce que personne ne lit les retours. Un pilote qui ne touche que l'auteur n'apprend rien non plus.
Le journal, et ce qu'on n'y met pas
Sans journal, le mardi matin se perd. Le minimum utile rejoint ce que l'article sur la facture d'API demande déjà pour les coûts : qui a appelé, quel usage, combien de jetons en entrée, combien en sortie, quel modèle. On y ajoute le jugement humain, une case simple : utile, faux, hors sujet, refusé à tort.
Ce journal n'est pas une copie intégrale des dossiers. Le texte collé par l'utilisateur peut contenir un nom de client, un prix, un extrait médical. L'article sur les confidences versées dans une conversation rappelle que le texte quitte la pièce. On décide avant le pilote : durée de conservation, qui a le droit de lire, ce qu'on tronque. Une phrase de question et la source citée suffisent souvent à comprendre l'échec. Le document entier, rarement.
💡 Le refus est une fonction
Un assistant qui répond toujours a l'air serviable le premier jour et dangereux le deuxième. Prévoyez les cas où il doit dire non : aucun passage des documents ne couvre la question, la demande touche un dossier qu'il n'a pas le droit de voir, la consigne demande d'inventer un chiffre. Un refus clair vaut mieux qu'une phrase plausible. Notez dans le journal les refus que les utilisateurs contestent : ce sont eux qui disent si la règle est trop dure.
Les droits, avant les bonnes manières
L'assistant lit ce que le compte technique peut lire. S'il est branché sur toute la base pour « simplifier », il répondra avec le document de la mauvaise équipe. Les droits se posent comme pour un nouveau salarié : quels dossiers, quels outils, aucune élévation silencieuse. Sécuriser une application qui parle à un modèle détaille les portes habituelles, de l'injection de consigne au secret collé dans un prompt.
Le RAG ne corrige pas un droit trop large. Il retrouve mieux ce qu'on lui a donné. Si on lui a donné trop, il retrouve trop. Le pilote est le moment de retirer des sources, pas seulement d'en ajouter parce qu'une réponse a été pauvre.
Ce que le pilote doit avoir rendu visible
Avant d'élargir, on relit trois choses, et seulement trois.
Les questions qui reviennent. Si cinq personnes posent la même question et que trois reçoivent une source différente, le corpus est contradictoire ou le découpage est mauvais. On corrige les documents, on ne change pas de modèle pour « voir ».
Les refus contestés. Une collègue dit que l'assistant a refusé une question à laquelle le dossier répond. On ouvre le dossier avec elle. Soit la règle de refus était trop large, et on l'ajuste. Soit le passage existe mais n'est pas retrouvé, et c'est un problème de recherche, celui que le tutoriel RAG traite. Soit le passage n'existe pas, et le refus était juste : on l'explique, on ne le retire pas pour faire plaisir.
Les questions que personne n'avait prévues. Ce sont les plus utiles. Elles disent le travail réel, celui du mardi, pas celui du jeu d'essai écrit par l'auteur. On en ajoute quelques-unes au banc d'essai de l'épisode suivant, avec la bonne réponse écrite à la main. Sans cette copie, le pilote se termine sur des souvenirs.
On note aussi le temps humain. Combien de minutes pour lire le journal de la semaine, combien de corrections de documents, combien de fois l'interrupteur a été discuté. Un assistant qui fait gagner du temps à l'équipe et en coûte davantage à une seule personne n'a pas encore de propriétaire viable. Ce temps-là ne sort pas d'une facture d'API. Il se chronomètre, grossièrement, sur le pilote. Nous ne publions pas ici une durée type : elle dépend du métier. Nous disons qu'elle fait partie du compte, au même titre que les jetons.
Le coût se lit comme une ligne
On n'annonce pas ici un coût par conversation. On n'en a pas mesuré un pour cet article. On dit comment le tenir. Chaque appel journalise les jetons. À la fin du pilote, on a une fourchette : telle question courte, tel dossier long, tel modèle. On compare cette fourchette à la grille du fournisseur du moment, pas à un souvenir.
Pour fixer un ordre de grandeur de grille, et seulement cela, l'article sur la facture cite les prix publics d'Anthropic relevés le 24 juin 2026, en dollars par million de jetons : Claude Opus 5 à 5 en entrée et 25 en sortie, Claude Sonnet 5 à 2 et 10, Claude Haiku 4.5 à 1 et 5. Ces montants décrivent cette grille-là, à cette date-là. Ils ne décrivent pas la facture d'un assistant interne, qui dépend du volume, du cache, et du modèle réellement appelé. Ils bougent. On les relit avant d'en faire un budget.
La question du pilote est plus étroite : est-ce que l'usage réel, celui des collègues, reste dans l'enveloppe qu'on avait acceptée en cadrant le projet ? Si une seule question, répétée, mange le budget, ce n'est pas un succès d'adoption. C'est un réglage à changer avant d'élargir.
Un propriétaire, et un interrupteur
Quelqu'un, nommé, lit le journal chaque semaine du pilote. Ce n'est pas « l'équipe ». C'est une personne qui peut dire : on continue, on restreint, on éteint. L'interrupteur est un réglage qui coupe les appels sans déployer une nouvelle version dans l'urgence. Le jour où on l'utilise n'est pas un échec du projet. C'est la preuve que le retour arrière existe.
Le mémo Livrer, recetter, pouvoir revenir en arrière pose la même exigence pour n'importe quelle mise en ligne : ce qui part en production doit pouvoir en revenir.
Élargir vient après. Les trois questions du pilote ont des réponses stables, les refus sont compris, le coût par usage est lu et pas deviné, les droits ont été réduits au moins une fois. Alors on ajoute des personnes, par petit groupe, en gardant le même journal. On ne change pas le modèle, les sources et les règles de refus le même jour : sinon le journal ne dit plus ce qui a bougé. Le propriétaire relit une semaine de ce nouveau groupe avant le suivant. Le journal de la semaine dit si le groupe ajouté pose encore des questions nouvelles, ou seulement celles déjà classées. Cinquante personnes ne s'obtiennent pas en changeant un chiffre dans un réglage. Elles s'obtiennent quand le petit groupe n'apporte plus de question nouvelle, seulement les mêmes, déjà classées. Le banc d'essai de l'épisode suivant dit comment savoir si le changement d'après a amélioré les réponses, au lieu de se fier à l'impression du mardi.
Tant que ces conditions manquent, le prototype reste sur le poste de son auteur. C'est un bon endroit pour un prototype.
Pour faire construire ce passage, ou le faire relire avant qu'il touche les dossiers, la page Intelligence artificielle est le point d'entrée.
