Commentaires résidus de prompt.

Un relecteur repère des commentaires résidus de prompt quand les commentaires documentent la conversation qui a produit le code plutôt que le code lui-même. Quatre indices, souvent concomitants :

• Prompt reformulé — un commentaire qui paraphrase la demande verbatim (// Fonction pour additionner deux nombres) au-dessus d'une fonction littéralement nommée add.
• Narration des étapes — un compte rendu ligne par ligne d'opérations évidentes (// Étape 1 : boucler sur le tableau, // incrémenter i de 1 au-dessus de i++).
• Apartés de chat — remarques à la deuxième personne, au présent, adressées à vous, le prompteur (// Comme demandé, voici le handler mis à jour, // Bien sûr ! Voici le correctif, // Note : remplace par ta vraie clé d'API).
• Résidu d'élision / de marqueur — // ... rest of the code here, // keep your existing logic, // your code here, // TODO: implement error handling laissés dans le code source committé.

// Fonction pour additionner deux nombres et renvoyer le résultat   <- reformule le prompt
function add(a: number, b: number): number {
  // Étape 1 : additionner les deux nombres                          <- narre l'évidence
  const sum = a + b;
  return sum; // renvoyer la somme
}

// Comme demandé, voici le handler mis à jour                        <- aparté de chat à « vous »
export async function handler(req: Req, res: Res) {
  // ... gardez ici votre logique de validation existante ...        <- élision : vrai code perdu
  // TODO: implement error handling                                  <- marqueur livré tel quel
  const user = await db.users.find(req.params.id);
  res.json(user);
}

La ligne d'élision est la dangereuse : elle se lit comme de la documentation mais c'est en réalité une instruction à un humain de coller du code que le modèle a omis — appliquez le bloc verbatim et la validation existante disparaît silencieusement. OX Security a trouvé des « Commentaires partout » dans 90–100 % du code généré par IA dans son étude de plus de 300 dépôts, les décrivant comme des marqueurs qui « ont l'air utiles mais soutiennent surtout l'IA elle-même, encombrant les dépôts ».

Pourquoi les modèles l'émettent

• Mimétisme du token suivant des corpus de tutoriels. Le mélange d'entraînement est saturé d'articles de blog, de réponses StackOverflow et de docs où chaque ligne est expliquée pour un apprenant. Le modèle reproduit ce registre didactique — narration et intention reformulée — parce que c'est la continuation statistiquement probable, pas parce que le dépôt environnant en a besoin.
• Fuite du registre de chat / complaisance. Le RLHF règle les assistants pour être explicatifs et conciliants dans le canal de chat. Ce ton conversationnel à la deuxième personne fuit dans le canal de code, produisant des apartés « Comme demandé… » et « Note : tu devrais… » qui n'ont aucun sens une fois le code détaché de la conversation.
• Raisonnement narré en commentaires. Les modèles externalisent leur plan (« Étape 1… Étape 2… ») sous forme de commentaires inline — une fuite de chaîne de pensée figée dans le fichier.
• L'élision est une commodité de chat, mal appliquée. Dans une réponse de chat, // ... reste inchangé ... est une façon polie d'éviter de réimprimer un fichier. Quand cette réponse est collée ou appliquée automatiquement à un vrai fichier, la commodité devient un résidu littéral — et une perte de données littérale.
• Aucun contexte de dépôt, alors il reformule le prompt. Faute du ticket, du domaine et du vrai « pourquoi », le modèle n'a rien de vrai à dire dans un commentaire, alors il se rabat sur la paraphrase de la seule chose dont il dispose : votre prompt. OX qualifie ces commentaires de « marqueurs internes pour naviguer dans les limites de contexte… dépendance à la mémoire à court terme plutôt qu'à une véritable compréhension ».

Pourquoi c'est nuisible

• Charge de revue. Chaque ligne de narration est du bruit qu'un humain doit lire en passant. La formule d'OX : l'IA « code comme un développeur junior » à vitesse machine, et la revue humaine « ne peut pas passer à l'échelle de la production de l'IA » — les commentaires résidus rendent chaque diff plus coûteux à relire précisément quand il y a plus de diffs.
• Exactitude / perte de données. Les marqueurs d'élision (// ...existing code...) provoquent la perte de vrai code lorsque les blocs sont appliqués à l'aveugle.
• Pourrissement des commentaires. Les commentaires de prompt reformulé dupliquent l'intention du code en prose ; la prose dérive à mesure que le code change, laissant une documentation activement trompeuse — le smell classique des Commentaires-comme-déodorant de Fowler.
• Incomplétude cachée. // TODO: implement error handling est le modèle signalant qu'il a travaillé à la limite de sa compétence ; livré tel quel, c'est de la logique inachevée déguisée en tâche suivie.
• Indices de sécurité. // replace with your actual API key se trouve généralement à côté d'un identifiant de remplacement codé en dur — le résidu marque exactement la ligne qui intéresse un scanner (et un attaquant).

Tactiques de prompting / de génération

• Contraignez le registre : « Produis le fichier complet. N'abrège jamais avec // ..., // rest of the code ou // existing code. Ne narre pas les étapes — ne commente que la justification non évidente (le pourquoi). Aucun aparté conversationnel ; ceci va directement dans un dépôt. »
• Demandez un diff unifié plutôt qu'un extrait enrobé de prose, afin que les omissions soient explicites et applicables au lieu d'être éludées avec un commentaire d'élision.
• Exigez que le modèle exécute le formateur et votre config de lint (par ex. no-warning-comments avec des termes personnalisés) et rapporte le résultat — boucler la boucle « valider avec le linter » attrape automatiquement les résidus de marqueur/TODO.
• Ajoutez une barrière grep en pre-commit / CI pour les marqueurs de résidu (rest of the code, your code here, existing code, As requested, Step \d) et traitez les marqueurs d'élision comme un blocage strict, car ils signifient souvent que du code a été silencieusement perdu.

Le refactoring

Supprimez purement et simplement les apartés de chat et la narration. Lorsqu'un commentaire ne fait que reformuler ce que le code fait, c'est le signal qu'il faut rendre le code auto-documenté — appliquez Extraire une fonction et Renommer pour que le nom porte l'intention, puis ne gardez que les commentaires qui expliquent un pourquoi non évident (Fowler : Supprimer les commentaires qui servent de déodorant à de mauvais noms).

// avant — résidu de prompt
// Crée une fonction qui valide une adresse e-mail à l'aide d'une regex
function validateEmail(input) {
  // vérifier si l'entrée correspond au motif d'e-mail
  const re = /^[^@]+@[^@]+\.[^@]+$/;
  // renvoyer true ou false
  return re.test(input);
}

// après — le nom porte l'intention ; le seul commentaire explique le pourquoi non évident
const EMAIL_RE = /^[^@]+@[^@]+\.[^@]+$/; // volontairement souple : on n'attrape que les fautes de frappe avant l'envoi, pas la RFC 5322
const isValidEmail = (input: string): boolean => EMAIL_RE.test(input);

Pour le résidu d'élision, n'appliquez jamais le bloc tel quel — comparez-le au fichier courant et restaurez ce que le modèle a perdu. Pour // TODO: implement …, soit terminez la logique, soit convertissez-le en ticket suivi et faites échouer le build sur le terme de marqueur pour qu'il ne puisse pas être livré tel quel.