KM4BI KM4BI

Le cauchemar d’infrastructure dont personne ne parle

Les agents de code accélèrent le produit, mais déplacent la pression vers les plateformes data et infra, où fiabilité, revue et opérations doivent aussi…

Les agents de code ne créent pas seulement plus de fonctionnalités: ils déplacent la contrainte vers les couches qui doivent les faire tourner. Dans cet échange, Emma, qui dirige l’ingénierie Data Platform Infrastructure chez OpenAI, décrit une tension très concrète: les équipes produit accélèrent avec Codex, tandis que les équipes plateforme doivent absorber davantage de workloads, de PR et de demandes de support sans relâcher leurs exigences de fiabilité.

Le vrai goulot d’étranglement

La plateforme data d’OpenAI soutient les analytics, le streaming, les event buses, le ML infra, les feature stores, les pipelines sécurisés, les données d’entraînement et les données d’évaluation. Autrement dit, presque toute l’entreprise repose sur ces systèmes. Quand les agents augmentent la vitesse des équipes applicatives, la plateforme devient naturellement le point de pression.

Emma donne plusieurs exemples déjà opérationnels: automatisation de releases, triage dans Slack, PR créées avec preuves et vidéos, support interne, debugging de jobs et extraction de savoir d’infrastructure sous forme de skills. Ces usages économisent du temps, mais révèlent aussi une asymétrie: une app alpha peut tolérer l’imperfection, un cluster Spark ou Kafka beaucoup moins.

La défense en profondeur devient centrale

Le problème n’est pas seulement de générer du code. Il faut aussi le relire, le déployer, l’isoler et l’opérer. Emma plaide pour une architecture multi-agents: un agent code, d’autres agents spécialisés relisent, puis d’autres surveillent et interviennent côté opérations. C’est une forme de code ownership augmenté, nourrie par des bases de connaissance, des tool calls, des skills et des evals internes.

Le risque est que des agents très orientés objectif touchent des API internes, produisent des workloads Flink ou Spark mal compris par leurs utilisateurs, ou déclenchent des incidents sur des systèmes partagés. Les équipes plateforme doivent donc rendre leurs interfaces plus robustes, moins ambiguës et plus défensives.

Ce que les équipes peuvent faire maintenant

Emma recommande de commencer par gagner du temps: bots de support, AGENT.md, skills, petits systèmes isolés et eval suites privées. Même une suite d’évaluation simple, maintenue dans Notion ou un document interne, peut aider à savoir quand un nouveau modèle est prêt pour un workflow donné.

Le signal stratégique est clair: l’adoption des agents ne peut pas rester concentrée sur les couches applicatives. Pour que la productivité tienne dans la durée, l’infrastructure, la revue de code et les opérations doivent elles aussi devenir agentiques — mais avec des garde-fous beaucoup plus stricts.

Source