GPTs sur mesure : ce qu'un assistant sans code ne couvre pas

Un GPT sur mesure est une version de ChatGPT configurée sans code par son créateur, avec une consigne, des documents de référence et éventuellement des outils, pour un usage précis. Le créateur décrit ce qu’il attend en langage courant, ajoute quelques fichiers, choisit les capacités autorisées, puis partage l’assistant.

Quatre éléments composent un tel assistant. La consigne fixe le rôle, le ton et les limites de sujet. Les documents fournissent une base de connaissance consultée au moment de répondre. Les capacités activent la navigation, la génération d’images ou l’exécution de code. Les actions, enfin, permettent d’appeler un service extérieur, dans la continuité des plugins ChatGPT, quand un modèle commence à agir.

Ce qui est nouveau n’est pas la technique, déjà accessible par programmation, mais l’accès : n’importe quel collaborateur peut désormais assembler ces quatre éléments en quelques minutes.

Créer un assistant spécialisé sans écrire de code devient accessible à n’importe quel collaborateur, et c’est réellement utile, à condition de ne pas confondre cette facilité avec la mise en production. Le malentendu commence précisément là.

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. C’est l’écart déjà décrit dans l’anatomie d’un POC qui ne passe jamais : la démonstration réussie ne dit rien de la tenue en usage réel.

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 d’assistant 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. C’est la raison pour laquelle le corpus est le projet, et non un simple préalable.

Un assistant personnel sert son créateur, qui connaît ses limites ; un système d’organisation sert des utilisateurs qui ne les connaissent pas, et doit donc les compenser par construction. Le tableau suivant compare les deux situations sur les points qui comptent.

Un même assistant peut passer de la colonne de gauche à celle de droite sans que rien ne change dans sa configuration. C’est ce glissement silencieux qu’il faut savoir repérer.

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é. Certaines de ces décisions relèvent d’ailleurs de ce qu’on ne délègue jamais à un modèle.

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.

Reprendre un assistant devenu structurant consiste à conserver ce que son créateur a appris sur le besoin, puis à reconstruire autour les quatre exigences manquantes. La méthode suit six étapes.

1. Recueillir l’existant. Récupérer la consigne, les documents chargés et, surtout, les questions réellement posées par les utilisateurs. Ce matériau vaut plus que la configuration elle-même.

1. Constituer le jeu de tests à partir de ces questions : une trentaine de cas avec la réponse attendue, validée par un expert métier.

1. Cartographier les droits. Pour chaque document, établir qui a le droit de le consulter, et faire en sorte que l’assistant ne réponde qu’à partir de ce que l’utilisateur peut lire.

1. Désigner un responsable du corpus, avec une fréquence de revue et une règle de retrait des documents abrogés.

1. Mettre en place la journalisation des questions, des documents utilisés et des réponses, avec une durée de conservation définie.

1. Remplacer l’assistant d’origine, en prévenant ses utilisateurs et en retirant l’ancienne version partagée, faute de quoi les deux coexisteront.

Cette reprise ne jette pas le travail du créateur : elle le prolonge. C’est souvent lui qui connaît le mieux le besoin, et l’associer à la reprise est le moyen le plus sûr de ne pas perdre ce qui fonctionnait.

Les erreurs fréquentes face aux GPTs sur mesure oscillent entre deux excès : tout interdire par prudence, ou tout laisser circuler sans repérer ce qui devient critique. Elles ont des conséquences différentes mais une même cause, l’absence de critère de passage.

• Interdire la création d’assistants. L’usage devient clandestin et l’organisation perd sa meilleure source de cas d’usage.

• Partager un assistant personnel tel quel, avec les documents de son créateur, à une équipe qui n’a pas les mêmes droits.

• Compter les assistants créés comme indicateur de réussite, alors que seul l’usage répété signale une valeur.

• Ajuster la consigne sans tests, et dégrader des réponses qui fonctionnaient sans le savoir.

• Brancher des actions sur un assistant partagé sans avoir défini ce qu’il a le droit de faire seul.

Ces erreurs se repèrent lors d’un inventaire des assistants en circulation, ce qui constitue l’un des premiers volets d’un audit IA.

La compétence à transmettre n’est plus « créer un assistant » mais « savoir quand un assistant ne suffit plus », et 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. Les enseignements d’un dispositif à grande échelle sont détaillés dans former deux cents personnes à l’IA générative, et l’offre correspondante figure sur la page formation IA.

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.