Reconnaître du code écrit par une IA

La question se pose dans trois situations concrètes : en revue de code, quand on veut savoir quelle attention porter à un fichier ; en recrutement, face à un test technique ; et en audit, quand on reprend une base dont personne ne connaît l'origine.

Disons-le d'emblée : il n'existe aucun moyen fiable de prouver qu'un code a été généré. Les outils qui prétendent le faire produisent des faux positifs en quantité, notamment sur du code bien écrit par des développeurs expérimentés. Ce qui suit ne sert pas à accuser quelqu'un, mais à savoir où porter son attention.

Les signaux qui reviennent

Le commentaire qui paraphrase la ligne

C'est le motif le plus caractéristique. Un développeur commente pourquoi, parce que le comment est déjà dans le code. Un modèle commente le comment, parce qu'il produit du texte qui accompagne du code sans savoir ce qui mérite une explication.

// Incrémente le compteur
counter++;

// Boucle sur les utilisateurs
for (const user of users) {

// Retourne le résultat
return result;

Trois commentaires de ce type dans un même fichier constituent le signal le plus net qu'on puisse observer. Un humain pressé n'écrit pas de commentaires ; il n'en écrit pas d'inutiles.

L'uniformité anormale

Le code humain porte les traces de son histoire : une fonction écrite un mardi soir ne ressemble pas à celle du lundi matin. On y trouve des styles qui cohabitent, une abréviation ici et un nom complet là, une fonction de quarante lignes à côté d'une de trois.

Le code généré en une passe est homogène d'un bout à l'autre : mêmes longueurs de fonction, même densité de commentaires, même façon de nommer partout. Cette régularité est agréable à lire et improbable chez un humain travaillant sur plusieurs semaines.

La gestion d'erreur décorative

Un motif très fréquent : l'erreur est capturée, puis relancée telle quelle ou remplacée par un message générique. Le bloc existe, il rassure visuellement, il ne fait rien.

try {
  return await fetchUser(id);
} catch (error) {
  console.error("Une erreur est survenue :", error);
  throw error;
}

Un développeur qui écrit un try/catch a généralement une raison : réessayer, produire une valeur de repli, convertir l'erreur pour l'appelant. Quand le bloc n'apporte rien, il vient souvent d'une consigne du type « ajoute une gestion d'erreur » plutôt que d'un besoin réel.

La complétude suspecte

Aucun TODO, aucun code commenté, aucune fonction laissée à moitié, tous les cas traités uniformément. Une base de code humaine réelle contient toujours des traces de travail en cours et de compromis assumés. Une propreté parfaite dès la première version en dit long.

Le nommage générique

Un modèle nomme selon la forme de la donnée, un humain selon son rôle métier. On obtient donc beaucoup de data, result, item, response, handleData, processItems — là où un développeur du domaine aurait écrit facture, lignesImpayees ou relancerClient.

C'est aussi le signal le plus utile en pratique, parce qu'il pointe un vrai défaut : ce code ne parle pas le langage du métier, donc il sera plus difficile à maintenir, quelle qu'en soit l'origine.

L'abstraction sans usage

Une interface implémentée une seule fois, un paramètre de configuration jamais utilisé autrement qu'avec sa valeur par défaut, une couche d'indirection qui ne sert rien. Le modèle produit la forme complète du motif de conception, y compris les points d'extension dont personne n'a besoin.

Les signaux qui ne valent rien

Plusieurs indices très partagés sur les réseaux ne résistent pas à l'examen. Les prendre au sérieux mène à accuser à tort des gens qui écrivent simplement bien.

• Le code bien formaté ou bien indenté — c'est le formateur automatique qui fait ça, sur tous les projets sérieux depuis dix ans.
• Les emoji dans les messages de commit — une convention d'équipe répandue bien avant les assistants.
• Certains mots dans les commentaires, ou les tirets cadratins — ces marqueurs varient d'un modèle à l'autre, changent à chaque version, et frappent surtout les non-anglophones qui écrivent une langue soignée.
• L'absence de fautes de frappe — cela signale un correcteur orthographique, pas une machine.
• Un commit volumineux — cela signale une branche longue ou une migration, pas nécessairement une génération.

Ce que ça change en relecture

L'intérêt n'est pas de trancher sur l'origine, mais d'adapter la relecture. Devant du code présentant plusieurs de ces motifs, trois vérifications rapportent davantage que le reste.

1. Chercher ce qui manque plutôt que ce qui est faux : validation d'entrée, limite de débit, cas d'erreur réels. Le code généré pèche par omission, rarement par erreur visible.
2. Vérifier que les dépendances ajoutées existent vraiment et depuis longtemps.
3. Confronter le code aux règles métier que personne n'a écrites. C'est là que le code généré se trompe le plus, parce que ces règles ne figurent dans aucun corpus.

Le cas du recrutement

Chercher à détecter l'usage d'une IA dans un test technique est un combat perdu, et probablement mal posé. Un candidat qui livre du code généré qu'il ne comprend pas et un candidat qui livre du code généré qu'il a relu, corrigé et sait défendre n'ont pas les mêmes compétences — mais leur code peut être identique.

La seule évaluation qui tient est donc conversationnelle : demander pourquoi cette approche plutôt qu'une autre, ce qui se passe si telle entrée arrive, ce qu'il faudrait changer pour supporter dix fois plus de charge. Ces questions révèlent immédiatement la différence, et elles restent pertinentes quel que soit l'outil utilisé.