GPTs sur mesure : ce qu'un assistant sans code ne couvre pas
AssistantsProductionGouvernanceAdoption2023-11-0910 min
Construire un assistant devient l'affaire de dix minutes. Ce qui reste à faire ensuite représente l'essentiel du travail, et personne ne l'a annoncé.
Une bonne nouvelle et un malentendu
Créer un assistant spécialisé sans écrire de code devient accessible à n'importe quel collaborateur, et c'est réellement utile. Le malentendu commence quand cette facilité est prise pour la mise en production.
Ce que la création sans code couvre effectivement : la consigne, le ton, quelques documents de référence, un périmètre de sujet. C'est suffisant pour un usage individuel, pour explorer un besoin, pour convaincre un comité. C'est aussi la meilleure façon de faire émerger des cas d'usage réels, ce qui a beaucoup de valeur.
Ce que cela ne couvre pas : tout le reste. Et le reste est ce qui distingue un assistant utilisable par une personne d'un système utilisable par une organisation.
Les quatre exigences qui restent entières
Les droits d'accès, le jeu de tests, la journalisation et la mise à jour du corpus ne sont couverts par aucun outil de création sans code. Ce sont pourtant les quatre points qui décident si un assistant survit six mois.
Les droits d'accès viennent en premier. Un assistant construit avec les documents auxquels son créateur a accès sera consulté par des personnes qui n'y ont pas droit. Le problème est invisible tant que l'assistant reste personnel, et immédiat dès qu'il est partagé.
Le jeu de tests vient ensuite. Sans une trentaine de cas avec réponse attendue, personne ne peut dire si une modification de la consigne améliore ou dégrade le comportement. Chaque ajustement devient un pari.
La journalisation détermine si un incident est analysable. Sans trace des questions posées et des documents utilisés, une réponse fausse reste inexplicable.
La mise à jour du corpus, enfin, est le point qui tue le plus d'assistants : les documents chargés au démarrage vieillissent, et l'assistant répond avec assurance sur la base d'une procédure abrogée.
Ce que je recommande à une organisation qui voit fleurir ces assistants
- Les laisser proliférer en usage individuel. C'est la meilleure source de cas d'usage réels, et l'interdiction produit surtout de l'usage clandestin.
- Poser une règle unique et lisible : aucun document confidentiel dans un assistant partagé. Voir confidentialité : ce qu'on a le droit de mettre dans un prompt.
- Repérer ceux qui deviennent structurants. Un assistant utilisé quotidiennement par une équipe entière n'est plus un essai : il doit être repris proprement.
- Mesurer l'usage, pas la satisfaction. Le nombre d'assistants créés ne dit rien ; le nombre utilisé la semaine suivante dit tout. Voir mesurer l'adoption, pas la satisfaction.
Le seuil où il faut reprendre le travail
Un assistant doit être repris en ingénierie dès qu'une décision de l'organisation en dépend, ou dès qu'il est utilisé par des personnes qui ne l'ont pas construit. Ces deux critères suffisent à trancher, et ils évitent les débats de principe.
Le premier critère porte sur l'enjeu. Un assistant qui aide à rédiger un courrier peut rester tel quel indéfiniment. Un assistant qui oriente une décision de garantie, de recrutement ou de tarification doit être testé, journalisé et supervisé.
Le second critère porte sur la distance entre l'auteur et l'utilisateur. Celui qui a construit l'assistant connaît ses limites et corrige mentalement ses réponses. Celui qui l'utilise sans l'avoir construit prend la réponse au premier degré. C'est là que le risque apparaît, et c'est le sujet de supervision humaine : la concevoir, pas la promettre.
Le signal qui doit déclencher la reprise
Le jour où quelqu'un demande « qui maintient cet assistant ? » et que personne ne répond, le passage en ingénierie est déjà en retard. C'est le meilleur indicateur que j'aie trouvé, et il ne demande aucun outillage.
Ce que ça change pour la formation
La compétence à transmettre n'est plus « créer un assistant » mais « savoir quand un assistant ne suffit plus ». C'est le déplacement pédagogique que cette facilité impose.
Apprendre à rédiger une consigne prend une heure et devient rapidement obsolète, les modèles étant de plus en plus tolérants aux consignes approximatives. Apprendre à reconnaître qu'un usage a changé de nature, qu'il engage l'organisation, qu'il touche des données protégées, qu'il est devenu quotidien pour une équipe, reste utile durablement.
C'est ce que j'enseigne en priorité dans les formations que j'anime, et c'est le cadre décrit dans former à tenir un système, pas à utiliser un outil.
Ce déplacement a un effet secondaire appréciable. Une formation centrée sur les limites produit des utilisateurs qui signalent les problèmes au lieu de contourner l'outil en silence. C'est la différence entre une organisation qui apprend de ses assistants et une organisation qui accumule des assistants abandonnés sans jamais savoir pourquoi.
Questions fréquentes
- Faut-il interdire aux collaborateurs de créer des assistants ?
Non. L'interdiction produit de l'usage clandestin et prive l'organisation de ses meilleurs cas d'usage. Une règle unique et lisible sur les documents confidentiels vaut mieux qu'une interdiction générale.
- Quand un assistant doit-il être repris en ingénierie ?
Dès qu'une décision de l'organisation en dépend, ou dès qu'il est utilisé par des personnes qui ne l'ont pas construit. Ces deux critères suffisent à trancher sans débat de principe.
- Que se passe-t-il si les documents chargés vieillissent ?
L'assistant continue de répondre avec assurance sur la base d'une procédure abrogée, sans aucun signal d'erreur. C'est la cause la plus fréquente d'abandon, et elle exige un processus de mise à jour, pas un meilleur modèle.
- Comment savoir quels assistants comptent vraiment ?
En mesurant l'usage répété, pas la création. Le nombre d'assistants créés ne dit rien ; le nombre encore utilisé un mois plus tard identifie les quelques-uns qui méritent d'être repris proprement.