Kyle Daigle (COO de GitHub) : « Copilot rend les développeurs 55% plus productifs »

Ciblant les développeurs pour créer, stocker, gérer et partager leur code, Github s’est engagé sur la voie de l’IA générative (genAI) avant même que ChatGPT ou Copilot ne soit largement accessible au public. Grâce à un partenariat précoce avec OpenAI et Microsoft (qui l’a racheté 7,5 Md$ en 2018), le spécialiste du partage de code a amélioré et optimisé son outil. D’aucuns pensent qu’à mesure que la genAI continue d’évoluer et peut produire davantage de code en se basant uniquement sur les demandes des utilisateurs, les développeurs ne seront plus nécessaires. Comme l’a déclaré dernièrement le CEO de Nvidia, Jensen Huang, grâce à l’IA, « tout le monde dans le monde est maintenant un programmeur ». C’est donc cela le miracle de l’intelligence artificielle ? Au lieu de développer des logiciels, le patron de Nvidia pense ainsi que les humains devraient se concentrer sur des compétences plus importantes telles que la biologie, l’éducation, la fabrication ou l’agriculture… au point de voir le langage de programmation et le langage humain ne faire qu’un.

Travaillant chez GitHub depuis 11 ans, Kyle Daigle est directement impliqué dans ces sujets et ces réflexions puisqu’il a pris la direction des opérations du groupe il y a environ un an et a justement participé à la stratégie de développement de la genAI, qui vise à découvrir comment la technologie peut profiter à ses quelque 3 000 employés – développeurs et non-développeurs – et à sa communauté externe d’utilisateurs. Jusqu’à présent, la genIA permet aux codeurs d’être 55 % plus productifs, a notamment indiqué Kyle Daigle dans une interview accordée à notre confrère Computerworld à propos des différentes façons dont la genAI a apporté des gains d’efficacité et aidé les développeurs et les non-développeurs. 

IDG NS. Quand avez-vous déployé Copilot ? Pourquoi ? Et qu’est-ce qu’il a permis à GitHub de faire ?

Kyle Daigle. Cela fait maintenant deux ans et demi que nous travaillons sur Copilot. Nous avons commencé à travailler dessus lorsque nous avons obtenu un accès anticipé aux modèles OpenAI dans le cadre de notre partenariat avec Microsoft. Comme pour beaucoup d’entreprises aujourd’hui, la question principale était de savoir comment utiliser ces LLM à bon escient. Il nous a fallu un certain temps pour mettre au point la sauce secrète qui a donné naissance à Copilot. À l’origine, lorsque nous utilisions les modèles, nous pensions que nous allions construire des outils pour documenter le code. Vous savez, vous lui donnez votre référentiel et il vous dit ce que fait ce code. Mais au fil des expériences, l’idée du « texte fantôme » – un certain modèle d’achèvement de ce que fait Copilot en montrant l’intégralité d’un message plutôt qu’une seule ligne – a été une sorte de grande avancée pour pouvoir tirer le meilleur parti d’un outil puissant. Aujourd’hui, plus d’un million d’utilisateurs de GitHub utilisent Copilot chaque jour. Nos statistiques montrent qu’il les rend 55 % plus productifs et qu’il écrit environ 60 % du code. Nous prévoyons que cette part atteindra environ 80 % au fil du temps dans de nombreux langages.

Je pense que le plus important, et nous en parlons beaucoup à nos équipes internes, c’est que les développeurs se sentent plus épanouis. Ils effectuent un travail plus créatif et non pas de fourmi. Au lieu de chercher à ce que la genAI se charge du créatif, nous offrons à l’humain d’être dans le siège du pilote en tant que développeur. Nous avons donc réussi à faire en sorte que tous les développeurs de notre environnement utilisent GitHub pour les aider à écrire du code. En interne, nous nous sommes attachés à tirer les leçons de Copilot et à les appliquer à d’autres domaines dans lesquels nous utilisons des outils d’IA en dehors des cas d’utilisation liés au développement de logiciels; et aussi pour nous aider à être un peu plus productifs.

L’aide au développement du code semble être l’un des premiers fruits à portée de main auquel votre plateforme genAI s’est attaquée. Depuis combien de temps l’utilisez-vous pour aider à la production de code et avec quels langages ?

