·6 min
Le SDLC devient bidirectionnel : la production revient écrire le code
Le SDLC devient bidirectionnel : trafic réel, traces, mémoire et incidents reviennent alimenter les décisions de code. Le défi n’est plus seulement le modèle, mais le contexte de production et ses garde-fous.
- AI-assisted Engineering
- Software Delivery
- DevSecOps
- Agentic AI
- Agent Memory
- Model Lifecycle
- Production Context
Pendant quinze ans, nous avons surtout déplacé l’information de gauche à droite : requirement → code → CI → production.
Les agents commencent à fermer la boucle dans l’autre sens. Le trafic réel, les traces, les incidents, les contraintes d’infrastructure et même la mémoire accumulée reviennent alimenter les décisions de code.
Le vrai sujet n’est donc plus seulement « l’IA écrit-elle bien du code ? ». Il devient : quelles données de production peut-on lui donner, dans quel environnement d’exécution, avec quelles limites et quelles politiques de lifecycle ?
Le 3 septembre, Cloudflare a ouvert en early access son service Vulnerability Discovery and Remediation, associé à Managed Defense et aux modèles OpenAI Daybreak.
Le pattern est plus intéressant que le modèle : l’analyse ne s’arrête pas au code source. Elle combine routes réellement actives, volume de trafic, événements WAF, protections existantes et source déployée pour prioriser les vulnérabilités.
Le système peut ensuite proposer un patch de code et, lorsque les preuves le justifient, une règle WAF temporaire. Les propositions sont validées hors modèle et restent soumises à revue humaine.
C’est un changement profond pour le DevSecOps : la production n’est plus seulement la destination du SDLC ; elle devient une source de contexte qui influence directement ce qu’on corrige et dans quel ordre.
2 — Cursor sépare enfin l’agent de son environnement d’exécution
Cursor a lancé le 2 septembre ses self-hosted machines. Le harness et la boucle agentique restent Cursor, mais l’exécution des tools peut rester entièrement dans le réseau de l’entreprise.
Codebase, build outputs et secrets restent sur les machines internes. Les équipes peuvent constituer des pools de workers dynamiques et faire tourner les Cloud Agents sur AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel ou E2B. Le computer use est également disponible sur workers Linux et Mac.
Le signal architectural : l’agent et son compute deviennent deux couches séparables. Pour une DSI, cela ouvre un compromis plus intéressant entre expérience SaaS et contrôle de l’exécution.
Cursor — Self-hosted machines →
3 — La mémoire d’un agent devient un actif à gouverner… et à supprimer
AWS publie le 4 septembre un pattern complet de lifecycle pour AgentCore Memory : expiration TTL, scoring de pertinence et consolidation par LLM.
Le problème est concret : après des mois, un agent peut continuer à ressortir un incident clos ou un runbook devenu obsolète. AWS distingue mémoire épisodique, sémantique et procédurale avec des politiques de rétention différentes.
Le sujet n’est pas seulement « memory improves UX ». La mémoire devient une donnée persistante avec fraîcheur, droit à l’oubli, auditabilité et risque de décision erronée.
AWS — AgentCore memory lifecycle →
4 — GitHub rappelle qu’un modèle n’est pas une dépendance stable
Le 3 septembre, GitHub a annoncé la dépréciation au 2 octobre de Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code et Claude Opus 4.7 dans l’ensemble des expériences Copilot.
Les administrateurs Business et Enterprise peuvent devoir activer explicitement les modèles de remplacement dans leurs policies.
Quand les modèles changent à cette vitesse, une organisation ne peut plus traiter le modèle sélectionné comme une dépendance implicite. Il faut savoir inventorier les workflows dépendants, rejouer les evals et migrer les policies.
GitHub — Copilot model deprecations →
5 — L’agent opérationnel commence à raisonner avec les runbooks du métier
AWS montre comment étendre DevOps Agent pour diagnostiquer les incidents après migration DMS vers Aurora PostgreSQL.
Le MCP fourni expose 20 tools en lecture seule et 46 runbooks. L’agent corrèle état DMS, validation, CloudWatch, Performance Insights, logs, CloudTrail et historique de déploiement.
Dans un test documenté, une investigation de validation a utilisé 11 tools et 33 appels ; une investigation ouverte a mobilisé 12 tools avant de sélectionner le runbook pertinent. AWS précise qu’il s’agit d’illustrations de leurs runs, pas d’un benchmark.
Le pattern à retenir : le MCP utile en entreprise n’est pas un catalogue géant de commandes. C’est souvent un ensemble de tools read-only étroits + expertise opérationnelle codifiée en runbooks.
Développeurs. Le contexte utile ne vient plus seulement du repository : production, incidents, security events et état de l’infrastructure entrent dans la boucle de résolution.
Architectes / Tech Leads. Il faut expliciter quatre plans : model, execution, memory et production context. Les mélanger dans un seul produit rend les migrations et la gouvernance fragiles.
CTO / DSI. Les plateformes Engineering doivent prévoir le changement permanent de modèles, les politiques de mémoire et la frontière de compute — pas uniquement distribuer un assistant.
ESN. Le terrain à forte valeur se déplace vers l’intégration entre AI Engineering, Platform, SecOps, Data et Run : là où le contexte client est difficile à commoditiser.
La réponse devrait couvrir au minimum code, logs, traces, trafic, secrets, mémoire, environnements d’exécution et capacité à proposer ou appliquer un changement.
1. Production-context experiment.
Sur un bug réel, donnez à l’agent uniquement traces/logs anonymisés + diff récent + tests. Mesurez temps jusqu’à hypothèse correcte et patch reviewable.
2. Memory policy sheet.
Pour chaque type de mémoire agentique : source, propriétaire, TTL, condition de consolidation, droit d’effacement, audit.
3. Model deprecation drill.
Prenez un workflow critique et remplacez son modèle. Combien de temps faut-il pour rejouer les evals, valider le coût et remettre en production ?
1. Production Context Readiness Assessment.
Cartographier quelles données Run/SecOps peuvent être rendues accessibles aux agents, avec anonymisation, permissions et audit.
2. Agent Memory Governance.
Conception des taxonomies, TTL, consolidation, delete workflows, conformité et observabilité de la mémoire.
3. Managed Model Lifecycle.
Pour les ESN : catalogue de modèles, policy management, tests de non-régression, deprecation watch et migration automatisée des workloads.
❓ Question de la semaine
Le prochain avantage compétitif d’une équipe Engineering viendra-t-il du meilleur coding agent… ou de sa capacité à lui fournir un meilleur contexte de production sans perdre le contrôle ?
🤓 Pour ceux qui ont encore du contexte window
Cloudflare — production-aware vulnerability remediation →
Cursor — self-hosted machines →
GitHub — Copilot model deprecations →
AWS — DMS investigations with DevOps Agent →
L’IA accélère le code. La prochaine étape est plus ambitieuse : raccourcir la distance entre ce qui se passe réellement en production et ce que l’équipe décide de changer.
Voir mon profil LinkedIn Se connecterRecevez la prochaine édition par email
Une inscription, pas de spam, désinscription sur simple demande.