monday.com a offert un regard détaillé sur la manière dont il exécute des agents d’IA de production pour la livraison logicielle sur Amazon Bedrock, donnant au marché une étude de cas concrète de ce à quoi ressemble l’« IA agentique » dans un grand environnement SaaS d’entreprise, plutôt que dans un environnement de démonstration.

Cette divulgation passe par un article du AWS Machine Learning Blog et une actualité AWS, de sorte que les informations sont en grande partie contrôlées par le fournisseur. Malgré cela, elle est notable parce que monday.com décrit non seulement l’utilisation des modèles, mais aussi les systèmes, files d’attente, couches de stockage, circuits de relecture et garde-fous opérationnels nécessaires pour permettre à des agents IA internes d’interagir avec Slack, GitHub et les workflows monday en production. Pour les bâtisseurs d’IA et les acheteurs d’entreprise, l’enjeu tient moins à un benchmark isolé qu’aux choix d’architecture derrière la fiabilité, la relecture, l’auditabilité et la supervision humaine.

Selon le récit d’AWS sur la configuration de monday.com, l’entreprise organise ses « AI Teammates » internes en trois niveaux. Au premier niveau, les humains utilisent des outils de codage IA comme assistants. Au deuxième, les équipes créent des compétences réutilisables et des sous-agents pour des tâches répétées. Au troisième, les agents prennent en charge des tâches de livraison de bout en bout pendant que les humains orchestrent et valident. AWS affirme que le système interne de monday.com, appelé Sphera, donne aux agents des identités stables d’un système à l’autre afin qu’on puisse leur attribuer du travail, les examiner ou les désactiver d’une manière qui rappelle des coéquipiers humains.

De l’assistant de codage au workflow d’agent géré

La partie la plus intéressante de la description de monday.com est qu’elle présente l’adoption de l’IA comme une progression opérationnelle plutôt que comme un simple lancement de produit. AWS indique que monday.com utilise Cursor pour des tâches rapides de pair programming et Claude Code pour des travaux d’ingénierie plus lourds, ce que l’entreprise classe dans sa couche d’assistance L1. Elle évolue ensuite vers des agents internes réutilisables en L2 et une livraison multi-agents en L3.

C’est important, car de nombreux déploiements d’IA en entreprise restent bloqués entre les expérimentations de type « copilot » et l’automatisation en production. Le récit de monday.com suggère que l’écart ne se résout pas uniquement avec de meilleurs modèles. Il se résout en enveloppant l’accès au modèle dans une couche d’orchestration qui comprend l’attribution du travail, la mémoire de session, l’utilisation d’outils, la revue de code, la relecture et la gestion des défaillances.

Dans le système de monday.com, un agent peut être déclenché depuis trois canaux : une mention Slack, une attribution d’élément monday ou une demande de revue de pull request GitHub. AWS dit que ces trois voies aboutissent à la même session d’agent, partageant la même mémoire et le même espace de travail sur disque. Cette conception semble destinée à éviter une fragmentation du contexte à travers différents outils de collaboration.

L’agent central mis en avant dans l’article, appelé Atlas, est décrit comme un agent ingénieur logiciel capable de prendre des tickets, rédiger des pull requests et livrer des fonctionnalités. AWS présente Atlas comme un membre d’une structure d’équipe plus large au sein de Sphera, où les agents ont un rôle défini, un périmètre, un responsable et un score de performance. Ce cadrage peut paraître cosmétique, mais monday.com affirme qu’il fait en réalité partie du schéma opérationnel qui régit l’adressage et la gouvernance des agents.

Pourquoi la pile AWS compte ici

L’architecture divulguée par monday.com est remarquable en partie parce qu’il ne s’agit pas d’une plateforme d’agents monolithique unique. Au lieu de cela, AWS explique que monday.com a construit un système en couches sur des services cloud standard, Amazon Bedrock gérant l’accès aux modèles et une pile plus large d’événementiel et de stockage effectuant l’essentiel du travail opérationnel.

Selon l’article, les déclencheurs externes arrivent d’abord dans Amazon SNS, qui les diffuse ensuite vers des files Amazon SQS. Des consommateurs exécutés sur Amazon EKS extraient les messages, déterminent quel agent doit les prendre en charge et confient le travail à un pod d’exécution d’agent. monday.com dit que cette configuration pub/sub plus files lui apporte des tentatives, des files de lettres mortes, du back-pressure lorsque Amazon Bedrock limite le débit, une relecture durable pour tester des builds corrigés et une diffusion parallèle.

