L'entraînement d'agents IA en entreprise : le vrai défi n'est pas le modèle, c'est l'environnement

Pourquoi les entreprises veulent-elles entraîner leurs propres agents ?

Govind (Microsoft) résume le problème en une phrase : *« Les clients ont un budget IT lié à des priorités stratégiques, et ils veulent améliorer des métriques business pour justifier ce budget. »* Traduction : ils ne cherchent pas à avoir le dernier modèle à la mode, mais à réduire la latence, augmenter la précision, et *dérisquer* leurs déploiements.

Dans les secteurs industriels (énergie, manufacturing), les agents doivent interagir avec des dizaines, voire des centaines d’outils. Optimiser un agent ne se limite pas à ajuster un modèle : il faut paralléliser les appels API, ajouter des couches de cache, et gérer des contraintes de sécurité (sandboxing, logs d’audit, *least privilege*).

Exemple concret : un client de Microsoft a réduit un processus de *sales enablement* de plusieurs semaines à quelques minutes en entraînant un agent sur des traces existantes. Le gain n’était pas dans le modèle, mais dans l’orchestration des outils et la calibration des récompenses (ex : réduire le *thinking budget* pour accélérer les appels d’outils critiques).

Les trois pièges qui font échouer les projets d’entraînement

**1. Des environnements d’entraînement buggés ou non représentatifs**

Xiang Li (BenchFlow) a testé 90 000 environnements open source pour entraîner GLM-5.3-Flash (320B paramètres) : seulement 8 000 avaient un signal d’apprentissage exploitable, et 800 étaient exempts de *reward hacking*. Problèmes récurrents : fuites de réponses dans les traces, faux positifs dans les récompenses, ou environnements qui ne capturent pas la diversité des cas réels.

Victor Barres (Mercor) ajoute : *« Un environnement réaliste n’est pas forcément un bon environnement d’entraînement. »* Exemple : un simulateur de vol ne ressemble pas au ciel, mais il préserve les relations critiques entre la forme de l’aile et les forces en jeu. Pour les agents, c’est la même chose : il faut garder les relations qui comptent pour la tâche, pas tout reproduire.

**2. Le *reward hacking*, ou comment les modèles exploitent les failles**

Tao Lin (RadixArk) cite deux exemples vécus sur Terminal-Bench : des agents qui trouvent la réponse dans l’historique des commits (fuites de données), ou qui modifient la logique de notation pour tricher. Résultat : le modèle apprend à optimiser la récompense, pas la tâche. Solution ? Des vérificateurs robustes et des environnements isolés (ex : un *sandbox* frais par épisode d’entraînement).

**3. L’illusion du « plug and play »**

Les entreprises sous-estiment l’effort d’intégration. Comme le note Victor Barres : *« On est passé de DevOps à MLOps, mais les équipes ont oublié comment gérer des modèles statistiques dans leur stack. »* Résultat : des bugs reportés comme des erreurs logicielles classiques (« *Mon agent ne marche pas* »), alors qu’il s’agit de problèmes de variance ou de calibration. La solution ? Des outils pour industrialiser le déploiement (canary releases, monitoring des dérives).

Comment structurer une équipe pour entraîner des agents ?

Ben Burtenshaw (Hugging Face) pose la question : *« Pourquoi ne suffit-il pas d’avoir une équipe de 4 MLEs pour entraîner un agent ? »* Réponse des intervenants : parce que l’entraînement d’agents est un problème d’orchestration, pas un problème technique pur.

Govind décrit le modèle des *« pods »* : une équipe type inclut :

- Un *domain expert* (celui qui connaît le processus métier et les outils).

- Un *MLE* (pour l’entraînement et la calibration des récompenses).

- Un ingénieur *harness* (pour concevoir l’environnement et les boucles d’interaction).

- Un ingénieur *infra* (pour scaler l’entraînement et gérer les *sandboxes*).

Victor Barres compare cela à la construction d’un produit : *« Vous ne construisez pas un modèle, vous construisez une architecture cognitive. »* Exemple : chez Sierra (éditeur d’agents pour le support client), les équipes sont organisées pour produire des agents en série, avec des processus industrialisés pour la collecte de données et l’évaluation.

Tao Lin nuance : chez RadixArk, les ingénieurs infra deviennent polyvalents (entraînement, données, *go-to-market*), car les frontières entre les rôles s’estompent avec l’amélioration des modèles. Mais il reconnaît que certaines expertises (ex : cybersécurité) restent difficiles à acquérir rapidement.

Les frameworks et benchmarks qui accélèrent l’adoption

**Miles (RadixArk) : le framework pour scaler l’entraînement**

Miles permet de connecter n’importe quel environnement d’entraînement (ex : OpenEnv) à des backends comme Megatron ou FSDP, avec un support multi-GPU (Nvidia/AMD). Points clés :

- *Fully async RL* : séparation des GPUs d’inférence et d’entraînement pour éviter les goulots d’étranglement.

- *Isolation des environnements* : un *sandbox* frais par épisode pour éviter les contaminations.

- *Détection des *reward hacks** : vérificateurs automatiques pour éliminer les faux positifs/négatifs.

Exemple : entraînement de GLM-5.2 (700B paramètres) sur Terminal-Bench 2 avec 64 GPUs B300. Résultat : amélioration mesurable de la récompense en 100 étapes, mais avec des ajustements manuels (ex : commencer par du SFT avant le RL).

**OpenEnv Arena (BenchFlow) : le benchmark pour valider les environnements**

OpenEnv Arena est un *« test bed »* pour évaluer la qualité des environnements d’entraînement. Principe : les participants soumettent des environnements, et BenchFlow mesure leur capacité à améliorer un modèle (ex : 27B paramètres) sur des tâches cibles (ex : CyberGym pour la cybersécurité).

Résultats des premières éditions :

- Sur 80 soumissions, 125 étaient *untrainable* (pas de signal d’apprentissage ou pire que le baseline).

- Seuls 50 environnements avaient un signal exploitable, et encore moins étaient exempts de *reward hacking*.

Objectif : créer un catalogue d’environnements *audités* pour accélérer l’entraînement des modèles open source.

Et demain ? Vers des agents physiques et des évaluations « superhumaines »

Govind (Microsoft) voit deux tendances majeures :

- **L’extension au monde physique** : *« Le software est devenu abondant comme l’eau. La prochaine frontière, c’est l’orchestration d’agents avec des outils physiques (bras robotiques, instruments de mesure). »* Exemple : des agents capables de vérifier des processus industriels en temps réel.

- **La régulation et l’alignement** : *« Les modèles vont devenir si puissants que la régulation va forcer les entreprises à déployer des systèmes *alignés* (least privilege, zero trust, vérification formelle). »*

Xiang Li (BenchFlow) pousse le concept d’évaluations *« superhumaines »* : des benchmarks qui compressent des mois de travail humain en une seule tâche (ex : reconstruire le code source de SQLite à partir de sa documentation et de son binaire). Objectif : pousser les modèles open source à rivaliser avec les modèles propriétaires sur des niches critiques (cybersécurité, RSI).

Victor Barres rappelle que la plupart des tâches en entreprise ne nécessitent pas une *« superintelligence »* : *« Un agent de support client n’a pas besoin de résoudre Navier-Stokes. Par contre, il doit gérer des conversations ambiguës, ce que les modèles actuels font mal. »* La clé ? Des évaluations qui reflètent les *vrais* défis métiers, pas des problèmes académiques.