Développement de Microsoft Copilot Cowork : neuf ingénieurs, 1 211 pull requests et le goulot d’étranglement de la vérification

Microsoft indique que neuf ingénieurs ont fusionné 1 211 pull requests lors du développement de Copilot Cowork le 21 octobre, les agents ayant écrit la majeure partie du code. Une pull request propose des modifications à examiner avant leur intégration. Cette distinction est importante : le chiffre mis en avant mesure les modifications fusionnées, tandis que la productivité dépend aussi de leur utilité, de leur fiabilité et de la charge de maintenance qu’elles engendrent.

Publié le 2 novembre, ce récit d’ingénierie décrit une équipe qui transforme sa manière de spécifier, réviser et exploiter les logiciels. Sa tension centrale oppose l’augmentation de la capacité d’implémentation à une capacité de vérification limitée. Produire davantage de modifications ne crée de valeur que lorsque l’organisation peut déterminer lesquelles méritent d’atteindre les utilisateurs.

Les recherches d’Anthropic sur les agents et les travaux de Google sur la livraison logicielle offrent des points de comparaison utiles, sans valider indépendamment les résultats de Microsoft. Toutes deux attirent l’attention sur les systèmes qui entourent les outils d’IA. Pour les responsables de l’ingénierie, la pression se concentre sur les pratiques de revue, l’architecture et la responsabilité à mesure que la production de code devient plus facile à étendre.

Ce que mesure réellement la performance du développement de Copilot Cowork

Selon le récit de l’ingénierie de Copilot Cowork de Microsoft, l’équipe backend a atteint ce total quotidien après avoir commencé ses travaux en janvier. Les ingénieurs ont conservé la responsabilité des exigences et des décisions les plus risquées. Des contrôles automatisés et des agents de revue ont examiné les modifications. Microsoft décrit également un changement sensible pour lequel les réviseurs humains ont détecté quatre problèmes bloquants que les agents de revue n’avaient pas repérés.

Une pull request fusionnée enregistre une activité acceptée ; sa valeur commerciale exige toujours des preuves distinctes.

Une organisation peut diviser une fonctionnalité en de nombreuses modifications ou regrouper des travaux liés dans une soumission plus importante. Ces deux approches modifient le décompte. Aucune n’établit la valeur apportée aux clients par le travail effectué. Comparer les équipes sur les seuls totaux risque donc de récompenser des différences de conditionnement plutôt que des différences de performance d’ingénierie.

Des modifications plus petites peuvent faciliter la revue, car chaque proposition pose une question plus circonscrite. Toutefois, un ensemble de changements individuellement compréhensibles peut encore produire un effet combiné inattendu. L’unité d’évaluation pertinente devient parfois la mise en production, le flux de travail du client ou le service dans la durée.

Prenons l’exemple hypothétique d’un assistant de planification qui lit une demande, vérifie les disponibilités et prépare une invitation à une réunion. Chaque composant peut réussir ses propres tests, tandis que le flux de travail complet gère mal une annulation. Compter les modifications réussies au niveau des composants ne permettrait pas de voir le véritable problème du client.

Cet exemple montre pourquoi cette performance mérite l’attention sans devenir un objectif universel. Le chiffre suggère un processus d’intégration exceptionnellement actif. Il ne révèle pas de mesure standardisée de la complexité des fonctionnalités, du bénéfice client ou de l’effort nécessaire pour maintenir le système qui en résulte.

Le calendrier importe aussi. Ce récit décrit un modèle opérationnel qui émerge d’un développement soutenu, plutôt qu’une brève démonstration de code généré. Les lecteurs devraient évaluer ses affirmations comme une étude de cas en production d’une entreprise, avec tout le contexte et les limites de sélection que ce format implique.

L’ingénierie de Copilot Cowork soulève donc une question de management qui dépasse la vitesse de codage : quelles preuves doivent justifier l’acceptation d’une modification ? Des réponses différentes impliquent des besoins en effectifs différents. Une équipe qui met l’accent sur les résultats de tests locaux s’organisera différemment d’une équipe exigeant une revue de sécurité, des preuves opérationnelles et des contrôles des résultats clients.

Le total quotidien ne peut répondre à cette question pour une autre organisation. Il rend toutefois la question plus difficile à repousser. Une fois l’implémentation étendue, de faibles critères d’acceptation deviennent une contrainte opérationnelle plutôt qu’un désagrément occasionnel.

Pour les acheteurs, la distinction est tout aussi pratique. Le rythme de développement d’un fournisseur décrit sa capacité à faire évoluer le produit. Un acheteur a toujours besoin de preuves que ces changements améliorent les flux de travail dont dépendent les employés.

