L’IA générative pour les ESN ? « Une lourde évolution, pas une révolution » (Sopra Steria)

Quatre outils de génération de code en test chez Sopra Steria

LeMagIT : Est-ce pour obtenir des suggestions de code ou en générer ?

Mohammed Sijelmassi : Nous avons déjà des solutions de suggestion de code, donc nous sommes plutôt intéressés par la génération de code. En matière de suggestion, ce qui pourrait être intéressant c’est que l’outil génère des propositions en lien avec l’infrastructure cible, notamment dans le cadre de projet cloud. Je pense que nous allons progressivement voir apparaître des solutions d’IA générative qui répondent à des enjeux spécifiques de l’ingénierie logicielle. Nous testons CodeWhisperer, GitHub Copilot, Gitlab Codey, et StarCoder (HuggingFace) pour sa nature open source.

LeMagIT : Un outil comme Tabnine ne vous intéresse-t-il pas ?

Mohammed Sijelmassi : Moyennement. Chez nous, il faut que l’outil s’inscrive pleinement dans nos chaînes CI/CD. Je ne cherche pas à donner accès à tous les outils aux développeurs. Je préfère un outil 10 % moins performant, mais qui est complètement transparent pour le développeur.

« Je ne cherche pas à donner accès à tous les outils aux développeurs. Je préfère un outil 10 % moins performant, mais qui est complètement transparent pour le développeur. »

Au début, beaucoup des outils que nous avons testés affichaient une belle fiche de spécifications, mais l’expérience utilisateur n’y était pas. Sachant que nos sujets principaux sont la génération de code, la redocumentation, la génération de tests et que nous pensons, à un horizon de deux ans, passer de la génération du requirement [les premiers éléments de documentation pour formaliser un projet logiciel, N.D.L.R.] à celles des patterns d’architecture.

Ce sont des règles qui sont écrites dans des livres, dans de la documentation. Les modèles d’IA générative peuvent s’en servir aisément pour générer des patterns. Cela prendra un peu de temps, car cela demande de faire évoluer les équipes et les processus qui sont aujourd’hui très structurés et séquencés. L’idée est que celui qui conçoit une architecture peut en générer la structure. Évidemment, les plus jeunes s’adaptent plus rapidement, tandis qu’il y a une courbe d’apprentissage plus lente à anticiper avec des collaborateurs plus seniors. Cela ne posera toutefois pas de problèmes métaphysiques.

À la fin de l’année (2023), nous avons déployé les quatre outils [CodeWhisperer, GitHub Copilot, Gitlab Codey, et StarCoder, N.D.L.R.] et nous équipons progressivement les équipes. Nous voulons mesurer et observer ce que cela leur apporte.

Étant donné le coût des solutions en question – parce qu’il faut aussi compter les intégrations avec les autres outils –, il est impératif qu’elles engendrent une amélioration notable de la productivité. Au total, cela représente une dépense d’une centaine de dollars par mois par développeur. Si nous gagnons une demi-journée de productivité, l’investissement est amorti. S’ils apportent satisfaction, à échéance de 15 à 18 mois, le recours à ces outils sera la norme.

LeMagIT : Est-ce une révolution ou une évolution ?  

Mohammed Sijelmassi : Pour les clients, sûrement. Pour nous, c’est une lourde évolution, pas une révolution. Nous sommes habitués à ce genre de changement.

La difficulté, c’est que cela à l’air tellement facile que l’on peut finir par faire n’importe quoi. Il faut que les outils de génération de code soient encadrés par des processus de développement définis par des ingénieurs expérimentés.

LeMagIT : Les éditeurs de solutions DevOps tels GitHub, GitLab et bien d’autres intègrent de plus en plus d’outils et de processus, qui, in fine, peuvent servir à encadrer l’usage des outils de génération de code. Cela ne va-t-il pas influencer l’évolution des chaînes CI/CD ? Quels outils choisir finalement ?

C’est vrai qu’il peut y avoir des chevauchements de fonctionnalités. Par exemple, GitLab conçoit de bonnes fonctions de sécurité, mais nous utilisons aussi Checkmarx. Il est fort probable que les solutions se recoupent. Notre travail est de déterminer quels sont les maillons qui formeront nos chaînes CI/CD. C’est important, car nous devons assurer un niveau de qualité, peu importe les outils en place. Plutôt que de choisir des solutions, notre travail consiste à définir une standardisation des processus dans 90 % des cas. C’est un effort en cours au regard des outils de génération de code. Cela demande un peu de temps.

