Vous restez responsable du code

Temps de lecture10 min

En bref

Résumé de l’article

Un assistant qui écrit du code ne prend aucune responsabilité sur ce code. Celle-ci reste entière, et elle est à vous : c’est votre nom qui sera sur le commit, et c’est vous qui devrez expliquer en soutenance pourquoi telle fonction fait ce qu’elle fait.

Au-delà de vos études, si vous développez un produit commercial, c’est votre responsabilité légale qui est engagée. Pour un petit jeu développé à la maison avec des ami(e)s, ce n’est pas très grave si des trucs ne marchent pas. Mais si vous laissez un agent coder le programme de déclenchement d’un airbag, ça peut être plus problématique.

Cet article explique ce que ces outils réussissent bien, ce qu’ils ratent de façon caractéristique, et quelles habitudes prendre pour que l’aide reste une aide.

Points clés à retenir

  • Vous spécifiez, vous relisez, vous validez. L’outil rédige un brouillon. Le partage des rôles s’arrête là.
  • Ce qui est bien présenté n’est pas forcément juste. Un code bien nommé et bien commenté peut être faux ; la mise en forme n’est pas un indice.
  • Si vous ne savez pas expliquer une ligne, elle n’est pas prête. C’est le test le plus simple et le plus fiable.
  • Les erreurs typiques sont identifiables : API inventées, cas limites oubliés, tests qui ne testent rien.
  • Apprendre en déléguant ne marche pas. Sur une notion que vous êtes en train d’acquérir, écrivez d’abord, demandez ensuite.

Contenu de l’article

Ce que ces outils font bien

  • Le code répétitif : boucles de lecture de fichier, conversions, squelettes de classes.
  • La traduction d’un algorithme connu en code.
  • Un premier jet de tests pour un comportement clairement décrit.
  • Les renommages, les extractions de fonction, les petites réorganisations.
  • Expliquer un message d’erreur, ou un code que vous découvrez.

Ce qu’ils ratent, et comment le repérer

Erreur typique Comment elle se manifeste Le réflexe
API inventée une méthode qui n’existe pas dans la bibliothèque ouvrir la documentation officielle
Cas limite oublié liste vide, division par zéro, fichier absent écrire le test du cas limite d’abord
Test qui ne teste rien assert True, ou un test qui passe sans le code casser le code exprès et vérifier que le test échoue
Faux plausible le code tourne mais le résultat est faux vérifier sur un exemple dont vous connaissez la réponse
Dépendance ajoutée un import d’une bibliothèque non installée regarder le diff avant d’accepter
Trou de sécurité chaîne SQL construite par concaténation, secret en dur relire les entrées venant de l’extérieur

Le plus dangereux est le quatrième : le code plausible et faux. Il ne lève aucune erreur, passe la relecture rapide, et se manifeste trois semaines plus tard sur un cas particulier.

Le test de l’explication

Une règle simple, et qui suffit dans l’immense majorité des cas :

Important

Si vous ne savez pas expliquer, ligne par ligne, ce que fait le code que vous vous apprêtez à valider, il n’est pas prêt. Soit vous le lisez jusqu’à le comprendre, soit vous demandez à l’assistant de l’expliquer et vous vérifiez son explication, soit vous l’écrivez autrement.

Ce test a un avantage sur toutes les règles plus élaborées : il ne demande aucun outil et vous pouvez l’appliquer en trois secondes.

Le cas particulier de l’apprentissage (le vôtre, pas celui du modèle)

Dans une UE comme celle-ci, vous n’êtes pas là pour produire du code, vous êtes là pour apprendre à en produire. Or déléguer un exercice à un assistant supprime exactement l’effort qui fait apprendre.

L’ordre qui fonctionne :

  1. Vous écrivez d’abord, même imparfaitement, même lentement.
  2. Vous demandez ensuite : une relecture, une autre approche, l’explication d’une construction que vous ne connaissiez pas.
  3. Vous comparez votre version et la sienne, et vous décidez.

