---
title: "Commentaires résidus de prompt"
type: "ai-smell"
slug: "prompt-residue-comments"
url: "http://localhost:3000/fr/ai-smells/prompt-residue-comments.md"
category: "Clarté"
description: "Des commentaires qui sont des artefacts de la conversation de génération — prompts reformulés, narration pas à pas, apartés de discussion et élisions de marqueur comme `// ... rest of the code here` — committés dans le code source au lieu d'une vraie documentation."
---
# Commentaires résidus de prompt

> Des commentaires qui sont des artefacts de la conversation de génération — prompts reformulés, narration pas à pas, apartés de discussion et élisions de marqueur comme `// ... rest of the code here` — committés dans le code source au lieu d'une vraie documentation.

## Signs and Symptoms

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

```ts
// 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 ».

## Reasons for the Problem

**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).

## Treatment

**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_).

```ts
// 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);
}

```

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

## Detected by

- **ESLint** `no-warning-comments` — Signale TODO/FIXME/XXX et des termes personnalisables — définissez `terms` pour attraper les résidus de marqueur comme "your code here" ou "rest of the code" (https://eslint.org/docs/latest/rules/no-warning-comments)
- **SonarQube / SonarSource** `S125` — Des sections de code ne devraient pas être commentées — signale les blocs élidés/laissés en commentaire (https://rules.sonarsource.com/javascript/RSPEC-125/)
- **SonarQube / SonarSource** `S1135` — Suit les usages des balises "TODO" — fait remonter les résidus TODO de marqueur livrés en tant que code (https://rules.sonarsource.com/javascript/RSPEC-1135/)
- **SonarQube / SonarSource** `S1134` — Suit les usages des balises "FIXME" (https://rules.sonarsource.com/javascript/RSPEC-1134/)