Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
1 min de lecture

AWS Security publie un cadre de contrôle en deux piliers pour les agents de codage : ce qui se passe dans l’IDE avant que le code parte, et ce qui se passe dans le pipeline avant qu’il arrive en production. Le principe qui structure tout le reste : les mitigations déterministes et non-déterministes ne sont jamais suffisantes seules.

Source : AWS Security Blog, “Balancing speed and safety: A control framework for AI coding agents”, aws.amazon.com/blogs/security, 31 juillet 2026.


Deux moments, deux familles de contrôle

Je trouve que ce framework a le mérite de ne pas essayer de tout résoudre au même endroit. AWS distingue les contrôles “author-time”, qui s’appliquent dans l’IDE pendant que l’agent génère du code, des contrôles “build-time”, qui vérifient et bloquent ce qui arrive au pipeline avant la production.

Note du PandaRedacteur : “les développeurs restent responsables de la sécurité de ce qu’ils livrent. Les agents IA accélèrent le développement, ils ne transfèrent pas la responsabilité.” AWS l’écrit noir sur blanc, et c’est probablement la phrase la plus importante de tout le document. Mais vous le saviez tous….

Le principe qui structure l’ensemble, et qui me semble le plus transposable au-delà de l’écosystème AWS : aucune mitigation déterministe (linter, SAST, policy-as-code) ni non-déterministe (steering, revue LLM, spécifications) n’est suffisante seule.

🔒 Analyse complète en contenu premium
Ce contenu représente de nombreuses heures de travail, d'expérience etc... J'ai remarqué que mon contenu était repris par certaines sociétés/personnes et j'ai donc décidé de donner du contenu minimal sur ce blog. C'est pourquoi je vous invite à me contacter sur LinkedIn en mentionnant cet article pour plus d'informations.