QCon AI New York 2026 : six sessions pour examiner les agents en production

Quand un agent reçoit des droits sur un système réel, qu’une évaluation sert à décider d’un lancement ou que le contexte fait grimper la facture, la question n’est plus seulement de savoir si le modèle fonctionne. Il faut aussi savoir où il agit, comment on vérifie ses sorties et ce qui devient coûteux à l’échelle. C’est autour de ces décisions opérationnelles que s’organisent plusieurs sessions annoncées pour QCon AI New York 2026.

Dans son compte rendu des sessions confirmées par QCon AI New York, InfoQ décrit une conférence prévue les 15 et 16 décembre 2026 au Westin Jersey City Newport, destinée notamment aux ingénieurs seniors et aux responsables techniques. Son programme permet de relier des sujets souvent traités séparément : autorisations, évaluation, coûts d’inférence, revue du code et organisation du travail.

Les permissions d’un agent ne se résument pas à « tout ou rien »

La keynote d’ouverture porte sur l’identité et l’autorisation des agents en production. Selon la présentation qu’en fait InfoQ, deux choix posent problème : donner à l’agent un compte de service durable en espérant qu’il se comporte correctement, ou restreindre ses droits au point qu’il ne puisse plus accomplir sa tâche. La session de Nancy Wang doit aborder des solutions alternatives. L’annonce ne détaille pas ces solutions ; il serait donc prématuré d’en déduire un modèle d’autorisation précis.

Une autre intervention examine des contrôles appliqués côté serveur, dont les limites de débit et l’approbation par un pair pour les changements en production. Ronak Nathani doit présenter un agent d’exploitation Kubernetes associé à LinkedIn. InfoQ indique que le système intervient sur une plateforme couvrant plus de 500 000 nœuds et 5 millions de pods. Ces chiffres situent l’échelle évoquée dans la présentation ; ils ne constituent pas, à eux seuls, une mesure comparative de la sûreté ou de l’efficacité de l’agent.

Pour une équipe, l’intérêt de rapprocher ces deux sessions est de distinguer le périmètre d’accès du mécanisme de contrôle. Un agent peut avoir besoin d’un droit pour terminer une opération sans devoir pouvoir l’exercer sans limite. Les questions utiles portent alors sur l’identité utilisée, la portée de chaque action, les plafonds côté serveur et les changements qui nécessitent une validation humaine.

Une évaluation utile doit éclairer la décision de mise en production

La session consacrée au système de commande agentique de DoorDash porte sur la boucle d’évaluation. Fabio Flores défend l’usage du même juge pour les sessions simulées et les sessions de production, afin que les améliorations mesurées avant le lancement restent pertinentes une fois le système déployé. C’est une proposition présentée par l’intervenant, pas un résultat indépendant ni une garantie que le score reflétera tous les comportements réels.

Pour l’équipe qui conçoit ses propres évaluations, cette idée pose une question de continuité : les critères qui autorisent un changement avant lancement permettent-ils aussi de repérer une dégradation après lancement ? Il faut pouvoir relier une mesure à une décision — déployer, bloquer ou examiner un cas — et comprendre ce que cette mesure ne couvre pas. La session annoncée met l’accent sur le lien entre simulation et production, plutôt que sur un classement général de modèles.

Réduire le contexte peut agir sur les coûts, mais aussi introduire des échecs

La session de Tejas Chopra s’intéresse aux charges de travail dont le coût augmente quand le contexte s’allonge. InfoQ indique qu’elle abordera la compression et l’ordonnancement des prompts pour augmenter les cache hits chez les fournisseurs, ainsi que le stockage à plusieurs niveaux de l’historique des conversations. Les modes d’échec rencontrés par l’équipe font également partie des sujets annoncés. Aucun montant d’économie ni résultat chiffré n’est donné dans l’article d’InfoQ : il ne permet donc pas de comparer les approches sur leur rendement.

La distinction pratique est importante : réduire ou réorganiser le contexte peut modifier ce que le modèle reçoit, tandis que le stockage détermine quelles informations restent disponibles et à quel moment. Une évaluation des coûts qui ne regarde que les tokens manquerait les effets possibles sur la qualité des réponses ou sur la récupération de l’historique. Pour suivre ces dimensions dans un système en fonctionnement, voir aussi notre guide sur les traces, métriques et erreurs des agents IA.

La revue du code et la capacité de l’organisation comptent aussi

Min Chen doit présenter un système de revue qui filtre les suggestions à faible confiance avant qu’elles n’arrivent aux développeurs. InfoQ rapporte que ce système traite des dizaines de milliers de pull requests par semaine sur environ 10 000 dépôts, et que la session expliquera comment l’équipe mesure si les suggestions finissent dans le code fusionné. Le nombre de suggestions produites n’est donc pas l’unique signal évoqué : leur devenir dans le processus de revue compte également.

Enfin, Nathen Harvey, qui dirige DORA chez Google Cloud selon InfoQ, doit discuter de la maturité IA au-delà des seuls indicateurs d’adoption. La thèse annoncée est que l’IA amplifie ce qu’une organisation fait déjà bien, mais aussi ses difficultés. Pour un responsable technique, cela déplace l’examen : l’adoption d’un outil ne suffit pas à établir que le flux de livraison s’améliore, surtout si la revue ou un autre goulot d’étranglement limite déjà l’équipe.

Une checklist pour préparer les échanges

• Choisir un problème de production précis : permissions, qualité des évaluations, contexte coûteux ou volume de revue.
• Décrire les contraintes actuelles de l’équipe, notamment les actions autorisées et les décisions qui nécessitent une validation.
• Pour une évaluation, noter quelle mesure déclenche une décision et ce qu’elle ne permet pas de conclure.
• Pour les coûts, distinguer la consommation de tokens de la disponibilité et de la qualité du contexte.
• Pour la revue, regarder ce qui arrive aux suggestions après leur génération, pas seulement leur nombre.

Cette liste est une préparation possible, pas un protocole présenté ou validé par les intervenants. L’annonce d’InfoQ décrit des sessions à venir et des expériences rapportées par leurs présentateurs ; elle ne fournit pas encore les comptes rendus détaillés qui permettraient d’en reprendre les résultats. Le programme est néanmoins assez ciblé pour aider les équipes à formuler leurs propres arbitrages avant de comparer les retours de terrain aux contraintes de leur système.