Y Combinator finance toute une petite industrie de startups qui vendent aux entreprises des « employés IA » et des harnais d'agents. Cette semaine, l'incubateur a ouvert le code de celui qu'il avait construit pour son propre usage : licence MIT, à héberger soi-même plutôt qu'à louer par abonnement.
Ce qu'est QM
QM se définit, dans son README, comme un « harnais d'agent collaboratif pour le travail, sur Slack et sur le web ». Le problème qu'il résout est précis. La plupart des produits d'agents sont conçus comme un assistant personnel destiné à une seule personne, et ce format vole en éclats dès qu'une organisation tente de l'adopter : rien n'empêche le contexte, les identifiants ou les erreurs d'un salarié de déborder sur ceux d'un autre. La réponse de QM consiste à donner à chaque personne et à chaque espace — un canal Slack, une conversation de groupe, un projet — sa propre mémoire, ses fichiers, son trousseau de clés, ses permissions, ses tâches planifiées, ses applications web et son bac à sable persistant, tous cloisonnés. On peut travailler seul avec l'agent ou l'inviter dans un canal partagé ; dans les deux cas, son accès reste strictement limité à ce que ce périmètre lui accorde.
Le modèle de sécurité dit clairement ce que recouvre cet accès : un agent « agit au nom de la personne pour laquelle il travaille, avec ses identifiants et ses permissions, et tout ce qu'il fait est journalisé ». Trois modes configurables viennent se superposer : Strict (toute utilisation d'un outil exige une validation humaine), Auto (un classifieur filtre les données externes avant qu'elles n'atteignent le modèle — c'est le réglage par défaut) et Dangereux (ni filtrage, ni pause). Le README précise cependant qu'une politique de commandes prédéclarée, avec interdiction stricte de certaines actions comme les suppressions récursives ou le SQL destructeur, « s'applique dans tous les modes, y compris Dangereux ». Le plafond de permissions ne bouge pas ; seule varie la friction en dessous.
Ce que cela change pour la question du verrouillage
Le choix de conception le plus notable de QM, c'est qu'il ne désigne aucun vainqueur : « Choisissez votre harnais et votre modèle, et passez de l'un à l'autre. Pi, OpenCode, Codex et Claude Code font tourner le même cœur, si bien qu'un déploiement n'est lié à aucun fournisseur. » Architecturalement, le harnais, le stockage de session, le bac à sable et la mémoire se trouvent chacun derrière leur propre interface : remplacer l'un d'eux en production tient dans « un seul fichier de câblage », pas dans une réécriture.
À rapprocher de ce que ce blog avançait il y a quelques jours : des trois endroits où se loge réellement la dépendance à un fournisseur d'IA — l'API, le harnais de programmation, l'application grand public —, le harnais est précisément celui qui a été conçu pour qu'en changer ne coûte presque rien, parce que des outils comme Cursor ont fait du choix du modèle un simple menu déroulant plutôt qu'un engagement. QM applique la même logique un cran plus haut : on passe de « quel modèle répond à ma requête ? » à « quel fournisseur fait tourner les agents de mon entreprise ? ». Et cela vient de l'acteur le plus exposé à ce marché, puisqu'il en est l'investisseur. Si les bailleurs de fonds de QM ne croyaient pas à la portabilité au niveau du harnais, offrir cette infrastructure gratuite, neutre et auto-hébergeable serait une bien curieuse façon de protéger un portefeuille rempli d'entreprises qui facturent exactement cela.
L'origine : un an à faire tourner l'entreprise dessus
QM n'est pas un pari en l'air. C'est la version généralisée et ouverte d'une infrastructure que le General Partner de YC Pete Koomen (auparavant cofondateur d'Optimizely) dit avoir mis plus d'un an à construire pour faire tourner YC lui-même sur des agents. Lors d'un récent épisode du Y Combinator Startup Podcast, Koomen a raconté comment la version interne est passée d'une poignée d'outils à plus de 350, tous adossés à une même base de données, avec une boucle d'auto-amélioration nocturne qui relit chaque conversation entre salariés et agents de la journée et réécrit toute seule les compétences de l'organisation.
L'anecdote qu'il emploie pour rendre la chose tangible : une compétence chargée de rédiger des descriptions de startups en deux phrases — le genre de texte qu'un partenaire de YC écrit à la main des dizaines de fois par promotion — a démarré comme une simple consigne rédigée par un humain, puis n'a cessé de s'améliorer en s'entraînant sur les transcriptions de vraies séances de conseil, où les partenaires corrigeaient ses propositions. Koomen affirme qu'elle rédige aujourd'hui ces descriptions mieux que lui. Que cette compétence soit ou non représentative des 349 autres, elle illustre exactement la thèse de YC : n'importe quelle organisation peut se construire un « cerveau collectif » en enregistrant simplement ses productions de travail et en laissant des agents les lire et agir en continu. QM est l'échafaudage que YC tend désormais à qui veut tenter l'expérience sans y consacrer un an au préalable.
Un détail dit l'époque mieux que l'annonce elle-même : plusieurs commits du dépôt lors de ses derniers jours de préparation, du 29 au 31 juillet, mentionnent « claude » comme coauteur aux côtés des ingénieurs de YC. L'outil censé faire tourner les agents IA d'une organisation a lui-même été construit, en partie, par l'un d'eux.
À surveiller
- QM va devenir l'architecture de référence à laquelle on comparera les autres startups d'« employés IA », non parce qu'elle est la plus aboutie, mais parce qu'elle est gratuite, auto-hébergeable, et qu'elle émane de l'organisation la plus avancée dans l'usage d'agents parmi celles qui publient leurs chiffres.
- La bibliothèque interne de 350 outils, toujours en croissance, est plus importante que QM lui-même. Un harnais reste une infrastructure ; une bibliothèque de compétences qui s'améliore toute seule chaque nuit, entraînée sur les conversations mêmes de l'entreprise, voilà la vraie idée de produit testée ici — et la plus difficile à ouvrir ou à copier.
- L'examen critique portera sur la piste d'audit, pas sur le modèle d'accès. Confier à un agent les identifiants d'un salarié est un choix défendable dès lors que chaque action est journalisée ; toute la question est de savoir si « tout ce qu'il fait est journalisé » résistera à un incident réel, et pas seulement dans un README.