Faut-il recruter des IAs pour développer ?

L’année 2023 marque le retour en force de l’intelligence artificielle avec la démocratisation des IA génératives. La crainte que ces IAs ne viennent supplanter l’humanité réapparaissent et certains concepteurs de ces mêmes IA appellent même à un moratoire de leur développement et de leur utilisation. L’origine de ces craintes provient probablement du fait que ces IA génératives ouvrent des perspectives d'évolution dans des domaines jusqu’ici peu touchés par l’automatisation. Des prévisions (certains diront des spéculations) plus ou moins cohérentes sur les gains de productivité et l’impact que cela aura sur les métiers fleurissent dans les magazines et les blogs. En particulier, cette étude de McKinsey portant sur 16 lignes métiers montre que le software engineering est clairement un domaine qui sera fortement impacté par l’IA générative.

La révolution de l’IA dans le développement de code n’a pas attendu le buzz de chatGPT. La société TabNine est créée en 2017 et dès 2018 Microsoft lance Intellicode, puis copilot en 2022. AWS joint aussi le mouvement avec AWS Whisper. Tous ces outils sont opérationnels et utilisés.

Les évolutions récentes des Large Language Models (LLM) ont rendu ces outils de plus en plus puissants posant la question de leur généralisation et de leur mode de commercialisation. La société Kite a dû mettre la clé sous la porte faute de ne pas avoir réussi cette transformation.

Effet de mode, évolution ou révolution, est ce que bientôt il y aura moins de développeurs chez OCTO Technology ? Quels gains peut-on attendre, est-ce que la qualité va s’en ressentir ? Comment les équipes vont-elles accueillir ces outils ? Faut-il les former ? Quels risques y a t il à utiliser ces outils ? C’est à toutes ces questions que nous allons répondre dans cet article.

Cet article n’est pas de la prospective, il est le résultat mesuré de l’expérience des développeurs OCTO de tout niveau (junior, senior) et sur différentes technologies (back, front). Il est principalement basé sur l’utilisation de GitHub Copilot, une des principales technologies utilisées dans les entreprises.

L'IA au chevet du développeur

L’arrivée de l'IA générative dans le domaine du développement logiciel se traduit par l'avènement d’outils qui permettent d’assister le développeur dans l’écriture de code au sens large : code, commentaire, données, revues de code, revue de sécurité etc.. Les principaux outils utilisables de manière opérationnelle par les développeurs sont  GitHub Copilot, AWS Whisper et Tabnine. Ces outils s'installent dans les outils de développements (IDE) et transforment  la façon dont les développeurs créent du code en leur fournissant une assistance intelligente en temps réel.

Copilot

JetBrain AI

TabNine

Amazon

L’utilisation de ces outils n’est pas gratuite, il faut compter en moyenne entre 10$ et 20$ par mois et par utilisateur pour une utilisation en entreprise. Des plans gratuits pouvant être mis à disposition de catégories d’utilisateurs : étudiants, individuels, contributeurs…

Ces outils proposent aux développeurs une saisie semi-automatique du code. Ils fonctionnent sur le principe de l’autocomplétion pendant que le développeur écrit le code. Ils sont directement intégrés à l’éditeur de code (IDE).  Il est possible de recevoir des suggestions de diverses manières, soit en commençant à écrire le code, soit en rédigeant un commentaire en langage naturel, ce que vous voulez que le code fasse. Les outils s’adaptent au contexte du code que vous êtes en train d’écrire, ainsi qu’au code dans les fichiers associés ou ouverts dans votre IDE.

Certains outils permettent aussi de faire des demandes via une interface de type chatGPT. En particulier Copilot X, permet de faire des requêtes (prompts) en langage naturel, ouvrant ainsi la voie à de nouveaux cas d’usages comme la recherche de bug ou le refactoring.

Ces outils fonctionnent comme un assistant toujours là, suggérant continuellement des morceaux de code. Le développeur reste maître d’accepter, refuser ou modifier les suggestions. C’est à lui de contrôler la validité des suggestions. L’enjeu est donc que la pertinence des suggestions soit suffisamment bonne afin que ces suggestions aident le développeur sans le perturber.

Ces outils utilisent des LLMs, en particulier Copilot utilise l’intelligence artificielle de OpenAI. Ces outils ont été entraînés sur des bases de codes publiques et parfois privées (par exemple AWS Whisper) et sont capables de reconnaître les langages de programmations les plus populaires (Java, Javascript, Python….). Outre qu’ils soient directement intégré à l’IDE, la différence majeure avec chatGPT est que ces outils intègrent automatiquement à leur contexte le code en train d’être développé et sont spécialisés dans les opérations liées au développement : écriture de code, de commentaires, de code de test, de fichiers de données, explication de programme, analyse de sécurité, analyse de bug, recommandations....

Cas d’usages et pertinence

Les principaux cas d’usage mis en œuvre par nos développeurs sont les suivants :

• Ecrire du code à partir d’un commentaire

• Créer des méthodes de tests

• Créer des jeux de tests

• Générer des readme

• Créer du code sur un modèle

• Analyser un morceau de code

• Optimiser un morceau de code