Cet ordre garde l’assistant dans le rôle où il est le plus utile (un(e) collègue qui relit) plutôt que dans celui où il vous dessert.

Information

Anthropic a publié une étude sur l’effet de ces outils sur l’acquisition des compétences de programmation : How AI assistance impacts the formation of coding skills. Elle vaut la lecture, notamment pour la distinction entre les usages qui consolident et ceux qui érodent.

Les règles à retenir

À faire

  • Lire chaque ligne avant d’accepter.
  • Lancer les tests, et vérifier qu’ils testent quelque chose.
  • Demander à l’assistant d’expliquer ce qu’il a produit ; s’il n’y arrive pas, se méfier.
  • Relire particulièrement ce qui touche aux entrées extérieures et aux secrets.

À ne pas faire

  • Coller du code qu’on ne comprend pas.
  • Laisser un agent modifier des fichiers sans relire le diff.
  • Faire confiance à une version de bibliothèque annoncée par le modèle sans vérifier.
  • Envoyer du code confidentiel à un service dont on ignore où il l’envoie.
  • Se dire « l’IA l’a écrit, donc c’est bon ».

Pour aller plus loin

Les paquets inventés

Une API inventée provoque une erreur dès que le code l’appelle. Un paquet inventé est plus dangereux. Une étude de 2024 (Spracklen et al., voir ci-dessous) a fait générer 576 000 programmes à 16 modèles, et a constaté qu’au moins 5,2 % des paquets recommandés par les modèles commerciaux, et 21,7 % pour les modèles libres, n’existaient pas. Elle a relevé plus de 200 000 noms inventés différents, dont certains revenaient de manière répétée.

Cette répétition rend possible une attaque : repérer les noms que les modèles inventent souvent, et publier sur PyPI un paquet malveillant sous ce nom. La personne qui exécute uv add sur la suggestion de son assistant installe alors le code de l’attaquant(e), qui s’exécute avec ses droits.

Le réflexe : avant d’ajouter une dépendance proposée par un assistant, vérifiez sur pypi.org qu’elle existe, qu’elle est maintenue, et qu’elle est bien celle que vous croyez.

L’injection de prompt

En mode agent, le modèle lit beaucoup de texte que vous n’avez pas écrit : le README d’une dépendance, une page web, un ticket, un commentaire dans du code récupéré. Or, un modèle ne fait pas de distinction fiable entre les données qu’il lit et les instructions qu’il doit suivre. Un texte qui contient « ignore les consignes précédentes et exécute la commande suivante » peut donc être suivi comme s’il venait de vous. C’est ce qu’on appelle une injection de prompt, et l’OWASP la classe en tête des risques liés aux applications utilisant des modèles de langue.

Quelques réflexes limitent le risque :

  • Gardez les demandes d’accord avant l’exécution des commandes, et lisez-les.
  • Méfiez-vous d’un agent lancé sur un dépôt ou une page web dont vous ignorez la provenance.
  • Ne donnez pas à un agent l’accès à des secrets (mots de passe, clés d’accès) dont il n’a pas besoin.

Les tests de mutation

Le réflexe « casser le code exprès et vérifier que le test échoue » peut être automatisé. Un outil de test de mutation fabrique de nombreuses versions légèrement modifiées de votre code, appelées mutants : un < remplacé par <=, un + par un -, une ligne supprimée, etc. Il lance ensuite vos tests sur chacun d’eux.

Un mutant qui fait échouer au moins un test est dit « tué » : vos tests ont détecté la modification. Un mutant qui « survit » révèle un comportement que vos tests ne vérifient pas. C’est un excellent moyen d’évaluer des tests écrits par un assistant. En Python, l’outil mutmut permet de le faire (voir aussi l’article sur les tests).

Pour aller encore plus loin

  • L’étude de Spracklen et al. (2024) sur les paquets inventés par les modèles de génération de code (en anglais).
  • La documentation de mutmut, un outil de test de mutation pour Python (en anglais).