GitHub renforce Copilot Autofix alors que l’IA ralentit la livraison logicielle
GitHub Copilot Autofix pourrait aider les développeurs à mieux gérer les vulnérabilités alors que le volume de code généré par l’IA submerge les processus de livraison. Mais peut-on vraiment faire confiance à l’IA pour encadrer l’IA ?
Copilot Autofix est entré en disponibilité générale pour les clients Advanced Security en août et pour tous les dépôts en septembre. Cet outil analyse d’abord le code dans les dépôts GitHub à la recherche de vulnérabilités de sécurité. Ensuite, il génère des explications pour les développeurs sur la raison de leur importance et suggère des correctifs. Cette semaine, le service s’est enrichi de fonctionnalités en préversion publique : les campagnes de sécurité, destinées à résorber les arriérés de dettes de sécurité, et des intégrations avec des outils d’analyse de code tiers, notamment ESLint, JFrog static application security testing (SAST) et Polaris de Black Duck.
Selon Katie Norton, analyste chez IDC, les entreprises doivent utiliser la remédiation automatisée des vulnérabilités à deux niveaux : pendant que les développeurs codent et pour faire le ménage dans les backlogs (une pratique codifiée dans la méthode Scrum).
« Autofix peut contribuer à la programmation, en aidant les développeurs à réduire l’introduction de vulnérabilités. Les campagnes de sécurité, quant à elles, participeront à la réduction du backlog ou de la dette de sécurité », déclare-t-elle. « De nombreux outils existants dans le domaine de la remédiation automatisée ne s’attaquent qu’à l’entretien du backog ou à l’assistance à la programmation, c’est pourquoi il sera utile d’avoir une approche double dans le cadre de GitHub Advanced Security ».
Rapprocher Autofix de Dependabot
Jusqu’à présent, les campagnes de sécurité sont principalement axées sur l’analyse des vulnérabilités CodeQL de GitHub et les résultats SAST, mais Katie Norton s’attend à ce que cela s’étende également aux vulnérabilités et aux dépendances open source par le biais de Dependabot, un système de mise à jour des dépendances conçu par la filiale de Microsoft. D’autres outils d’analyse du code source, comme Endor Labs Open Source, modélisent les dépendances et l’impact des mises à jour des paquets open source vulnérables.
« Il existe des capacités de mise à jour automatique de la sécurité, mais j’aimerais que Dependabot soit plus étroitement intégré à Autofix afin de le rendre plus intelligent », note-t-elle.
GitHub a fait un pas dans cette direction cette semaine avec la version privée de Copilot Autofix pour Dependabot qui couvre les dépôts TypeScript. La nouvelle intégration comprend des correctifs générés par l’IA pour résoudre les ruptures causées par les mises à niveau des dépendances dans les pull requests issues de Dependabot, selon un changelog publié par l’éditeur.
Les effets néfastes de l’IA sur les performances de livraison des logiciels
Alors que les outils d’analyse du code source alimentés par l’IA se multiplient, le rapport annuel Accelerate State of DevOps de l’équipe DevOps Research and Assessment (DORA) de Google Cloud a examiné ce mois-ci l’effet du code généré par l’IA sur les processus de livraison de logiciels. L’adoption de l’IA a été forte parmi les quelque 3 000 personnes qui ont répondu à l’enquête cette année. Environ 81 % d’entre elles ont déclaré utiliser l’IA, principalement pour écrire, expliquer, documenter et optimiser le code, ainsi que pour résumer des informations.
Si l’analyse de Google DORA tend à démontrer que l’IA permet d’améliorer la fluidité, la productivité et la satisfaction professionnelle des individus, ainsi que la qualité de la documentation des projets, ses effets sur les performances globales en matière de livraison de logiciels ne sont pas aussi positifs. Pour chaque augmentation de 25 % de l’adoption de l’IA, Google DORA a constaté une diminution de 1,5 % du débit de livraison des logiciels et une diminution de 7,2 % de la stabilité de livraison, une mesure combinée du taux d’échec et du taux de reprise pour les changements de logiciels.
« Le changement de paradigme fondamental que l’IA a produit en matière de productivité des répondants et de vitesse de génération de code a peut-être fait oublier l’un des principes les plus fondamentaux de DORA, à savoir l’importance des lots de petite taille », selon le rapport. « DORA a toujours montré que les changements plus importants sont plus lents et plus susceptibles de créer de l’instabilité ».
Andy Thurai, analyste chez Constellation Research, fournit une autre explication.
« Alors que 75 % des personnes interrogées utilisent l’IA pour la rédaction du code, moins de 60 % d’entre elles l’utilisent pour le débogage, l’examen du code et la rédaction de tests », déclare-t-il. « Cela pourrait être dû au fait que les outils dans ces domaines ne sont peut-être pas matures, ou que les entreprises choisissent de ne pas leur faire confiance pour ces tâches », suggère-t-il. « Quoi qu’il en soit, si la moitié du DevOps est automatisée et pilotée par l’IA et que le reste essaie encore de rattraper son retard, cela ne se terminera pas bien. »
Un autre observateur pense que c’est encore plus simple que cela.
« L’utilisation de l’IA pour le développement de logiciels n’est pas encore mûre ».
David StraussCTO, Pantheon
« L’utilisation de l’IA pour le développement de logiciels n’est pas encore mûre », signale David Strauss, directeur technique chez le fournisseur de services WebOps Pantheon. « Les entreprises exagèrent leur adoption. Elles devraient montrer une plus grande confiance dans le code [généré par] l’IA, une meilleure productivité ou des effets de substitution plus élevés des heures d’ingénierie, si elles obtiennent réellement les résultats qu’elles prétendent obtenir grâce à l’IA ».
Le rapport Google DORA indique que la confiance dans l’IA est pour l’instant fragile : 39,2 % des personnes interrogées ont déclaré n’avoir que peu ou pas confiance dans l’IA. Une majorité – 67 % – des personnes interrogées ont fait état d’au moins une amélioration de leur capacité à écrire du code grâce aux outils de programmation assistés par l’IA, mais pour environ 40 % d’entre elles, cette amélioration a été qualifiée de « légère ». Seuls 10 % ont observé des améliorations « extrêmes » de leur capacité à écrire du code grâce à l’IA, selon le rapport.
Peut-on faire confiance à l’IA pour réparer les bêtises de l’IA ?
GitHub utilise un ensemble de tests automatisés pour contrôler la qualité des suggestions de Copilot Autofix, selon la documentation de l’entreprise. Les red teams de GitHub soumettent également le système à des stress tests afin de vérifier qu’il n’y a pas de dommages potentiels, et un système de filtrage par-dessus le LLM sous-jacent permet d’éviter que des suggestions potentiellement dangereuses soient affichées pour les utilisateurs, selon la documentation.
Mais la documentation de GitHub contient également cette mise en garde : « Vous devez toujours prendre en compte les limites de l’IA et modifier les changements si nécessaire avant de les accepter », peut-on lire. « Vous devez également envisager de mettre à jour les tests CI et la gestion des dépendances pour un référentiel avant d’activer Copilot Autofix pour l’analyse du code ».
C’est exactement la façon dont Veradigm a abordé l’utilisation de GitHub Copilot Autofix. « Il est parfois étonnamment bon, et fait parfois des choses auxquelles je ne m’attendais pas ou qui briseraient d’autres fonctionnalités », constate Kyler Middleton, ingénieure logiciel principale chez Veradigm, un éditeur de solutions logicielles dans le secteur de la santé. « Il est frappant de constater qu’il se comporte comme un ingénieur humain à cet égard ».
Toutefois, la détection du code généré par l’IA est « un problème non résolu, avec un grand P », souligne-t-elle. « Faute de pouvoir détecter si un code est généré par l’IA ou par l’homme, nous nous sommes contentés de tester notre code autant que possible », poursuit-elle.
Cela ressemble beaucoup à ce qui se passait avant l’apparition de l’IA : les ingénieurs copient probablement aussi du code provenant d’endroits aléatoires sur les internets. »
Kyler MiddletonIngénieure logiciel, Veradigm
« Cela ressemble beaucoup à ce qui se passait avant l’apparition de l’IA : les ingénieurs copient probablement aussi du code provenant d’endroits aléatoires sur les internets. Nous devons compter sur des personnes intelligentes pour lire le code et sur de bons tests unitaires pour trouver les problèmes », résume Kyler Middleton.
Mais d’autres ont des doutes quant à l’utilisation de l’IA pour tester les résultats de l’IA, en particulier lorsque les mêmes modèles de fondation sont utilisés des deux côtés de l’équation de la génération et du test du code.
« Il est difficile d’utiliser l’IA pour faire confiance à l’IA pour la même raison que les gens manquent souvent leurs propres erreurs – un système d’IA qui comprend une erreur potentielle ne la commettra généralement pas en premier lieu », pense David Strauss de Pantheon. « Une autre IA pourrait être capable de repérer des problèmes dans le travail d’une consœur, mais les autres modèles peuvent encore être trop similaires dans leur entraînement et la distribution de leurs capacités pour “réviser le code” résultant du travail d’une autre IA, d’une manière qui inspire la confiance, du moins aujourd’hui ».
Par ailleurs, l’utilisation de grands modèles de langage distincts pour évaluer les résultats d’un autre modèle introduit de la complexité et des coûts dans l’équation, alors même que de nombreuses entreprises ont déjà du mal à obtenir un retour sur investissement de l’IA générative, renchérit Andy Thurai de Constellation Research.
« Cela nous ramène à la question de savoir quel est le but de tout cela », poursuit-il. « Si vous adoptez cette technologie en vue de gagner en productivité et en rentabilité, cela pourrait bien aller à l’encontre de l’effet recherché ».