C’est un point important pour les équipes qui planifient des agents d’IA en production. La difficulté n’est souvent pas de générer du code ou du texte. C’est de gérer les pics de charge, de relancer les tâches après des échecs, de retracer ce qui s’est passé et de récupérer en sécurité lorsque les dépendances ou les points d’accès des modèles deviennent indisponibles. L’architecture de monday.com montre une préférence pour des schémas d’infrastructure sobres mais éprouvés.

L’entreprise précise aussi qu’elle enveloppe le Claude Agent SDK plutôt que de s’appuyer directement dessus. AWS attribue trois raisons à monday.com : préserver la neutralité fournisseur au point d’appel via Amazon Bedrock, réduire la latence de démarrage à froid avec des caches préchauffés, et garder le contrôle de ce qu’elle appelle la couche « harness », là où résident l’évaluation, la composition des plugins, les communications et la logique de revue. C’est un signal utile pour les bâtisseurs. Cela suggère que l’exécution du modèle peut être interchangeable, tandis que le plan de contrôle et la logique de workflow deviennent l’avantage interne durable.

Stockage, mémoire et choix d’ingénierie moins glamour

Un deuxième enseignement de cette divulgation est que les systèmes d’agents ont besoin de plusieurs types d’état, et que ces états ne doivent pas vivre dans une seule base de données.

AWS dit que monday.com conserve l’état vivant, comme la tâche courante, le heartbeat, les verrous et les journaux de messages, dans Amazon ElastiCache pour un accès à faible latence. La mémoire de session et les fichiers de travail sont stockés dans Amazon EFS, tandis que les enregistrements durables comme les transcriptions, artefacts, instantanés et évaluations vont dans Amazon S3. Amazon RDS figure parmi les services utilisés, même si l’extrait de l’article n’en précise pas le rôle exact. AWS Secrets Manager est utilisé pour la gestion des secrets par session.

Cette répartition compte, car beaucoup de prototypes d’agents traitent la mémoire comme une seule abstraction. En pratique, les agents de codage ont besoin de quelque chose de plus proche d’un système distribué conventionnel : un état éphémère rapide, un système de fichiers partagé pour les outils qui attendent une sémantique POSIX, et un stockage long terme pour les audits et les preuves.

AWS explique que monday.com a choisi Amazon EFS plutôt que le stockage objet pour les sessions actives parce que le Claude Agent SDK et des outils de développement courants comme git et npm attendent un vrai système de fichiers. Cela permet aussi à une session de reprendre sur un autre pod Amazon EKS en montant le même chemin. C’est un choix pragmatique, qui reflète la réalité selon laquelle les agents logiciels dépendent souvent des mêmes hypothèses de fichiers et de processus que les développeurs humains.

Pour les équipes IA d’entreprise, c’est l’un des aspects les plus crédibles de l’histoire. On dépasse le raccourci marketing de la « mémoire » et l’on voit que les espaces de travail persistants, la reprise et les environnements d’outillage déterministes sont centraux pour la fiabilité des agents.

Preuves, affirmations et ce qui reste non vérifié

Comme le matériau source provient d’AWS et du AWS Machine Learning Blog, les affirmations les plus fortes en matière de performance et d’adoption doivent être considérées comme rapportées par le fournisseur. AWS dit que toutes les données de l’article proviennent des données de production internes de monday.com.

Ces affirmations incluent le fait que neuf développeurs sur dix chez monday.com utilisent chaque mois des outils de codage IA, contre environ la moitié il y a un an, et que le débit de pull requests par ingénieur a augmenté de plus de la moitié. AWS ajoute que cette couche L2 de compétences et de sous-agents est l’endroit où se situe actuellement la majeure partie de l’activité de monday.com.

Ce sont des affirmations significatives si elles sont exactes, mais les lecteurs doivent noter ce qui manque dans les preuves disponibles. Il n’y a pas de méthodologie indépendante, pas de dénominateur brut pour « builders », pas de période de base au-delà d’un langage relatif général, et aucun détail indiquant si le débit plus élevé de pull requests s’est traduit par un meilleur cycle time, moins d’incidents ou des charges de revue différentes. Le matériel ne quantifie pas non plus les coûts, les taux de défauts, ni la fréquence à laquelle des réviseurs humains rejettent ou réécrivent la sortie des agents.

De même, AWS affirme qu’Amazon Bedrock aide monday.com à garder au même endroit le suivi des coûts, la planification des capacités et les pistes d’audit des appels de modèles grâce à des mécanismes tels que Application Inference Profiles. C’est plausible comme avantage de plateforme, mais les preuves ici restent descriptives plutôt que comparatives. Il n’existe pas de benchmark direct contre d’autres chemins de déploiement.