Lors de nos premières expériences, nous travaillions beaucoup en Python, en JavaScript et dans d’autres langages de ce type. GitHub est principalement une entreprise Ruby, mais nous écrivons également en Go, en C et en FirGit. Nous avons donc élargi les cas d’utilisation de Copilot et l’avons utilisé dans différents langages. Mais dans l’ensemble il est capable de fonctionner avec la grande majorité des langages de la sphère publique. Si vous avez un langage propriétaire, il peut l’émuler parce qu’il regarde le code à l’intérieur de votre référentiel et il peut faire un très bon travail pour déterminer ce qu’il doit utiliser pour alimenter la prochaine ligne de code ou la prochaine méthode. Nous sommes donc passés de quelques langages de test à pratiquement tous les langages de programmation modernes qui ont un contexte suffisant dans l’open source et Internet.

Où en est Copilot en ce qui concerne la complétion de code ?

En termes de taux de complétion de code, ce dont nous parlons, c’est que dans certains cas, lorsque vous écrivez avec Copilot, il peut terminer une ligne de code, mais il peut aussi compléter une méthode entière, un fichier ou une classe entière, en fonction du langage que vous utilisez. Avec un outil comme Copilot Chat, vous pouvez parler à Copilot et lui dire voici le problème que j’essaie de résoudre, et il peut potentiellement générer l’intégralité d’un fichier pour vous. Vous pouvez alors dire je ne veux pas qu’il soit bleu, je veux qu’il soit rouge ou je veux qu’il utilise telle ou telle API comme ce genre d’ajustements. Lorsque nous parlons de la quantité de code générée, nous parlons de la quantité de code que Copilot a fourni et de la quantité que l’utilisateur a conservée au fil du temps. Évidemment, lorsque vous obtenez un résultat, vous pouvez penser oh, ce n’est pas correct ou si vous êtes un développeur, vous pouvez penser que le code n’est pas correct, en écrire un tas d’autre et vous rendre compte qu’il n’est pas possible de le remanier tout de suite. Mais en fait ce n’est pas tout à fait correct.

Ce que nous constatons, c’est que la grande majorité du code généré par la solution est conservé. Ensuite, après avoir écrit des codes, soumis un PR, exécuté l’intégration continue, les étapes suivantes sont également plus rapides. Ainsi, l’examen du code écrit par Copilot avec un développeur tend à être plus rapide parce que le code finit par être meilleur. L’intégration continue aboutit plus souvent à un feu vert que rouge lors de la première version parce que le code tend à être plus correct. Il y a donc beaucoup d’impacts intéressants en aval, également, lorsque vous êtes en mesure d’utiliser Copilot dans le cadre de votre charge de travail en tant que développeur.

Avez-vous constaté des problèmes – des inexactitudes – lors de l’utilisation de Copilot ?

Le code que nous vous fournissons imite également celui qu’il voit dans votre dépôt. Ainsi, dans certains cas, si la base de code est plus ancienne, il en tiendra compte et appliquera peut-être une pratique qui n’est plus moderne, comme le casing des variables ou si vous avez une bibliothèque qu’il appellera parce qu’il essaie d’émuler votre projet existant ainsi que le modèle sous-jacent. Pour certains développeurs, la solution consiste à utiliser le chat de Copilot pour dire nous sommes en train de mettre à jour ce projet, j’aimerais donc utiliser la nouvelle approche. C’est l’un des moyens de résoudre ce problème. Mais nous nous appuyons aussi sur l’outil pour trouver d’autres moyens d’aider les développeurs à rester en sécurité en corrigeant également les vulnérabilités. Ainsi, l’une des choses que nous avons partagées lors de la conférence GitHub Universe en novembre s’appelait Security Autofix, qui utilise une technologie d’IA sous-jacente similaire. Ainsi, lorsque vous lui dites que vous avez connaissance d’une vulnérabilité dans une base de code, nous n’allons pas seulement vous dire que vous avez une vulnérabilité que vous devez corriger. Nous allons également procéder à la correction sur place. Tout ce que vous avez à faire, c’est de dire oui, je suis prêt à le faire.

Copilot est donc toujours dans le siège de copilote. Vous devez toujours suivre les meilleures pratiques. Il est toujours nécessaire d’effectuer des analyses de sécurité et des analyses secrètes et toutes les choses qui ont été vraies pour les bonnes pratiques de développement de logiciels, quoi qu’il en soit. Mais nous essayons de trouver des moyens d’introduire l’IA dans l’ensemble du cycle de vie du développement logiciel sur GitHub pour vous aider. Ce n’est donc pas seulement dans votre IDE lorsque vous écrivez du code.

