DevOps : les conseils de la CTO de GitLab pour adopter l’IA
Sabrina Farmer, CTO de GitLab, fournit un ensemble de points d’orientation afin de favoriser la bonne adoption de l’IA dans les équipes de développement. Au vu des gains observés, les développeurs risquent de ne plus pouvoir faire sans.
Outre le fait d’infuser l’IA générative dans sa plateforme DevSecOps, GitLab l’adopte pour ses besoins internes. À la tête de cette initiative, sa directrice technique, Sabrina Farmer.
La CTO, ancienne vice-présidente de l’ingénierie SRE et Core Infrastructure chez Google, est persuadée que l’IA générative apporte des gains de productivité. Elle l’aurait prouvé en interne.
« Nous constatons que les équipes qui perçoivent l’IA comme une opportunité progressent plus rapidement », assure-t-elle. « Ces équipes apprennent plus efficacement, identifient les problèmes de sécurité de manière proactive et interagissent différemment avec leur code ».
Puisque les révisions de code préliminaires sont effectuées par un LLM, les ingénieurs seraient capables d’identifier non pas des problèmes de syntaxes, mais des soucis liés aux dépendances. « Pour quelqu’un qui comprend réellement comment son application fonctionne, il s’agit de lui permettre de se concentrer sur ces tâches à valeur ajoutée », défend la directrice technique.
Pourtant, de premières études et certains développeurs remarquent qu’ils perdent du temps à corriger les erreurs ou les bugs générés par l’IA, que les gains de temps fondent à cause d’enjeux organisationnels, tandis que les primo-adoptants d’agents IA ne perçoivent pas de gain en matière de collaboration.
Trouver les bons périmètres de déploiement
« N’essayez pas de tout changer en même temps. Concentrez-vous vraiment sur la proposition de valeur. »
Sabrina FarmerCTO de GitLab
Ce serait en cherchant à résoudre des points de friction spécifiques, à l’échelle de l’équipe, que les entreprises peuvent tirer les bénéfices de l’IA, selon Sabrina Farmer. « N’essayez pas de tout changer en même temps. Concentrez-vous vraiment sur la proposition de valeur », recommande-t-elle. Revue de code préalable, conversion de pipelines CI/CD, génération de snippets de code, validation par rapport à des règles métiers ou de conformité… peu importe l’usage, tout doit être cantonné à un périmètre restreint.
« Soyez très critique quant à la manière dont vous l’appliquez. Ceux qui l’utilisent pour modifier l’entièreté d’une base de code, pour tous les aspects de la sécurité, et qui pensent qu’à l’avenir ils n’auront plus besoin d’embaucher des ingénieurs prennent un risque énorme », poursuit-elle.
« Vous pouvez vibe coder et créer quelque chose qui semble fonctionner. Mais cela ne veut pas dire que cela protège les données des utilisateurs et que l’application tient la charge avec des milliers, voire des millions de connexions concurrentes ».
De même, les LLM seraient plus utiles pour les ingénieurs afin de simplifier leur documentation et de la rendre accessible à une plus large audience (ou à différents rôles) qu’à la générer entièrement.
Or les gains ne doivent pas se limiter aux développeurs. GitLab applique cette approche à l’échelle du projet : un espace de partage du code, de la configuration CI/CD, des issues ou encore des Merge Requests (équivalent des Pull Requests chez GitHub).
« Lorsque vous disposez d’une grande diversité d’outils, la charge cognitive est élevée. [...] « Vous ne pouvez pas contrôler tous ces environnements logiciels différents. »
Sabrina FarmerCTO de GitLab
Chaque développeur peut bénéficier d’une assistance pour des charges de travail définies et partagées par tout ou partie d’une équipe. Le préalable, selon GitLab et sa CTO, est de mettre une plateforme de génie logiciel unifiée. « Lorsque vous disposez d’une grande diversité d’outils, la charge cognitive est élevée. Vous choisissez de constituer des équipes responsables, de suivre toutes ces intégrations et de gérer ces logiciels. Et rien de tout cela ne contribue directement à votre activité », argue celle qui a poussé l’unification des piles technologiques chez Google.
En outre, Sabrina Farmer ne pense pas que les développeurs devraient avoir le choix de l’assistant ou de l’agent. C’est contraire à la philosophie DevOps des origines, mais le fait de laisser les développeurs choisir leur outil « est devenu un risque pour les entreprises ». Une opinion qui, selon elle, est répandue depuis cinq ans. « Vous ne pouvez pas contrôler tous ces environnements logiciels différents ».
Ainsi, la mise en place « d’une armée d’agents IA » serait, actuellement, contre-productive. Toutes les tâches communes aux membres d’une équipe DevOps ne peuvent être concernées. « D’une, vous dépensez probablement trop d’argent, de deux, vous risquez de réduire la qualité des résultats produits », alerte Sabrina Farmer.
D’autant que les scripts et les autres méthodes d’automatisation demeurent valables.
« Les agents IA sont extrêmement utiles pour tout ce qui nécessite un “raisonnement”, de la planification semi-autonome », signale la directrice technique. « Je pense que les gens se trompent en pensant qu’ils peuvent automatiser toutes les tâches à leur place. Il existe en réalité de nombreuses autres façons moins coûteuses d’automatiser les flux de travail, surtout quand ils sont prévisibles ».
Dans tous les cas, un contrôle et une supervision accrus s’imposent. « Les modèles changent d’un mois à l’autre, ils ne sont pas 100 % statiques. Il faut donc encore beaucoup de surveillance lors de l’implémentation de l’IA. Chez GitLab, nous avons toujours un humain dans la boucle », illustre la directrice technique.
L’IA ne remplacera pas les développeurs… s’ils consentent à l’adopter
« [L’IA] va changer la manière dont les équipes d’ingénieurs travaillent, ce qui ne va pas nécessairement entraîner une diminution des emplois [...]. »
Sabrina FarmerCTO de GitLab
Si l’équipe et l’application de l’IA à des tâches spécifiques sont les bonnes échelles, certaines décisions doivent être imposées à plus haut niveau, d’après Sabrina Farmer. « L’argument consistant à dire qu’ils vont gagner du temps, qu’ils peuvent réinvestir dans des tâches plus valorisantes, est apprécié des développeurs », assure-t-elle.
En revanche, l’adoption, comme avec tout outil de développement, est parfois complexe. « Concernant la révision de code, je constatais une différence de productivité marquée entre les équipes qui utilisaient l’IA et celles qui ne l’utilisaient pas. J’ai dû l’imposer ».
Est-ce à dire que l’IA remplacera les développeurs ? Sabrina Farmer n’y croit pas. « Je pense que cela ne nous rend pas service lorsque des médias racontent que l’IA remplacera les développeurs », lance-t-elle. « Elle va changer la manière dont les équipes d’ingénieurs travaillent, ce qui ne va pas nécessairement entraîner une diminution des emplois, à moins que ces équipes d’ingénieurs ne cherchent à maintenir le statu quo ».
Pour approfondir sur IA appliquée, GenAI, IA infusée