Les responsables de l’ingénierie font face à un problème de capacité de vérification

Lorsque la capacité d’implémentation augmente, la ressource rare devient la confiance justifiée dans ce qui est livré.

Cette confiance provient de plusieurs sources : une exigence précise, des tests pertinents, une revue éclairée et des preuves issues du service en fonctionnement. Ces sources répondent à des questions différentes. Un test peut établir le comportement attendu pour des entrées sélectionnées sans établir que l’exigence elle-même sert le client.

Les recherches de Google sur le développement logiciel assisté par l’IA offrent une comparaison plus large. Les résultats DORA de 2025 associent l’adoption de l’IA à une augmentation du débit de livraison, tout en soulignant l’importance de l’organisation environnante. L’étude décrit l’IA comme un amplificateur des forces et faiblesses existantes.

Cette perspective soutient une interprétation prudente de la performance de Microsoft. Une équipe dotée d’une responsabilité claire et de contrôles de publication fiables dispose de points d’application pour une capacité d’implémentation supplémentaire. Une équipe aux responsabilités non résolues peut au contraire accumuler davantage de propositions que personne ne peut approuver avec confiance.

La pression repose donc d’abord sur les responsables de l’ingénierie et les équipes plateforme. Ils déterminent qui est propriétaire des critères d’acceptation, quelles modifications nécessitent une attention spécialisée et comment une mise en production peut être annulée. Ces décisions deviennent plus importantes lorsque les propositions arrivent plus vite.

Les spécialistes de la sécurité sont confrontés à un problème d’allocation similaire. Examiner chaque modification avec la même intensité consomme de l’attention quel que soit le risque. N’examiner que les fichiers manifestement liés à la sécurité manque les comportements introduits ailleurs. La difficulté consiste à relier les modifications aux autorisations, aux données et aux actions clients qu’elles affectent.

Les responsables produit héritent également de davantage de responsabilités. Les demandes ambiguës deviennent coûteuses lorsque le logiciel peut être produit avant que les désaccords n’apparaissent. Une implémentation soignée peut créer un élan autour d’une exigence mal comprise, rendant la correction politiquement plus difficile même lorsque modifier le code reste techniquement simple.

C’est ici que les organisations devraient distinguer l’attente de la délibération nécessaire. Certains retards reflètent des informations manquantes ou un réviseur surchargé. D’autres protègent une décision irréversible. Traiter les deux comme du gaspillage encourage les équipes à supprimer des garde-fous simplement parce qu’ils ralentissent un tableau de bord.

Une réponse managériale utile consiste à examiner où l’incertitude entre dans le processus. Si les réviseurs demandent à répétition ce qu’une fonctionnalité doit faire, l’exigence doit être retravaillée. S’ils questionnent à répétition les effets du déploiement, le processus de publication a besoin d’une meilleure visibilité.

Il s’agit de diagnostics organisationnels, non d’arguments en faveur de processus illimités. Chaque contrôle supplémentaire a un coût. Le critère doit être de savoir s’il répond à une question importante qu’un autre contrôle laisse sans réponse.

L’histoire du développement de Copilot Cowork rend ce compromis particulièrement visible. Les responsables de l’ingénierie doivent désormais expliquer comment ils étendront la capacité de vérification parallèlement à la capacité d’implémentation. Acheter l’accès à un agent de codage ne résout pas cette décision opérationnelle.

Pour les acheteurs d’entreprise, la question correspondante concerne la qualité des changements. Des publications plus rapides deviennent utiles lorsque les employés subissent moins d’interruptions, bénéficient d’autorisations plus claires et réalisent leurs tâches de manière plus fiable. La seule fréquence des publications laisse ces résultats indéterminés.

La migration de Copilot Cowork vers Rust sépare le langage de l’architecture

Microsoft indique que la migration de Copilot Cowork vers Rust a réduit le temps de réponse médian du premier tour de 7,9 secondes à 2,7 secondes sur une période de comparaison. L’entreprise attribue également une partie de l’amélioration au déplacement de la boucle d’agent et n’avance aucune affirmation sur le coût par tour.

Une migration peut améliorer un service sans établir que le langage de programmation a causé chaque amélioration.

Un environnement d’exécution est l’ensemble des mécanismes logiciels qui exécutent le travail d’une application. Déplacer ces mécanismes entre des langages peut modifier la gestion de la mémoire, la planification, le déploiement et le comportement au démarrage. Si plusieurs éléments changent ensemble, la mesure qui en résulte capture leur effet combiné.

