Bayer Crop Science a 22 agents en production. Pas dans une démo filmée à l’arrache, pas dans un labo en quête de financement : dans le circuit quotidien de ses sélectionneurs végétaux. Leur mission n’a rien de glamour. Répondre à la question la plus banale du métier, celle qui coûte une heure de logs à chaque fois : « pourquoi mon workflow a planté hier ? »
La réponse prend désormais moins de dix minutes, et dans 80 % des cas elle arrive sans qu’un ingénieur s’en mêle. Ces chiffres sortent d’un billet daté du 23 octobre sur le blog d’AWS, écrit avec les équipes qui ont construit la machine. C’est un cas client, pas une évaluation indépendante. À prendre avec la pincée de sel d’usage. L’architecture, elle, est racontée assez précisément pour qu’on puisse la lire en sachant ce qu’on lit.
Le moteur existait déjà, il manquait le mode d’emploi
Bayer Crop Science fait tourner des centaines de configurations de modèles sur des données qui mélangent génomique, essais au champ, imagerie, conditions environnementales et sorties de modèles. Pour garder tout ça reproductible et traçable, la boîte a construit le Connected Decision Engine (CDE), une usine à déployer, orchestrer, surveiller et réutiliser des workflows de machine learning.
Sauf qu’à force de succès, le goulot d’étranglement s’est déplacé. Il n’est plus dans l’exécution du workflow, il est dans son explication. Comprendre un résultat obligeait à recoller du contexte depuis les API, la documentation, les métadonnées, les dashboards et les logs. Il fallait savoir quel système interroger avant même de savoir quoi demander.
ADE, l’Agentic Decision Engine, est la réponse : une interface en langage naturel posée sur CDE. Un agent superviseur classe la demande, la route vers un agent spécialiste, celui-ci va chercher le contexte au bon endroit, et l’utilisateur reçoit sa réponse sans naviguer dans la pile. Vingt-deux spécialistes tournent en production, chacun cloisonné à un domaine avec ses propres outils. Un agent « expert métier » répond par RAG, un agent « opérationnel » tape dans l’API de CDE, un agent « dépannage » lit la télémétrie, un agent « visualisation » sort des graphiques ou renvoie un dashboard existant.
Les choix de gens qui se sont déjà brûlés
Ce qui rend le montage intéressant, ce ne sont pas les 22 agents. C’est la plomberie autour.
L’authentification et l’autorisation restent hors du code des agents, via AgentCore Gateway et des autorisations IAM cadrées. Les agents accèdent aux API internes comme à des outils MCP. Chaque session utilisateur est isolée dans un runtime managé, et les requêtes passent par un proxy d’identité Microsoft Entra ID avant d’atteindre les agents. Le socle est agnostique du framework, ce qui a laissé l’équipe garder son orchestration LangGraph et choisir ses modèles.
Le plan de données est découpé au scalpel : DynamoDB pour les checkpoints LangGraph, Aurora PostgreSQL pour les sessions, les retours utilisateurs et l’analytique, ElastiCache pour le cache à TTL, S3 plus Titan Text Embeddings V2 et OpenSearch Serverless pour le RAG, CloudWatch pour la télémétrie. Rien d’exotique. Tout sent le type qui a déjà passé une nuit à chercher pourquoi un agent parlait à un service qu’il n’aurait jamais dû voir.
Un détail mérite qu’on s’y arrête, le pattern « Models as Skill ». Le code et la documentation de chaque modèle sont convertis en définitions de compétences rangées dans un registre. Les agents répondent donc à partir de l’implémentation réelle du modèle, pas de leur souvenir vague de ce que fait ce genre de modèle. C’est la seule parade sérieuse au problème de fond.
80 % de quoi, exactement ?
Le chiffre qui va tourner partout, c’est celui des 80 % de questions résolues sans ingénieur dans la boucle. Il faut le lire pour ce qu’il est : un taux d’escalade, pas un taux d’exactitude. Rien dans le billet ne dit combien de réponses sont fausses. Rien ne dit ce que devient une réponse fausse qui n’a pas déclenché d’escalade, ce qui est précisément le scénario qui coûte cher. Un diagnostic erroné sur un workflow de phénotypage, ça peut vouloir dire une saison à recroiser les données.
Pas de chiffre non plus sur le coût de la plateforme, le nombre d’utilisateurs ou la répartition des 20 % restants. On sait seulement que c’est « la première phase », formule qui laisse entendre qu’il y en aura d’autres et qui évite soigneusement de promettre quoi que ce soit.
Ça ne retire rien au résultat. Un taux de résolution de 80 % sur des questions techniques internalisées, c’est très loin des démos d’agents qui commandent une pizza. Ça veut juste dire que Bayer a construit un excellent service après-vente pour ses modèles, pas une superintelligence agronomique.
L’ingénieur qui n’est plus dans la boucle était très occupé avant
Deuxième détail que les slides oublieront : AWS Unified Operations a fourni un Technical Account Manager dédié et un ingénieur spécialiste IA générative, avec trois points techniques par semaine, de la conception à la mise en production. Autrement dit, la version « sans ingénieur dans la boucle » a demandé un ingénieur AWS dans la boucle pendant tout le build.
Ce n’est pas une contradiction, c’est le métier. Personne de sérieux n’a jamais prétendu monter 22 agents en production sans expertise pointue. Mais ça recadre le récit : ce que Bayer a acheté, c’est un accompagnement et une plateforme, pas une autonomie tombée du ciel.
Dans un article récent (Le temps que l’IA te fait gagner, quelqu’un d’autre le paie), je racontais que le temps gagné par l’IA se paie ailleurs. Chez Bayer, on voit la variante optimiste du mécanisme. L’heure de chasse aux logs que le sélectionneur ne fait plus, c’est du temps d’ingénieur de support qui repart dans la chaîne au lieu de disparaître.
Ce qui reste quand l’outil marche
Bayer n’a pas remplacé ses agronomes. Il a remplacé la chasse au log par une conversation. C’est nettement moins spectaculaire qu’un modèle qui torche des maths, et c’est infiniment plus utile à la personne qui doit décider quel croisement garder au printemps.
Le jour où les 80 % monteront à 95 %, l’ingénieur qui diagnostiquait à la main n’aura plus qu’à traiter les cas moches. C’est un progrès, personne ne va pleurer la chasse aux logs. C’est aussi une compétence qui va s’évaporer sans bruit, et le jour où les 22 agents tomberont tous en même temps, il faudra bien quelqu’un pour se souvenir de quel côté on lisait CloudWatch.
Sources :
Comments are closed