Invites système : les deux couches invisibles des conversations IA

Lorsque vous écrivez une question à un assistant conversationnel et recevez une réponse, l’impression est qu’il n’y a que deux entrées dans la fenêtre, celle de l’utilisateur et celle du modèle. C’est une image incomplète. Avant même que le premier caractère ne soit tapé, la conversation est déjà peuplée de texte que l’utilisateur n’a pas écrit et qu’il ne voit en grande partie pas. Ce texte établit qui est le modèle, comment il doit se comporter, de quels outils il dispose, quel jour on est aujourd’hui.

Il s’agit de l’invite du système pour la conversation et détermine une grande partie de l’échange avant le début de l’échange.

La formule doit être comprise dans un sens plus large que l’actuelle, où « invite système » désigne uniquement le bloc d’instructions cachées que le fournisseur insère en amont. Ici, il inclut tout ce qui entre dans la fenêtre contextuelle au-delà de l’échange explicite de questions et de réponses, et se compose de deux couches. L’un est décidé par le fournisseur et ne peut être modifié. L’utilisateur construit l’autre, souvent sans s’en rendre compte, à chaque fois qu’il connecte un service ou installe un composant. Ce sont les deux couches que cette analyse maintient distinctes.

Le mécanisme s’applique à tout assistant basé sur un modèle de langage. Ce qui change, d’un écosystème à l’autre, c’est à quel point la couche utilisateur peut être enrichie, de quelques instructions personnelles à la connexion de services externes en passant par l’installation de composants qui ajoutent des capacités et des règles à la conversation.

L’analyse suivante utilise Claude comme référence concrète, car c’est un cas dans lequel la partie gouvernée par l’utilisateur est parmi les plus développées, et donc les plus adaptées pour montrer de quoi est constituée cette couche.

La première couche est écrite par celui qui produit le modèle, est insérée au début de chaque conversation et reste la même pour tout le monde, sauf mises à jour périodiques. Dans le cas de Claude, il est largement lisible, car Anthropic publie l’invite système de ses applications web et mobiles dans une section release notes, mise à jour à chaque nouvelle version du modèle.

Ceux qui accèdent via API écrivent leur propre partie, mais le modèle ne reste pas sans règles, car des contraintes de sécurité sont intégrées lors de la formation et l’utilisation reste soumise aux politiques des fournisseurs. Cela change l’endroit où se situent ces contraintes, et non le fait qu’elles existent.

La lecture de ce texte est instructive, car elle montre que de nombreux comportements apparemment spontanés du modèle sont en réalité des instructions explicites. La couche collecte certains composants récurrents. Le premier est l’identité du produit, c’est à dire à quel modèle il répond et le peu d’informations le concernant. Ils suivent des règles de comportement et de sécurité, non négociables par construction, qu’aucune instruction de l’utilisateur ne peut bouleverser.

Ensuite, il y a le ton et le format par défaut, la base stylistique sur laquelle se greffent les préférences personnelles lorsqu’elles existent. Le bloc généralement le plus conséquent est l’orchestration des instruments, avec les fiches techniques décrivant le nom, la fonction et les paramètres de chacun au modèle. Ils ferment les métadonnées de session, telles que la date et le modèle d’exécution, ainsi que les injections dynamiques que la plateforme peut ajouter au cours de l’échange.

Deux limites de visibilité pèsent sur cette couche. La première est que le texte publié est l’invite comportementale de base, et non l’instantané de tout ce qui entre dans la fenêtre dans une session réelle, où vous ajoutez des onglets d’outils actifs et des métadonnées actuelles. La seconde, plus subtile, est que ce texte se trouve sur une page de documentation et non dans la conversation. Il a le modèle devant lui à chaque échange, l’utilisateur ne l’a pas, et pendant qu’il converse, il ne lui vient pas naturellement de le chercher ailleurs, de sorte que même la partie publiée reste hors de sa vue au moment précis où elle compte.

Généralement, cette couche constitue la plus grande partie de l’ensemble de l’invite du système, souvent plusieurs fois plus grande que la partie contrôlée par l’utilisateur. C’est le coût fixe de la conversation, non modifiable, mais construit pour laisser à l’utilisateur une marge d’intervention sur l’autre moitié.

La deuxième couche est formée par les choix de ceux qui utilisent l’assistant et varie d’une personne à l’autre et d’une session à l’autre. Chez Claude, il comprend des éléments distincts, qui méritent d’être vus un à un.

Les instructions rédigées par l’utilisateur sont réparties en plusieurs niveaux, avec différentes méthodes d’insertion.

Les préférences utilisateur sont valables pour chaque conversation et constituent le niveau le plus simple, celui où vous indiquez au modèle quel est votre nom, quel ton utiliser, quelles conventions suivre, ce qu’il faut éviter.