Certains acteurs du secteur IT craignent que la capacité de l’IA à générer automatiquement du code évincent les développeurs. Qu’en pensez-vous ?

Je pense qu’au cours de l’histoire moderne, il y a eu tant de moments où un élément technologique est apparu dans le monde, comme la presse à imprimer, que tout le monde s’est dit attendez une minute mon travail va-t-il disparaître ? Mais en réalité, ce qui s’est passé, c’est que beaucoup de travaux et d’opportunités qui n’étaient plus rentables l’ont soudain été, parce que les développeurs ne passent plus 60 à 70 % de leur temps à résoudre des problèmes qui ont été résolus des dizaines, des centaines et des milliers de fois. La réalité, c’est que GitHub Copilot rend les développeurs 55 % plus productifs. Certains clients ont réagi en disant est-ce que cela signifie que je récupère 55 % du temps de travail de mes développeurs ? En réalité, vos développeurs gagnent la capacité de résoudre des problèmes plus difficiles de manière plus créative qu’ils ne pouvaient le faire auparavant lorsqu’ils devaient faire tout ce travail eux-mêmes. Chez GitHub, nous recrutons toujours des développeurs. Nous embauchons en ce moment même. Ce que nous constatons, c’est que nous consacrons plus de temps à la discussion initiale ou à l’architecture et au problème que nous résolvons avec les clients. Car plus le codage devient rapide, plus il est important de consacrer son temps à la résolution créative de problèmes plutôt qu’au travail routinier que nous avons tous effectué à un moment ou à un autre de notre carrière.

Je suis plus excité par ce que l’IA commence à nous apporter tel la capacité de résoudre des problèmes plus importants qui n’étaient peut-être pas possibles avant, comme la réécriture complète d’une application. Beaucoup de clients remettent cela à plus tard, car ils se demandent comment ils pourraient se le permettre. Mais si c’est 50 % moins cher, vous pourrez peut-être passer à cette nouvelle technologie et l’utiliser pour résoudre encore plus rapidement la prochaine série de problèmes. Je pense qu’il nous reste beaucoup de travail à faire. Selon tous les analystes, il n’y a pas assez de développeurs dans le monde. Il y a donc du chemin à parcourir avant de devoir nous inquiéter du manque de travail des développeurs.

Quels sont les avantages de la genAI pour les équipes qui ne sont pas des développeurs ?

L’un des principaux éléments de Copilot qui n’est pas assez estimé est la capacité d’apprentissage et de développement (learn and development), ou d’amélioration des compétences au bureau. Vous avez quelqu’un qui est nouveau dans un rôle, une entreprise, une langue et vous pouvez venir et avoir immédiatement quelqu’un à qui vous pouvez poser des questions, avec qui vous pouvez écrire du code et obtenir cette boucle de rétroaction immédiate avec Copilot. Il ne s’agit pas seulement des nouveaux arrivants. Dans de nombreux cas, les développeurs les plus expérimentés se voient confier ces vieux projets qui sont extrêmement importants pour l’entreprise, mais qui sont restés sur les étagères, dans un placard, pour assurer son bon fonctionnement. Lorsqu’ils ont besoin d’aller dans ces projets et de faire des mises à jour, l’aspect L&D a été vraiment important parce qu’ils peuvent y aller et dire je connais Java, mais je ne connais pas Scala ou je connais Java, mais je ne connais pas .Net ou autre chose. Et pouvez-vous m’aider à savoir quelles sont les prochaines étapes ? Dans le même ordre d’idées, nous axons également Copilot sur l’expérience de l’utilisateur, c’est-à-dire qu’il suffit de commencer à taper. Il n’y a pas de véritable formation, il n’y a pas d’apprentissage, il n’y a pas de boutons à comprendre. J’ai donc pris ces deux enseignements et nous avons commencé à chercher en interne d’autres endroits où nous pensions qu’il y avait du travail et où nous pouvions mettre en œuvre l’IA sans avoir à l’activer. C’est là le véritable secret. Si vous devez apprendre aux gens comment l’utiliser, ce n’est pas beaucoup mieux que n’importe quel autre choix technologique que vous pourriez faire.

Quelles ont été vos autres grandes victoires ?

