Détecteur de code IA : pourquoi votre code est signalé et comment y remédier

Un détecteur de code IA a classé votre code comme écrit par une machine. Voici ce que signifie ce chiffre, pourquoi le code propre est signalé, et les modifications qui font baisser le taux.

Cet article est traduit automatiquement de l'original anglais ; certaines tournures peuvent paraître rigides. Lire l'original en anglais

Un détecteur de code IA note un fichier, un dépôt ou une soumission selon son apparence de génération automatique. Il renvoie un score au niveau du document ainsi que des surlignages par fichier ou par fonction. Si le vôtre est élevé, la démarche utile n’est pas de contester le chiffre. Il s’agit de trouver quelles lignes portent le signal et de les corriger.

Ce verdict a une moitié inconfortable. Les détecteurs devinent à partir de motifs de surface, et le code a moins de motifs de surface que la prose. Un fichier propre, idiomatique et bien commenté écrit par une personne peut ressembler exactement à du code généré, car le code généré est entraîné sur des personnes écrivant exactement de cette façon. Les scores élevés sont courants et ne prouvent pas que vous avez triché.

Ce qu’un détecteur de code IA mesure réellement

Il ne lit pas votre intention. Il lit des statistiques.

La plupart des détecteurs, pour la prose comme pour le code, examinent deux choses : à quel point chaque token suivant est prévisible (perplexité) et à quel point cette prévisibilité varie au fil du document (burstiness). Le code humain est irrégulier. Vous écrivez une boucle ennuyeuse, puis un assistant bizarre avec un nom étrangement spécifique, puis un commentaire qui mentionne un numéro de ticket, puis quatre lignes de configuration copiées-collées. Le code généré tend à être plus lisse : longueurs d’identifiants cohérentes, style de commentaire cohérent, structure cohérente de la première à la dernière ligne.

Cette régularité est le signal. La solution n’est donc pas de rendre votre code pire. Il s’agit de laisser transparaître l’irrégularité naturelle d’un vrai projet.

Une dernière chose qu’il vaut la peine de dire clairement : la sortie d’un détecteur est une estimation de probabilité, pas une preuve de paternité. La FAQ de GPTZero décrit elle-même un chiffre de confiance comme « la probabilité que le détecteur soit correct dans sa classification » et donne l’exemple que 90 % signifie que 90 % du temps, sur des documents similaires, le détecteur est correct (source : gptzero.me). C’est une affirmation sur le comportement de l’outil, pas sur votre fichier. La documentation de Turnitin décrit un réglage afin qu’aucun score ni surlignage ne soit attribué dans la plage de 1 % à 19 %, pour éviter les faux positifs (source : www.turnitin.com). Chaque fournisseur gère ouvertement le même compromis : détecter le texte généré, ne pas brûler le travail honnête.

Pourquoi mon propre code est-il signalé comme écrit par une IA ?

Quatre raisons couvrent la plupart des cas.

Le code standard reste du code standard. Les gestionnaires CRUD, l’échafaudage de tests, les fichiers de configuration et la colle de bibliothèque standard sont presque identiques, qu’ils aient été tapés par une personne ou un modèle. Il n’y a presque aucun signal de paternité à trouver, donc le détecteur se rabat sur des a priori.

Votre style est cohérent. Si vous nommez tout data, result, handleX, et commentez chaque fonction sur le même ton bref, vous avez accidentellement produit la fluidité qui se lit comme générée. La cohérence est normalement une vertu. Ici, elle vous coûte cher.

Le fichier est court. Les entrées courtes donnent très peu de matière à un détecteur. Une seule fonction utilitaire relève surtout d’un a priori, pas d’une preuve.

Vous avez utilisé un modèle, pour une partie. La plupart du code signalé en 2026 est mixte : vous avez écrit l’architecture, un assistant a écrit trois fonctions utilitaires, et vous les avez légèrement modifiées. Les coutures sont réelles et elles se manifestent par un changement de texture entre les sections.

