Depuis plus de deux ans, GitHub développe sa propre plateforme d’IA générative baptisée Copilot pour aider les développeurs à coder. L’outil a gagné en fonctionnalité et son adoption apporte des gains de productivité importants pour les programmeurs, souligne Kyle Daigle, COO de l’éditeur dans un entretien.
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.
Début 2023, la société de gestion des voyages et des dépenses Navan a choisi d’adopter la technologie d’IA générative pour une myriade d’utilisations commerciales et d’assistance à la clientèle. Une décision impliquant des mesures pour éviter les dérives et problèmes de sécurité.
Originaire de Palo Alto en Californie, Navan (ex-TripActions) s’est tourné en février 2023 vers ChatGPT d’OpenAI et les outils d’aide au codage de GitHub Copilot pour écrire, tester et corriger le code. Avec, à la clé, une meilleure efficacité opérationnelle et une réduction des frais généraux. Les outils d’IA générative ont également été utilisés pour créer une expérience conversationnelle pour l’assistant virtuel client de l’entreprise, Ava. Ce chatbot pour les voyages et les dépenses, apporte aux clients des réponses à leurs questions et une expérience de réservation conversationnelle. Il peut également fournir des données aux voyageurs d’affaires, telles que les dépenses de voyage de l’entreprise, le volume et les détails granulaires des émissions de carbone.
Grâce à l’IA générative, bon nombre des 2 500 employés de Navan ont pu éliminer les tâches redondantes et créer du code beaucoup plus rapidement que s’ils l’avaient créé de toute pièce. Cependant, les outils d’IA générative ne sont pas exempts de risques en matière de sécurité et de réglementation. Par exemple, 11 % des données que les employés collent dans ChatGPT sont confidentielles, selon un rapport du fournisseur de cybersécurité CyberHaven. Navan dispose d’une licence pour ChatGPT, mais l’entreprise a proposé à ses employés d’utiliser leurs propres instances publiques de la technologie, ce qui peut entraîner des fuites de données en dehors des murs de l’entreprise. Celle-ci a donc décidé de limiter les fuites et autres menaces en utilisant des outils de surveillance et en appliquant un ensemble de directives claires. Un outil SaaS, par exemple, signale à un employé qu’il est sur le point d’enfreindre la politique de l’entreprise, ce qui a permis de sensibiliser davantage les travailleurs à la sécurité, selon Prabhath Karanth, RSSI de Navan. Des moyens ont été mis en place pour protéger l’entreprise contre les abus et les menaces intentionnelles ou non liées à l’IA générative comme l’explique ainsi le responsable.
Lucas Mearian : Pour quelles raisons votre entreprise utilise-t-elle ChatGPT ?
Prabhath Karanth : L’IA existe depuis longtemps, mais son adoption dans les entreprises pour résoudre des problèmes spécifiques est passée cette année à un tout autre niveau. Navan a été l’un des premiers à l’adopter. Nous avons été l’une des premières entreprises du secteur des voyages et des dépenses à réaliser que cette technologie allait être disruptive. Nous l’avons adoptée très tôt dans les flux de travail de nos produits… Et aussi dans nos opérations internes.
Workflows produits, opérations internes… Les chatbots utilisés aident-ils les employés à répondre aux questions et les clients aussi ?
Il existe quelques applications du côté des produits. Nous avons un assistant de workload appelé Ava, qui est un chatbot alimenté par cette technologie. Notre produit offre une multitude de fonctionnalités. Par exemple, un tableau de bord permet à un administrateur de consulter des informations sur les voyages et les dépenses de son entreprise. Et en interne, pour alimenter nos opérations, nous avons cherché à savoir comment nous pouvions accélérer le développement de logiciels. Même du point de vue de la sécurité, j’étudie de très près tous les outils qui me permettent de tirer parti de cette technologie. Cela s’applique à l’ensemble de l’entreprise.
Certains développeurs qui ont utilisé la technologie d’IA générative pensent qu’elle est efficace. Ils disent que le code qu’elle génère est parfois absurde. Que vous disent vos développeurs sur l’utilisation de l’IA pour écrire du code ?
Cela n’a pas été le cas ici. Nous avons eu une très bonne adoption par la communauté des développeurs, en particulier dans deux domaines. Le premier est l’efficacité opérationnelle ; les développeurs n’ont plus besoin d’écrire du code à partir de zéro, du moins pour les bibliothèques standard et les outils de développement. Nous constatons de très bons résultats. Nos codeurs sont en mesure d’obtenir un certain pourcentage de ce dont ils ont besoin, puis de construire à partir de là. Dans certains cas, nous utilisons des bibliothèques de code open source – c’est le cas de tous les développeurs – et donc, pour l’obtenir et s’en servir pour écrire du code, c’est un autre domaine où cette technologie est utile. Je pense qu’il y a certaines façons de l’adopter. On ne peut pas l’adopter aveuglément. On ne peut pas l’adopter dans tous les contextes, or le contexte est essentiel.
Utilisez-vous d’autres outils que ChatGPT ?
Pas vraiment dans le contexte de l’entreprise. Du côté des codeurs, nous utilisons également Github Copilot dans une certaine mesure. Mais dans le contexte non-développeur, c’est surtout OpenAI.
Comment classeriez-vous l’IA en termes de menace potentielle pour la sécurité de votre entreprise ?
Je ne dirais pas qu’il s’agit de la menace la plus grave, mais plutôt d’un nouveau vecteur de menace qu’il convient d’atténuer au moyen d’une stratégie globale. Il s’agit de gérer les risques. L’atténuation n’est pas seulement une question de technologie. La technologie et les outils sont un aspect, mais il faut également mettre en place une gouvernance et des politiques sur la manière dont vous utilisez cette technologie en interne et la produisez. Il faut évaluer les risques liés aux personnes, aux processus et à la technologie, puis les atténuer. Une fois que cette politique d’atténuation est en place, le risque est réduit. Si vous ne faites pas tout cela, alors oui, l’IA est le vecteur le plus risqué.
Quels types de problèmes avez-vous rencontré avec des employés utilisant ChatGPT ? Les avez-vous surpris en train de copier et coller des informations sensibles de l’entreprise dans des fenêtres d’invite ?
Chez Navan, nous essayons toujours d’avoir une longueur d’avance ; c’est tout simplement la nature de notre activité. Lorsque l’entreprise a décidé d’adopter cette technologie, l’équipe de sécurité a dû procéder à une évaluation globale des risques… Je me suis donc assis avec mon équipe de direction pour le faire. La structure de mon équipe de direction est la suivante : un responsable de la sécurité des plateformes de produits, qui se trouve du côté de l’ingénierie ; ensuite, nous avons SecOps, qui est une combinaison de sécurité d’entreprise, DLP – détection et réponse ; puis il y a une fonction de gouvernance, de risque, de conformité et de confiance, qui est responsable de la gestion des risques, de la conformité et de tout le reste. Nous nous sommes donc assis et avons procédé à une évaluation des risques pour chaque domaine d’application de cette technologie. Nous avons mis en place certains contrôles, tels que la prévention de la perte de données, afin de nous assurer que, même involontairement, il n’y a pas d’exploitation de cette technologie pour extraire des données, qu’il s’agisse d’IP ou d’informations personnelles identifiables des clients. Je dirais donc que nous avons gardé une longueur d’avance.
Avez-vous encore surpris des employés en train d’essayer de coller intentionnellement des données sensibles dans ChatGPT ?
La méthode DLP que nous appliquons ici est basée sur le contexte. Nous ne faisons pas de blocage général. Nous détectons toujours les choses et nous les traitons comme un incident. Il peut s’agir d’un risque d’initié ou d’un risque externe, et nous impliquons alors nos homologues des services juridiques et des ressources humaines. Cela fait partie intégrante de la gestion d’une équipe de sécurité. Nous sommes là pour identifier les menaces et mettre en place des protections contre elles.
Avez-vous été surpris par le nombre d’employés qui collent les données de l’entreprise dans les invites du ChatGPT ?
Pas vraiment. Nous nous y attendions avec cette technologie. L’entreprise s’efforce de faire connaître cette technologie aux développeurs et à d’autres personnes. Nous n’avons donc pas été surpris. Nous nous y attendions.
Craignez-vous que l’IA générative entraîne une violation des droits d’auteur lorsque vous l’utilisez pour la création de contenu ?
Il s’agit d’un domaine de risques qui doit être abordé. Vous avez besoin d’une certaine expertise juridique pour ce domaine. Nos conseillers juridiques internes et notre équipe de juristes se sont penchés sur la question, et nous avons activé tous nos programmes juridiques. Nous avons essayé de gérer le risque dans ce domaine. Navan a mis l’accent sur la communication entre les équipes chargées de la protection de la vie privée, de la sécurité et des questions juridiques et ses équipes chargées des produits et du contenu sur les nouvelles lignes directrices et restrictions au fur et à mesure qu’elles apparaissent; et les employés ont reçu une formation supplémentaire sur ces questions.
Êtes-vous au courant du problème lié à la création de logiciels malveillants par ChatGPT, intentionnellement ou non ? Avez-vous dû y remédier ?
Je suis un professionnel de la sécurité et je surveille donc de très près tout ce qui se passe du côté offensif. Il y a toutes sortes d’applications. Il y a des logiciels malveillants, il y a de l’ingénierie sociale qui se produit grâce à l’IA générative. Je pense que la défense doit constamment rattraper son retard. J’en suis tout à fait conscient.
Comment surveiller la présence de logiciels malveillants si un employé utilise ChatGPT pour créer du code ? Disposez-vous d’outils logiciels ou avez-vous besoin d’une deuxième paire d’yeux sur tous les codes nouvellement créés ?
Il y a deux possibilités. La première consiste à s’assurer que le code que nous envoyons à la production est sécurisé. L’autre est le risque d’initié – s’assurer que le code généré ne quitte pas l’environnement de l’entreprise Navan. Pour le premier volet, nous disposons d’une intégration continue, d’un déploiement continu – CICD – d’un pipeline de co-déploiement automatisé, qui est entièrement sécurisé. Tout code envoyé à la production fait l’objet d’un code statique au point d’intégration, avant que les développeurs ne le fusionnent avec une branche. Nous disposons également d’une analyse de la composition du logiciel pour tout code tiers injecté dans l’environnement. En outre, le CICD durcit l’ensemble du pipeline, de la fusion à la branche jusqu’au déploiement. En plus de tout cela, nous avons également des tests d’API en cours d’exécution et des tests d’API en cours de construction. Nous disposons également d’une équipe de sécurité des produits qui s’occupe de la modélisation des menaces et de la révision de la conception de toutes les fonctionnalités critiques qui sont livrées à la production. La deuxième partie – le risque d’initié – est liée à notre stratégie DLP, qui consiste à détecter les données et à y répondre. Nous ne procédons pas à un blocage général, mais à un blocage basé sur le contexte, sur de nombreuses zones de contexte. Nous avons obtenu des détections relativement précises et nous avons pu protéger l’environnement informatique de Navan.
Pouvez-vous nous parler d’outils particuliers que vous avez utilisés pour renforcer votre profil de sécurité contre les menaces liées à l’IA ?
Cyberhaven, sans aucun doute. J’ai utilisé des technologies DLP traditionnelles par le passé et le rapport bruit/signal peut parfois être très élevé. Ce que Cyberhaven nous permet de faire, c’est de mettre beaucoup de contexte autour de la surveillance des mouvements de données dans toute l’entreprise – tout ce qui quitte un point d’extrémité. Cela inclut les points d’accès au SaaS, les points d’accès au stockage, autant de contextes. Cela a considérablement amélioré notre protection et notre surveillance des mouvements de données et des risques liés aux initiés. Cette technologie nous a énormément aidés dans le contexte OpenAI.
En ce qui concerne Cyberhaven, un rapport récent a montré qu’environ un employé sur 20 colle des données confidentielles de l’entreprise dans le seul chatGPT, sans parler des autres outils d’IA internes. Lorsque vous avez surpris des employés en train de le faire, quels types de données étaient typiquement copiées et collées qui seraient considérées comme sensibles ?
Pour être honnête, dans le contexte OpenAI, je n’ai rien identifié de significatif. Quand je dis important, je fais référence à des informations personnelles identifiables sur les clients ou sur les produits. Bien sûr, il y a eu plusieurs autres cas de risques d’initiés pour lesquels nous avons dû procéder à un triage et faire intervenir le service juridique pour mener toutes les enquêtes. En ce qui concerne OpenAI en particulier, j’ai vu ici et là des cas où nous avons bloqué l’accès en fonction du contexte, mais je ne me souviens pas d’une fuite massive de données.
Pensez-vous que les outils d’IA générique à usage général finiront par être supplantés par des outils internes plus petits, spécifiques à un domaine, qui peuvent être mieux utilisés pour des usages spécifiques et plus facilement sécurisés ?
Il y a beaucoup de cela en ce moment – des modèles plus petits. Si vous regardez comment OpenAI positionne sa technologie, l’entreprise veut être une plateforme sur laquelle ces modèles plus petits ou plus grands peuvent être construits. J’ai donc l’impression qu’un grand nombre de ces petits modèles seront créés en raison des ressources informatiques que les grands modèles consomment. Le calcul deviendra un défi, mais je ne pense pas qu’OpenAI sera dépassé. Il s’agit d’une plateforme qui vous offre une certaine flexibilité quant à la manière dont vous souhaitez développer et à la taille de la plateforme que vous souhaitez utiliser. C’est ainsi que je vois les choses se poursuivre.
Pourquoi les entreprises devraient-elles croire qu’OpenAI ou d’autres fournisseurs SaaS d’IA n’utiliseront pas les données à des fins inconnues, telles que l’entraînement de leurs propres grands modèles de langage ?
Nous avons un accord d’entreprise avec eux, et nous avons choisi de nous en retirer. Nous avons pris de l’avance d’un point de vue juridique. C’est la norme pour tout fournisseur de services cloud.
Quelles mesures conseilleriez-vous à d’autres RSSI de prendre pour sécuriser leurs entreprises contre les risques potentiels posés par la technologie IA générative ?
Commencez par l’approche des personnes, des processus et des technologies. Effectuer une évaluation de l’analyse des risques du point de vue des personnes, des processus et de la technologie. Faites une évaluation globale et holistique des risques. Ce que je veux dire par là, c’est qu’il faut examiner votre adoption globale : allez-vous l’utiliser dans les workflows de vos produits ? Si c’est le cas, il faut que le directeur technique et l’équipe d’ingénieurs soient des acteurs clés de cette évaluation des risques. Il faut bien sûr que le service juridique soit impliqué. Vous devez impliquer vos homologues chargés de la sécurité et de la protection de la vie privée. Il existe également plusieurs cadres déjà proposés pour effectuer ces évaluations des risques. Le NIST a publié un cadre d’évaluation des risques liés à l’adoption d’un tel système, qui aborde pratiquement tous les risques à prendre en compte. Vous pouvez ensuite déterminer celui qui s’applique à votre environnement. Il faut ensuite mettre en place un processus de surveillance continue de ces contrôles, afin de couvrir le tout de bout en bout.