Rédiger et tester des instructions pour IA
Publié le · Mis à jour le
Pour rédiger des instructions pour une IA, définissez le résultat attendu, le contexte utile, les limites et les vérifications nécessaires. Fournissez des exemples courts et distinguez votre demande des documents à analyser.
Définir le résultat et le périmètre initial
Commencez par nommer le travail, son utilisateur et le résultat dont celui ci a besoin. « Crée une application excellente » laisse les décisions essentielles ouvertes. Une demande plus exploitable serait : « Crée un formulaire de maintenance pour les locataires, indique les champs obligatoires, conserve la demande et permets de consulter son état ». Vous décrivez ainsi des comportements observables plutôt qu’une impression générale, et vous pouvez repérer les exigences encore manquantes.
Limitez la première version aux écrans et aux informations indispensables. Précisez si vous voulez un plan, une proposition ou une réalisation. Dans un projet existant, décrivez l’écran actuel et le comportement à modifier. Séparez les changements visuels des changements de données si leur combinaison rend la vérification confuse. Un périmètre réduit permet de comprendre chaque résultat avant de construire une nouvelle fonction dessus ou d’adopter une décision difficile à expliquer.
Associez chaque objectif à un critère concret. Le formulaire doit signaler une description absente, préserver les données après correction et produire un enregistrement consultable après envoi. Vous pouvez soumettre ce cadrage à Infera Agent en vérifiant les possibilités de réalisation de votre compte. La formulation ne prouve pas l’existence d’une fonction. Demandez quels points nécessitent une configuration supplémentaire ou un travail distinct avant de considérer le parcours comme réalisable et complet.
- Nommez utilisateur, tâche et résultat.
- Délimitez une première version vérifiable.
- Définissez des critères observables.
Apporter du contexte et des exemples représentatifs
Ajoutez les informations qui changent une décision : langue, public, champs, format attendu et liens entre écrans. Inutile de transmettre tout l’historique du projet pour corriger un message précis. Utilisez les noms réellement visibles afin de distinguer les éléments ressemblants. Lorsque des données manquent, demandez une liste courte des hypothèses et la question qui bloque la réalisation exacte. Une incertitude explicite se traite plus facilement qu’une supposition incorporée silencieusement au résultat.
Présentez un exemple courant et un cas particulier. Pour la maintenance, le premier peut contenir une description courte et un numéro de logement ; le second, une description longue ou un champ absent. Indiquez le résultat attendu pour chaque cas. Pour un tableau, nommez les colonnes, leur ordre et la représentation des valeurs indisponibles. Pour un texte, précisez le lecteur, la longueur, le ton et les faits à ne pas inventer. Relisez aussi la cohérence de vos exemples.
Expliquez le rôle du fichier ou de l’image de référence : structure, contenu, données ou apparence. Une référence imprécise ne remplace pas les exigences. Employez des informations fictives clairement signalées lorsque la démonstration suffit. Séparez les faits établis des suggestions et des valeurs provisoires. Conservez le cadrage principal dans un document indépendant pour le mettre à jour et le réutiliser sans transmettre des détails anciens à un nouveau projet ni mélanger des décisions contradictoires.
- Ajoutez le contexte déterminant.
- Expliquez le résultat de chaque exemple.
- Précisez format et incertitudes.
Vérifier puis corriger la cause du problème
Comparez le résultat aux critères établis plutôt qu’à son apparence. Ouvrez l’écran concerné, saisissez les exemples et examinez le fichier ou l’enregistrement produit lorsque la demande concerne une réalisation. Pour un texte, vérifiez les faits, la langue, la couverture du sujet et les répétitions. Conservez la demande, sa version et le résultat observé. La prochaine révision pourra ainsi cibler un problème identifié au lieu de recommencer avec une demande générale d’amélioration.
Formulez le retour en trois parties : comportement observé, comportement attendu et étapes de reproduction. Par exemple : « Une description vide produit un succès ; un avertissement près du champ et aucune demande créée sont attendus ; répéter l’envoi et inspecter les enregistrements ». Demandez le changement et sa vérification. Si les données sont incorrectes, modifier seulement le message ne résout pas le problème. Une interface convaincante peut cacher un fonctionnement qui reste incompatible avec le besoin initial.
Pour comparer des formulations, changez un facteur à la fois et gardez les mêmes cas. Évaluez un contexte supplémentaire, un exemple ou un format plus précis sans remplacer simultanément toute la tâche. Notez les réussites et les limites ; une bonne réponse isolée ne démontre pas une qualité constante. Enregistrez une version utile avec sa date et son objectif. Lorsque le projet évolue, actualisez noms, champs et critères, puis recommencez les vérifications avant de reprendre l’ancienne demande.
- Comparez aux critères de réussite.
- Décrivez observation, attente et reproduction.
- Gardez versions et résultats.
Distinguer documents et autorité des instructions
Un fichier ou une page peut contenir des instructions détournant la tâche : c’est un risque d’injection d’instructions. Présentez les références comme données à analyser. Leur séparation textuelle ne garantit pas la protection. Appliquez les autorisations et limites des outils hors du modèle, avec un accès minimal.
Contrôlez les changements inattendus après lecture externe. Évitez les secrets dans les demandes et prévoyez une validation humaine des opérations sensibles. Référence : https://genai.owasp.org/llmrisk/llm01-prompt-injection/ . Relecture du code : https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html . Ces mesures réduisent le risque sans certifier la sécurité de l’application.
- Traitez les références comme données.
- Contrôlez les actions hors du modèle.
Questions
Une demande longue est elle meilleure ?
Seulement si ses précisions servent la tâche. Supprimez les répétitions et comparez les versions avec les mêmes exemples et critères.
Comment demander une correction utile ?
Décrivez le comportement observé, celui attendu et les étapes de reproduction. Ajoutez un exemple représentatif et demandez comment le changement a été vérifié.
Faut il un style formel ?
La clarté et des noms stables sont plus utiles. Employez une langue que vous maîtrisez et demandez un résultat concret que vous pouvez examiner.
Quand réutiliser une demande ?
Après avoir conservé une version satisfaisante sur vos cas de vérification. Actualisez contexte et attentes pour le nouveau projet, puis vérifiez de nouveau.