Avant de réécrire quoi que ce soit, évaluez-le correctement. Le détecteur d’IA de DeAIze note l’ensemble du document et met en évidence chaque phrase selon la probabilité d’IA, afin que vous puissiez voir quelles lignes portent le signal au lieu de deviner. L’offre gratuite vous donne 200 mots à l’inscription, sans carte bancaire.

La solution : modifiez les régions signalées, pas tout le fichier

Traitez le score comme un linter. Vous ne reformatez pas un dépôt parce qu’une fonction émet un avertissement.

Évaluez d’abord, modifiez ensuite. Obtenez une vue par ligne ou par fonction. Dans DeAIze, il s’agit d’une mise en évidence au niveau des phrases ; en termes de code, cela pointe vers les régions, pas vers le fichier.
Triez par signal, pas par taille. Corrigez les trois régions les plus chaudes avant de toucher à quoi que ce soit de froid. Réécrire du code froid est un effort inutile et ajoute du risque.
Rendez les commentaires spécifiques. C’est la modification la plus rentable dans le code. Remplacez // Initialize the client par une note que seul votre projet pourrait produire : une référence de ticket, un bug amont connu, une raison pour laquelle un paramètre est ignoré.
Brisez la symétrie. Si chaque fonction a la même forme de commentaire, supprimez certains commentaires. Si chaque variable est un mot complet, raccourcissez les évidentes. Si la structure est parfaitement parallèle, laissez une branche être traitée en ligne.
Gardez vos propres aspérités. Le TODO à moitié terminé, la vérification défensive que vous avez ajoutée après un incident, le contournement légèrement laid avec une date dedans. Ce sont des signaux de paternité et ils sont vrais.
Réévaluez et comparez. Si le nombre a changé, gardez la modification. Sinon, annulez-la. Ne gardez jamais une réécriture qui a empiré le code pour rien.

Une illustration concrète. Avant, une fonction utilitaire signalée :

// Function to calculate the total price
def calculate_total_price(items):
    # Initialize total
    total = 0
    # Iterate through items
    for item in items:
        total += item.price
    # Return the total
    return total

Après, même comportement, moins de symétrie :

def order_total(items):
    # No discount logic here on purpose - pricing service owns that (TICKET-4412)
    return sum(i.price for i in items if not i.voided)

La deuxième version est plus courte, plus idiomatique et porte une raison qu’un lecteur peut vérifier. C’est ce qu’un véritable auteur laisse derrière lui. Ce n’est pas de l’obfuscation et cela ne change pas ce que fait le code. Notez qu’il s’agit d’une illustration, pas d’un avant/après mesuré.

Ce que nos propres tests disent sur les taux de détection

Nous avons exécuté notre détecteur sur deux corpus le 2026-09-28, avec un seuil de signalement de 30 %. Un échantillon de référence de 709 passages de référence issus de 61 guides DeAIze sélectionnés parce que leurs métadonnées ne les marquaient pas comme générés a obtenu une moyenne de 26 % et une médiane de 25 %, avec une plage de 0 % à 69 % ; 239 des 709 passages ont obtenu un score égal ou supérieur à ce seuil. L’authorship humaine n’a pas été vérifiée de manière indépendante, donc ces comptages ne peuvent pas établir un taux de faux positifs humains. Une sortie de modèle non éditée, 12 passages DeepSeek générés à partir de prompts fixes sans édition, a obtenu une moyenne de 33 % et une médiane de 34 %, plage de 4 % à 46 %.

Relisez cela, car c’est la version honnête. Les passages de référence, dont l’authorship humaine n’a pas été vérifiée de manière indépendante, et la sortie de modèle DeepSeek non éditée se situaient dans des plages qui se chevauchent, et les moyennes étaient plus proches que la plupart des gens ne l’attendent. La détection n’est pas un séparateur net. C’est un signal bruité que vous devez interpréter, ce qui explique précisément pourquoi la mise en évidence phrase par phrase importe plus que le chiffre principal. Pour un aperçu plus large des raisons pour lesquelles les scores varient d’un outil à l’autre, voir AI Detector Accuracy.

