Agents IA en production : le cas monday.com sur Bedrock
monday.com fait tourner des agents IA en production depuis plusieurs mois, pas en pilote. L'entreprise a détaillé son architecture le 22 juillet 2026 dans un billet technique publié sur le blog machine learning d'AWS. Le cas mérite qu'on s'y arrête : il ne s'agit pas d'une startup qui construit sur une page blanche, mais d'un éditeur SaaS avec une base de code vieille de dix ans, des centaines d'ingénieurs, et une infrastructure AWS déjà mature.
Ce que monday.com fait tourner réellement
Pas un greenfield : agents dans une base de code de dix ans
Le détail qui distingue ce cas des démonstrations habituelles : les agents de monday.com n'opèrent pas dans un environnement neuf conçu pour l'IA. Ils interviennent dans une base de code accumulée sur une décennie, avec ses conventions historiques, ses dépendances legacy et ses zones mal documentées. Le billet d'AWS insiste sur ce point : une bonne partie du travail d'ingénierie a consisté à adapter les agents à l'existant, pas l'inverse.
Les chiffres de production annoncés (et leur source interne)
monday.com avance qu'environ 90 % de ses Builders — le nom interne donné aux équipes de développement — utilisent les agents Sphera au quotidien, et qu'ils constatent une hausse d'environ 50 % du nombre de pull requests par ingénieur. Ces deux chiffres, publiés le 22 juillet 2026, proviennent des données internes de monday.com et n'ont pas fait l'objet d'un audit tiers. Ils donnent un ordre de grandeur, pas une preuve méthodologique.
Agents comme coéquipiers, pas comme jobs
Le schéma Sphera : identité, manager, scope, score
Sphera est le nom donné par monday.com à son système d'agents IA. Le choix de conception central : chaque agent possède une identité propre (un nom, un rôle défini), un manager humain qui valide son périmètre d'action (scope), et un score de performance suivi dans le temps, comme pour un employé. Ce cadre sert un objectif opérationnel précis : savoir qui répond de quoi quand un agent modifie du code ou répond dans un canal Slack.
Atlas, ingénieur logiciel sans IDE
Atlas est l'agent le plus documenté du système : un agent d'ingénierie logicielle qui ouvre des tickets, propose des correctifs et répond aux questions techniques, sans jamais ouvrir un environnement de développement intégré (IDE) au sens où un humain l'entend. Il opère par appels d'outils (tool calls) et lecture de code source directement via son harness. Le terme « coéquipier » (teammate), employé par monday.com et AWS, décrit cette présence continue dans les canaux de travail — il ne décrit pas un statut d'employé ni une autonomie de décision équivalente à celle d'un humain.
L'architecture événementielle derrière les agents
Trois inboxes, une session : Slack, monday, GitHub
Concrètement, Atlas et les autres agents Sphera reçoivent des sollicitations depuis trois canaux distincts : des messages Slack, des éléments créés dans monday.com lui-même, et des événements GitHub (issues, pull requests, commentaires de revue). Chacun de ces canaux génère un événement qui doit être rattaché à la bonne session de travail, même si l'agent a déjà une conversation en cours ailleurs sur le même sujet.
SNS vers SQS vers EKS : ce que la file apporte
Les événements transitent par Amazon SNS puis sont mis en file via Amazon SQS avant d'être traités par des workers exécutés sur Amazon EKS. Ce choix d'architecture événementielle permet d'absorber les pics de sollicitation sans perdre de message, et de découpler la réception d'un événement de son traitement effectif par l'agent. C'est une architecture de production classique, pas une nouveauté : sa valeur ici tient à son application systématique à des agents IA, qui ont tendance à être conçus en mode synchrone dans les prototypes.
Pourquoi un harness maison autour du Claude Agent SDK
monday.com s'appuie sur le Claude Agent SDK d'Anthropic pour la boucle de raisonnement et d'appel d'outils, mais a construit un harness (couche d'orchestration maison) par-dessus. Ce harness gère l'authentification aux différents systèmes internes, l'application des règles de scope définies par le manager de l'agent, et la consignation des actions pour le calcul du score de performance. Le SDK fournit le moteur agentique ; le harness fournit la gouvernance d'entreprise.
État, mémoire et reprise de session
ElastiCache pour le live, EFS pour les sessions
Deux couches de stockage distinctes gèrent l'état des agents. Amazon ElastiCache conserve l'état conversationnel actif, à faible latence, pour les échanges en cours. Amazon EFS (Elastic File System) stocke les sessions de travail plus longues, celles qui doivent survivre à un redémarrage de worker ou à une interruption de plusieurs heures — un agent qui travaille sur une pull request complexe peut avoir besoin de reprendre le fil le lendemain.
Le journal quotidien d'Atlas comme mémoire persistante
Atlas tient un journal quotidien (daily log) qui consigne les décisions prises, les fichiers modifiés et les questions laissées en suspens. Ce journal sert de mémoire persistante entre les sessions : plutôt que de recharger l'intégralité de l'historique conversationnel à chaque réveil, l'agent relit un résumé structuré de son activité récente. C'est un choix d'ingénierie pragmatique face à la limite de taille de contexte des modèles, plus qu'une prouesse architecturale.
Les trois niveaux d'ingénierie IA (L1, L2, L3)
Où se situe vraiment monday aujourd'hui
monday.com décrit un modèle de maturité à trois niveaux pour classer le degré d'autonomie de ses agents. En L1, l'agent suggère et l'humain valide chaque action. En L2, l'agent exécute des tâches définies avec supervision humaine sur les étapes sensibles — c'est le niveau où se situe la majorité des usages Sphera au 22 juillet 2026, selon le billet d'AWS. En L3, l'agent agirait de façon autonome sur un périmètre élargi, avec un contrôle humain a posteriori plutôt qu'avant chaque action.
Le chemin vers l'autonomie et le merge à score de confiance
Le billet présente le merge entièrement autonome — un agent qui fusionnerait une pull request sans validation humaine préalable, sur la base d'un score de confiance calculé automatiquement — comme un objectif de feuille de route, pas comme un fonctionnement acquis. Cette précision est importante : rien dans la publication ne décrit un déploiement en L3 généralisé aujourd'hui. L'humain reste au volant sur les décisions de merge.
Les limites et ce que le cas ne dit pas
Ce cas d'usage a un contexte qui ne se généralise pas tel quel. monday.com dispose de centaines d'ingénieurs, d'une infrastructure AWS déjà mature avant le projet Sphera, et d'une équipe plateforme dédiée pour construire le harness. Une PME ou une équipe de cinq développeurs ne reproduit pas cette architecture avec les mêmes moyens ni le même délai.
Les chiffres de +50 % de PR par ingénieur et de 90 % d'adoption viennent des données internes de monday.com, non auditées par un tiers indépendant.
Le billet ne détaille pas le taux d'erreur des agents ni le volume de correctifs humains nécessaires après intervention d'Atlas.
Le niveau L3 (autonomie complète avec merge automatique) est présenté comme une cible, pas comme un acquis en production.
Aucune donnée n'est publiée sur le coût d'infrastructure (Bedrock, EKS, SQS, ElastiCache, EFS) rapporté au gain de productivité mesuré.
Le cas ne dit rien des effectifs d'ingénierie avant et après l'introduction des agents : il ne permet pas de conclure sur un impact net en emplois.
Par où commencer
Cartographier vos canaux d'entrée avant toute brique agentique : Slack, ticketing, dépôt de code — identifiez où naissent réellement les demandes avant de choisir un framework.
Définir un scope et un score de performance pour chaque agent dès le prototype, même basique : un agent sans manager ni périmètre documenté devient impossible à auditer six mois plus tard.
Choisir un niveau d'autonomie explicite (L1 ou L2) avant de parler d'agents IA en production, et ne monter en autonomie qu'après avoir mesuré un taux d'erreur acceptable sur plusieurs semaines.
Sources
AI teammates: How monday.com runs production AI agents on Amazon Bedrock — Amazon Web Services, AWS Machine Learning Blog, 22/07/2026
Amazon Bedrock — Amazon Web Services, Amazon Web Services, 22/07/2026
Claude Code — Anthropic, Anthropic, 22/07/2026
Amazon Elastic Kubernetes Service (EKS) — Amazon Web Services, Amazon Web Services, 22/07/2026
Amazon Simple Queue Service (SQS) — Amazon Web Services, Amazon Web Services, 22/07/2026
Cet article a été rédigé et illustré par un système d'intelligence artificielle à partir des sources citées ci-dessus, puis publié automatiquement, sans relecture humaine préalable. Si vous relevez une erreur factuelle, merci de nous la signaler.
Commentaires