De plus en plus de logiciels de génération automatique de code émergent. Mais comment et pourquoi des développeurs décident de leur faire confiance, ou non ?

Avec l'avènement de grands modèles de langage comme le fameux GPT3.5 utilisé par ChatGPT, un nombre croissant de logiciels de génération automatique de code – Copilot de Github, CodeT5 de SaleForce, AlphaCode de DeepMind ou encore PolyCoder de l'Université Carnegie Mellon University – sont apparus comme de nouveaux outils proposés aux développeurs pour accélérer leur productivité. Ces logiciels s'adaptent au projet en cours en analysant le code déjà écrit pour proposer du code adapté.

• L'IA AlphaCode de DeepMind serait aussi bonne (ou mauvaise) qu'un développeur humain moyen
• Le Copilot de GitHub disponible en version finale et payante

Mais pour choisir l'un d'entre eux, les développeurs doivent leur accorder leur confiance. Comment un outil de ce type acquiert une confiance suffisamment forte pour être adopté par des ingénieurs dont les projets sont parfois très critiques ?

En 2021, David Gray Widder, chercheur de l'Université Carnegie Mellon de Pittsburgh, et ses collègues ont présenté à la conférence scientifique CHI Conference on Human Factors in Computing Systems, une étude se penchant sur la question. Cette recherche peut permettre d'avoir une grille d'analyse plus objective des qualités et défauts de ce genre de logiciels.

Une étude ethnographique à la NASA

Si ces outils commencent à être de plus en plus répandus, la NASA en avait déjà créé un en 2017.

David Gray Widder a passé dix semaines au sein d'une équipe de la NASA pour étudier comment les ingénieurs apprennent à faire confiance à un outil de génération de code automatisé pour des fonctionnalités essentielles.  Ces ingénieurs utilisaient, à l'époque, un cadriciel (framework) pour les aider à écrire des logiciels destinés aux missions spatiales. David Gray Widder et ses collègues ont donné le pseudonyme de Chief à ce cadriciel afin d'anonymiser leur objet de recherche. Dans Chief, un système autonome et déterministe (contrairement aux grands modèles de langage) génère du code C++ de bas niveau à partir de fichiers XML créés par les ingénieurs.

Les auteurs expliquent bien, qu'ici, « les règles de génération ont été créées et approuvées par des ingénieurs expérimentés en logiciels de contrôle afin de s'assurer qu'elles n'introduisent pas elles-mêmes des erreurs », ce qui n'est pas le cas des outils basés sur les grands modèles de langage. Mais nous pouvons quand même en tirer quelques informations sur la confiance et l'acceptation de l'utilisation de logiciels d'aide à la génération de code. Les chercheurs résument d'ailleurs leur article à une réponse à la question « Comment se développe la confiance des ingénieurs logiciels dans un outil automatisé dans un contexte à fort enjeu ? ».

David Gray Widder a utilisé plusieurs méthodes d'anthropologie pour creuser la question, des entretiens en face à face, des entretiens de groupes, des exercices de « pensée à voix haute » effectués par les ingénieurs et de l'observation participante en assistant à des réunions d'équipe.

Ressortent de ces dix semaines de terrain certains besoins pour qu'un outil de génération de code automatisé soit bien accepté au sein d'une équipe d'ingénieurs travaillant sur des projets critiques.

Besoin de transparence et de facilité d'utilisation

Pour que ces ingénieurs fassent confiance à Chief, il leur faut des retours d'information du logiciel et la possibilité de comprendre comment il fonctionne. Certains se sont plaint de devoir relire le code généré pour comprendre ce qu'il faisait.

Par exemple, l'un d'eux explique à David Gray Widder que « le contexte dans lequel un port est appelé est déroutant. Je n'ai compris qu'en lisant le code autogénéré pour comprendre ce qui se passe ». Une documentation du fonctionnement et de l'utilisation de l'assistant est aussi importante pour ces utilisateurs, ainsi qu'un temps d'entrainement à son utilisation. Certains ont eu besoin de s'acclimater à son utilisation et développer un « sixième sens » pour discriminer ce que Chief arrivait bien à faire et ce qu'il fallait relire et tester.

Pour que les ingénieurs se sentent à l'aise pour l'utiliser, le système doit aussi être le plus intuitif possible et, si des bugs sont connus, qu'ils soient le plus documentés possibles. Ces observations sont assez évidentes et communes pour tout logiciel. Plus spécifique à ce genre d'outil, David Gray Widder relève que les ingénieurs de la NASA ont soulevé des problèmes de conformation aux standards dans le système (notamment, Chief n'intégrait pas le concept de sérialisation de la manière standard).

Contexte social et processus d'intégration

Mais David Gray Widder et ses collègues montrent que la confiance envers un système de génération automatique de code ne se crée pas seulement avec l'utilisation de l'outil en lui-même. Elle dépend aussi des interactions des autres membres de l'équipe et d'autres utilisateurs avec le logiciel.

Chief est composé de plusieurs parties. Et plus une partie était utilisée par d'autres, plus les ingénieurs de la NASA se fiaient à elle : « plus il y a d'yeux, plus je ferai confiance dans sa solidité », témoigne un des participants.

Celle-ci s'acquiert aussi par la connaissance des personnes qui ont codé le logiciel. L'un d'eux explique, par exemple, accorder du crédit à Chief « parce que je travaille avec des personnes très intelligentes qui travaillent dessus ».

Mais elle peut s'effondrer si un ingénieur se sent « trahi », parce qu'il a laissé passer une erreur évidente faite par le système et qui se répercute sur son image auprès de ses collègues.

Pour les ingénieurs, le processus d'intégration du système au sein de la NASA joue aussi. La mise en place de tests formels avant son adoption, puis son utilisation dans une mission spatiale réussie permettent une plus grande confiance. La création d'une « zone sûre » du logiciel, rassemblant les fonctionnalités qui ont fait consensus, a aussi permis de renforcer le crédit envers le système entier.

Dans leur conclusion, les chercheurs expliquent qu'ils pensent « que Chief doit être considéré comme un collaborateur et, par conséquent, que la confiance doit être considérée comme quelque chose que l'opérateur place dans la collaboration entre l'homme et le système automatisé, ce qui l'inclut lui-même, plutôt que la confiance qu'il place dans Chief  ».

Ceci peut sans doute s'adapter à tout outil de génération automatique de code. La confiance du développeur doit se bâtir non pas par rapport à l'outil en lui-même, mais dans son interaction avec cet outil.