Cette distinction compte, car les débats sur les langages de programmation réduisent souvent un projet architectural à un simple affrontement. Cette présentation produit un titre clair, mais offre une base médiocre pour la décision d’investissement d’une autre équipe. La question pertinente est de savoir quel mécanisme répond à son propre goulot d’étranglement.

Les garanties de concurrence de Rust offrent une référence technique concrète. La concurrence signifie que des parties distinctes d’un programme peuvent progresser indépendamment. Rust utilise des règles de propriété et la vérification des types pour détecter de nombreuses erreurs de mémoire et de concurrence avant l’exécution.

Ces garanties ont des limites. Elles n’établissent pas qu’une réponse contient les bonnes informations métier, qu’une opération est autorisée ou que les utilisateurs reçoivent les événements dans la séquence attendue. La sécurité du langage et la correction de l’application ne se recoupent que partiellement.

Un service de planification illustre la différence. Son code peut gérer la mémoire de manière sûre tout en sélectionnant le mauvais calendrier. Ses tâches peuvent s’exécuter sans course aux données tout en envoyant une invitation avant approbation. Une garantie au niveau du langage ne peut fournir une règle produit manquante.

Les preuves de migration nécessitent donc plusieurs couches. L’une concerne l’utilisation des ressources et le temps de réponse. Une autre concerne le comportement dans des conditions de trafic réalistes. Une troisième concerne la préservation par le remplacement d’obligations auparavant implicites.

Une comparaison contrôlée devrait idéalement maintenir stables la charge de travail et les conditions d’infrastructure tout en documentant les changements évalués. Les migrations en production offrent rarement une séparation expérimentale parfaite. Cette limite devrait orienter l’attribution plutôt qu’effacer des mesures opérationnelles utiles.

Pour les développeurs qui lisent le récit de la migration de Copilot Cowork vers Rust, l’implication pratique est analytique. Déterminez si le problème pertinent concerne la planification de l’exécution, la surcharge au démarrage, le comportement de la mémoire ou la conception de l’application avant de généraliser le résultat.

Pour les acheteurs, le langage lui-même importe généralement moins que le résultat du service. Des réponses initiales plus rapides sont précieuses, mais elles n’établissent pas une réalisation plus rapide d’une tâche complète. Un système peut commencer à répondre plus tôt tout en mettant davantage de temps à produire un livrable correct.

La même distinction s’applique à l’économie. Une amélioration de la latence n’établit pas automatiquement un coût d’exploitation inférieur. L’utilisation de l’infrastructure, les appels aux modèles, les nouvelles tentatives et le travail de support influencent tous le calcul.

Cela fait de la migration une étude de cas utile sur l’attribution. Elle montre pourquoi un résultat d’ingénierie devrait conserver son contexte architectural lorsqu’il devient une affirmation publique de performance.

La revue par agent exige une base indépendante de confiance

Ajouter des réviseurs n’accroît la confiance que lorsque leurs vérifications fournissent des preuves utiles et suffisamment indépendantes.

Un agent IA est un système piloté par un modèle qui sélectionne des actions et utilise des outils pour atteindre un objectif. Un agent chargé de la revue peut examiner une modification proposée, relever des préoccupations et demander des corrections. Son jugement reste un résultat à évaluer, en particulier lorsque l’agent auteur a fourni une grande partie des explications environnantes.

Les modèles de flux de travail d’agents d’Anthropic décrivent des systèmes qui séparent la génération de l’évaluation. L’entreprise recommande des conceptions simples, des critères d’évaluation clairs et une complexité supplémentaire uniquement lorsqu’elle améliore les résultats. Cela offre un point de comparaison utile avec le rôle croissant de la revue automatisée.

La tâche d’un évaluateur est plus simple lorsque la réussite peut être observée directement. Un calcul numérique peut être vérifié par un calcul indépendant. Un flux de travail sensible aux autorisations exige un type de preuve différent, car l’action correcte dépend de l’identité, des politiques et du contexte.

Le danger central est une incompréhension partagée. Un auteur et un réviseur peuvent être d’accord parce qu’ils ont interprété de la même manière une exigence ambiguë. Leur accord ne résout pas l’ambiguïté. Un modèle ou un prompt distinct n’aide que s’il apporte une différence pertinente dans les preuves ou le raisonnement.

Les tests présentent une limite similaire. Un test écrit en même temps qu’une implémentation peut reproduire les hypothèses de cette implémentation. Sa réussite établit la cohérence entre ces artefacts. Elle n’établit pas nécessairement la cohérence avec le comportement attendu.

Des preuves indépendantes peuvent provenir d’un contrat existant, d’un comportement observé, d’une exigence approuvée ou d’un cas d’échec soigneusement sélectionné. La bonne source dépend de la modification. La distinction importante concerne la capacité des preuves à contredire l’implémentation.

