·5 min
Après le copilote, la boucle d’amélioration continue
Les agents commencent à apprendre de leurs traces, les skills encodent la méthode métier et les pipelines durcissent leurs politiques. Le prochain avantage du Delivery IA sera la boucle de feedback.
- AI Delivery
- Agent Optimization
- Agent Skills
- GitHub Actions
- Engineering Metrics
- Software Delivery
- ESN
Nous avons passé deux ans à équiper les développeurs. Le prochain saut est ailleurs : équiper le système de Delivery pour qu’il observe ce qui marche, détecte ce qui échoue et améliore ses propres configurations — sans transformer la production en laboratoire sauvage.
Cette semaine, les signaux convergent : traces utilisées pour optimiser les agents, skills métier évaluées comme du code, politiques CI exécutables et métriques d’adoption qui descendent au niveau des usages. L’IA n’est plus seulement dans la boucle de production. La boucle elle-même devient programmable.
⚡ Le signal de la semaine — L’agent entre dans sa propre boucle d’amélioration
Le 16 septembre, AWS a détaillé AgentCore optimization : des traces de production évaluées servent à proposer une nouvelle configuration d’agent, puis cette configuration passe par évaluation offline et A/B test avant promotion.
Le mécanisme ferme une boucle que beaucoup d’équipes font encore à la main : observer → diagnostiquer → modifier prompt, tools ou skills → réévaluer → promouvoir. Des garde-fous rejettent notamment une configuration qui grossit de plus de 20 %, relâche la sécurité ou recopie verbatim des traces.
Sur les benchmarks publiés par AWS, le Single Agent Reflector atteint 81,55 % sur AppWorld en 6 minutes et 20 tours ; la variante expérimentale Sub-Agent Reflector atteint 95,83 %. Ce sont des résultats fournisseur, pas une promesse de performance en production.
Une configuration agentique devient un artefact versionnable avec télémétrie, candidats, evals, shadow/A-B et promotion. Les pratiques de progressive delivery arrivent sur le comportement des agents. Décision : créez un pipeline de promotion pour vos configurations IA avant de chercher à les rendre auto-évolutives.
Source primaire →1 — Une skill n’est pas de la documentation : c’est une procédure métier testable
Le 16 septembre, AWS a publié 38 agent skills open source couvrant 11 domaines santé et life sciences. Elles encodent procédures de décision, seuils, erreurs fréquentes, paramètres et critères de validation dans des fichiers SKILL.md auditables.
Sur 410 prompts, AWS rapporte que les agents équipés de skills gagnent 69,5 % à 85,9 % des comparaisons face aux mêmes agents sans skills selon le harness. Le gain le plus fort porte sur le raisonnement critique ; la variance baisse jusqu’à 61,9 % dans certains domaines. L’évaluation est produite par AWS et utilise un LLM judge : il faut la reproduire sur vos tâches.
Le signal : le contexte métier utile n’est pas seulement une base RAG. Une partie du savoir-faire doit être exprimée comme procédure exécutable et évaluée. Pour une ESN : transformer audits, standards d’architecture, checklists de migration ou playbooks de delivery en skills portables, puis démontrer leur valeur par des evals.
Source primaire →2 — La CI devient une frontière de sécurité à politiques exécutables
Le 17 septembre, GitHub a rendu GA les Workflow execution protections pour Actions. Elles contrôlent qui peut déclencher un workflow et quels événements sont autorisés, avec ciblage par fichier, mode d’évaluation, insights et API REST pour gérer les règles comme du code.
GitHub prépare aussi un défaut plus restrictif sur pull_request_target pour certains dépôts publics, avec enforcement annoncé au 2 novembre 2026 pour les dépôts concernés utilisant la politique par défaut.
Plus les agents ouvrent des PR, lancent des workflows et manipulent des repos, plus le pipeline devient le point où une intention générée rencontre des secrets et des droits réels. Le pattern : autonomie en amont, politique déterministe au point d’exécution.
Source primaire →3 — Mesurer « Copilot activé » ne suffit plus
Le 17 septembre, GitHub a enrichi son Copilot impact dashboard avec l’engagement par fonctionnalité sur 28 jours : code completion, agent edit, code review passive ou active, cloud agent, CLI et app. Un utilisateur est compté engagé sur une feature s’il l’utilise au moins deux jours dans la période.
Deux équipes ayant 80 % d’utilisateurs actifs peuvent donc avoir des maturités très différentes. La prochaine étape pour un CTO est de croiser cette télémétrie avec lead time, temps de review, taux de reprise, incidents et satisfaction développeur. L’adoption décrit le comportement ; elle ne prouve pas la valeur.
Décision : remplacez « licences actives » par une matrice usage × outcome × type de tâche.
Source primaire →4 — Le coding agent devient aussi un outil de performance engineering
Le 17 septembre, Anthropic a publié un cas de recherche où Claude a optimisé plus de 30 modèles open source de prédiction et conception biomoléculaire en moins de quatre semaines. Anthropic rapporte un speed-up moyen d’environ 4× et un mode basse mémoire permettant de traiter des systèmes de plus de 10 000 tokens biomoléculaires sur un seul nœud GPU NVIDIA.
Le signal pour une DSI : un coding agent peut être appliqué à un portefeuille de code existant avec une fonction objectif mesurable — vitesse, mémoire, coût — et produire des optimisations vérifiables par benchmark.
Pour une ESN, cela ouvre une catégorie moins commoditisable que « développer plus vite » : AI-assisted performance engineering sur workloads data, calcul, JVM, GPU ou batch, avec baseline et gains mesurés.
Source primaire →🧭 Ce que ça change pour nous
Développeurs : traitez prompts, skills et tool descriptions comme des artefacts testables. Architectes : dessinez la boucle traces → evals → candidat → shadow/A-B → promotion → rollback. Platform Engineering : placez des politiques déterministes là où l’agent obtient des droits réels. CTO / DSI : reliez les usages par fonctionnalité à un outcome. ESN : transformez le savoir-faire en procédures exécutables, évaluées et portables.
🏢 Le sujet que je mettrais sur la table d’un COMEX IT
Quel actif voulons-nous réellement accumuler avec l’IA : des licences, des prompts… ou une boucle d’apprentissage organisationnelle ? Une entreprise qui observe les tâches, mesure les outcomes, encode ses méthodes en skills et réinjecte les résultats dans ses standards améliore son système de Delivery à chaque projet.
🧪 À tester lundi
Choisissez un workflow agentique déjà utilisé. Prenez 20 à 50 traces représentatives, définissez un score et séparez succès / échec. Proposez une modification de configuration puis faites-la passer par des evals avant promotion. Transformez aussi un playbook répétable en SKILL.md avec déclencheurs, étapes, critères de sortie et erreurs fréquentes.
💰 Où est le business ?
Agent Improvement Loop : instrumentation des traces, datasets d’eval, promotion contrôlée. Skill Factory ESN : méthodologies propriétaires en skills auditables et multi-harness. AI Performance Engineering : optimisation coût, latence, mémoire et capacité avec baseline et gains mesurés.
❓ Question de la semaine
Votre organisation sait-elle apprendre systématiquement de 100 tâches réalisées par ses agents — ou ces 100 tâches disparaissent-elles simplement dans l’historique ?
🤓 Pour ceux qui ont encore du contexte window
GitHub — Actions execution protections
Si vous avez déjà mis en place une boucle d’evals ou commencé à transformer vos standards en skills, je serais curieux de comparer les approches : qu’est-ce qui crée le plus de valeur chez vous — meilleure qualité, moins de variance ou moins de temps humain ?
Recevez la prochaine édition par email
Une inscription, pas de spam, désinscription sur simple demande.