SimpleOne montre pourquoi Claude et les relecteurs IA ne distinguent pas le code d'IA du code humain

SimpleOne a proposé un test simple : distinguer le code écrit par un humain du code généré par une IA. Il s'avère que c'est difficile non seulement pour les développeurs, mais aussi pour le relecteur IA lui-même, qui vérifie le code selon les mêmes schémas que ceux qui l'ont produit.

Pourquoi c'est difficile

Dans son article, l'équipe a rassemblé plusieurs paires de fonctions : validation d'e-mail, requête vers une API, chargement de configuration et calcul d'une remise. Dans chaque paire, une version a été écrite par un humain, l'autre par un modèle. Sur le papier, la tâche semble simple : le code d'IA comporte en général plus de typage, plus de commentaires et une pseudo-netteté. En pratique, c'est moins net. Certains exemples se trahissent par un excès de rigueur, mais dès la troisième ou la quatrième paire, il devient clair que le style seul ne permet pas toujours d'identifier l'auteur.

L'exemple le plus parlant est la fonction de calcul de remise, où la différence entre les versions disparaît presque. Les deux extraits fonctionnent, les deux passent l'analyse statique, les deux paraissent raisonnables. Mais la vraie erreur ne se cache pas à l'intérieur de la fonction : elle est à l'endroit où on l'appelle. Si la remise doit être figée au moment de la validation de la commande, il est exclu de la recalculer à chaque ouverture de la page. Ce n'est plus une question de syntaxe ou de best practices, mais de logique métier et de contexte du projet, que le relecteur automatique n'a généralement pas.

Ce qui trahit le code synthétique

SimpleOne relève plusieurs indices permettant parfois encore de repérer du code d'IA. Il ne s'agit pas d'erreurs grossières, mais d'un style suspectement « parfait » : le code paraît soigné, mais se comporte comme s'il cherchait à impressionner le relecteur plutôt qu'à résoudre une tâche concrète de production. Ces signaux sont apparus le plus souvent dans les exemples d'e-mail, d'API et de configuration.

• Des docstrings trop détaillées, énumérant Args, Returns et chaque exception, même pour une toute petite fonction.
• Des edge cases et des vérifications superflus que personne n'a demandés et qui ne découlent pas de l'énoncé de la tâche.
• Des entités inventées autour du code : exceptions personnalisées, loggers ou champs obligatoires qui n'existent pas dans le projet.
• Des fallbacks « sûrs » comme data.get('user', {}), qui ne plantent pas tout de suite, mais masquent le vrai problème.

D'où le principal risque : l'IA n'écrit souvent pas du code franchement mauvais, mais du code qui paraît convaincant. Il est typé, formaté, commenté et couvre une foule de scénarios. Mais une partie de ces scénarios est sortie de nulle part, et une partie des garde-fous ne fait que compliquer le débogage. On prend facilement un tel code pour du code de qualité si l'on regarde la forme sans vérifier comment il s'intègre dans un système précis.

Où la relecture déraille

Le problème décrit par SimpleOne ne se réduit pas à la qualité d'un seul modèle. Si Claude génère le code et qu'un autre outil d'IA le vérifie selon les mêmes schémas, l'équipe se retrouve dans une boucle fermée de confiance synthétique. Tout est au vert : il y a des types, de la gestion d'erreurs, des commentaires. Mais la relecture peut ne pas voir que UserFetchError n'existe pas dans le projet, que secret_key est apparu soudain sans aucune exigence, ou qu'un retour « silencieux » d'un dictionnaire vide coûtera ensuite des heures de recherche du bug.

« Le relecteur IA en a trouvé 2 sur 5. »

L'équipe a testé cela sur de vrais bugs de production. Le relecteur automatique n'a attrapé que deux cas simples : une variable inutilisée et l'absence de vérification de null. Sont passés entre les mailles les problèmes qui exigent le contexte du projet : une erreur logique dans un calcul, une race condition lors de requêtes parallèles et un ordre de migrations incorrect.

La conclusion est pragmatique : l'IA fonctionne bien comme premier filtre, mais ne remplace pas l'humain sur les zones critiques, où il importe de comprendre la logique métier et les conséquences des changements.

Ce que cela signifie

L'usage massif de l'IA dans le développement change non seulement la vitesse d'écriture du code, mais aussi le processus même de contrôle qualité. Vérifier du code généré avec un autre outil génératif est utile, mais insuffisant. Si une équipe ne teste pas son relecteur sur d'anciens bugs et ne garde pas un humain dans la chaîne de décision, elle risque d'obtenir non pas de la qualité, mais une imitation très vraisemblable de celle-ci.