Prenons un contrôle automatisé qui signale une réussite alors qu’il n’a reçu aucune entrée pertinente. Son résultat ressemble à une inspection réussie, mais il ne contient aucune information sur la modification proposée. Un symbole de réussite visible devient trompeur lorsque les utilisateurs ne peuvent pas savoir ce que le contrôle a réellement examiné.

C’est pourquoi la qualité de la revue ne peut pas être réduite au nombre d’agents affectés. Un petit ensemble de contrôles aux objectifs distincts peut inspirer davantage confiance que des revues générales répétées. L’objectif est de couvrir les modes de défaillance importants sans créer un flux de commentaires illisible.

L’intervention humaine doit également avoir un rôle précis. Demander à quelqu’un d’approuver une modification sans lui donner le temps ni le contexte crée une supervision nominale. Une revue efficace exige une décision claire, des preuves pertinentes et l’autorité de rejeter la proposition.

Pour le développement avec Copilot Cowork, l’enseignement plus large concerne la relation entre automatisation et responsabilité. Un retour automatisé plus rapide peut soutenir le jugement humain, mais l’organisation a toujours besoin d’un fondement explicite pour accepter le risque.

Ce fondement doit rester compréhensible après le départ des auteurs initiaux de la conversation. Un registre consultable des exigences et des décisions aide les futurs réviseurs à reconstruire l’intention. Les équipes qui gèrent ce contexte peuvent explorer une base de connaissances consultable sans considérer les documents stockés comme une preuve que le logiciel se comporte correctement.

La recherche sur la productivité nuance le titre sur les pull requests

L’étude de cas de Microsoft et les recherches indépendantes sur la productivité mesurent des choses différentes ; leurs conclusions ne peuvent donc pas se substituer les unes aux autres.

L’expérience de METR sur la productivité des développeurs offre un contrepoint utile. Dans son étude du début de 2025, 16 développeurs open source expérimentés ont réalisé 246 tâches. L’autorisation d’utiliser l’IA a augmenté le temps d’exécution de 19 % dans ce contexte, malgré la conviction des participants que les outils les aidaient.

Ce résultat concerne des développeurs, des dépôts, des tâches et des outils particuliers. Il n’établit pas que l’IA ralentit toutes les équipes d’ingénierie. Il ne permet pas non plus d’évaluer directement un flux de travail ultérieur organisé autour de nombreux agents exécutés en parallèle.

METR a ensuite apporté davantage de nuances. Sa mise à jour de l’expérience sur la productivité de février 2026 a décrit des problèmes de sélection et la difficulté de mesurer le temps lorsque les développeurs utilisaient des agents simultanément. Les chercheurs ont jugé les résultats plus récents peu fiables pour estimer précisément l’effet actuel.

Ensemble, ces sources établissent un problème de mesure plutôt qu’un verdict universel. Le temps d’exécution des tâches, les modifications fusionnées et l’utilité déclarée par les utilisateurs peuvent évoluer différemment. Une évaluation solide précise quel résultat importe avant d’interpréter un résultat.

Pour un développeur individuel, un outil peut réduire le travail pénible sans réduire le temps écoulé. Pour une organisation, un outil peut élargir l’éventail des projets réalisables sans réduire l’effort de maintenance. Ces avantages méritent d’être pris en compte, mais ils nécessitent des intitulés précis.

Une équipe peut également accomplir davantage de travail parce qu’elle choisit des tâches plus petites. Cela peut améliorer la livraison en réduisant l’attente et l’incertitude. Cela peut aussi gonfler les mesures d’activité tout en laissant les problèmes majeurs des clients sans solution. Le seul nombre ne permet pas de distinguer ces explications.

Le scénario contrefactuel importe également. Évaluer la productivité exige une certaine estimation de ce qui se serait produit sans l’outil ou le processus. Une mise en production réussie établit qu’une équipe a livré quelque chose. Elle n’établit pas indépendamment l’ampleur de l’accélération attribuable à l’IA.

Le récit public de Microsoft fournit un exemple opérationnel, plutôt qu’une comparaison randomisée. Ce format peut révéler des mécanismes utiles et des modes de défaillance. Il ne peut pas isoler chaque contribution de l’expertise des développeurs, de l’infrastructure, du soutien organisationnel et des capacités du modèle.

La même prudence s’applique aux concurrents. Les orientations architecturales d’Anthropic expliquent une approche de conception, tandis que les recherches de Google décrivent des tendances plus larges. Aucune des deux ne permet d’établir quel fournisseur produit le meilleur résultat pour une charge de travail d’entreprise donnée.