• Déboguer un morceau de code

Le retour d’expérience est très positif, même s’il est nécessaire de garder un esprit critique et de faire des ajustements pour avoir un code opérationnel qui convient au besoin. En dehors de la sensibilisation aux limites de l’outil, il n’y a pas d’apprentissage à faire. La prise en main de l’outil est très intuitive.

On constate que le bénéfice est variable suivant la qualité du code : plus le code est de qualité, homogène, respecte les standards et bonnes pratiques de programmation, plus l’outil sera pertinent.

On constate que le bénéfice dépend aussi du type de code qui est développé. Voyons cela plus en détail.

• Tout d’abord un outil d’IA générative nous facilite grandement la vie lors de tâches rébarbatives, tel que la mise en place d’un CRUD basique. Nous aurons peu de retouche à faire, et son accompagnement dans les tests unitaires est formidable, surtout sur de la génération de données de tests.

• Côté front, sa faiblesse se fait aujourd'hui ressentir sur l’écriture de test utilisateur, ainsi que sur le CSS dans certains cas. Dans un contexte d’entreprise, où les exigences graphiques sont données, l’outil sera plus un perturbateur qu’un facilitateur.

• La génération des readme permet d’avoir une première version avec un niveau de langage très correct (en français ou en anglais) qu’il est ensuite possible d’enrichir.

• L’outil est aussi très performant sur de la génération de “data”, par exemple pour les fichiers d’internationalisation ou encore pour des données de test.

• Cette facilitation de l'écriture peut aussi réduire les obstacles à l’adoption de certaines pratiques qui peuvent être jugées rébarbatives. Ex : Écriture de doc, Augmentation du nombre de tests

• Lorsqu’un développeur doit utiliser une librairie pour un besoin ponctuel, l’outil permet d’écrire du code avec une syntaxe correcte sans devoir aller chercher des exemples sur le Web (stack overflow ou documentation des bibliothèques). Cela est d’autant plus utile avec des stacks techniques comme le javascript qui utilisent de nombreuses bibliothèques qui évoluent fréquemment. Dans ces usages les outils de GenIA apportent une fluidité au développeur qui n’est plus bloqué par les “détails” syntaxiques.

• Les outils fonctionnent sans problème  même si on utilise le français dans les commentaires ou les noms des objets (méthodes, variables…)

Une efficacité qui varie suivant les langages et framework utilisés

En conclusion, notre retour d’expérience montre un intérêt important du point de vue du développeur à l’utilisation de ces outils dans de nombreux cas d’usages du développement. Nous allons voir quels sont les gains et les risques

Gains de productivités

L'une des forces des outils de génération de code et en particulier Copilot est sa capacité à suggérer des lignes de code en fonction du contexte. Nos développeurs ont constaté un gain non négligeable sur une journée de développement, ce gain pouvant aller au delà de 10% suivant les taches effectuées.

Cependant cela dépend énormément de la pertinence des suggestions et donc, comme vu plus haut, du type de code qui est écrit. Dans une journée type un développeur fera, entre autres activités, des recherches sur des forums (ex. stackoverflow), lira de la documentation (ex API stripe..), construira un code passe partout (boilerplate) ou encore vérifiera la syntaxe d’un framework. Ces activités s'exécutent dans des outils/onglets différents. Copilot peut aider à en adresser une bonne partie sans que le développeur ne quitte son IDE.  En regroupant ainsi plusieurs choses au même endroit Copilot réduit le context switching et facilite la concentration pour l'écriture du code.

Certaines tâches de développement comme la génération de données de tests sont rébarbatives et n’ont que peu voire aucun intérêt intellectuel pour les développeurs. Par exemple, un développeur peut aisément demander à Copilot de créer une centaine d'entrées dans une  table CLIENT avec nom, prénom, date de naissance, genre et profession. Outre le temps gagné, cette délégation aide à  réduire la charge mentale liée aux tâches fastidieuses ou répétitives.

En créant une nouvelle expérience de développement, l’utilisation de Copilot aide à se concentrer davantage sur la valeur ajoutée du code. Les gains de productivité apportés par une réduction de la charge mentale sont difficiles à mesurer sans étude sur le long terme.

On observe donc des gains de productivité, mais ces gains ne sont rien si la qualité n’est plus au rendez-vous.

Amélioration de la qualité du code

Lors d’un développement logiciel le point le plus important (en tout cas chez OCTO ;-))  est la qualité du code. Une bonne productivité en termes de “features” qui se fait au détriment de la qualité du code est une bombe à retardement. C’est un phénomène très connu sous le terme de dette technique voire de code spaghetti dans les cas les plus critiques !

Est-ce que ces outils peuvent nous assister sur cet aspect ?

Notre retour d’expérience est que ces outils ne dégradent ni n’améliorent la qualité du code. La raison provient de deux facteurs. D’une part, le code produit l’est à partir d’exemples sur gitHub qui ont un niveau “standard” de codage, on obtient par conséquent un code tout à fait classique. Le second facteur est qu’au final le seul juge est le développeur, un développeur ne doit pas accepter du code qu’il juge de mauvaise qualité. De plus, dans les bonnes pratiques telles que celles appliquées chez OCTO, le code généré comme le code non généré doit être revu par un autre développeur avant d’être versé à la branche principale (PR/MR). Une piètre qualité de génération amènera donc une baisse de la productivité mais pas de la qualité tant que l’équipe suit des processus solides de développement de code de qualité.

