·6 min
Les agents doivent apprendre à oublier
Une mémoire agentique peut devenir obsolète, les modèles expirent et les workflows doivent combiner IA, déterminisme et contrôle humain. Le nouveau défi n’est plus seulement de déployer des agents, mais de gérer leur vieillissement.
- Agentic AI
- Software Delivery
- Agent Memory
- GitHub Copilot
- DevSecOps
- AI Governance
- ESN
On parle beaucoup de donner une mémoire aux agents. Beaucoup moins de leur apprendre à oublier.
Dès qu’un agent reste en production plusieurs mois, sa mémoire devient un actif… et une dette : contexte périmé, règles obsolètes, biais accumulés, données personnelles à supprimer.
Cette semaine, plusieurs signaux montrent la même transition : l’IA ne se traite plus seulement comme un modèle à appeler, mais comme un système vivant à opérer dans le temps.
La mémoire d’un agent devient une ressource à gérer comme une base de données
AWS a publié le 4 septembre un pattern de memory lifecycle management pour les agents longue durée : TTL, scoring de pertinence, consolidation et pruning exécutés dans un workflow nocturne.
Le cas est concret : un agent de support continuait à traiter comme actif un litige facturation résolu quatre mois plus tôt ; un autre répétait un runbook de déploiement déjà remplacé.
AWS propose de différencier les durées de conservation selon le type de mémoire : les souvenirs épisodiques expirent plus vite, les faits sémantiques vivent plus longtemps, les procédures ont le niveau de rétention le plus élevé. Le pattern inclut une suite de tests avant/après pruning pour vérifier que l’agent ne perd pas une connaissance utile.
Pourquoi c’est structurant : une mémoire agentique n’est pas un simple cache. Elle devient une donnée gouvernée, avec qualité, rétention, audit, conformité et regression testing.
AWS — Lifecycle policies for agent memory →2 — GitHub rappelle que le modèle est une dépendance qui expire
GitHub a annoncé le 3 septembre la dépréciation de quatre modèles dans toutes les expériences Copilot le 2 octobre 2026 : Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code et Claude Opus 4.7.
Les alternatives recommandées sont Gemini 3.8 Flash, Kimi K3 et Claude Opus 5. Le signal est opérationnel : les modèles entrent désormais dans le dependency management du poste de développement.
Si prompts, skills, règles ou workflows sont optimisés pour un modèle précis, une dépréciation peut produire une migration applicative déguisée. Il faut tester la portabilité et connaître le blast radius d’un changement de modèle.
GitHub — Copilot model deprecations →3 — L’agent n’a pas vocation à remplacer chaque étape déterministe
AWS recommande pour Quick Automate une règle presque anti-hype : si la règle peut être écrite complètement, utilisez une étape déterministe.
Les agents prennent leur place sur l’interprétation de contenu non structuré, les ambiguïtés et le jugement. Les calculs, transformations, contrôles de seuil et enchaînements contractuels restent du code déterministe.
Même logique pour le human-in-the-loop : AWS distingue validations bloquantes et notifications non bloquantes et recommande de mesurer combien de fois les reviewers changent réellement la proposition de l’agent.
Conséquence architecture : un workflow agentique robuste ressemble moins à « un gros agent autonome » qu’à une composition de reasoning probabiliste, étapes déterministes et gates humains.
AWS — Agentic automation patterns →4 — Pendant que l’IA accélère le code, l’AppSec classique continue d’évoluer
CodeQL 2.26.4 ajoute notamment le support de Go 1.27, des modèles de sinks SQL injection pour Spring R2DBC et de nouvelles détections pour les workflows GitHub Actions.
La query actions/unpinned-tag détecte maintenant des références mutables vers les reusable workflows. Ce détail rappelle que AI-assisted Engineering n’annule aucune des vieilles classes de risque logiciel.
Au contraire, plus le volume de changements augmente, plus SAST, provenance, dépendances et policies CI deviennent importants pour absorber cette vitesse sans déplacer le coût vers la production.
GitHub — CodeQL 2.26.4 →5 — La gouvernance des agents commence à dépasser les frontières de l’entreprise
Reuters rapporte que les États-Unis et la Chine préparent pour mi-septembre un dialogue centré sur la sécurité de l’IA. L’agenda reste en discussion et la Maison-Blanche a indiqué qu’aucune réunion n’était encore officiellement planifiée.
Parmi les sujets proposés : coopération sur le monitoring des cyberattaques pilotées par IA et partage d’informations entre laboratoires en cas d’incident.
Pour les DSI, le point est l’émergence probable de mécanismes de disclosure et d’échange d’incidents propres aux agents, comme le logiciel a fini par construire ses pratiques CVE, CERT et responsible disclosure.
Reuters — AI safety dialogue →🧭 Ce que ça change pour nous
Développeurs. Le modèle, la mémoire et les tools deviennent des dépendances versionnées, testées et remplaçables.
Architectes / Tech Leads. Ajoutez le temps à vos architectures : que devient une mémoire après 30 jours ? un modèle après sa dépréciation ? une policy après un changement de risque ?
CTO / DSI. La maturité agentique se mesure moins au nombre de POC qu’à la capacité à faire évoluer les agents sans perdre connaissance, sécurité ni contrôle.
ESN. Une offre se dessine autour du lifecycle : migration de modèles, mémoire gouvernée, regression suites, policy management et operational readiness.
Avons-nous défini comment nos agents vieillissent — ou seulement comment ils démarrent ?
Un POC répond à « est-ce que ça marche aujourd’hui ? ». Une plateforme répond aussi à « comment cela reste correct, conforme et remplaçable dans douze mois ? ».
🧪 À tester lundi
1. Memory expiry review. Classez les mémoires en épisodique / sémantique / procédurale et définissez une rétention différente.
2. Model swap test. Exécutez la même regression suite avec deux modèles et mesurez qualité, erreurs tools, coût et latence.
3. Deterministic boundary map. Identifiez les étapes qui n’ont réellement besoin d’aucun jugement : elles devraient probablement sortir du LLM.
💰 Où est le business ?
Agent Lifecycle Audit. Modèles, mémoire, tools, policies, evals, deprecation plan, données personnelles et ownership.
Model Migration Factory. Regression suite + compatibilité skills/tools + rollout progressif.
Agent Memory Governance. Rétention, droit à l’oubli, consolidation, audit et tests de non-régression.
❓ Question de la semaine
Quel est aujourd’hui le composant le moins gouverné de vos agents : le modèle, la mémoire, les tools ou les données qu’ils accumulent ?
🤓 Pour ceux qui ont encore du contexte window
AWS — lifecycle policies for agent memory
GitHub — Copilot model deprecations
AWS — agentic automation patterns
GitHub — CodeQL 2.26.4
Reuters — AI safety dialogue
Nous avons appris à déployer les agents. La prochaine discipline est probablement de savoir les faire évoluer, oublier, migrer et mourir proprement.
Voir mon profil LinkedInSe connecterRecevez la prochaine édition par email
Une inscription, pas de spam, désinscription sur simple demande.