Le 21 octobre 2026, neuf ingénieurs de Microsoft ont fusionné 1 211 pull requests dans la branche principale du backend de Copilot Cowork, selon l’entreprise. Ce jalon donne une idée du rythme de développement, pas de la qualité du code. Microsoft attribue cette cadence au travail parallèle des agents, à des spécifications précises et à plusieurs contrôles humains. L’équipe décrit aussi ses pratiques et la migration de Python vers Rust.
Ce que recouvre le chiffre du 21 octobre
Le décompte d’une journée est distinct des 4 581 pull requests que Microsoft dit avoir fusionnées pendant la semaine du 12 octobre. L’entreprise rapporte également que 257 pull requests ont été fusionnées en janvier et 2 754 en mai. Ces volumes mesurent l’activité du dépôt, pas la qualité du logiciel ni la productivité de chaque ingénieur.
Microsoft situe la première mise en production de Rust au 24 septembre. Le dernier cluster a été transféré le 10 octobre, date à laquelle l’entreprise dit avoir achevé la migration du runtime depuis Python.
Les garde-fous décrits par Microsoft
Avant d’écrire du code, chaque agent devait recevoir une spécification Markdown indiquant le comportement attendu, les critères de réussite et ce qui ne devait pas être modifié. Un agent pouvait aider à rédiger cette spécification à partir d’une description orale, mais une personne la relisait et la corrigeait. Pour travailler en parallèle, les agents utilisaient des copies séparées du dépôt et recevaient chacun une tâche liée à une spécification.
L’entreprise décrit aussi une séparation entre l’agent et les opérations Microsoft 365. Le modèle s’exécutait dans un conteneur sans identifiants utilisateur. Un hôte de confiance gérait l’identité, les règles, les approbations, l’exécution des outils et l’audit des opérations. Dans les changements critiques, une personne gardait la responsabilité de la revue : Microsoft rapporte que des réviseurs agents avaient manqué quatre problèmes bloquants dans un cas sensible.
Les contrôles automatiques avaient eux aussi des garde-fous. Chaque vérification devait indiquer combien de fichiers elle avait examinés ; chaque nouveau contrôle devait être accompagné d’un test conçu pour le faire échouer. L’objectif était de repérer les vérifications qui affichaient un résultat positif sans avoir réellement testé le code.
Comment l’équipe a comparé Python et Rust
Pour vérifier le comportement de Rust, des générateurs exécutaient l’implémentation Python sur des entrées définies et enregistraient ses sorties dans des fixtures JSON. Les tests Rust rejouaient ensuite ces cas. Microsoft rapporte environ 430 fixtures. Un test contrôlait aussi le nombre de cas avant leur exécution, afin qu’une fixture vide ne puisse pas faire réussir le test par défaut.
Cette méthode a d’abord manqué un détail : Python transmettait certains événements dans un ordre précis, sans que cet ordre soit explicitement défini. La première version Rust ne l’a pas conservé. Microsoft indique que l’équipe a ensuite corrigé ce problème.
Les mesures de latence rapportées
Microsoft a comparé deux clusters pendant la même fenêtre de 12 heures, à la fin de septembre. Le p50 est la médiane ; le p90 indique le seuil sous lequel se situent 90 % des mesures. Les chiffres ci-dessous portent sur le délai du premier tour avant l’arrivée du premier jeton de réponse.
| Environnement | p50, en secondes | p90, en secondes |
| Python | 7,9 | 14,5 |
| Rust | 2,7 | 6,2 |
Microsoft précise que le changement ne se limitait pas au langage : la boucle de l’agent a également quitté le conteneur pour être intégrée au service Rust. L’entreprise indique que ce déplacement a contribué de façon importante à la baisse des délais. La comparaison ne permet donc pas d’attribuer tout l’écart à Rust seul.
Microsoft rapporte aussi que, sous charge, les blocages de la boucle d’événements Python atteignaient 11,9 secondes. L’entreprise dit que 16,7 % des créations de session duraient exactement 5 secondes parce qu’un délai d’attente expirait, et qu’un processus Python a été tué 539 fois en une semaine sur un cluster. Elle dit que les blocages et les expirations de délai ont disparu après la migration.
Le coût par tour n’a pas été correctement mesuré par Microsoft, qui ne revendique pas de baisse des coûts liée au portage.
Ce que des développeurs disent de leurs flux de travail
Dans une discussion sur Reddit, un utilisateur a décrit l’aide d’un agent Copilot Studio à la création de Logic Apps à partir d’exemples et d’instructions de projet. Il devait toutefois copier lui-même le résultat final dans Logic Apps. D’autres participants ont évoqué des plans et spécifications en Markdown, avec des scripts exécutés dans VS Code. Ce sont des expériences et suggestions individuelles, pas une description générale des capacités de Copilot Cowork.
Dans une autre discussion, des utilisateurs ont opposé les tâches qu’ils estiment réalisables avec Copilot classique, comme résumer des courriels ou préparer des présentations, à des processus qui enchaînent plusieurs étapes entre documents et données. Ce débat porte sur l’intérêt pratique de l’orchestration ; il ne constitue pas une comparaison testée des produits.
