Depuis mi-avril, une nouvelle controversée secoue la communauté des développeurs utilisant Visual Studio Code. En effet, Microsoft a discrètement modifié le comportement par défaut de l’éditeur, entraînant l’ajout automatique de la mention “Co-authored-by: Copilot <[email protected]>” dans les commits Git, même lorsque l’utilisateur n’a pas utilisé ou activé Copilot. Cette évolution, élément d’une mise à jour probablement décidée sans consultation préalable de la communauté, a provoqué un tollé général.
Le changement a été effectué via la pull request #310226, déposée sans description claire le 15 avril et rapidement fusionnée le lendemain par le développeur dmitrivMS. La communauté a découvert avec stupeur que cette modification concernait deux fichiers seulement, et touchait principalement la façon dont les commits étaient enregistrés. La réaction n’a pas tardé : la PR a été largement critiquée, notamment par un tsunami de commentaires furieux, plus de 370 votes négatifs contre seulement deux positifs, et de nombreuses réactions “confused”.
Ce changement automatique de la mention “Co-authored-by” sans consentement et en dépit de la désactivation des options IA a été perçu comme une forme de fraude, la communauté dénonçant une décision unilatérale et non transparente de Microsoft.
Les développeurs ont rapidement réagi en tentant de neutraliser ce comportement perturbateur, notamment en ajoutant dans leur fichier settings.json la ligne “git.addAICoAuthor”: “off”. Pour les commits déjà pollués, des commandes telles que git rebase -i ou git filter-branch sont conseillées, mais ces solutions restent limitées si les commits ont été déjà fusionnés dans des branches distantes ou intégrés à des PR. La situation s’est complexifiée avec la remontée de bugs, notamment le #313064, révélant que la nouvelle configuration par défaut, “all”, attribuait à Copilot des suggestions qui n’étaient même pas présentes dans le code, générant ainsi une attribution abusive et gênant pour les audits ou la crédibilité des développeurs.
La polémique a rapidement gagné en ampleur, surtout face à l’ampleur du problème : faire passer du code écrit par un humain pour du code assisté par une IA pourrait entraîner des conséquences professionnelles et légales. Sur GitHub, la communauté a qualifié cette pratique de “vandalisme” et de fraude, certains allant jusqu’à craindre que cela ne coûte des emplois ou ne provoque des sanctions lors d’audits. La presse spécialisée n’a pas été en reste, avec Windows Central évoquant la possibilité que ces erreurs puissent “coûter des jobs” ou entacher des contrats dans des secteurs sensibles comme la fintech ou la cybersécurité.
Face à la pression, Microsoft a finalement rectifié le tir en modifiant la valeur par défaut dans VS Code 1.118, la passant de “all” à “chatAndAgent”, puis en la désactivant purement et simplement dans la version 1.119, déployée aujourd’hui. La Product Manager Courtney Webster a présenté ses excuses publiques, reconnaissant que la manière dont cette fonctionnalité a été implémentée et déployée n’a pas été à la hauteur des attentes. Cependant, ce coup de colère communautaire soulève une question plus large : la confiance dans l’écosystème Microsoft, déjà fragilisée par l’intégration croissante de Copilot dans Windows, Office et même des extensions pour Apple, est sérieusement ébranlée. La communauté commence à se détourner de ces outils, déçue par des pratiques perçues comme opaques ou arbitraires.
En conclusion, cette affaire met en lumière les dangers d’une gestion unilatérale des fonctionnalités dans des outils aussi critiques que VS Code, surtout lorsque celles-ci interfèrent avec l’intégrité du travail des développeurs. Pour se prémunir contre de futurs mauvais coups, certains recommandent déjà de migrer vers des alternatives telles que VSCodium ou Zed, qui respectent la vie privée et ne polluent pas l’historique avec des mentions automatiques indésirables. De même, migrer ses dépôts vers des plateformes plus respectueuses, comme Codeberg ou Forgejo, pourrait être une solution pour préserver une maîtrise totale de son environnement de développement. La question reste ouverte : Microsoft tiendra-t-il ses promesses de transparence ou succédera-t-on encore à une série de décisions mal communiquées et mal préparées ?
