·6 min
Quand le coding agent devient cyber-critique
GPT-6 Astra atteint le niveau cyber « Critical » pendant que les sandboxes, les compétences et les rôles Engineering se recomposent. Le sujet n’est plus seulement d’accélérer le code, mais d’adapter le système de confiance autour des agents.
- AI-assisted Engineering
- Software Delivery
- Agentic AI
- Cybersecurity
- Developer Platform
- AI Fluency
- ESN
On a passé deux ans à demander : « jusqu’où l’IA peut-elle coder ? »
La question devient moins confortable : « que se passe-t-il lorsqu’un modèle capable de trouver des zero-days entre dans les outils du développeur ? »
Cette semaine, les signaux convergent vers une nouvelle catégorie d’acteurs du SDLC : des systèmes capables d’écrire, d’exécuter, de tester — et parfois d’attaquer.
Le sujet pour les CTO n’est donc plus seulement l’adoption. C’est le niveau de confiance que l’organisation sait construire autour de cette autonomie.
OpenAI a publié GPT-6 Astra le 3 septembre. Le point qui mérite davantage d’attention que les benchmarks de coding est ailleurs : Astra est le premier modèle qu’OpenAI classe au niveau « Critical » pour les capacités de cybersécurité dans son Preparedness Framework.
OpenAI indique qu’avec les bons outils et accès, Astra peut identifier des vulnérabilités jusque-là inconnues et développer de nouvelles façons de les exploiter sur des systèmes bien protégés, sans supervision humaine étape par étape. L’entreprise précise également avoir étendu le monitoring de désalignement à l’ensemble des inférences externes utilisant des tools.
Le lendemain, GitHub a annoncé GPT-6 Astra généralement disponible dans GitHub Copilot. Ce rapprochement est important : une capacité considérée comme cyber-critique par son fournisseur rejoint directement une surface utilisée pour écrire et modifier du logiciel.
Cela ne signifie pas que Copilot donne automatiquement des capacités offensives sans garde-fous. Cela signifie que la frontière entre « assistant de développement » et « acteur cyber puissant » se rapproche du quotidien Engineering.
Décision à tester : pour les modèles avancés, ajouter une classification de risque par usage : code lecture seule, modification de repo, exécution locale, accès CI/CD, accès secrets, diagnostic production, opérations sécurité.
2 — vm2 : une sandbox n’est pas une frontière de sécurité parce qu’elle s’appelle « sandbox »
Le 2 septembre, GitLab Threat Research a publié une vulnérabilité critique dans vm2, bibliothèque Node.js utilisée pour exécuter du code non fiable.
La faille, notée CVSS 10.0 par GitLab, permet une sortie de sandbox et de l’exécution de code arbitraire dans certaines configurations. Le cas est particulièrement intéressant pour les équipes qui industrialisent des agents : GitLab souligne explicitement l’usage croissant de ce type de librairie dans des outils où une IA exécute son propre code généré.
vm2 3.11.7 bloque l’attaque documentée, mais GitLab insiste sur un point plus large : une configuration trop permissive de require.external / require.root peut conserver un risque, et la recommandation à long terme est de privilégier des mécanismes plus forts — containers ou processus séparés — pour du code réellement non fiable.
La leçon d’architecture est simple : « sandbox » est une implémentation, pas une propriété de sécurité. Pour un agent de coding, le blast radius dépend autant du mécanisme d’isolation que des permissions système, du réseau, des secrets montés et des outils accessibles.
Décision à tester : inventorier les agents capables d’exécuter du code et documenter pour chacun quatre choses : isolation réelle, réseau atteignable, secrets disponibles, capacité d’écriture sur le poste/repo/infrastructure.
GitLab Threat Research — vm2 critical RCE →
3 — GitLab : le problème d’adoption n’est plus « qui a une licence ? », mais « qui sait déléguer correctement ? »
Toujours le 2 septembre, GitLab a publié son playbook interne pour développer l’AI fluency des équipes techniques.
Le signal est intéressant parce que l’entreprise distingue explicitement accès à l’outil et capacité à travailler avec l’IA. GitLab a retenu un modèle fédéré : socle et gouvernance centralisés, expérimentation et stratégie fonctionnelle locales.
L’entreprise a également créé un AI Literacy Ladder pour adapter la montée en compétence au niveau et au rôle de chacun. Un mois après son lancement, GitLab rapporte une hausse de 22,3 % des interactions quotidiennes avec son principal outil interne de coding IA.
Ce chiffre mesure de l’usage, pas de la productivité. GitLab évalue le programme avec trois dimensions — Reach, Depth et Applied Value — plutôt qu’avec une métrique unique.
C’est probablement la prochaine étape des programmes d’adoption : arrêter les formations génériques « prompt engineering pour tous » et apprendre aux équipes à décider quoi déléguer, comment cadrer le contexte et comment juger le résultat.
Décision à tester : construire une matrice de fluency par rôle — Developer, Tech Lead, QA, Product, Platform, SRE — avec trois niveaux : assister, déléguer, superviser.
GitLab — AI-fluent technical teams →
4 — Capgemini commence à nommer le métier : « Agentic AI Engineer — AI Native Software Engineering »
Les changements d’organisation deviennent visibles dans les intitulés de postes.
Le 4 septembre, Capgemini Engineering a publié une offre Senior Software Engineer intitulée « Agentic AI Engineer — AI Native Software Engineering » en Italie. Le même jour, le groupe publiait également des rôles « Google Agentic AI Engineer » et « Data Engineer (AI & Agentic Solutions) ».
Pris isolément, un job posting est un signal faible. Pris avec l’offre actuelle « AI-powered custom software engineering » de Capgemini — qui décrit une plateforme Engineering conçue pour la collaboration humains + agents, avec gouvernance, guardrails, DevSecOps, golden paths et observabilité — cela montre une évolution plus concrète : l’agentic engineering commence à entrer dans la taxonomie des compétences et du staffing des grandes ESN.
Ce n’est pas la disparition du Software Engineer, mais une spécialisation supplémentaire : architecture d’agents, toolchains, RAG, MCP, gouvernance, sécurité, evals et intégration SDLC.
Décision à tester : cartographier les missions actuelles et identifier celles où un rôle « Agentic Engineering » transversal apporterait plus de valeur qu’un simple déploiement d’assistant individuel.
Capgemini Careers — Agentic AI Engineer →
Capgemini — AI-powered custom software engineering →
Développeurs. Plus un agent sait modifier et exécuter, plus la valeur du jugement sur permissions, dépendances, isolation, tests et blast radius augmente.
Architectes / Tech Leads. Les capacités agentiques deviennent une nouvelle classe de workload : selon ses tools et credentials, un modèle devient un acteur avec des privilèges.
CTO / DSI. Les programmes d’adoption doivent rapprocher Engineering, Platform et Security. Le sujet ne tient plus uniquement dans « Developer Experience ».
ESN. La différenciation se jouera moins sur le nombre de personnes « certifiées IA » que sur la capacité à délivrer des workflows agentiques sûrs, mesurés et intégrés au SI client.
Je commencerais par une cartographie très concrète : modèles autorisés, tools disponibles, credentials, réseau atteignable, environnements accessibles et human gates.
1. Agent Blast Radius Review.
Pour un coding agent pilote, listez ce qu’il peut lire, écrire, exécuter et appeler : filesystem, Git, shell, MCP, cloud, CI/CD et secrets.
2. Auditer vos sandboxes.
Vérifiez technologie d’isolation, version, réseau autorisé et secrets montés. Si vm2 est présent, contrôlez version et configuration signalées par GitLab.
3. Construire votre AI Literacy Ladder.
Commencez avec trois niveaux : ASSISTER → DÉLÉGUER → SUPERVISER, adaptés à chaque rôle.
1. Agent Security & Blast Radius Assessment
Audit 5 jours des tools, credentials, sandboxes, réseau et human gates pour DSI/CISO/Platform ayant déjà déployé des coding agents ou MCP servers.
2. AI Engineering Fluency Program
Matrice de fluency par rôle, ateliers sur workflows réels, mesure Reach / Depth / Applied Value et coaching managers.
3. Agentic Engineering Capability Design pour ESN
Définition des rôles, skills, staffing model, accelerators, gouvernance et 2–3 offres industrialisables autour du SDLC agentique.
❓ Question de la semaine
Qui devrait « posséder » la politique d’accès d’un agent capable de coder et d’agir : le CTO, le CISO, la Platform Team… ou une nouvelle gouvernance commune ?
🤓 Pour ceux qui ont encore du contexte window
OpenAI — Safety overview GPT-6 Astra →
GitHub — GPT-6 Astra in Copilot →
GitLab — AI-fluent technical teams →
Capgemini — AI-powered custom software engineering →
Les agents deviennent plus capables. Le sujet intéressant est maintenant de savoir si nos organisations deviennent capables de leur donner le bon niveau de liberté — ni trop peu pour tuer le gain, ni trop pour transformer l’accélération en risque.
Voir mon profil LinkedInSe connecterRecevez la prochaine édition par email
Une inscription, pas de spam, désinscription sur simple demande.