Votre checklist d’action
- 01
Définir la tâche et ses limites
Décrivez les entrées, la sortie attendue, les utilisateurs et les décisions interdites à l’IA. Comparez le gain espéré à une solution simple sans modèle génératif. Exemple : retrouver la procédure interne applicable à une demande, avec passage cité et date de version. La réussite demande une source correcte et accessible au demandeur. Une réponse plausible sans preuve doit compter comme un échec, même si sa rédaction paraît convaincante.
- 02
Cartographier les données
Documentez les données envoyées, leur localisation, la conservation et les conditions du fournisseur. Limitez les informations sensibles et vérifiez les autorisations sur les documents indexés. Pour un RAG, séparez autorisation d’indexer, autorisation de retrouver et autorisation de restituer. Un document visible par l’administrateur ne doit pas devenir accessible à tous. Testez le même sujet avec plusieurs profils et conservez les refus attendus.
- 03
Évaluer sur des cas représentatifs
Constituez un jeu de cas normaux, difficiles et adversariaux avec critères de réussite. Mesurez erreurs factuelles, citations, refus, coûts et latence, puis conservez les versions testées. Gardez un lot de contrôle distinct des exemples utilisés pour ajuster les instructions. Faites annoter les réponses par une personne compétente et suivez séparément citations incorrectes, réponses incomplètes et refus justifiés. Comparez à une recherche documentaire simple.
- 04
Limiter les capacités des agents
Accordez le minimum de permissions. Exigez une validation humaine avant toute action engageante, séparez les environnements et prévoyez un arrêt ainsi qu’un retour arrière. Une réponse correcte ne donne pas le droit d’envoyer un message, modifier un compte ou supprimer un document. Délimitez les outils par action et par ressource ; exigez une confirmation explicite lorsque l’opération engage son destinataire ou modifie des données sensibles.
- 05
Tester les entrées hostiles
Traitez les documents et pages récupérés comme des données non fiables. Testez les injections de prompt, l’exfiltration, les outils détournés et les réponses sans preuve ; ne supposez pas qu’un filtrage résout tout. Placez une consigne contradictoire dans un document de test et observez si le système la traite comme du contenu. Vérifiez aussi qu’un résultat d’outil ne devient pas une autorisation. Le test porte sur le parcours complet, pas uniquement sur le modèle.
- 06
Surveiller et réévaluer
Nommez un responsable, surveillez les incidents et refaites les évaluations lors des changements de modèle, de prompt ou de corpus. Définissez un seuil d’arrêt et une alternative manuelle. Conservez un journal proportionné permettant de retrouver le cas, les sources et la décision humaine sans recopier inutilement les données sensibles. Rejouez les cas critiques après toute modification et prévoyez le retour à une procédure manuelle documentée.
Exemple pédagogique : un assistant répond aux questions sur des contrats. Préparez le même dossier avec un profil autorisé et un profil exclu. Le premier doit recevoir une réponse appuyée sur le bon passage ; le second ne doit révéler ni contenu ni extrait réservé. Ajoutez un document sans rapport contenant une instruction d’envoi par email : sa présence dans le corpus ne doit pas autoriser cet envoi.
Références : données, usages et limites
Documentation consultée le .
| Source et objet | Donnée ou repère vérifié | Comment l’utiliser | Limite à conserver |
|---|---|---|---|
| MITRE ATLAS Examiner les tactiques, techniques et cas documentés visant des systèmes IA. |
Le dépôt officiel publie les données ATLAS : tactiques, techniques et études de cas. Ces éléments complètent une analyse du système réellement déployé. | Choisissez les scénarios correspondant aux données, interfaces et outils de votre application. Testez les permissions et les conséquences, pas seulement la réponse du modèle. | Un catalogue de techniques n’est pas une garantie de couverture exhaustive ni un résultat de test sur votre système. |
| NIST · AI Risk Management Framework Organiser la gestion des risques associés à l’IA. |
Le cœur de l’AI RMF s’articule autour de Govern, Map, Measure et Manage. Il s’agit d’un cadre volontaire de gestion du risque. | Définissez usage, personnes concernées et conséquences d’erreur. Rapprochez chaque risque d’une évaluation, d’un responsable et d’un moyen d’arrêt ou de reprise. | Le cadre ne certifie ni un modèle ni une application. Son utilisation ne dispense pas d’examiner les obligations applicables. |
| OWASP · LLM Top 10 Préparer des tests sur les risques des applications de modèles de langage. |
L’édition 2025 inclut notamment Prompt Injection, Sensitive Information Disclosure et Excessive Agency. | Traduisez un risque en scénario observable : document hostile, donnée réservée ou outil hors périmètre. Notez le comportement attendu et la preuve du refus. | Une liste de risques n’est pas une évaluation complète. Le filtrage des entrées ne démontre pas à lui seul l’autorisation de chaque action. |
RAG : droits, citations et caches
Le RAG ne délègue pas les permissions au modèle
Le corpus apporte des informations ; le service d’accès décide quels passages une identité peut recevoir. Distinguez la sélection pertinente, la permission sur l’objet et l’autorité d’agir après lecture.
- Couvrir recherche vectorielle, branche lexicale, citations et caches.
- Appliquer le retrait de droits aux conversations déjà ouvertes.
- Vérifier séparément qualité de réponse et absence de fuite.
Explorer la matrice de droits RAG et ses cas de test →
Références consultées le · OWASP · LLM08:2025 Vector and Embedding Weaknesses OWASP · API1:2023 Broken Object Level Authorization
OAuth/OIDC : audience et droits
Un agent IA conserve les frontières d’autorisation de chaque outil
Une instruction du modèle ne crée pas une délégation. Pour chaque outil, identifiez le client appelant, le serveur de ressources, l’audience et la politique sur les objets.
- Limiter les droits à l’opération et au destinataire utiles au cas d’usage.
- Ne pas transférer le jeton d’un outil à une autre API par simple commodité.
- Tester qu’un agent ne lit pas les objets d’un autre locataire malgré un scope de lecture.
Voir les destinataires et les dix scénarios OAuth/OIDC →
Sources vérifiées le · IETF · RFC 9700 · OAuth 2.0 Security BCP · IETF · RFC 9068 · JWT access token profile · OpenID Foundation · OpenID Connect Core 1.0 · IETF · RFC 8725 · JWT Best Current Practices · IETF · RFC 6749 · OAuth 2.0 framework
SSRF : URL et connexions
Un outil d’agent IA garde des sorties réseau bornées
Le texte produit par un modèle, un document récupéré ou un résultat de recherche ne doit pas élargir les destinations autorisées d’un outil. Définir le connecteur par opération et par service permet de contrôler ce qu’un agent peut réellement joindre.
- Reconstruire les requêtes à partir d’identifiants métier lorsque le service est connu.
- Contrôler résolution, connexion, proxy et chaque redirection au composant de sortie.
- Conserver une décision traçable et des limites de réponse, même après retry ou repli.
Lire les 12 cas et les contrôles de connexion →
Sources relues le · OWASP · SSRF Prevention Cheat Sheet · WHATWG · URL Living Standard · AWS EC2 · Instance metadata options · IETF · RFC 3849
IA : contrôler un résultat JSON
Le contrat d’extraction précède toute action d’agent
Un objet généré par IA reste une entrée à contrôler. Des types valides ne prouvent ni les valeurs du document, ni l’identité de l’acteur, ni son droit d’écrire dans le système cible.
- Valider avant de transmettre les champs au connecteur.
- Traiter unknown et les preuves absentes par une voie explicite de revue.
- Appliquer les contrôles de contexte et d’autorisation à chaque opération aval.
Comparer les 14 sorties et leur motif →
Sources relues le · IETF · RFC 8259 · JSON Schema · Object reference · JSON Schema · Draft 2020-12 validation · Python 3.12 · json decoder · python-jsonschema · Schema validation · OWASP · LLM05:2025 Improper Output Handling

