Un coup de gueule venu de l'open source Dans la communauté de l'émulation et de la décompilation de jeux vidéo, les mainteneurs alertent. Des portages entièrement ou largement générés par IA se multiplient, avec des bugs critiques qui rendent certains projets à peine utilisables. Une équipe a repris un projet concurrent pour cette raison, en pointant la dette technique et une maintenance qui risque de devenir ingérable sans documentation. Le principal serveur communautaire ne met plus en avant les projets reposant largement sur du code IA. Et de grands projets open source refusent désormais les contributions générées de taille importante. L'effet de bord, plus grave que le bug Un exemple résume le problème. Dans l'un de ces projets, une modification générée par un agent a touché le module de rendu graphique partagé par plusieurs projets. Résultat : des problèmes de compatibilité et de maintenance bien au-delà du périmètre initial. Le code généré ne produit pas seulement des erreurs locales. Il touche des composants communs que personne n'avait prévu de modifier. Un déséquilibre structurel L'IA a supprimé une contrainte : écrire du code. Elle n'a rien changé au reste. Relire, comprendre, tester, maintenir prennent toujours autant de temps. Quand le volume produit augmente et que la capacité de vérification reste stable, la qualité baisse. Mécaniquement. La dette s'accumule là où personne ne regarde. Un développeur de la communauté l'a résumé autrement : le problème n'est pas l'outil, ce sont ceux qui l'utilisent sans chercher à comprendre ce qu'il fait. Ce que ça change pour une équipe produit En entreprise, le symptôme apparaît plus tard, en recette ou en production. Les pull requests grossissent, les revues deviennent superficielles, les régressions passent. Accélérer la génération de code sans industrialiser les tests revient à déplacer la charge vers le support. La capacité de test automatisé devient donc la vraie limite. Elle détermine combien de code généré une organisation peut absorber sans dégrader ses applications. Mesurer la part de code fusionné sans test associé est un bon point de départ.