Quand c’est le mauvais choix

N’utilisez rien de tout cela pour faire passer un travail que vous n’avez pas réalisé. Si le devoir, le contrat ou la revue de code exige que le code soit le vôtre, un score de détecteur de code IA est le moindre de vos problèmes dès que quelqu’un lit le diff et vous demande d’expliquer une fonction que vous ne pouvez pas expliquer.

Vous devriez également passer tout cet exercice si :

La politique interdit catégoriquement l’assistance par IA. Modifier pour baisser un score ne rend pas une soumission non autorisée autorisée. Demandez, puis divulguez.
Le code est généré de bout en bout et vous ne le comprenez pas. Réécrire les commentaires ne vous sauvera pas lors d’une présentation. Apprenez le code ou ne le soumettez pas.
Vous êtes accusé, pas noté. Si une procédure formelle a commencé, la bonne démarche est la documentation et vos brouillons, pas une réécriture. Audience d’intégrité académique IA couvre ce que les panels évaluent réellement.
Votre équipe partage un guide de style. Imposer une voix personnelle dans un dépôt partagé pour plaire à un détecteur est un mauvais compromis. Corrigez uniquement les régions signalées.

Une courte liste de vérification avant de resoumettre

Vous savez quelles régions ont été signalées, pas seulement le score global.
Chaque modification a maintenu le comportement identique, et vous avez les tests pour le prouver.
Les commentaires portent désormais des raisons spécifiques au projet, des numéros de ticket ou des dates.
Vous avez supprimé les commentaires passe-partout qui n’apportaient rien.
Vous avez rescanné et pouvez dire ce qui a changé.
Vous pouvez expliquer chaque ligne de la soumission à voix haute, sans notes.

Si vous avez utilisé un modèle pour certaines parties du fichier, dites-le là où la divulgation est attendue. Une courte note indiquant quelles parties ont été assistées et comment vous les avez vérifiées est presque toujours un meilleur résultat qu’un score propre que vous ne pouvez pas défendre.

Comment cela s’intègre dans le flux de travail global

Le code est un cas particulier car les motifs de surface sont plus ténus. La plupart de la même méthode s’applique à la prose, et le guide humaniser le texte IA couvre la boucle plus en détail : évaluer le texte, réécrire uniquement les phrases signalées, ne conserver une réécriture que lorsque la similarité sémantique indique que le sens a survécu, puis réévaluer et rapporter avant et après. Sur le paragraphe d’exemple utilisé sur le site, un score IA de 92 % est devenu 4 %.

Pour le code, la boucle est plus simple et vous la faites principalement à la main. Les détecteurs sont réglés pour être prudents. La documentation de Turnitin note que s’ils identifient 50 % d’un document comme probablement écrit par IA, il pourrait contenir jusqu’à 65 % de texte IA (source : www.turnitin.com) — les fournisseurs élargissent la fourchette car l’estimation ponctuelle n’est pas fiable. Traitez chaque score de code de la même manière : une raison d’examiner, jamais une raison de paniquer, et jamais un verdict en soi.

Note de mesure : les chiffres de cet article proviennent de notre propre observation locale du détecteur le 2026-09-28 — n = 709 passages de référence issus de 61 guides sélectionnés par métadonnées contre n = 12 passages de modèle DeepSeek non modifiés, score IA médian de 25 % et 34 % respectivement. L’authorship humaine n’a pas été vérifiée de manière indépendante ; les passages d’un même guide sont corrélés, ces chiffres n’établissent donc pas un taux de faux positifs humains. Méthode : méthodologie. Preuve datée : observation du corpus, 2026-09-28.