Malgré cela, l’article est plus solide que beaucoup d’études de cas IA parce qu’il consacre plus de temps à la conception du système qu’à des promesses de transformation abstraites. L’absence de validation indépendante n’efface pas le signal architectural ; elle limite seulement le poids que les acheteurs devraient accorder aux chiffres de productivité.

Ce que cela signifie pour les bâtisseurs et les acheteurs d’entreprise

Pour les équipes logicielles, l’exemple monday.com souligne une séparation pratique dans la pile IA. Des produits comme Cursor et Claude Code peuvent améliorer rapidement la productivité de développeurs individuels, mais passer à l’échelle au-delà de l’assistance personnelle exige une infrastructure bien plus proche de l’ingénierie de plateforme que de l’ingénierie de prompts.

Pour les acheteurs d’IA d’entreprise, ce cas rappelle que déployer des agents IA dans des organisations logicielles en contact avec la clientèle impose des exigences plus fortes qu’un simple déploiement de chatbot. Les agents qui ouvrent des pull requests ou agissent sur des tickets ont besoin d’une identité durable, de permissions limitées, d’observabilité, de chemins de rollback, de points de revue et d’assez de détails d’audit pour satisfaire les équipes sécurité et conformité.

L’histoire clarifie aussi le positionnement concurrentiel autour d’Amazon Bedrock. AWS présente le service non pas seulement comme un accès aux modèles, mais comme un point de contrôle pour la capacité, la gouvernance et la comptabilité des coûts sur de nombreux agents. Ce discours est susceptible de résonner auprès des entreprises déjà standardisées sur AWS, en particulier celles qui veulent de l’optionnalité de modèles sans construire leur propre couche de passerelle à partir de zéro.

En même temps, la conception même de monday.com suggère que les services cloud seuls ne résolvent pas le problème central du workflow. La couche différenciante est le harness interne : routage, évaluation, logique de plugins, politique de revue et intégration spécifique aux équipes avec Slack, GitHub et monday lui-même. Les entreprises qui achètent des plateformes d’agents devront décider quelle part de ce harness elles souhaitent posséder.

Ce qu’il faut surveiller ensuite

Le prochain signal à surveiller est de savoir si monday.com ou AWS fournit des preuves plus solides sur la qualité logicielle et le coût opérationnel, et pas seulement sur les métriques d’activité. Le volume de pull requests est utile, mais les acheteurs d’entreprise voudront voir des données sur les taux d’incidents, la fréquence des rollbacks, le temps de revue et les exceptions de sécurité.

Un deuxième signal est de savoir si monday.com élargit l’autonomie des agents au-delà des workflows d’ingénierie internes. Si les agents peuvent passer en toute sécurité de l’assistance au codage à des tâches produit et opérationnelles plus larges, cela renforcerait l’idée que des systèmes multi-agents structurés peuvent devenir un modèle général en entreprise.

Troisièmement, il faut observer si AWS transforme cette architecture en conseils ou fonctionnalités plus produits autour d’Amazon Bedrock, Amazon EKS et des outils d’orchestration. La description actuelle laisse encore entendre un travail d’ingénierie personnalisé important de la part de monday.com.

Enfin, il sera utile de suivre si les concurrents publient des récits de production tout aussi détaillés. Le marché regorge d’affirmations autour des agents IA, mais relativement peu de comptes rendus expliquant comment les agents conservent réellement le contexte, se remettent d’un échec et passent la revue humaine dans une pile d’entreprise vivante.

Perspective Creati.ai

La vraie nouvelle ici n’est pas que monday.com utilise l’IA pour coder. Beaucoup d’entreprises le font. Le développement le plus important est que monday.com décrit un modèle opérationnel de production pour les agents IA qui les traite comme des travailleurs gérés au sein de systèmes de livraison logicielle existants, avec des files d’attente, des systèmes de fichiers, des pistes d’audit et des limites de revue explicites.

C’est vers cela que se dirige le marché de l’IA d’entreprise. Les gagnants ne seront pas les équipes aux démonstrations les plus spectaculaires, mais celles qui sauront rendre les agents IA lisibles pour les responsables d’ingénierie, les équipes sécurité, les équipes financières et les opérateurs d’astreinte. L’architecture de monday.com, telle que présentée par AWS, suggère que l’adoption des agents devient crédible lorsqu’elle est construite d’abord comme une infrastructure, et seulement ensuite comme une intelligence.