Nous devons tout de même agir rapidement, car nos clients nous demandent dans quelles mesures cela peut impacter les coûts et leurs projets. Dans les dix-huit prochains mois, j’estime que les gains de productivité s’observeront dans la qualité du code produit. Là où l’on ne faisait pas tous les tests par manque de temps, il sera plus évident de les exécuter.

En ce qui concerne la détection de problèmes dans le code, il y a historiquement un frein pour les ESN qui travaillent sur du code qu’elles n’ont pas rédigé. Si je peux obtenir un commentaire automatique du code, si je peux l’interroger, les outils d’IA générative sont d’une aide précieuse.

Peu importe si le code a été rédigé par un développeur ou généré par un LLM, ces mêmes outils peuvent aider à la génération automatique de la maintenabilité. Il suffit pour le développeur d’interroger l’assistant afin d’obtenir une liste de points au regard de la dette technique potentiellement engendrée. Bien utilisés, les outils de génération de code sont véritablement collaboratifs.

Enfin, l’écriture/la génération du code représente 30 % d’un projet complet d’ingénierie logicielle. Le coût d’un projet ne se limite pas exclusivement à sa phase de développement, mais englobe l’ensemble de son cycle de vie. Il y a beaucoup d’efforts à mener en matière de déploiement, d’établissement, de la rigueur des processus, et de maintenabilité.

Encore aujourd’hui, certains projets ne sont pas très chers à développer, mais coûtent une fortune à maintenir, car la moindre modification « casse » le système. Nous voulons mettre en place des outils pour vérifier la santé du code et l’application des processus, au lieu de revenir sans cesse à la documentation.

Les DSI interrogent Sopra Steria sur l’adoption de l’IA générative

LeMagIT : Que dites-vous aux clients qui voudrait adopter eux aussi adopter les outils d’IA générative ?

Mohammed Sijelmassi : Nos clients nous interrogent sur trois aspects.

« Beaucoup de choses qui se disent aujourd’hui sur l’IA générative ne sont pas bonnes à mon sens, parce que l’on cherche à automatiser des choses qui existent. »

Premièrement, ils veulent savoir comment faire : « comment puis-je déployer ce type d’outil en interne ? ». Nos clients sont des DSI. Ils se posent forcément des questions sur la ou les technologies à adopter.

Ils se demandent s’il est nécessaire ou non de fine-tuner des modèles en interne. Dans des secteurs très réglementés, c’est plutôt conseillé. Dans d’autres, moins. Ils ont donc des questions sur la protection des données et sur la propriété intellectuelle. Notre direction juridique nous aide à y répondre.

Deuxièmement, ils s’interrogent sur la manière de mettre ses outils dans les mains de leurs équipes. Dans ce cas-là, nous partageons nos expériences afin de déterminer dans quelles situations l’IA générative est intéressante.

Troisièmement, ils s’interrogent sur des aspects métiers : « qu’est-ce que cela change pour moi ou mes collaborateurs ? ». Aujourd’hui, l’on a tendance à tout mettre dans la panière « GenAI » alors que les modèles de machine learning existent et sont en production depuis des années. En revanche, l’aspect conversationnel est très important.

Beaucoup de choses qui se disent aujourd’hui sur l’IA générative ne sont pas bonnes à mon sens, parce que l’on cherche à automatiser des choses qui existent. L’on ne va pas remplacer des automatisations et au mieux économiser l’intervention de trois demi-postes. Ce n’est pas le sujet. Le véritable enjeu, c’est de faire différemment.

« L’on ne va pas remplacer des automatisations et au mieux économiser l’intervention de trois demi-postes. Ce n’est pas le sujet. Le véritable enjeu, c’est de faire différemment. »

Aujourd’hui, si vous discutez avec un directeur métier de supply chain, il vous dira que l’utilisation de l’IA pour automatiser le transfert de fichiers n’est pas très utile. En revanche, si cela l’aide à prendre la meilleure décision possible lors d’une rupture de la chaîne logistique, alors il sera intéressé.

De la même manière, dans le monde bancaire, vous avez la possibilité d’embrasser des changements d’habitude des clients. Certains d’entre eux s’interrogent sur des projets d’investissements et n’ont pas forcément le temps de prendre rendez-vous avec un conseiller sur leurs horaires de bureau. Ceux-là peuvent vouloir obtenir une expérience proche de celle qu’ils auraient avec un conseiller en placement en dehors des heures d’ouverture.