Pour les responsables de l’ingénierie, la conséquence est de résister à la tentation de transformer un chiffre marquant en formule d’effectif. Les décisions relatives aux effectifs exigent des preuves sur la livraison durable, la qualité, la charge de support et le travail qui reste hors du processus mesuré.

L’histoire laisse également ouverte une question économique. Le coût total du travail accepté comprend la génération, l’évaluation, l’infrastructure, l’attention humaine et les corrections après la mise en production. Davantage d’activité d’implémentation peut coexister avec une meilleure ou une moins bonne économie.

Le développement avec Copilot Cowork devrait donc être évalué comme un exemple spécifique de réorganisation du travail. Sa contribution la plus forte consiste à susciter de meilleures questions sur les preuves, plutôt qu’à fournir un taux de conversion universel entre ingénieurs et agents.

Trois signaux permettront de mieux juger le modèle de développement

Les prochaines preuves utiles concernent des résultats durables, une vérification reproductible et le coût complet du travail accepté.

Le premier signal est un suivi reliant l’activité de développement à la fiabilité en production. Au cours des prochains mois, la communication d’informations sur les échecs de mise en production, les annulations ou les problèmes clients récurrents aiderait les lecteurs à interpréter le volume de modifications fusionnées.

Une amélioration de la fiabilité parallèlement à une livraison durable renforcerait l’argument en faveur du modèle opérationnel. Une hausse du travail de correction le compliquerait. Dans les deux cas, le résultat offrirait davantage de valeur décisionnelle qu’un autre relevé d’activité isolé.

La comparaison devrait utiliser des définitions cohérentes. Une modification des pratiques de reporting peut donner l’impression qu’un service est plus sain sans changer son comportement. Les lecteurs devraient rechercher une période de mesure stable et une explication claire de ce qui est considéré comme un échec.

Le deuxième signal est la preuve que les pratiques de vérification se transfèrent au-delà de l’équipe d’origine. Une évaluation documentée, une configuration de test reproductible ou un cas de production comparable aiderait à distinguer une approche largement utile d’un résultat dépendant de conditions inhabituelles.

La réplication n’exige pas qu’une autre équipe atteigne le même total quotidien. Elle exige de démontrer qu’une capacité d’implémentation supplémentaire produit des résultats acceptés sans submerger la revue et les opérations. Des charges de travail différentes devraient raisonnablement produire des niveaux d’activité différents.

Si d’autres équipes reproduisent les avantages sous des contraintes différentes, le cas devient plus général. Si la réussite dépend fortement d’une infrastructure spécialisée ou d’une expertise concentrée, son applicabilité devient plus restreinte. Cela resterait une information utile pour les acheteurs et les responsables de l’ingénierie.

Le troisième signal est un bilan économique crédible. Le coût par tâche client menée à bien établirait un lien entre les modifications d’ingénierie et la réalité opérationnelle du produit. Il révélerait également si les nouvelles tentatives et le travail correctif absorbent les gains d’efficacité apparents.

Une communication utile expliquerait quels coûts entrent dans le calcul. Exclure la revue ou l’infrastructure répondrait à une question plus étroite. Les inclure aiderait les organisations à comparer l’approche avec leur processus existant.

Il s’agit de priorités d’observation, et non d’engagements de reporting annoncés. Microsoft n’a pas promis chaque mesure évoquée ici. Leur absence laisserait certaines parties du dossier sans réponse plutôt que d’établir automatiquement un échec.

Pour les acheteurs d’entreprise, l’action immédiate consiste à demander aux fournisseurs des preuves liées à un flux de travail réel. Choisissez une tâche que les employés effectuent, définissez un résultat acceptable et examinez comment le système gère les exceptions. Gardez l’activité de développement distincte de la réussite client.

Pour les responsables de l’ingénierie qui évaluent le développement avec Copilot Cowork, utilisez cette étape pour préciser les questions qui sous-tendent vos propres décisions d’adoption. Identifiez ce que votre équipe peine à vérifier, les endroits où l’intention se perd et les résultats qui justifient une automatisation supplémentaire. Comparez le travail accepté sur une période significative, y compris l’effort nécessaire pour le corriger. Lisez le récit d’ingénierie sous-jacent parallèlement aux recherches sur la productivité, car ils répondent à des questions différentes. Examinez ensuite si votre organisation peut expliquer pourquoi une modification mérite d’être livrée. Lorsque l’implémentation devient plus facile à développer, cette explication devient une responsabilité centrale de l’ingénierie. Quelles preuves convaincraient votre équipe qu’une plus grande quantité de code généré est devenue un logiciel plus fiable ?