L’une des premières grandes victoires que nous avons remportées chez GitHub, et j’ai vu cela dans d’autres endroits, c’est de prendre l’IA et de l’amener dans l’environnement de l’informatique. Nous avons un peu plus de 3 000 Hubbers [employés de GitHub] qui ont saisi des centaines et des centaines de tickets [d’assistance] dans un ancien système, pour obtenir de l’aide sur la raison pour laquelle leur ordinateur portable ne fonctionne pas, sur la manière d’accéder au VPN, etc. GitHub fonctionne essentiellement avec Slack. Nous sommes une entreprise qui fonctionne d’abord à distance. Nous avons des employés dans le monde entier, nous ne sommes pas une entreprise qui retourne au bureau. Ce que nous avons fait, c’est dire, si nous sommes tous sur Slack, pourquoi ne pas faire en sorte que l’interaction avec le service informatique dans cet outil soit également alimentée par l’IA ?

Ainsi, au lieu d’aller sur un portail et de soumettre un ticket, nous avons un canal appelé IT Help Desk, et dans ce canal se trouve un bot que nous appelons OctoBot. Lorsque vous posez une question, un fournisseur appelé MoveWorks, avec lequel nous avons conclu un partenariat, voit cette question et OctoBot vient vous dire oui, je sais exactement ce que vous devez faire. Voici les prochaines étapes. Et dans de nombreux cas, nous pouvons même automatiser le flux de travail pour dire nous allons configurer ceci dans ces autres systèmes pour vous. Peut-être que c’est ce que veulent tous les développeurs. Cliquez sur ce bot et nous vous enverrons votre nouvel ordinateur portable. Comme nous n’avons pas créé de nouveau système et que nous n’avons pas eu à former qui que ce soit à un nouveau portail, nous avons constaté une énorme amélioration. OctoBot résout aujourd’hui 30 % des problèmes dès le départ. Nous gagnons des heures par jour sur le temps de chaque membre du personnel informatique, que nous pouvons réinvestir dans d’autres initiatives d’IA.

Le plus intéressant c’est que la satisfaction des clients a augmenté de 12 points. Aujourd’hui, le taux de satisfaction est de 98 %. Je n’ai pas eu à former qui que ce soit. Nous n’avons pas eu à déployer cette technologie comme on le ferait normalement dans une entreprise. Nous l’avons simplement mise en place là où tout le monde demandait déjà de l’aide. Je pense que c’est là le grand secret : lorsque je parle à des collègues d’autres entreprises de la manière dont on peut supprimer les tâches et faire gagner du temps aux gens tous les jours sans introduire de nouveaux comportements, je me dis que c’est un bon exemple. En voici un : nous sommes en train de tester six ou sept autres outils au sein de l’entreprise à partir de ce processus. Environ 10 % de nos employés participent à une sorte d’essai d’outil d’IA, dans le cadre duquel nous suivons le même processus : comment faire sans habilitation ? Pouvons-nous l’intégrer dans le flux ? Ensuite, nous mesurons simplement le temps gagné de l’autre côté. Si nous gagnons du temps et que l’outil est rentable, nous continuons à progresser. Ce que nous ne faisons pas, c’est d’avoir un outil sur lequel il faut se renseigner, être formé, ou qui est très ouvert. Cet outil peut tout faire pour vous ! Car nous constatons qu’il rend les gens plus productifs, plus heureux et, en fin de compte, qu’il les libère de leur labeur.

Envisagez-vous d’autres outils de genAI ?

En ce qui concerne GitHub, nous avons repris une grande partie de la technologie Copilot sous-jacente et nous l’avons appliquée à nos cas d’utilisation de l’assistance. Ainsi, lorsque vous êtes sur GitHub, que vous avez un problème et que vous devez saisir un ticket, c’est très similaire à ce que nous avons appris de notre expérience en matière d’informatique. Lorsque vous commencez à suivre le flux, et nous suivons le processus normal pour résoudre le problème, il y a une étape où vous pouvez finir par parler à Copilot. Nous l’appelons Support Copilot. Il est capable de vous guider dans le contexte de votre demande et de l’accès dont vous disposez, et de résoudre potentiellement votre problème sur-le-champ.