Les instructions de projet ne sont valables que dans un projet spécifique et sont ajoutées aux préférences lorsque vous y travaillez, pour donner au modèle le contexte et les règles de ce travail sans avoir à les répéter à chaque fois.

Enfin, les instructions générales de Cowork sont définies séparément et sont lues au début de chaque session de cet environnement.

Aucun de ces éléments n’ajoute de nouvelles fonctionnalités, ils guident tous le comportement.

Les capacités sont ajoutées par les autres composants.

Les serveurs MCP, issus du standard ouvert Model Context Protocol, connectent l’assistant à des services et outils externes, de la recherche sur le Web à l’accès aux fichiers, d’une boîte aux lettres à une base de données. Chaque serveur apporte avec lui les fiches techniques de ses outils, et ces fiches techniques entrent dans le contexte au démarrage, avec un coût souvent invisible, car un serveur doté de nombreux outils ajoute autant de descriptions avant même la première question.

Les compétences sont des dossiers d’instructions qui enseignent une procédure ou une compétence spécifique, du style d’écriture d’une entreprise à la manière de remplir un document, et elles se chargent progressivement, seule leur description entre au démarrage et le corps seulement en cas de besoin, ce qui permet d’en garder plusieurs installées sans alourdir chaque conversation.

Enfin, les plugins sont des packages qui regroupent des compétences, des connecteurs et autres extensions dans une seule installation distribuée via marketplace, et mettent en contexte ce qu’ils contiennent selon les règles de chacun.

Tous ces éléments ne sont pas présents partout, car la couche utilisateur change avec l’environnement. Dans les environnements dédiés au travail avec du code, deux autres sont ajoutés : les hooks, qui effectuent des actions automatiques et déterministes lorsqu’une condition se produit, en dehors du raisonnement du modèle, et les fichiers mémoire, où l’assistant conserve les informations d’une session à l’autre.

Le trait commun de toutes ces composantes reste le même, chacune doit déclarer son existence au modèle pour fonctionner, et pour ce faire elle occupe de l’espace dans le contexte.

Additionnés, ces éléments créent l’empreinte de la couche utilisateur, la partie de l’invite système qui porte la signature de la personne utilisant l’assistant.

Maintenir les deux niveaux séparés a des conséquences pratiques. Le premier est la hiérarchie, car les deux niveaux ne sont pas au même niveau. La couche système fixe les limites que l’utilisateur ne peut pas franchir, les règles de sécurité, l’identité du modèle, les contraintes comportementales non négociables, et aucune instruction utilisateur ne peut les renverser. Cependant, à l’intérieur de ces limites, la couche utilisateur dispose d’un réel pouvoir et peut modifier les comportements par défaut du système.

La formule correcte n’est pas « le système gagne toujours », mais « le système fixe les limites, l’utilisateur gouverne ce qu’il y a à l’intérieur ».

La seconde est la connaissabilité. La couche utilisateur ne peut pas être lue en un seul endroit, car elle est constituée de différentes sources, chacune à sa place, et son empreinte globale n’existe pleinement qu’au sein d’une session active, au moment où la plateforme assemble les pièces. Lister ce que vous avez installé n’est pas la même chose que savoir combien cela pèse, ni voir les chevauchements, les doubles descriptions, les composants connectés puis oubliés. Pour vraiment connaître votre couche utilisateur, vous devez l’observer pendant qu’elle est en fonctionnement, et non la reconstruire de mémoire à partir d’un inventaire.

D’où le point pratique. Des deux couches, une seule est à la portée de l’utilisateur, et c’est aussi celle qui a tendance à se développer sans contrôle, car chaque service connecté et chaque composant installé reste et continue de prendre de la place dans chaque conversation même lorsqu’il n’est plus nécessaire. Reconnaître que cette couche existe et qu’elle vous appartient est la première étape pour la traiter comme quelque chose qui peut être inspecté et entretenu, et non comme une accumulation silencieuse.

Changez votre façon de lire le comportement de l’assistant

Voir ces couches change la façon dont vous lisez le comportement de l’assistant. Une réponse surprenante, un refus inattendu, un ton discordant cessent de ressembler à des caprices de modèle et deviennent l’effet d’instructions précises, en partie écrites par le fournisseur, en partie accumulées par l’utilisateur. Le modèle n’a pas de caractère spontané, il fonctionne dans un contexte qui s’assemble autour de lui à chaque démarrage, et une partie de ce contexte porte la signature de ceux qui l’utilisent.

Pour une organisation qui adopte ces outils la conséquence est concrète. La qualité et la prévisibilité des réponses dépendent également de la manière dont la couche utilisateur est entretenue, qui doit être conçue et entretenue comme toute autre configuration, avec des examens périodiques de ce qui est connecté et installé, plutôt que de le laisser s’installer. C’est la seule partie sur laquelle on peut réellement intervenir, et c’est aussi celle qui reretient l’attention.