Prompts métier : juridique, tech et RH
Des gabarits de prompts éprouvés pour trois métiers réglementés — juridique, développement technique et ressources humaines — avec leurs contraintes de conformité et les pièges spécifiques à chacun.
Table des matières
Pourquoi les prompts métier exigent une structure différente
Un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire générique — « résume ce texte », « rédige un e-mail professionnel » — convient à des tâches ponctuelles et peu risquées, où une approximation se corrige en une relecture rapide. Dès qu'un prompt s'applique à un métier réglementé, la nature du risque change : une clause contractuelle mal formulée engage la responsabilité de l'entreprise, une suggestion de code introduit une faille de sécurité en production, une question d'entretien mal cadrée peut constituer une discrimination à l'embauche caractérisée.
Ce chapitre propose des gabarits pour trois familles de métiers — juridique, technique, ressources humaines — construits sur un principe commun : le prompt ne se limite pas à décrire la tâche, il encode aussi les limites de ce que le modèle peut affirmer et le point de contrôle humain avant diffusiondiffusionIAFamille de modèles génératifs qui synthétisent une image (ou autre signal) en dénisant progressivement un bruit.Voir dans le glossaire.
Les templates de ce chapitre sont des points de départ à adapter au contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire réel de votre organisation — juridiction, convention collective, politique de sécurité interne. Aucun gabarit générique ne remplace la validation d'un expert du domaine sur un contenu à enjeu réel.
Juridique : rédaction, analyse et veille
Cas d'usage réalistes
Dans un cabinet ou un service juridique interne, le prompt engineeringprompt engineeringIADiscipline consistant à concevoir des instructions précises pour guider un LLM vers la réponse souhaitée. Elle inclut les techniques de chain-of-thought, few-shot, rôle et format de sortie.Voir dans le glossaire rend service sur des tâches à faible risque de diffusionmodèle de diffusionIAGénérateur d'images qui part de bruit pur et le retire progressivement, guidé par une description textuelle, jusqu'à faire apparaître une image cohérente.Voir dans le glossaire directe : premières lectures de contrats, synthèses de jurisprudence pour orientation (jamais pour citation finale), reformulation de clauses standard, veille réglementaire par thème. Il rend un très mauvais service dès qu'on lui délègue une conclusion juridique définitive sans relecture par un professionnel habilité.
Le risque central en juridique est double : l'hallucinationhallucinationIAProduction par un modèle d'un énoncé faux formulé avec la même assurance qu'un fait établi. Le phénomène est structurel : le modèle optimise la vraisemblance, pas la vérité.Voir dans le glossaire de références (articles de loi, jurisprudences ou ouvrages inexistants, présentés avec la même assurance qu'une source réelle) et la fuite de confidentialité lorsqu'un texte de contrat réel est collé dans un outil externe sans garantie contractuelle sur le traitement des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire.
Gabarit de prompt
Contexte : [nature du document — contrat de prestation, CGV, clause de non-concurrence...]
Juridiction applicable : [droit français, droit du travail, etc.]
Tâche : identifier les clauses à risque dans le texte ci-dessous, sans en proposer une réécriture définitive.
Contraintes :
- N'invente aucune référence légale ou jurisprudentielle. Si tu cites un texte, précise sa source exacte et signale si tu n'es pas certain de son exactitude.
- Distingue clairement une observation factuelle (« cette clause plafonne la responsabilité à X ») d'une appréciation (« cette clause semble déséquilibrée »).
- Ne formule aucune conclusion sur la validité juridique du document : signale les points qui nécessitent une revue par un juriste.
Texte à analyser : [texte anonymisé si possible]
Un contrat réel contient souvent des noms, des montants et des clauses couvertes par le secret professionnel ou une obligation de confidentialité contractuelle. Avant de le transmettre à un modèle, anonymisez les identités et les données chiffrées sensibles, ou utilisez exclusivement un environnement dont le contrat de traitement des données garantit l'absence de réutilisation à des fins d'entraînement.
Pièges spécifiques au juridique
- Citer une jurisprudence inventée avec une référence plausible. Un numéro d'arrêt, une date et une juridiction cohérents en apparence ne garantissent rien : la seule vérification fiable consiste à rechercher la référence dans une base de jurisprudence officielle.
- Confondre reformulation et conseil juridique. Un modèle peut reformuler une clause de façon plus lisible sans que cela constitue un avis sur sa validité ou son opposabilité — cette distinction doit être explicite dans le prompt et rappelée au lecteur final.
- Traiter une synthèse de veille comme exhaustive. Une synthèse produite à partir des connaissances du modèle peut omettre une évolution réglementaire récente ; elle doit être positionnée comme point de départ, pas comme état de l'art vérifié.
Tech : documentation, revue et génération de code
Cas d'usage réalistes
Côté développement, le prompt engineering accélère la rédaction de documentation technique, la génération de tests unitaires, l'explication d'un code legacy peu documenté, et une première passe de revue de code avant relecture humaine. Le risque n'est pas l'hallucination de faits historiques mais la génération de code syntaxiquement correct et fonctionnellement dangereux — une requête SQL vulnérable à l'injection, une gestion des secrets en clair, une dépendance obsolète recommandée sans vérification de ses failles connues.
Gabarit de prompt pour une revue de code assistée
Rôle : relecteur technique senior spécialisé en sécurité applicative.
Contexte : extrait de code ci-dessous, langage [Python/JS/...], fonction destinée à [description du contexte d'exécution].
Tâche : identifier les problèmes potentiels dans les catégories suivantes, dans cet ordre de priorité :
1. Failles de sécurité (injection, gestion des secrets, contrôle d'accès).
2. Comportements incorrects sur les cas limites (entrées vides, valeurs nulles, concurrence).
3. Lisibilité et respect des conventions du langage.
Pour chaque problème identifié, indique la ligne concernée, la gravité (bloquant / à corriger / suggestion) et une piste de correction — sans réécrire l'intégralité du fichier.
Ne valide jamais un code comme "sûr" ou "sans faille" : signale seulement l'absence de problème détecté dans le périmètre analysé.
Code : [extrait]
Une revue de code générée sans hiérarchie mélange une faute de nommage et une injection SQL au même niveau d'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire. Demander explicitement une priorisation par gravité oriente le relecteur humain vers ce qui compte réellement avant de traiter le reste.
Pièges spécifiques au technique
- Faire confiance à une suggestion de dépendance sans vérification. Un modèle peut recommander une bibliothèque obsolète, abandonnée ou porteuse de vulnérabilités connues, car son entraînement reflète un état passé de l'écosystème plutôt que la situation actuelle des CVE publiées.
- Coller du code contenant des secrets réels dans le prompt. Une clé d'API ou un identifiant de connexion collé pour contexte reste potentiellement conservé côté outil selon la politique de rétention utilisée — retirer systématiquement les secrets avant tout envoi.
- Considérer l'absence de remarque comme une validation de sécurité. Un modèle qui ne signale rien n'a pas nécessairement tout vérifié ; il peut simplement ne pas avoir couvert la catégorie de faille pertinente pour ce code précis.
RH : recrutement, communication interne et procédures
Cas d'usage réalistes
En ressources humaines, le prompt engineering aide à rédiger des offres d'emploi, préparer des grilles d'entretien structurées, synthétiser des retours de candidats ou rédiger des communications internes standardisées. C'est le domaine où le risque de discrimination est le plus direct : une formulation de prompt mal cadrée peut produire des critères de sélection indirectement discriminatoires (âge, situation familiale, origine) sans que cela apparaisse de façon explicite dans le texte généré.
Demander à un modèle de « décrire le profil idéal » sans contrainte peut faire ressortir des critères corrélés à des caractéristiques protégées par le droit du travail (par exemple une préférence implicite pour un profil jeune associée à « dynamisme »). Le prompt doit interdire explicitement ces critères en amont, pas seulement espérer qu'ils n'apparaissent pas.
Gabarit de prompt pour une grille d'entretien
Poste : [intitulé et niveau de séniorité]
Compétences évaluées : [liste des compétences techniques et comportementales liées au poste]
Tâche : proposer une grille de 8 questions d'entretien évaluant strictement les compétences listées ci-dessus.
Contraintes impératives :
- Aucune question ne doit porter, même indirectement, sur l'âge, la situation familiale, l'état de santé, les origines, les convictions religieuses ou l'orientation sexuelle du candidat.
- Chaque question doit être reliée explicitement à une compétence évaluée, pas à une impression générale de "profil" ou de "culture fit" non définie.
- Formule les questions de façon identique pour tous les candidats à un même poste, sans variation implicite selon un profil supposé.
Format de sortie : tableau avec colonnes Question / Compétence évaluée / Ce qu'une bonne réponse démontre.
Pièges spécifiques aux RH
- Utiliser un prompt pour trier des CV de façon automatisée sans supervision. Un tri automatisé fondé sur des critères non audités peut reproduire ou amplifier un biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire présent dans les données d'exemple fournies au modèle — cette pratique expose à un risque juridique direct au titre de la non-discrimination à l'embauche.
- Injecter des données personnelles de candidats dans un outil externe sans base légale claire. Un CV contient des données personnelles au sens du RGPDRGPDConformitéRèglement européen sur la protection des données personnelles. Il s'applique dès qu'un système d'IA traite de telles données, et se cumule avec l'AI Act.Voir dans le glossaire ; leur traitement par un outil tiers doit reposer sur une base légale documentée et un contrat de sous-traitance conforme.
- Générer une évaluation de performance sans revue managériale. Une synthèse d'entretien annuel produite automatiquement peut refléter un ton disproportionné par rapport aux faits rapportés ; elle doit rester un brouillon soumis à la validation du manager avant tout archivage RH.
Grille de conformité transversale
Les trois métiers partagent une même logique malgré des contraintes distinctes. Le tableau suivant résume les points de vigilance propres à chacun, à utiliser comme grille de relecture avant tout déploiement d'un prompt métier en production.
| Domaine | Risque principal | Donnée sensible à protéger | Action de conformité minimale |
|---|---|---|---|
| Juridique | Référence légale ou jurisprudentielle inventée | Contenu du contrat, identité des parties | Vérification de chaque référence citée dans une base officielle |
| Technique | Code fonctionnellement correct mais vulnérable | Secrets, clés d'API, identifiants | Revue de sécurité humaine avant fusion en production |
| RH | Critère de sélection indirectement discriminatoire | Données personnelles des candidats et salariés | Interdiction explicite des critères protégés dans le prompt, audit périodique |
Elle sert de point de départ pour cadrer un prompt métier avant sa mise en usage régulier. Une organisation soumise à des obligations sectorielles spécifiques (santé, finance, secteur public) doit compléter cette grille avec ses propres exigences réglementaires.
Construire son propre gabarit métier
Un gabarit de prompt métier robuste répond systématiquement à quatre questions, indépendamment du domaine :
- Quelle est la tâche précise et ses limites ? Distinguer explicitement ce que le modèle doit produire de ce qu'il ne doit pas trancher (par exemple : reformuler une clause, mais jamais statuer sur sa validité).
- Quelles données sensibles transitent par le prompt ? Identifier avant rédaction si le contenu contient des données personnelles, des secrets techniques ou des informations confidentielles, et anonymiser ou retirer ce qui peut l'être.
- Quelles catégories d'erreur sont interdites par construction ? Formuler des contraintes négatives explicites — ne pas inventer de référence, ne pas évaluer de critère protégé, ne pas valider une sécurité non vérifiée — plutôt que de compter sur la seule qualité de la demande positive.
- Qui valide, et sur quel périmètre ? Nommer la personne ou le rôle responsable de la relecture finale, et préciser si cette relecture porte sur l'intégralité du contenu ou seulement sur les segments à risque identifié.
Pour un prompt juridique : tâche = identifier les clauses à risque, sans conclusion de validité ; données sensibles = texte contractuel anonymisé ; erreurs interdites = invention de référence légale ; validation = juriste habilité sur les clauses signalées. La même structure s'applique en changeant simplement le contenu de chaque case pour le technique ou les RH.
Ce qu'il faut retenir
Les prompts métier ne diffèrent pas des prompts génériques par leur formulation, mais par ce qu'ils doivent explicitement interdire. Le juridique exige l'absence de référence inventée et la protection de la confidentialité, le technique exige une revue de sécurité systématique avant toute mise en production, les RH exigent l'exclusion explicite de tout critère discriminant dès la formulation du prompt. Dans les trois cas, la qualité du résultat ne se mesure pas à la fluidité du texte produit, mais à la facilité avec laquelle un professionnel du domaine peut vérifier, en un temps raisonnable, les points qui engagent réellement une responsabilité. Construire ses propres gabarits en suivant les quatre questions présentées ici — tâche, données sensibles, erreurs interdites, validation — permet d'adapter cette logique à n'importe quel métier réglementé au-delà des trois exemples traités.
L'essentiel à retenir
Ce chapitre applique les principes de prompt engineering vus précédemment à trois métiers où l'erreur a un coût direct : le juridique, le développement technique et les ressources humaines. Pour chacun, il présente les cas d'usage réalistes, un gabarit de prompt réutilisable et les contraintes de conformité propres au domaine — secret professionnel, sécurité du code, non-discrimination à l'embauche. Il détaille aussi les pièges les plus fréquents observés en production dans ces contextes et propose une grille transversale pour évaluer le niveau de risque d'un prompt métier avant déploiement. L'objectif est de donner des structures directement adaptables, pas des exemples isolés à copier tels quels.
Questions fréquentes
Peut-on utiliser un modèle grand public pour analyser un contrat confidentiel ?
Un modèle peut-il remplacer une revue de sécurité de code par un développeur senior ?
Comment éviter qu'un prompt de recrutement produise des critères discriminatoires ?
Faut-il vérifier chaque référence juridique produite par un modèle ?
Un CV envoyé à un outil d'IA pose-t-il un problème RGPD ?
Les gabarits de ce chapitre sont-ils utilisables tels quels dans n'importe quelle organisation ?
Pourquoi structurer une revue de code par niveau de gravité plutôt qu'en liste plate ?
Progression sauvegardée dans votre navigateur.
Quiz de validation
Quiz Player
Quiz de validation
Plusieurs réponses possibles — validez ensuite.
Vrai ou faux.
Quiz indisponible (données invalides).