De l’autre côté, en regardant vers l’extérieur, nous avons également dépassé l’idée que Copilot vous aide à écrire du code et à résumer une demande d’extraction. Que se passe-t-il lorsque l’on renverse le modèle et que l’on commence à décrire à Copilot le problème que l’on cherche à résoudre ? C’est l’exploration sur laquelle nous travaillons et que nous appelons Copilot Workspace. Essentiellement, au lieu de commencer directement dans le code, vous commencez par un problème : vous commencez par une question GitHub décrivant ce que vous essayez d’accomplir. Copilot peut prendre cela et aller de la prose [messages écrits] de ce que vous essayez de faire, au code, puis vous pouvez éditer la prose et cela changera le code. Ensuite, vous pouvez modifier le code si nécessaire. Enfin, il peut le tester, l’exécuter, le construire et le déployer à partir du langage naturel. C’est un domaine que nous essayons de dépasser et de trouver comment écrire plus de code, plus rapidement et avec plus de précision. Parfois, le meilleur code n’est pas de code du tout et il s’agit simplement d’utiliser le langage humain.

Comment déterminez-vous le retour sur investissement et avez-vous calculé le retour sur investissement de cette technologie ?

Vous pouvez mesurer un million de choses [en interne] ; c’est également vrai pour le développement de logiciels. Dans le développement de logiciels, il existe des pratiques qui permettent de mesurer les paramètres DORA – cette idée de la quantité de code que l’on fait passer dans le pipeline. Vous pouvez mesurer les paramètres d’espace. Il existe toutes sortes de méthodes. En interne, lorsque nous essayions de travailler sur ces cas d’utilisation informatique, c’était la même chose. Combien de tickets sont détournés ? Combien de tickets ont été fermés ? En fin de compte, nous mesurons tous l’activité. En fin de compte, ce que nous essayons de mesurer, c’est le temps. Combien de temps récupérez-vous ? Pour moi, lorsque nous effectuons toutes ces mesures, le retour sur investissement est intégré parce que nous récupérons le temps que les employés utilisaient auparavant pour résoudre ces tickets, effectuer des flux manuels, écrire du code – peu importe ce que c’est.

Nous prenons donc ce temps et l’investissons dans des activités plus stratégiques. Le retour sur investissement a donc été très clair pour l’idée de l’OctoBot ; les 55 % de productivité supplémentaire sont en fin de compte réinvestis automatiquement parce que vous êtes capable d’avancer plus rapidement en tant que développeur de logiciels, et nous essayons d’autres outils qui redonnent aux employés, potentiellement, de 30 minutes à une heure par jour. Ils peuvent ainsi se consacrer à des tâches plus stratégiques pour nos clients et avancer plus rapidement. Je pense que vous pouvez le constater chez GitHub : nous avons l’impression de pouvoir faire beaucoup plus qu’avant, et ce n’est pas parce que nous avons connu une croissance de 50 % au cours de l’année écoulée, c’est parce que nous sommes capables de réinvestir ce temps. 

Quels conseils donneriez-vous aux entreprises qui envisagent d’utiliser ou d’étendre leur utilisation de l’IA générique ?

La meilleure chose que les entreprises puissent faire pour démarrer est de trouver des méthodes pour intégrer l’IA dans les flux de travail existants – les équipes n’ont pas besoin de réinventer la roue, car il est plus facile d’utiliser des fonctionnalités d’IA qui restent dans le flux, et non pas qui exigent un comportement tout à fait nouveau. Rencontrez les employés là où ils sont, donnez-leur les outils d’IA dont ils ont besoin, et ils finiront par en faire l’évangélisation auprès des autres. Voici quelques autres conseils tirés de mon expérience chez GitHub : élaborez un plan que vous pourrez répéter. Nous ne sommes plus à l’époque où il fallait aller vite et tout casser, mais ce n’est pas non plus le moment d’élaborer une stratégie de déploiement unique sur six mois. Mais des décennies d’écriture de logiciels nous ont appris que l’itération est plus importante qu’un énorme projet de réécriture que l’on espère correct. Il est important de piloter souvent, tôt, en petits groupes.

Vous devez faire de l’expérimentation un élément central de votre culture. Chez GitHub, cela se traduit par l’implication de plus de 10 % de notre entreprise dans des projets pilotes d’IA. Laissez l’IA se charger de votre travail. Les meilleurs outils d’IA sont ceux qui permettent à nos meilleures qualités humaines de briller.  Concentrez-vous sur ce qui distrait les employés de leur travail – comme la gestion des calendriers par exemple – et laissez l’IA se charger du travail pour que vos employés puissent libérer leur créativité de manière plus importante et plus profonde.