Le risque pourrait être que les développeurs “perdent” globalement leur sens critique pour diverses raisons : flemme, force de l’habitude, sur-confiance en la machine, pression à produire**.** Pour le moment nous avons constaté l’inverse : les développeurs, y compris les plus juniors sont sensibles à leur responsabilité et l’exigence de qualité qu’ils doivent avoir autant vis à vis de leur code que vis à vis du code généré par un outil.

Limites & Risques

Comme précisé précédemment il est fondamental que les développeurs qui utilisent ces outils soient conscients des limites de l’outil et gardent leur sens critique. Actuellement, les outils ne sont pas suffisamment fiables/élaborés pour pouvoir générer du code sans validation humaine.  L'outil peut parfois se tromper ou mal interpréter les intentions du développeur. Il arrive qu’il propose des suggestions inappropriées, comme des champs, des noms de classe ou de méthodes qui ne sont pas totalement pertinents ou qui ne suivent pas les normes du projet. Tout cela n’est pas un obstacle rédhibitoire à  l’utilisation de l’outil tant que les générations sont globalement satisfaisantes.

La sensibilisation des développeurs et l’utilisation d’outils et de méthodologies de contrôle de qualité permet de détecter le mauvais code : qu’il ait été généré par un outil ou par un humain. Par exemple, la mise en place de Linters, d’outils de mesure de qualité de code comme Sonar et bien sûr des processus de ‘pair reviewing’ avant merge.

Un autre risque est lié à l’utilisation d’un outil d’IA dans des contextes non adaptés. La lecture de suggestions non pertinentes ou bien l'acceptation de suggestions qui nécessitent beaucoup de modifications peut être contre-productive. La plupart des outils permettent d’activer/désactiver manuellement la suggestion, ce qui n’est pas idéal si l’on travaille sur du code composite (par exemple du Vue qui mélange code de type HTML,JS et CSS).

Deux autres risques sont communément évoqués lors de l’utilisation d’intelligence artificielle : la violation du copyright et la fuite de code ou de données.

La violation du copyright ne peut arriver que sur des morceaux de code qui seraient génériques (algorithmes par exemple) et qui en général contiennent de nombreuses lignes. Dans les autres cas, il n'y a rien de nouveau : copilot fait la même chose qu’un développeur qui s’inspire de quelques lignes de code sur stack overflow pour les adapter à son contexte. Le conseil est donc d’éviter ou au moins d’être vigilant quand l’outil propose des méthodes longues. AWS Whisper a un outil de détection qui lui permet de reconnaître du code suggéré qui est similaire à du code de sa base d’apprentissage et qui est par conséquent soumis à du copyright. AWS Whisper donne le lien sur le code et le type de licence. Même si cette détection n’est pas garantie à 100% c’est un niveau supplémentaire de garde-fou.

La fuite des données est prise en compte par l’outil. Il est possible de paramétrer l’outil pour qu’il ne conserve pas les bouts de codes ‘snippets’ de l’application en cours de développement. Il est aussi possible par paramétrage de limiter les fichiers qui sont éligibles au contexte (fichiers de variables d’environnement par exemple qui pourrait contenir des mot de passe ou des IPs). Il existe toutefois un risque résiduel que les snippets soient “capturés” au moment où ils sont sur le serveur. L’impact de ce type de fuite peut être largement mitigé en suivant des règles sécurisées de développement : pas de mot de passe dans le code, pas de données de production (user, credentials) dans le code. Ce sont les mêmes pratiques que celles qui permettent de se prémunir de fuites de données via les outils de gestion de code sources.

Conclusion

En permettant aux développeurs de gagner du temps via des suggestions pertinentes, une limitation du contexte switching et de leur charge mentale, les outils comme copilot apportent une nouvelle expérience aux développeurs ainsi que des gains de productivité qui couvrent largement les coûts d’abonnement. Ces gains de productivité vont encore progresser car ces outils sont en forte évolution.

De nombreux développeurs nous ont indiqués qu’ils ne pourraient plus s’en passer tant ces outils aident dans les tâches de peu d'intérêt. L’accueil des développeurs n’est toutefois pas homogène, certains se sentant menacés par une technologie qui effectue une partie de leur travail. Ces outils modifient effectivement la manière de travailler et le type de tâches qu’ils vont effectuer. Cependant cette crainte reste infondée car ces outils permettent d’accompagner le développeur mais ne sont pas assez puissant pour fonctionner sans eux ! L’avenir est déjà en marche avec l’intégration opérationnelle de ces outils dans les principaux éditeurs du marché et une adoption en hausse. Un signe est que JetBrains est en train de proposer sa propre solution pour son IDE vedette IntelliJ. Il est fort à parier que les IA de génération de code seront la norme de demain.

Les développeurs doivent-ils avoir peur de l’IA comme Dave dans “2001, l'Odyssée de l’espace” ?