04 - Evaluer, fiabiliser, securiser#

C'est la section que tout le monde saute. C'est aussi celle qui separe le bricolage du travail serieux.

Temps de lecture : 6 min | Niveau : Intermediaire

Ce que tu sauras faire apres#

• Expliquer pourquoi un prompt "qui marche bien" n'est pas un prompt valide.
• Choisir dans quel ordre lire les 6 fiches de cette section.
• Reperer les 3 risques concrets qui te concernent en data engineering : mauvaise extraction, hallucination, fuite de donnees.
• Mettre en place un reflexe minimal avant de brancher un prompt sur des donnees d'entreprise.

🎯 Pourquoi cette section existe#

Tu ecris un prompt. Tu le testes. Ca marche. Tu le mets en production sur 40 000 lignes.

Trois semaines plus tard, quelqu'un remarque que 6 % des montants sont faux. Personne ne sait depuis quand. Personne ne sait si c'est le prompt, le modele, ou un changement de format dans les fichiers sources.

Voila le probleme. Quand tu ecris du SQL, tu as un plan d'execution, des contraintes, des tests unitaires dbt. Quand tu ecris un prompt, tu n'as rien. Par defaut, tu juges au feeling, sur 2 ou 3 exemples que tu as choisis toi-meme (donc les plus faciles).

Cette section remplace le feeling par des chiffres.

🧨 Les trois facons de se planter#

Et une quatrieme, moins grave mais tres reelle : ca coute cher et c'est lent, et tu ne sais pas combien exactement. C'est la fiche 06.

📚 Les fiches de la section#

1. 01 - Construire un jeu de tests Comment fabriquer 20 cas de test representatifs, definir un critere de reussite chiffre, et automatiser la comparaison. Exemple fil rouge : extraction de champs sur des factures.
2. 02 - Le LLM comme juge Faire noter les sorties d'un modele par un autre modele. Grille de notation, prompt de juge pret a copier, biais connus du juge, et surtout : quand il ne faut PAS l'utiliser.
3. 03 - Reduire les hallucinations Autoriser le "je ne sais pas", exiger des citations du document source, verification en deux passes, ancrage sur les donnees fournies. Avec les prompts exacts.
4. 04 - Prompt injection et securite Injection directe et indirecte, un fichier de donnees qui contient des instructions cachees, ce qui se passe quand un agent a des outils. Principes de defense et reference OWASP.
5. 05 - Donnees sensibles et RGPD Ce qu'on ne colle pas dans un prompt, pseudonymisation avant envoi, difference entre compte grand public et API entreprise, retention, choix de la region. Checklist avant d'envoyer des donnees clients.
6. 06 - Mesurer qualite, cout et latence Les 3 metriques a suivre, comment les mesurer sans usine a gaz, et un tableau de suivi d'experimentations de prompts.

🧭 Dans quel ordre lire#

Si tu as 20 minutes : lis 01 et applique-la sur ton prompt le plus utilise. C'est la fiche qui rapporte le plus vite.

Si tu as une demi-journee : 01 → 03 → 06. Tu obtiens un prompt mesure, plus fiable, et dont tu connais le cout.

Si tu branches un agent sur des donnees d'entreprise : 04 et 05 ne sont pas optionnelles. Lis-les avant, pas apres.

✅ Le reflexe minimal#

Avant de brancher un prompt sur des donnees reelles, pose-toi ces quatre questions. Si tu ne peux pas repondre, tu n'es pas pret.

1. Sur combien de cas je l'ai teste ? (moins de 20 = tu ne sais rien)
2. Quel est mon critere de reussite chiffre ? ("c'est bien" n'est pas un critere)
3. Qu'est-ce qui se passe si le modele se trompe silencieusement ?
4. Est-ce que les donnees que j'envoie ont le droit de sortir de l'entreprise ?

Template pret a copier : fiche de mise en service#

Colle ce bloc en haut du fichier du prompt, et remplis-le. Tant qu'il reste un crochet vide, le prompt ne part pas en production.

PROMPT : [NOM DU PROMPT]
TACHE : [CE QU IL FAIT, EN UNE PHRASE]

1. TESTE SUR : [NOMBRE] cas, dont [NOMBRE] cas limites
   Jeu de tests : [CHEMIN DU FICHIER DANS LE REPO]
2. CRITERE CHIFFRE : [METRIQUE] >= [SEUIL]
   Contrainte bloquante : [EX : 0 VALEUR INVENTEE]
3. SI LE MODELE SE TROMPE : [CE QUI SE PASSE, EX : LIGNE MISE EN QUARANTAINE]
   Controle par code apres coup : [EX : VALIDATION DE SCHEMA JSON]
4. DONNEES ENVOYEES : [NATURE DES DONNEES]
   Canal autorise : [EX : CLE API DE L ORGANISATION]
   Validation obtenue : [QUI A VALIDE, OU "AUCUNE : DONNEES FICTIVES"]

A retenir#

• Un prompt teste sur 3 exemples que tu as choisis n'est pas teste.
• La regle officielle d'Anthropic est claire : beaucoup de cas notes automatiquement vaut mieux que peu de cas notes a la main.
• Les deux gros risques metier sont l'erreur silencieuse et la fuite de donnees, pas le modele qui dit une betise evidente.
• Un agent avec des outils change la nature du risque : une erreur ne produit plus un mauvais texte, elle produit une action.
• Cette section n'est pas un avis juridique ni un audit de securite. C'est un socle de bonnes pratiques d'ingenieur.

Depots GitHub a explorer#

Ces depots te donnent du code qui tourne pour chaque sujet de la section : fabriquer un jeu de tests, faire noter par un juge, attaquer ton propre prompt avant les autres, masquer les donnees personnelles, suivre le cout et la latence.

Celui a cloner en premier : promptfoo/promptfoo. C'est le seul qui te fait passer du feeling au chiffre en une soiree : tu ecris un fichier YAML, tu listes tes cas, tu lances, tu as un tableau.

Il couvre a lui seul les fiches 01, 02 et 04. Garde deepeval pour quand tu voudras brancher ces tests dans ta CI en Python.

Sources#

Toutes ces pages ont ete ouvertes et verifiees le 26 septembre 2026.

• Anthropic - Define success criteria and build evaluations
• Anthropic - Reduce hallucinations
• Anthropic - Mitigate jailbreaks and prompt injections
• OWASP Gen AI Security Project - LLM Top 10
• Microsoft Learn - Planning red teaming for large language models