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 » (Comments Everywhere) — « des commentaires en ligne excessifs qui alourdissent fortement la charge de calcul … et rendent le code plus difficile à relire et à maintenir » — dans 90–100 % du code généré par IA de son étude sur plus de 300 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.

Pourquoi c'est nuisible

• Charge de revue. Chaque ligne de narration est du bruit qu'un humain doit sauter. La formule d'OX : l'IA travaille comme "une armée de développeurs juniors talentueux mais inexpérimentés", et "une revue de code digne de ce nom ne peut tout simplement pas suivre la nouvelle cadence de production" — 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 qui reformulent le prompt dupliquent en prose l'intention du code ; la prose dérive à mesure que le code change et laisse une documentation activement trompeuse — l'odeur classique Commentaires de Fowler, où les commentaires servent de déodorant.
• 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 le cycle lint-correction 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 fait le code, c'est le signal qu'il faut rendre le code auto-documenté — appliquez Extraire une méthode et Renommer la méthode (ou Extraire une variable pour une expression isolée) pour que le nom porte l'intention, puis ne gardez que les commentaires qui expliquent un pourquoi non évident. C'est le conseil de Fowler pour l'odeur Commentaires : quand vous ressentez le besoin d'écrire un commentaire, essayez d'abord de refactorer pour que le commentaire devienne superflu.

// 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.