Une politique secure coding "classique" (OWASP Top 10, input validation, gestion secrets, crypto, etc.) reste indispensable. Mais elle ne couvre pas les bugs propres au code qui appelle des LLM. Voilà la checklist 24 points que j'intègre à la politique dev d'un client quand l'app embarque un LLM ou un agent.
Le principe
La politique secure coding LLM complète la politique classique. Elle ne la remplace pas. À intégrer dans :
- Le guide dev interne.
- Le template de PR.
- La checklist de code review.
- La suite de tests Semgrep/SAST custom.
Les 24 points
Gestion des prompts (1-5)
1. Pas de secrets, clés API, IDs internes, données métier sensibles dans les system prompts.
2. System prompts en SCM, versionnés, change-controlled. Modification = revue obligatoire.
3. Séparation système / utilisateur via structured prompting (jamais concaténation naïve f"... {user_input} ...").
4. Sanitization du contenu RAG / web crawl injecté en contexte (au minimum filtrer les instructions injection connues).
5. Délimitations claires pour le contenu non-fiable (
Gestion des appels LLM (6-10)
6. Clés API LLM provider en secrets manager exclusivement. Jamais en variable d'env loguée. Rotation planifiée.
7. Configuration modèle (name, version, temperature, top_p) en config versionnée. Pas de magic numbers.
8. Timeout obligatoire (recommandé 30s-2min selon cas). Sans timeout, blocage thread.
9. Retry policy avec backoff + jitter, bornée. Pas de retry infini.
10. Fallback en cas de panne provider (réponse dégradée, basculement sur autre provider, mode lecture seule).
Traitement des outputs (11-14)
11. Pas d'eval / exec sur l'output. Si exécution code généré, sandbox obligatoire (Pyodide, micro-VM, container restreint).
12. Validation de la sortie structurée (JSON, function call args) contre schema. Échec = rejet.
13. Output escaping côté UI (HTML escape, Markdown safe rendering).
14. Filtering PII sur les outputs (regex emails, téléphones, IDs internes, secrets) avant retour utilisateur.
Tools / function calls / MCP (15-18)
15. Catalogue de tools versionné, review-gated à chaque ajout.
16. Validation stricte des paramètres tool (schema, type, ranges, allowlist).
17. Audit log de chaque tool call avec paramètres et résultat.
18. Validation humaine obligatoire pour actions externes ou irréversibles.
Mémoire et état (19-21)
19. Cloisonnement strict mémoire conversationnelle par utilisateur / tenant.
20. Politique de rétention claire avec TTL et purge automatisée.
21. Pas de PII non chiffrée dans la mémoire long-terme (mem0, custom).
Tests et observabilité (22-24)
22. Suite de tests adversariaux (prompt injection, jailbreak, tool abuse) intégrée en CI, bloquante.
23. Logging structuré des appels LLM (input hash, model version, durée, coût) — pas de PII en clair dans les logs.
24. Métriques d'usage exposées (volume, coût, taux d'erreur, validations humaines) avec alerting.
Comment je l'opère
Intégration dans la politique dev
- Section dédiée "Sécurité LLM" dans le guide dev.
- Points 1, 3, 6, 11 obligatoires (bloquants en review).
- Reste : recommandations avec justification écrite si dérogation.
Intégration dans la CI
- Règles Semgrep custom pour les points 1, 4, 6, 11, 16 (les plus mécaniques).
- Tests unitaires sur le filter PII (point 14).
- Suite adversariale Promptfoo/PyRIT (point 22).
Intégration dans la PR template
Section ajoutée dans la PR template : ```
Sécurité LLM (si applicable)
- [ ] Pas de secret dans le system prompt
- [ ] Pas de concaténation naïve dans le prompt
- [ ] Output validé/escapé
- [ ] Si nouveau tool : ajouté au catalogue et review-gated
- [ ] Si action externe : validation humaine en place
- [ ] Tests adversariaux passing
```
Formation dev
2h de formation interne par an minimum. Mise à jour quand les techniques évoluent (computer use, agents multi-modèles, etc.).
Les pièges classiques
Politique trop générique
Une politique qui dit "implémenter la sécurité LLM" sans les 24 points ne sert à rien. Trop floue pour être vérifiée.
Politique sans outillage Semgrep
Les règles mécaniques (point 1, 6, 11) doivent être en CI. Sinon elles ne sont vérifiées qu'en revue humaine — donc inconstantes.
Pas de mise à jour
L'écosystème LLM évolue (MCP, computer use, modèles multimodaux). La politique doit suivre. Revue annuelle minimum.
Politique sans suite de tests
Sans tests adversariaux automatisés, la politique reste déclarative. Les tests sont la vérification de la politique.
Politique invisible
La politique doit être citée dans la PR template, dans la formation, dans les revues. Si elle n'est pas visible, elle n'est pas appliquée.
Le lien avec les autres référentiels
Cette checklist alimente :
- OWASP ASVS appliqué LLM (voir OWASP ASVS LLM).
- OWASP LLM Top 10 (voir OWASP LLM Top 10).
- ISO 42001 clause A.8 (operational management).
- NIST AI RMF fonction MANAGE.
Chaque point peut être tracé à une exigence des référentiels, ce qui rend défendable.
Mon avis en 1 ligne
24 points concrets, intégrés à la politique dev, à la CI, à la PR template, à la formation, et tracés aux référentiels. C'est ce qui transforme une politique secure coding LLM déclarative en politique vérifiée. Compter 3-5 jours pour outiller initial, plus 4-8h par trimestre pour mise à jour. C'est l'investissement le moins cher pour limiter la dette LLM à la source.