Quand vous ouvrez une conversation avec un assistant IA, vous croyez être le premier à parler. Vous ne l'êtes pas. Un texte a déjà été transmis au modèle, invisible dans l'interface, qui lui explique qui il est, ce qu'il peut faire, quel ton adopter et ce qu'il doit refuser. C'est le system prompt, et il explique une bonne partie des comportements qui vous surprennent.
C'est l'une des couches les moins connues et les plus déterminantes de ce que vous vivez en utilisant ces outils. Expliquons-la.
Le principe
Un modèle de langage brut ne sait pas qu'il est un assistant. Il produit la suite la plus probable au texte qu'il reçoit, comme nous l'expliquions dans notre article sur les LLM. Rien en lui ne dit qu'il doit se comporter comme un interlocuteur serviable.
Le system prompt comble ce manque. C'est un texte placé en tête de la conversation, traité comme une instruction de niveau supérieur, qui définit le cadre. Il peut faire quelques lignes ou plusieurs milliers de mots.
Son contenu type couvre quatre choses : une identité et un rôle, des capacités disponibles comme la recherche web ou l'accès à des outils, des consignes de comportement sur le ton et le format, et des limites sur ce qui doit être refusé ou traité avec précaution.
Pourquoi c'est important pour vous
Trois comportements courants s'expliquent par cette couche.
Les différences entre interfaces. Le même modèle accessible via une application grand public et via une API pour développeurs peut se comporter différemment. Ce n'est pas le modèle qui change, ce sont les instructions qui l'encadrent. Un développeur écrit les siennes, l'utilisateur d'une application reçoit celles du fournisseur.
Les refus qui semblent arbitraires. Quand une IA décline une demande anodine, c'est souvent une consigne de prudence formulée largement qui se déclenche, plutôt qu'une décision du modèle lui-même. Cela rejoint ce que nous décrivions à propos des garde-fous : le curseur est réglé quelque part, et il produit des faux positifs.
Le ton. Une partie de ce que nous décrivions comme la personnalité d'un modèle vient de l'entraînement, mais une autre partie vient de ces instructions. C'est la couche la plus facile à modifier, et donc celle que les fournisseurs ajustent le plus souvent.
Faut-il rendre ces instructions publiques ? Le débat est réel. En faveur : elles déterminent ce que l'outil accepte de faire, et l'utilisateur a un intérêt légitime à le savoir. Contre : les publier facilite leur contournement, puisque connaître précisément les consignes aide à formuler des demandes qui passent à côté. Plusieurs acteurs ont choisi de publier tout ou partie des leurs, ce qui va dans le sens de la transparence que nous appelions de nos voeux à propos de la neutralité impossible. D'autres non.
Ce que ça change si vous développez
Pour qui construit un produit sur une API, le system prompt est le principal levier de personnalisation, avant même le choix du modèle.
Trois conseils pratiques. Soyez précis sur le rôle et le périmètre : un cadre flou produit des réponses hors sujet. Placez ces instructions en tête et gardez-les stables, ce qui permet de bénéficier de la mise en cache et de réduire fortement vos coûts. Et surtout, ne considérez jamais ces instructions comme une barrière de sécurité : elles orientent le comportement, elles ne le garantissent pas. Un contenu piégé dans les données que traite votre système peut les contredire, comme le montre le mécanisme de l'agentjacking.
Ce qu'il faut retenir
Il y a toujours quelqu'un qui a écrit quelque chose avant vous. C'est peut-être la meilleure façon de résumer cette couche.
Cela ne veut pas dire qu'on vous manipule : ces instructions servent le plus souvent à rendre l'outil utile et sûr. Mais elles constituent un choix éditorial invisible, qui décide de ce que la machine acceptera de faire pour vous. Savoir qu'elles existent change la manière dont on interprète un refus, une différence de ton, ou un comportement inattendu. Ce n'est pas la machine qui a décidé : c'est quelqu'un, quelque part, qui a écrit une ligne.