analyseFonctionne bien avec ClaudeFonctionne bien avec ChatGPTFonctionne bien avec Gemini

Faire expliquer un code inconnu avant de le modifier

Plonger dans un module hérité, une dépendance tierce ou la pull request d'un collègue signifie lire du code sans aucun contexte en tête. Les développeurs collent désormais la fonction ou le fichier dans un modèle et lui demandent ce qu'il fait et pourquoi — chercher des réponses (54 %) et apprendre à connaître une base de code (33 %) comptent parmi les tâches IA les plus courantes selon l'enquête Stack Overflow. Le risque est faible puisqu'il s'agit de lire, pas de livrer.

Vous êtes un ingénieur senior qui m'aide à comprendre du code que je n'ai pas écrit. Je vais coller un extrait ; expliquez-le pour que je puisse le modifier en toute sécurité.

Langage/framework : {{language}}
Où cela s'insère dans le système : {{context}}
Code :
{{code}}

Détaillez :
1. Résumé — ce que fait ce code, en deux phrases.
2. Bloc par bloc — le rôle de chaque section significative, y compris les particularités ou idiomes du langage peu évidents.
3. Entrées, sorties et effets de bord — ce qu'il lit, retourne, modifie ou appelle en externe.
4. Hypothèses et cas limites — ce qui doit être vrai pour que cela fonctionne, et où cela casserait.
5. Questions à vérifier — tout ce que vous déduisez plutôt que vous ne savez avec certitude.

Règles :
- Basez chaque affirmation sur le code que j'ai collé. Si le comportement dépend de code, d'une configuration ou de types que je n'ai pas fournis, dites que cela dépend de quelque chose de non montré plutôt que de deviner.
- N'inventez pas de noms de fonctions, de bibliothèques ou de comportements non visibles dans l'extrait. Signalez toute ambiguïté au lieu de la résoudre silencieusement.
- Privilégiez un langage clair plutôt que le jargon ; quand un terme technique est incontournable, définissez-le une fois.

Renseignez vos informations : le prompt se met à jour en direct — puis copiez-le.

Langage / frameworkOù ce code s'insèreLe code à expliquer (à coller)

Ce que vous obtenez (extrait)

Résumé : cette fonction applique un debounce aux appels à search() afin qu'il ne se déclenche que 300 ms après que l'utilisateur a cessé de taper, en annulant tout appel en attente. Bloc par bloc : elle conserve un identifiant de minuteur dans une closure ; chaque appel efface le minuteur précédent et en planifie un nouveau, puis transmet ses arguments via ...args au déclenchement du minuteur. Effets de bord : définit et efface un minuteur ; appelle search() uniquement avec les arguments les plus récents. Hypothèses : repose sur une seule variable de minuteur partagée dans la portée englobante. La façon dont search gère les erreurs dépend de code non montré. Questions à vérifier : search est-elle asynchrone ? Si oui, les résolutions qui se chevauchent ne sont pas gérées ici.

Le flux de travail complet

Ne collez que du code que vous avez le droit de partager ; supprimez d'abord les secrets, clés et identifiants internes
Donnez au modèle le contexte environnant (framework, où le code s'exécute) pour que l'explication soit exacte
Relisez l'explication en la comparant au code et résolvez vous-même chaque signal « non montré » ou ambigu
Confirmez votre compréhension en exécutant le code ou en le parcourant pas à pas avant de le modifier

Attention à

Ne collez jamais de code source propriétaire, d'identifiants, de clés API ou de données clients dans un compte IA grand public — elles peuvent être conservées et utilisées pour entraîner le modèle. Samsung a interdit ChatGPT grand public en 2023 après que des employés ont divulgué du code interne, et les enquêtes montrent que la plupart des employés continuent d'y coller des données de l'entreprise. Utilisez une offre entreprise avec entraînement désactivé, ou ne partagez que des extraits non sensibles.

Le modèle explique le code avec assurance, même quand il devine pour les parties que vous n'avez pas montrées. Considérez comme non vérifié tout comportement dépendant de code, de configuration ou de types non montrés, jusqu'à ce que vous le vérifiiez vous-même.

Une explication n'est pas un test. Confirmez le comportement en exécutant le code ou en le parcourant pas à pas, pas en faisant confiance au résumé.

D’où ça vient

Chaque cas d’usage de ce site s’appuie sur des témoignages réels rapportés par les développeurs en exercice — rien n’est inventé par nous.

Plus de cas d’usage de l’IA pour les développeurs

analyse

Faire expliquer un code inconnu avant de le modifier

Le flux de travail complet

Attention à

D’où ça vient

Plus de cas d’usage de l’IA pour les développeurs

Une première relecture de votre diff avant qu'un humain ne le voie

Générer des tests unitaires que vous validez ensuite par rapport à la spécification

Déboguer avec la méthode du canard en plastique un problème qui vous résiste

Transformer une décision en ADR ou dans la documentation que vous aviez sautée

Rédiger des messages de commit et des descriptions de PR à partir de votre diff