Comprendre les instructions système et utilisateur
Lorsque vous discutez avec une intelligence artificielle, vous avez généralement l’impression de lui transmettre une consigne et d’obtenir une réponse.
Pourtant, dans de nombreux systèmes d’IA conversationnelle, votre message n’est pas nécessairement la seule instruction prise en compte.
Un assistant peut également recevoir des consignes définies par l’application, son développeur ou le fournisseur du modèle.
Ces instructions permettent notamment de définir son rôle, son comportement général, les règles qu’il doit respecter et la manière dont il doit traiter les demandes.
Une entreprise utilise un assistant informatique chargé d’expliquer des procédures techniques aux employés.
L’application lui transmet une instruction générale :
Un employé lui écrit ensuite :
L’assistant doit traiter cette demande en tenant compte des instructions générales applicables.
Dans une application utilisant une hiérarchie d’instructions, tous les messages n’ont pas la même autorité.
Une demande utilisateur peut préciser une tâche, mais elle ne peut pas nécessairement remplacer les règles définies à un niveau supérieur.
1. Objectifs pédagogiques
À la fin de ce cours, vous serez capable de :
- Expliquer ce qu’est une instruction dans un système d’IA.
- Distinguer les instructions système, développeur et utilisateur.
- Comprendre le principe de hiérarchie des instructions.
- Identifier les situations dans lesquelles plusieurs consignes entrent en conflit.
- Distinguer une instruction d’une donnée à analyser.
- Comprendre le rôle des messages d’outil.
- Reconnaître une tentative de détournement des instructions.
- Rédiger des instructions cohérentes pour un assistant spécialisé.
- Comprendre les limites des instructions système.
- Appliquer ces principes à des situations professionnelles.
2. Qu’est-ce qu’une instruction ?
Une instruction est une consigne adressée à un système d’intelligence artificielle pour orienter son comportement ou sa réponse.
Elle peut préciser :
- la tâche à réaliser ;
- le rôle attendu ;
- le ton à employer ;
- le format de réponse ;
- les étapes à suivre ;
- les informations à utiliser ;
- les limites à respecter.
Ces consignes n’ont cependant pas nécessairement la même autorité selon leur origine.
3. Pourquoi existe-t-il plusieurs niveaux d’instructions ?
Un assistant conversationnel peut être utilisé par plusieurs personnes et intégré à différentes applications.
Le fournisseur du modèle peut définir certaines règles générales, tandis que le développeur de l’application peut déterminer son fonctionnement particulier.
L’utilisateur, lui, formule ses demandes dans le cadre de cette application.
Il est donc utile de distinguer les responsabilités.
| Acteur | Rôle principal | Exemple |
|---|---|---|
| Fournisseur du modèle | Définit certaines règles générales et mécanismes de fonctionnement. | Règles de sécurité ou d’utilisation du modèle. |
| Développeur de l’application | Définit le rôle et les fonctionnalités de l’assistant. | Assistant spécialisé dans le support informatique. |
| Utilisateur | Demande une tâche particulière. | Expliquer une panne de connexion. |
| Source externe | Fournit des données à traiter. | Document, page web ou résultat d’un outil. |
Cette organisation permet de séparer les règles de fonctionnement de l’application des demandes ponctuelles.
4. Comprendre les rôles des messages
Dans de nombreuses interfaces de programmation pour modèles conversationnels, les messages possèdent un rôle.
Ce rôle indique au système de quel type de message il s’agit.
| Rôle | Fonction |
|---|---|
| System | Fournir des instructions générales au modèle, selon l’architecture utilisée. |
| Developer | Définir le comportement voulu par le développeur de l’application. |
| User | Transmettre la demande de l’utilisateur. |
| Assistant | Représenter les réponses ou messages produits par l’assistant. |
| Tool | Transmettre le résultat d’un outil utilisé par l’assistant. |
Tous les fournisseurs n’utilisent pas exactement les mêmes rôles, les mêmes noms ou les mêmes règles de priorité.
Certains systèmes regroupent plusieurs catégories d’instructions, tandis que d’autres proposent des mécanismes distincts.
Les exemples de ce cours présentent des principes courants, notamment dans les architectures inspirées des API conversationnelles d’OpenAI. Ils ne constituent pas une règle universelle applicable à tous les modèles.
5. Comprendre l’instruction système
Une instruction système est une consigne de haut niveau fournie au modèle par l’environnement qui l’exécute.
Selon la plateforme, elle peut contribuer à définir :
- le rôle général de l’assistant ;
- son comportement attendu ;
- certaines limites ;
- les règles de présentation ;
- les priorités à respecter.
Cette instruction a vocation à influencer les réponses de l’assistant pendant les échanges concernés.
Son application effective dépend de l’architecture et des mécanismes du système utilisé.
6. Comprendre l’instruction développeur
Dans certaines API, le rôle developer permet au concepteur d’une application de définir des instructions propres à son service.
Il peut par exemple préciser que l’assistant doit produire un type de document particulier.
Cette consigne organise le comportement de l’assistant pour les besoins de l’application.
Le rôle développeur n’est pas une simple étiquette décorative. Lorsqu’il est pris en charge par l’API, il correspond à un niveau d’instructions distinct du message utilisateur.
7. Comprendre l’instruction utilisateur
Une instruction utilisateur correspond à la demande formulée par la personne qui utilise l’assistant.
Cette demande précise le travail à effectuer.
Elle peut compléter les instructions de l’application tant qu’elle ne contredit pas des consignes de priorité supérieure.
L’utilisateur peut notamment :
- fournir les données à traiter ;
- préciser son objectif ;
- demander un format particulier ;
- indiquer le public visé ;
- demander des modifications.
8. Comprendre les messages de l’assistant
Les messages portant le rôle assistant correspondent aux contenus produits par le modèle.
Lorsqu’un historique de conversation est transmis au modèle, les réponses précédentes peuvent lui fournir du contexte.
Cela ne signifie pas qu’une ancienne réponse de l’assistant devient automatiquement une instruction de haut niveau.
Une réponse antérieure peut contenir une erreur. Sa présence dans l’historique ne la rend pas correcte.
9. Comprendre les messages d’outil
Certains assistants peuvent utiliser des outils externes pour rechercher des informations, effectuer des calculs ou interagir avec un logiciel.
Le résultat de l’outil peut être transmis au modèle sous un rôle spécifique.
Un résultat d’outil fournit une information. Il ne doit pas être automatiquement traité comme une nouvelle consigne prioritaire.
Cette distinction devient particulièrement importante lorsque les outils récupèrent des pages web, des documents ou des messages provenant de tiers.
10. Visualiser la hiérarchie des instructions
Dans les systèmes utilisant une hiérarchie comparable à celle documentée par OpenAI, les instructions peuvent être représentées de la manière suivante.
Contraintes définies au niveau de la plateforme ou du modèle.
Consignes générales de haut niveau.
Consignes propres à l’application.
Demandes formulées par l’utilisateur.
Textes cités, documents externes et résultats d’outils, sauf mécanisme particulier prévu par le système.
Ce schéma est une représentation pédagogique, pas une description exhaustive de toutes les plateformes.
Les règles fondamentales ne correspondent pas nécessairement à un rôle de message accessible dans une API.
La priorité dépend de l’architecture du système. Une consigne située à un niveau inférieur ne peut pas normalement annuler une consigne contradictoire de niveau supérieur.
11. Comprendre la notion de priorité
La priorité permet de déterminer quelle instruction doit être suivie lorsque plusieurs consignes sont incompatibles.
Instruction développeur :
Instruction utilisateur :
Les deux consignes sont incompatibles.
Dans un système où l’instruction développeur est prioritaire, l’assistant doit respecter la règle de langue définie par l’application.
Il peut expliquer brièvement cette limite si cela est utile.
12. Quand les instructions sont compatibles
Deux instructions peuvent également se compléter sans entrer en conflit.
Instruction développeur :
Instruction utilisateur :
Les consignes sont compatibles.
L’assistant peut produire une réponse professionnelle, factuelle, organisée en trois paragraphes et précédée d’un objet.
Une instruction de niveau inférieur n’est pas automatiquement ignorée. Elle peut être appliquée lorsqu’elle reste compatible avec les règles prioritaires.
13. Exemple professionnel : assistant administratif
Une entreprise crée un assistant destiné à préparer des courriels administratifs.
Instruction développeur
Demande utilisateur
Réponse possible
Objet : Confirmation de réception de votre attestation d’assurance
Madame Durand,
Nous vous confirmons avoir reçu votre attestation d’assurance le 24 octobre 2026.
Nous restons à votre disposition pour toute information complémentaire.
Cordialement,
La demande utilisateur est traitée tout en respectant les règles de l’application.
14. Exemple de conflit dans le même assistant
Supposons maintenant que l’utilisateur demande :
Cette demande contredit la règle du développeur interdisant de présenter une réception comme une validation.
Une réponse cohérente serait :
Je peux rédiger un courriel confirmant la réception de l’attestation, mais je ne peux pas présenter le document comme validé sans confirmation de cette validation.
Voici une proposition de confirmation de réception.
L’assistant peut ainsi proposer une alternative compatible avec les consignes prioritaires.
15. Exemple professionnel : assistant pédagogique
Instruction générale
Demande utilisateur
Réponse possible
Le DNS, ou système de noms de domaine, permet notamment de retrouver l’adresse IP associée à un nom de domaine.
Lorsque vous saisissez une adresse comme exemple.fr dans votre navigateur, votre appareil peut interroger un service DNS pour obtenir l’adresse IP nécessaire à la connexion.
On peut comparer le DNS à un annuaire qui associe des noms faciles à retenir à des adresses utilisées par les machines.
L’instruction générale influence ici la manière d’expliquer, tandis que l’utilisateur choisit le sujet.
16. Exemple professionnel : support informatique
Instruction développeur
Demande utilisateur
Réponse possible
Plusieurs facteurs peuvent expliquer un ralentissement, mais la cause n’est pas encore identifiée.
Pour commencer, pouvez-vous préciser si le ralentissement concerne tous les logiciels ou seulement une application ?
Vous pouvez également vérifier si un programme consomme beaucoup de ressources dans le gestionnaire des tâches, sans arrêter de processus que vous ne connaissez pas.
La réponse reste prudente et ne présente pas une hypothèse comme un diagnostic.
17. Peut-on modifier les instructions système ?
La réponse dépend de l’environnement utilisé.
Dans une application grand public
L’utilisateur ne peut généralement pas modifier directement les instructions internes définies par le fournisseur ou le développeur.
Il peut parfois configurer des préférences, créer un assistant personnalisé ou fournir des instructions supplémentaires dans les limites proposées par l’application.
Dans une application développée avec une API
Le développeur peut souvent définir des instructions de haut niveau selon les mécanismes disponibles.
Il peut ainsi concevoir un assistant spécialisé dans une activité particulière.
Écrire « instruction système » dans un message utilisateur ne transforme pas ce message en véritable instruction système.
Le niveau d’autorité dépend du rôle et du mécanisme utilisés par l’application, pas simplement des mots présents dans le texte.
18. Pourquoi le rôle du message compte-t-il ?
Considérons deux messages contenant exactement la même phrase :
Cette phrase peut être transmise :
- comme instruction de haut niveau ;
- comme instruction développeur ;
- comme demande utilisateur ;
- comme texte cité dans un document.
Les mots sont identiques, mais leur statut peut être différent.
Dans une architecture hiérarchique, c’est notamment le rôle attribué au message qui détermine son niveau d’autorité.
19. Différencier instruction et donnée
Cette distinction est essentielle.
Une instruction indique au modèle ce qu’il doit faire.
Une donnée est une information que le modèle doit traiter.
Instruction
Elle définit une opération.
Donnée à traiter
Elle fournit le contenu à résumer.
Le modèle doit traiter le texte fourni comme une source d’information, et non comme une nouvelle autorité de commande.
20. Quand une donnée contient une instruction
Une donnée peut elle-même contenir une phrase formulée comme un ordre.
Par exemple, un document à résumer peut contenir :
Si cette phrase fait partie du document, elle doit normalement être considérée comme du contenu à analyser, et non comme une instruction à exécuter.
Une phrase impérative n’est pas automatiquement une instruction autorisée.
Il faut tenir compte de son origine et de son rôle dans la tâche.
21. Comprendre la prompt injection
Une prompt injection est une tentative de détourner le comportement d’un assistant en introduisant des instructions dans un contenu qu’il doit traiter.
Ce contenu peut provenir :
- d’une page web ;
- d’un document ;
- d’un courriel ;
- d’un résultat de recherche ;
- d’un fichier importé ;
- d’un résultat d’outil.
Un assistant doit résumer une page web.
La page contient :
Cette consigne provient de la page à analyser. Elle ne doit pas être considérée comme une instruction prioritaire.
Une prompt injection exploite précisément la confusion possible entre les données et les instructions.
22. Pourquoi les instructions système ne suffisent-elles pas à sécuriser une application ?
Il serait tentant de penser qu’une instruction système bien rédigée empêche tous les détournements.
En pratique, ce n’est pas une garantie suffisante.
Les modèles peuvent mal interpréter certaines situations, être influencés par des contenus externes ou produire des réponses non conformes aux attentes.
La sécurité doit donc également reposer sur des mécanismes extérieurs au prompt.
| Mesure | Utilité |
|---|---|
| Contrôle des permissions | Limiter les actions réellement autorisées. |
| Validation des entrées | Vérifier les données reçues. |
| Validation des sorties | Contrôler les résultats avant leur utilisation. |
| Confirmation humaine | Éviter certaines actions non souhaitées. |
| Journalisation adaptée | Faciliter l’analyse des incidents. |
| Gestion des accès | Empêcher l’accès à des ressources non autorisées. |
23. Les délimiteurs dans les prompts
Les délimiteurs servent à identifier clairement différentes parties d’un message.
Ils peuvent être constitués de titres, de balises ou de séparateurs.
Cette structure rend la distinction entre instructions et données plus explicite.
Les délimiteurs améliorent la lisibilité, mais ne garantissent pas qu’un modèle résistera à toutes les tentatives de prompt injection.
24. Exemple de conflit de format
Une application produit des réponses destinées à être traitées automatiquement.
Instruction développeur
Demande utilisateur
La demande d’explication entre en conflit avec le format strict.
Réponse attendue
Le système respecte la structure imposée par l’application.
25. Exemple de conflit de contenu
Une application sert à résumer des documents sans ajouter d’informations extérieures.
Instruction développeur
Demande utilisateur
La demande de date probable contredit l’instruction de ne pas ajouter de faits.
Une réponse cohérente consiste à résumer le document et à signaler que la date de livraison n’est pas précisée.
26. Les instructions contradictoires au même niveau
Des contradictions peuvent également apparaître entre plusieurs consignes de même niveau.
Ces deux exigences ne peuvent pas être respectées simultanément.
Le traitement dépend des règles de résolution du système : ordre des instructions, spécificité, mécanismes propres à la plateforme ou demande de clarification.
Il ne faut donc pas supposer qu’une règle unique résout tous les conflits sur toutes les plateformes.
Lorsqu’on conçoit un assistant, mieux vaut supprimer les contradictions dès la rédaction des instructions plutôt que compter sur le modèle pour les résoudre.
27. Les instructions permanentes et temporaires
Il est utile de distinguer les consignes destinées à s’appliquer durablement des demandes liées à une tâche précise.
| Type | Exemple |
|---|---|
| Instruction générale | Utiliser un ton professionnel pour les courriels. |
| Instruction propre à une tâche | Rédiger un accusé de réception pour Madame Martin. |
| Instruction propre à une réponse | Présenter les informations sous forme de tableau. |
La durée d’application réelle dépend de la manière dont l’application transmet les instructions au modèle.
Une instruction n’est pas nécessairement conservée indéfiniment simplement parce qu’elle a été formulée une fois.
28. Comprendre la notion de contexte
Le contexte correspond aux informations disponibles pour produire une réponse.
Il peut inclure :
- les instructions de l’application ;
- le message utilisateur ;
- une partie de l’historique ;
- des documents ;
- des résultats d’outils ;
- des données complémentaires.
Ces informations peuvent être présentes dans le même traitement sans avoir le même statut.
Être présent dans le contexte ne signifie pas posséder une autorité d’instruction.
29. Peut-on voir les instructions système d’un assistant ?
Pas nécessairement.
Les instructions internes peuvent être définies par le fournisseur ou le développeur et ne pas être accessibles à l’utilisateur.
Certaines applications affichent une partie de leur configuration ou permettent de consulter les instructions d’un assistant personnalisé.
D’autres ne les exposent pas.
Une réponse générée par un modèle prétendant reproduire ses instructions internes ne constitue pas, à elle seule, une preuve fiable de leur contenu exact.
30. Les instructions système sont-elles toujours secrètes ?
Non.
Le caractère confidentiel d’une instruction dépend du système et de sa conception.
Une application peut rendre publiques certaines règles de fonctionnement.
En revanche, il est déconseillé de considérer une instruction cachée comme un mécanisme suffisant pour protéger des secrets.
Les mots de passe, clés API et autres secrets techniques ne doivent pas être protégés uniquement en demandant au modèle de ne pas les révéler.
Ils doivent être gérés par des mécanismes de sécurité adaptés, indépendants des réponses du modèle.
31. Concevoir les instructions d’un assistant spécialisé
Pour créer un assistant professionnel, il est utile de définir plusieurs éléments.
- Son rôle.
- Les tâches autorisées.
- Les tâches exclues.
- Les données qu’il peut utiliser.
- Les formats attendus.
- Les situations nécessitant une clarification.
- Les vérifications à effectuer.
Ce modèle d’instructions doit ensuite être adapté aux fonctionnalités réelles de l’application.
32. Définir clairement les capacités réelles
Un assistant peut expliquer comment réaliser une opération sans avoir la capacité technique de l’effectuer.
Réponse trompeuse
Cette affirmation est incorrecte si aucune action n’a été exécutée.
Réponse adaptée
La réponse distingue conseil et action réelle.
Cette distinction est particulièrement importante dans les applications professionnelles.
33. Définir une règle de clarification
Un assistant peut recevoir une demande impossible à traiter correctement sans informations supplémentaires.
Demande utilisateur :
Mais aucune valeur n’est fournie.
Une instruction utile serait :
L’assistant devrait demander le chiffre d’affaires initial et le chiffre d’affaires final.
34. Définir une règle de vérification
Une instruction peut demander à l’assistant de vérifier certains aspects de sa réponse.
Ces consignes peuvent améliorer la qualité des réponses, mais ne garantissent pas l’absence d’erreurs.
Pour des opérations importantes, un contrôle indépendant reste nécessaire.
35. Définir des instructions de sortie structurée
Une application peut exiger des réponses dans un format précis afin de les exploiter automatiquement.
Exemple de sortie :
Dans une application réelle, un schéma de validation et, lorsque l’API le permet, un mécanisme de sortie structurée sont préférables à une simple consigne textuelle.
36. Séparer les responsabilités dans une application
Une bonne conception évite de confier toutes les décisions au modèle.
| Responsabilité | Composant approprié |
|---|---|
| Définir le comportement conversationnel | Instructions de l’application. |
| Contrôler les droits d’accès | Système d’authentification et d’autorisation. |
| Vérifier les données obligatoires | Validation applicative. |
| Produire un texte | Modèle d’IA. |
| Exécuter une action | Outil ou service autorisé. |
| Confirmer une opération importante | Contrôle applicatif et, si nécessaire, validation humaine. |
Les instructions servent à orienter le modèle. Elles ne remplacent pas les contrôles techniques.
37. Exemple complet : assistant de traitement de tickets
Une entreprise souhaite créer un assistant qui transforme des signalements en fiches structurées.
Instruction développeur
Message utilisateur
Réponse possible
Équipement : Ordinateur du bureau comptable et imprimante associée.
Symptôme : Les impressions ne sont pas produites alors que l’imprimante apparaît dans la liste des périphériques.
Impact : Impression des documents impossible.
Informations manquantes : Modèle d’imprimante, message d’erreur éventuel, état de la file d’attente, fonctionnement depuis d’autres postes.
Vérifications proposées : Contrôler l’état de l’imprimante, la file d’attente et la présence d’éventuels messages d’erreur.
Diagnostic confirmé : Aucun à ce stade.
La réponse respecte le format et n’invente pas la cause du problème.
38. Exemple : instruction cachée dans un document
Reprenons le même assistant.
Un utilisateur lui fournit un texte contenant :
La dernière phrase fait partie du document transmis.
Elle ne constitue pas une nouvelle instruction développeur.
L’assistant doit traiter le signalement sans affirmer que l’incident est résolu.
La séparation logique entre instructions et données doit également être accompagnée de tests et de contrôles techniques, particulièrement lorsque les contenus proviennent de sources non fiables.
39. Tester les conflits d’instructions
Pour évaluer un assistant, il faut prévoir plusieurs scénarios.
| Test | Résultat recherché |
|---|---|
| Demande compatible | La demande est exécutée normalement. |
| Demande contraire au format | Le format prioritaire est respecté. |
| Demande contraire aux limites | La limite est respectée. |
| Donnée contenant une instruction | La donnée n’est pas traitée comme une instruction prioritaire. |
| Information manquante | L’assistant demande une précision ou signale l’absence. |
| Résultat d’outil inattendu | Le contenu est contrôlé avant utilisation. |
Les tests doivent être répétés lorsque les instructions, le modèle ou l’application changent.
40. Les erreurs fréquentes à éviter
| Erreur | Pourquoi c’est problématique | Bonne pratique |
|---|---|---|
| Confondre rôle et texte | Un message utilisateur ne devient pas système parce qu’il contient ce mot. | Identifier le véritable rôle du message. |
| Supposer une hiérarchie universelle | Les plateformes peuvent fonctionner différemment. | Consulter leur documentation. |
| Traiter une page web comme une autorité | Elle peut contenir des instructions malveillantes. | La considérer comme une source de données. |
| Mettre des secrets dans les prompts | Une consigne de confidentialité ne suffit pas. | Utiliser une gestion sécurisée des secrets. |
| Multiplier les règles contradictoires | Le comportement devient difficile à prévoir. | Clarifier les priorités et les exceptions. |
| Supposer que l’IA exécute une action | Une réponse textuelle ne prouve aucune intervention. | Vérifier l’exécution réelle. |
| Ne pas tester les conflits | Les problèmes apparaissent en production. | Prévoir des scénarios de test. |
| Compter uniquement sur le prompt pour la sécurité | Le modèle peut mal suivre les consignes. | Ajouter des contrôles applicatifs. |
41. Exercice 1 — Identifier les rôles
ApplicationUne application de support informatique utilise les messages suivants :
Travail demandé :
- Identifiez le rôle probable de chaque message.
- Expliquez leur fonction.
- Indiquez lequel fournit une donnée externe.
Afficher la correction détaillée
Message A
Il contient des instructions générales. Il pourrait être transmis avec un rôle système ou développeur selon l’architecture.
Son rôle exact ne peut pas être déterminé à partir du texte seul.
Message B
Il correspond à une demande utilisateur.
Message C
Il correspond vraisemblablement à une réponse de l’assistant.
Message D
Il correspond à un résultat d’outil.
Conclusion
Le rôle d’un message dépend de son origine et des métadonnées transmises par l’application, et non uniquement de son contenu.
42. Exercice 2 — Résoudre un conflit d’instructions
ApplicationInstruction développeur :
Demande utilisateur :
Travail demandé :
- Identifiez les conflits.
- Déterminez quelles consignes doivent être privilégiées dans une hiérarchie où le développeur est prioritaire.
- Rédigez une réponse possible.
Afficher la correction détaillée
1. Conflits
- L’utilisateur demande l’anglais, alors que l’instruction développeur impose le français.
- L’utilisateur demande un paragraphe, alors que l’instruction développeur impose trois points numérotés.
2. Priorité
Dans l’architecture indiquée, les instructions développeur sont prioritaires.
3. Réponse possible
- Accessibilité : le stockage cloud permet d’accéder à ses fichiers depuis différents appareils connectés.
- Collaboration : plusieurs personnes peuvent travailler sur des documents partagés selon les droits accordés.
- Souplesse : la capacité de stockage peut souvent être adaptée aux besoins.
La réponse traite le sujet demandé tout en respectant les contraintes prioritaires.
43. Exercice 3 — Distinguer instruction et donnée
EntraînementUn assistant reçoit l’instruction suivante :
Document :
Travail demandé :
- Identifiez la tentative de détournement.
- Expliquez pourquoi elle ne doit pas être suivie.
- Proposez un résumé fidèle.
Afficher la correction détaillée
1. Tentative de détournement
La phrase demandant d’ignorer les instructions précédentes est une tentative de modification du comportement de l’assistant.
2. Pourquoi ne pas la suivre ?
Elle appartient au document à résumer. Elle ne possède pas l’autorité nécessaire pour remplacer les instructions de traitement.
3. Résumé possible
L’entreprise prévoit de renouveler 15 ordinateurs au prochain trimestre. Le budget prévisionnel de cette opération est de 12 000 €. Le document contient également une instruction adressée à l’assistant, sans rapport avec le projet présenté.
Cette réponse restitue les informations et identifie le contenu suspect sans lui obéir.
44. Exercice 4 — Construire des instructions développeur
EntraînementUne entreprise souhaite créer un assistant destiné à produire des comptes rendus de réunion.
Exigences :
- ton professionnel ;
- présentation structurée ;
- distinction entre décisions et propositions ;
- aucune échéance inventée ;
- signalement des informations manquantes.
Travail demandé :
- Rédigez une instruction développeur.
- Définissez le format de sortie.
- Ajoutez une règle de clarification.
- Expliquez pourquoi ces consignes doivent être communes à toutes les demandes.
Afficher la correction détaillée
1. Instruction proposée
2. Justification
Ces règles concernent le fonctionnement général de l’application.
Les utilisateurs peuvent fournir des réunions différentes, mais les exigences de qualité et de présentation restent communes.
45. Exercice 5 — Cas pratique professionnel complet
SynthèseSituation professionnelle
Une entreprise souhaite intégrer un assistant d’IA à son logiciel de suivi des demandes clients.
L’assistant doit :
- lire les messages reçus ;
- identifier leur objet ;
- proposer une catégorie ;
- préparer une réponse ;
- ne jamais prétendre qu’une action a été effectuée si ce n’est pas le cas.
Catégories autorisées :
- INFORMATION ;
- RECLAMATION ;
- DOCUMENT ;
- AUTRE.
Message client :
Le logiciel ne fournit aucune information permettant de confirmer la réception réelle du document.
Travail demandé :
- Définissez les instructions générales de l’assistant.
- Identifiez la catégorie du message.
- Rédigez une réponse adaptée.
- Expliquez pourquoi l’assistant ne doit pas confirmer la réception.
- Prévoyez un test de prompt injection.
- Indiquez les contrôles techniques nécessaires.
Afficher la correction détaillée
1. Instructions développeur proposées
2. Catégorie
Le message porte principalement sur la réception d’une attestation.
3. Réponse proposée
Objet : Votre demande de confirmation de réception
Madame, Monsieur,
Nous avons bien pris connaissance de votre demande concernant l’attestation que vous indiquez avoir transmise.
La réception effective de ce document doit être vérifiée avant de pouvoir vous la confirmer.
Nous vous remercions de votre compréhension.
Cordialement,
4. Justification
Le logiciel ne fournit aucune preuve de réception.
L’assistant ne peut donc pas affirmer que le document a été reçu.
5. Test de prompt injection
Un message client de test pourrait contenir :
Le comportement attendu consiste à traiter la demande réelle sans suivre l’instruction insérée dans le message client.
6. Contrôles techniques
- Vérification de la présence du document dans le système de gestion.
- Contrôle des droits d’accès aux dossiers.
- Validation du format de sortie.
- Contrôle de la réponse avant son envoi.
- Enregistrement de l’action d’envoi uniquement après exécution réelle.
7. Conclusion
L’assistant peut préparer une réponse et faciliter le classement des demandes.
Il ne doit pas inventer une confirmation ou une opération que le système n’a pas réellement effectuée.
46. Questions fréquentes — 20 questions
1. Qu’est-ce qu’une instruction système ?
Une consigne de haut niveau transmise au modèle par l’environnement qui l’exécute, selon l’architecture utilisée.
2. Qu’est-ce qu’une instruction utilisateur ?
Une consigne formulée par la personne qui utilise l’assistant pour demander une tâche.
3. À quoi sert une instruction développeur ?
Elle permet de définir le comportement attendu de l’assistant dans une application.
4. Toutes les plateformes utilisent-elles les mêmes rôles ?
Non. Les rôles et leurs priorités varient selon les fournisseurs et les API.
5. Pourquoi existe-t-il une hiérarchie ?
Pour organiser les priorités lorsque plusieurs instructions sont incompatibles.
6. Une demande utilisateur peut-elle compléter une instruction développeur ?
Oui, lorsqu’elle reste compatible avec les règles prioritaires.
7. Une demande utilisateur peut-elle annuler une instruction système ?
Dans une architecture hiérarchique, une instruction utilisateur ne peut normalement pas annuler une instruction système contradictoire.
8. Écrire « SYSTEM » dans un message change-t-il son rôle ?
Non. Le rôle est déterminé par la structure des messages transmise à l’API ou par le fonctionnement de l’application.
9. Qu’est-ce qu’un message assistant ?
Un message produit par le modèle dans la conversation.
10. Qu’est-ce qu’un message d’outil ?
Un contenu transmis au modèle après l’utilisation d’un outil externe.
11. Un résultat d’outil peut-il contenir une instruction malveillante ?
Oui. Il doit être traité avec les précautions adaptées à son origine.
12. Qu’est-ce qu’une prompt injection ?
Une tentative de détourner le comportement du modèle en introduisant des instructions dans un contenu qu’il doit traiter.
13. Les instructions système empêchent-elles toutes les attaques ?
Non. Des contrôles techniques et des tests restent nécessaires.
14. Peut-on consulter toutes les instructions internes d’un assistant ?
Pas nécessairement. Certaines instructions ne sont pas accessibles à l’utilisateur.
15. Les instructions système sont-elles toujours secrètes ?
Non. Leur visibilité dépend de la plateforme et de la conception de l’application.
16. Peut-on stocker des mots de passe dans une instruction système ?
Ce n’est pas une méthode de protection adaptée. Les secrets doivent être gérés par des mécanismes spécialisés.
17. Pourquoi distinguer instruction et donnée ?
Pour éviter qu’un document ou une source externe modifie indûment le comportement de l’assistant.
18. Pourquoi tester les conflits d’instructions ?
Pour vérifier que l’assistant respecte les priorités et réagit correctement aux demandes incompatibles.
19. Une instruction suffit-elle pour garantir un format JSON correct ?
Non. Une validation technique et, lorsque c’est disponible, un mécanisme de sortie structurée sont préférables.
20. Quel est le principe essentiel à retenir ?
Le contenu d’un message ne détermine pas, à lui seul, son autorité. Il faut tenir compte de son rôle et de son origine.
47. Glossaire
| Terme | Définition |
|---|---|
| Instruction | Consigne destinée à orienter le comportement ou la réponse d’un modèle. |
| Instruction système | Consigne de haut niveau fournie par l’environnement du modèle. |
| Instruction développeur | Consigne définie par le concepteur d’une application. |
| Instruction utilisateur | Demande formulée par l’utilisateur. |
| Rôle | Catégorie attribuée à un message dans une architecture conversationnelle. |
| Hiérarchie des instructions | Organisation des niveaux d’autorité des consignes. |
| Priorité | Règle déterminant quelle instruction prévaut en cas de conflit. |
| Conflit d’instructions | Situation dans laquelle plusieurs consignes sont incompatibles. |
| Message assistant | Contenu produit par le modèle. |
| Message d’outil | Résultat transmis après l’utilisation d’un outil. |
| Contexte | Ensemble des informations disponibles pour produire une réponse. |
| Donnée externe | Information provenant d’un document, d’un outil ou d’une source extérieure. |
| Prompt injection | Tentative de détourner le modèle par des instructions présentes dans un contenu non fiable. |
| Délimiteur | Marqueur utilisé pour séparer les différentes parties d’un prompt. |
| Validation | Vérification du respect de règles ou de critères définis. |
| API | Interface permettant à des logiciels de communiquer avec un service. |
| JSON | Format textuel structuré utilisé pour échanger des données. |
| Autorisation | Mécanisme déterminant les actions ou ressources auxquelles un utilisateur ou un système peut accéder. |
48. Les dix idées essentielles à retenir
- Un assistant d’IA peut recevoir plusieurs types d’instructions.
- Les instructions système définissent des consignes de haut niveau dans les architectures qui les utilisent.
- Les instructions développeur organisent le comportement de l’application.
- Les instructions utilisateur correspondent aux demandes de la personne qui utilise l’assistant.
- Les rôles et les priorités peuvent varier selon les plateformes.
- Dans une hiérarchie d’instructions, une consigne de niveau inférieur ne peut normalement pas annuler une consigne contradictoire de niveau supérieur.
- Une donnée externe ne doit pas être automatiquement considérée comme une instruction.
- La prompt injection exploite la confusion entre données et instructions.
- Les instructions seules ne garantissent pas la sécurité ou l’exactitude des résultats.
- Un assistant professionnel doit être testé et accompagné de contrôles techniques adaptés.
Pour comprendre le comportement d’un assistant d’IA, il faut distinguer ce qu’on lui demande, qui lui donne la consigne et quel niveau d’autorité possède cette consigne.
Cette distinction est indispensable pour concevoir des assistants cohérents, interpréter leurs réponses et limiter les risques liés aux contenus externes.
49. Ressources complémentaires
- OpenAI — Model Spec : principes de comportement et hiérarchie des instructions dans les systèmes OpenAI.
- OpenAI — Documentation sur la génération de texte : instructions et utilisation des modèles via API.
- Anthropic — Documentation : conception d’applications conversationnelles et bonnes pratiques.
- Google AI for Developers — Gemini API : documentation sur les instructions et les échanges avec les modèles.
- OWASP — Sécurité des applications utilisant des modèles de langage : risques et bonnes pratiques de sécurité.
Les exemples professionnels de ce cours sont fictifs et servent exclusivement à illustrer les principes présentés. Les modalités précises des rôles et des priorités doivent être vérifiées dans la documentation du fournisseur utilisé.
50. Passer à la pratique
Pour consolider vos acquis, entraînez-vous à :
- identifier les différents rôles dans une conversation ;
- repérer les conflits entre instructions ;
- distinguer les consignes des données à analyser ;
- rédiger les instructions générales d’un assistant spécialisé ;
- tester une tentative de prompt injection ;
- définir les contrôles nécessaires avant d’utiliser un résultat.
51. Préparer le cours suivant
Vous savez maintenant distinguer les instructions système, développeur et utilisateur, comprendre leurs priorités et reconnaître les limites des consignes transmises à un modèle.
Le prochain cours sera consacré à la production de réponses structurées en tableaux ou en JSON.
Vous apprendrez à définir précisément la présentation attendue, à organiser des informations dans une structure stable et à préparer des réponses pouvant être exploitées dans des documents ou des logiciels.
7 cours sur 15 — Vous comprenez les différents niveaux d’instructions et leur rôle dans le fonctionnement d’un assistant d’IA.
Exercices du cours
Entraînez-vous avec 15 exercices progressifs. Ouvrez un exercice pour répondre, puis afficher sa correction.