10 pour les Product Managers, 10 pour les Développeurs. Chaque prompt est testé, structuré et prêt à copier-coller dans ChatGPT, Claude ou Copilot. Fini les prompts vagues qui donnent des réponses génériques.
Product Managers
01Prioriser un backlog02Rédiger une user story03Analyser des feedbacks utilisateurs04Préparer un sprint planning05Écrire un PRD06Faire une analyse concurrentielle07Rédiger un pitch pour les stakeholders08Créer des personas09Définir des métriques de succès10Brainstormer des solutions à un problèmeCopiez le prompt et collez-le dans l'outil recommandé
Remplacez les [PLACEHOLDERS] par vos données réelles
Itérez sur la réponse en demandant des ajustements
Priorisation, specs, analyse, communication — tout ce dont un PM a besoin au quotidien
Vous avez 30+ tickets en attente et devez décider quoi faire en premier. Utilisez ce prompt en début de sprint ou lors d’un trimestre planning.
Tu es un Product Manager senior spécialisé en priorisation. Voici mon backlog produit : [COLLER VOTRE BACKLOG ICI — format : titre de la feature + description courte] Pour chaque item, évalue sur 3 axes (note de 1 à 5) : - Impact business (revenus, rétention, acquisition) - Effort de développement (1 = trivial, 5 = plusieurs sprints) - Urgence (dépendances, deadlines, dette technique) Classe les items par score Impact/Effort décroissant. Présente le résultat sous forme de tableau avec colonnes : Priorité | Feature | Impact | Effort | Urgence | Score | Recommandation. Termine par un résumé : les 3 items à faire absolument ce sprint et pourquoi.
Vous devez transformer une idée vague en user story structurée avec critères d’acceptation, prête à être embarquée par l’équipe dev.
Tu es un Product Manager expérimenté. Transforme cette idée en user story complète : Idée : [DÉCRIRE LA FONCTIONNALITÉ EN 1-2 PHRASES] Contexte produit : [NOM DU PRODUIT, TYPE D'UTILISATEURS] Génère : 1. User story au format : "En tant que [persona], je veux [action] afin de [bénéfice]" 2. 5 à 8 critères d'acceptation précis et testables (format Given/When/Then) 3. Scénarios edge cases à considérer 4. Définition de "Done" 5. Story points estimés (échelle fibonacci : 1, 2, 3, 5, 8, 13) avec justification 6. Dépendances éventuelles Sois précis et concret, évite le jargon inutile.
Vous avez collecté des retours utilisateurs (NPS, interviews, tickets support, avis) et devez en extraire des insights actionnables.
Tu es un UX Researcher senior. Analyse les feedbacks utilisateurs suivants et identifie les patterns : [COLLER LES FEEDBACKS ICI — avis, tickets support, verbatims d'interviews, commentaires NPS] Produis : 1. **Thèmes principaux** : regroupe les feedbacks par thème (max 6 thèmes), avec le nombre de mentions pour chacun 2. **Sentiment global** : positif / neutre / négatif avec pourcentage estimé 3. **Top 5 pain points** : les irritants les plus fréquents, classés par sévérité × fréquence 4. **Quick wins** : 3 améliorations faciles à implémenter qui auraient un impact immédiat 5. **Signaux faibles** : mentions rares mais potentiellement importantes à surveiller 6. **Recommandations produit** : 3 actions concrètes à prendre, priorisées Pour chaque insight, cite le verbatim exact qui le supporte.
Vous préparez le prochain sprint et devez structurer l’agenda, vérifier la capacité de l’équipe et proposer un engagement réaliste.
Tu es un Scrum Master expérimenté. Aide-moi à préparer le sprint planning. Contexte : - Durée du sprint : [2 semaines / 1 semaine] - Taille de l'équipe : [X devs, Y designers] - Vélocité moyenne des 3 derniers sprints : [X story points] - Objectif principal du sprint : [OBJECTIF] - Items candidats du backlog : [LISTER LES ITEMS AVEC LEURS STORY POINTS ESTIMÉS] Produis : 1. Capacité réelle de l'équipe (en tenant compte des congés, cérémonies, imprévus — règle des 80%) 2. Sélection recommandée d'items pour le sprint (ne pas dépasser la capacité) 3. Sprint goal formulé en 1 phrase claire 4. Risques identifiés et mitigations 5. Dépendances entre items (ordre suggéré) 6. Template d'agenda pour la réunion de sprint planning (timeboxé 2h)
Vous lancez une nouvelle fonctionnalité et devez rédiger le Product Requirements Document pour aligner toutes les parties prenantes.
Tu es un Head of Product qui rédige des PRDs clairs et complets. Génère un PRD pour la fonctionnalité suivante : Fonctionnalité : [NOM ET DESCRIPTION EN 2-3 PHRASES] Produit : [NOM DU PRODUIT] Cible : [UTILISATEURS CONCERNÉS] Structure du PRD : 1. **Résumé exécutif** (3 lignes max) 2. **Problème** : quel problème utilisateur résout-on ? Données à l'appui si possible. 3. **Objectifs et métriques de succès** : KPIs mesurables avec cibles 4. **Périmètre** : ce qui est inclus (in scope) ET ce qui ne l'est pas (out of scope) 5. **User stories** : les 3-5 user stories principales 6. **Design & UX** : principes directeurs, wireframes textuels si pertinent 7. **Exigences techniques** : contraintes, intégrations, performance attendue 8. **Plan de lancement** : phases (alpha, beta, GA), critères de passage 9. **Risques et dépendances** 10. **Timeline estimée** 11. **Questions ouvertes** Écris de manière concise, chaque section doit être actionnable.
Vous devez cartographier la concurrence avant un lancement ou un pivot stratégique. Ce prompt structure votre recherche.
Tu es un analyste stratégique spécialisé en produits tech. Réalise une analyse concurrentielle complète. Mon produit : [NOM + DESCRIPTION EN 1 PHRASE] Marché cible : [SEGMENT / GÉOGRAPHIE] Concurrents identifiés : [LISTER 3-5 CONCURRENTS] Pour chaque concurrent, analyse : 1. **Positionnement** : proposition de valeur principale 2. **Forces** : ce qu'ils font mieux que nous 3. **Faiblesses** : ce qui manque ou ce qu'ils font mal 4. **Pricing** : modèle et fourchette de prix 5. **Traction** : indices de taille (employés, levée de fonds, avis clients) Puis synthétise : - **Matrice de positionnement** : 2 axes pertinents pour le marché, place chaque acteur - **Gaps d'opportunité** : besoins non couverts par les concurrents - **Notre avantage différenciant** : recommandation de positionnement - **Menaces à surveiller** : tendances qui pourraient changer la donne Format : tableaux comparatifs quand c'est possible.
Vous devez convaincre la direction ou des investisseurs d’allouer des ressources à votre initiative. Ce prompt crée un argumentaire structuré.
Tu es un expert en communication produit. Aide-moi à rédiger un pitch convaincant pour présenter une initiative à des stakeholders. Initiative : [DÉCRIRE LE PROJET EN 2-3 PHRASES] Audience : [Qui sont les stakeholders ? C-level, investisseurs, board ?] Ce que je demande : [Budget, headcount, priorisation, go/no-go ?] Données disponibles : [MÉTRIQUES, RÉSULTATS DE TESTS, BENCHMARKS] Génère : 1. **Hook d'ouverture** (1 phrase percutante qui capte l'attention) 2. **Le problème** : pourquoi c'est urgent, chiffres à l'appui 3. **La solution** : ce que tu proposes, en termes simples 4. **L'impact attendu** : métriques business, ROI estimé 5. **Le coût** : investissement requis (temps, argent, équipe) 6. **La preuve** : données, témoignages, résultats de prototype 7. **L'ask** : ce que tu demandes précisément 8. **Le risque de ne rien faire** : que se passe-t-il si on n'agit pas ? Ton : confiant mais pas arrogant. Axé données. Maximum 1 page.
Vous construisez ou actualisez vos personas pour guider les décisions produit. Ce prompt génère des personas réalistes à partir de vos données.
Tu es un UX Researcher expert en création de personas. Crée des personas détaillés pour mon produit. Produit : [NOM + DESCRIPTION] Données disponibles : [interviews utilisateurs, analytics, données CRM — résumer les points clés] Nombre de personas souhaité : [2 à 4] Pour chaque persona, génère : 1. **Nom et photo description** (âge, poste, entreprise type) 2. **Citation caractéristique** (1 phrase qui résume sa mentalité) 3. **Contexte** : parcours, environnement de travail, outils utilisés 4. **Objectifs** : ce qu'il/elle cherche à accomplir (pro et perso) 5. **Frustrations** : ses 3 plus gros pain points 6. **Comportements** : comment il/elle utilise des solutions aujourd'hui 7. **Critères de décision** : ce qui compte pour choisir un outil (prix, UX, sécurité, etc.) 8. **Scénario d'usage type** : une journée typique avec notre produit Assure-toi que les personas sont suffisamment différents pour couvrir les segments clés.
Vous lancez une feature ou un produit et devez définir comment mesurer le succès. Ce prompt vous aide à choisir les bons KPIs.
Tu es un Product Analytics expert. Aide-moi à définir les métriques de succès pour cette initiative. Initiative : [DESCRIPTION DE LA FEATURE/PRODUIT] Objectif business : [CROISSANCE, RÉTENTION, MONÉTISATION, ENGAGEMENT ?] Baseline actuelle : [MÉTRIQUES ACTUELLES SI DISPONIBLES] Définis : 1. **North Star Metric** : la métrique unique qui capture la valeur délivrée aux utilisateurs 2. **Métriques primaires** (2-3) : directement liées au succès de l'initiative 3. **Métriques secondaires** (2-3) : indicateurs de santé complémentaires 4. **Métriques garde-fou** (1-2) : ce qui ne doit PAS se dégrader 5. **Pour chaque métrique** : - Définition précise (comment on la calcule) - Source de données - Cible à 30j / 90j / 6 mois - Seuil d'alerte (en dessous duquel on doit agir) 6. **Dashboard recommandé** : quels graphiques afficher et à quelle fréquence les regarder 7. **Plan de mesure** : events à tracker, segments à surveiller Sois pragmatique : mieux vaut 5 métriques bien suivies que 20 qu'on ne regarde jamais.
Vous êtes bloqué sur un problème produit et avez besoin de générer un maximum d’idées avant de converger. Ce prompt structure un brainstorming solo efficace.
Tu es un facilitateur d'innovation produit. Aide-moi à brainstormer des solutions. Problème : [DÉCRIRE LE PROBLÈME EN DÉTAIL — qui est affecté, depuis quand, quel impact] Contraintes : [BUDGET, TEMPS, TECH, ÉQUIPE — tout ce qui limite les solutions possibles] Solutions déjà envisagées : [CE QUI A DÉJÀ ÉTÉ PROPOSÉ OU ESSAYÉ] Procède en 4 phases : **Phase 1 — Divergence** : Génère 10 idées de solutions, des plus conventionnelles aux plus audacieuses. Pour chaque idée : 1 phrase de description. **Phase 2 — Exploration** : Pour les 5 idées les plus prometteuses, développe : - Comment ça marcherait concrètement - Effort estimé (T-shirt sizing : S/M/L/XL) - Impact attendu - Risque principal **Phase 3 — Combinaison** : Propose 2 solutions hybrides qui combinent le meilleur de plusieurs idées. **Phase 4 — Recommandation** : Classe les 3 meilleures solutions et recommande celle à prototyper en premier, avec justification.
Review, debug, tests, refactoring — des prompts pour coder plus vite et mieux
Vous devez relire du code (le vôtre ou celui d’un collègue) et vérifier qualité, sécurité et maintenabilité avant de merger.
Tu es un développeur senior qui fait des code reviews rigoureuses mais bienveillantes. Analyse le code suivant : ```[LANGAGE] [COLLER LE CODE ICI] ``` Contexte : [BRÈVE DESCRIPTION DE CE QUE FAIT LE CODE] Évalue sur ces axes : 1. **Correctness** : bugs, edge cases non gérés, erreurs logiques 2. **Sécurité** : injections, XSS, secrets en dur, OWASP top 10 3. **Performance** : complexité algorithmique, requêtes N+1, memory leaks 4. **Lisibilité** : nommage, structure, commentaires manquants 5. **Maintenabilité** : couplage, duplication, principes SOLID 6. **Tests** : le code est-il testable ? Quels tests manquent ? Pour chaque problème trouvé : - Sévérité : 🔴 Critique / 🟡 Important / 🔵 Suggestion - Ligne(s) concernée(s) - Explication du problème - Code corrigé proposé Termine par un résumé : le code est-il prêt à merger ? Si non, quels sont les blockers ?
Vous avez un bug que vous n’arrivez pas à résoudre. Ce prompt structure votre demande d’aide pour obtenir une réponse utile.
Tu es un expert en debugging. Aide-moi à trouver et corriger ce bug. **Comportement attendu** : [CE QUI DEVRAIT SE PASSER] **Comportement observé** : [CE QUI SE PASSE RÉELLEMENT] **Étapes pour reproduire** : 1. [ÉTAPE 1] 2. [ÉTAPE 2] 3. [...] **Message d'erreur** (si applicable) : ``` [COLLER LE MESSAGE D'ERREUR / STACK TRACE] ``` **Code concerné** : ```[LANGAGE] [COLLER LE CODE PERTINENT] ``` **Ce que j'ai déjà essayé** : [LISTER LES TENTATIVES DE FIX] **Environnement** : [OS, version du langage/framework, navigateur si frontend] Analyse systématiquement : 1. Les causes probables (classées par probabilité) 2. Comment vérifier chaque hypothèse 3. Le fix recommandé avec le code corrigé 4. Comment éviter ce type de bug à l'avenir
Vous devez ajouter des tests à du code existant ou écrire des tests pour une nouvelle fonctionnalité. Ce prompt génère des tests complets.
Tu es un expert en testing. Écris des tests unitaires complets pour le code suivant : ```[LANGAGE] [COLLER LE CODE À TESTER] ``` Framework de test : [Jest / PyTest / JUnit / Go testing / autre] Génère : 1. **Tests du happy path** : les scénarios normaux d'utilisation 2. **Tests des edge cases** : valeurs limites, listes vides, null/undefined, types incorrects 3. **Tests des cas d'erreur** : exceptions attendues, erreurs réseau, timeouts 4. **Tests de régression** : si un bug connu est mentionné, ajoute un test qui le couvre Pour chaque test : - Nom descriptif qui explique le comportement testé (format "should ... when ...") - Arrange / Act / Assert clairement séparés - Mocks/stubs si nécessaire (avec justification) Objectif : couverture > 90% du code. Indique les lignes/branches non couvertes s'il en reste.
Vous devez documenter une fonction, un module ou une API pour que d’autres développeurs (ou votre futur vous) puissent s’en servir.
Tu es un technical writer spécialisé en documentation de code. Documente le code suivant : ```[LANGAGE] [COLLER LE CODE ICI] ``` Type de documentation demandée : [CHOISIR : docstrings / README / API docs / commentaires inline] Génère : 1. **Description** : ce que fait le code, en 1-2 phrases 2. **Paramètres** : nom, type, description, valeur par défaut, contraintes 3. **Retour** : type et description de ce qui est retourné 4. **Exceptions/Erreurs** : quand et pourquoi elles sont levées 5. **Exemples d'utilisation** : 2-3 exemples concrets avec input/output 6. **Notes** : complexité algorithmique, effets de bord, thread-safety si pertinent Conventions : utilise le format standard du langage (JSDoc pour JS/TS, docstrings Google style pour Python, GoDoc pour Go, etc.) Le ton doit être clair et concis. Écris pour un développeur qui découvre le code pour la première fois.
Le code fonctionne mais il est devenu difficile à maintenir. Ce prompt vous aide à le restructurer proprement sans casser le comportement.
Tu es un architecte logiciel expert en refactoring. Refactorise le code suivant en préservant son comportement : ```[LANGAGE] [COLLER LE CODE À REFACTORISER] ``` Problèmes identifiés : [CODE SMELLS OBSERVÉS — duplication, fonction trop longue, couplage fort, nommage obscur, etc.] Objectifs du refactoring : - [ ] Améliorer la lisibilité - [ ] Réduire la duplication - [ ] Améliorer la testabilité - [ ] Respecter les principes SOLID - [ ] [AUTRE OBJECTIF SPÉCIFIQUE] Produis : 1. **Diagnostic** : liste les code smells détectés avec leur sévérité 2. **Plan de refactoring** : étapes ordonnées (chaque étape = un commit logique) 3. **Code refactorisé** : le résultat final complet 4. **Diff commenté** : explique chaque changement majeur et pourquoi 5. **Vérification** : comment s'assurer que le comportement n'a pas changé (tests à exécuter) Règles : pas de sur-ingénierie, pas d'abstraction prématurée. Le code doit être plus simple après qu'avant.
Vous démarrez un nouveau projet ou une refonte majeure et devez choisir la bonne architecture technique.
Tu es un architecte logiciel senior avec 15 ans d'expérience. Aide-moi à choisir l'architecture pour ce projet. Projet : [DESCRIPTION DU PROJET] Contraintes : - Équipe : [TAILLE ET SÉNIORITÉ] - Budget infra : [BUDGET MENSUEL] - Scale attendu : [NOMBRE D'UTILISATEURS / REQUÊTES PAR SECONDE] - Deadline : [DATE DE LIVRAISON] - Stack existante : [LANGAGES/FRAMEWORKS DÉJÀ UTILISÉS DANS L'ÉQUIPE] Propose 3 architectures possibles, pour chacune : 1. **Description** : schéma en ASCII art + explication 2. **Stack recommandé** : langages, frameworks, bases de données, infra 3. **Avantages** : pourquoi cette architecture est pertinente ici 4. **Inconvénients** : risques, complexité, coût 5. **Quand choisir cette option** : le profil de projet idéal Puis donne ta **recommandation finale** : quelle architecture choisir et pourquoi, en tenant compte spécifiquement de mes contraintes. Bonus : les erreurs classiques à éviter avec l'architecture recommandée.
Votre application est lente et vous devez identifier les causes et appliquer des optimisations ciblées.
Tu es un expert en performance et optimisation. Analyse et optimise ce code / cette requête : ```[LANGAGE / SQL] [COLLER LE CODE OU LA REQUÊTE LENTE] ``` Contexte : - Temps d'exécution actuel : [DURÉE OBSERVÉE] - Temps cible : [DURÉE SOUHAITÉE] - Volume de données : [TAILLE DES TABLES / NOMBRE D'ÉLÉMENTS] - Environnement : [SPECS SERVEUR, VERSION DB, etc.] Analyse : 1. **Bottlenecks identifiés** : où le temps est perdu et pourquoi 2. **Complexité actuelle** : O(?) en temps et espace 3. **Optimisations proposées** (classées par impact décroissant) : - Description du changement - Impact estimé sur le temps d'exécution - Complexité d'implémentation (S/M/L) - Trade-offs éventuels 4. **Code optimisé** : la version corrigée complète 5. **Comment mesurer** : méthode pour valider l'amélioration (benchmarks, profiling) 6. **Recommandations long terme** : caching, indexation, architecture si le problème est structurel
Vous devez valider, extraire ou transformer du texte avec une expression régulière et vous ne voulez pas y passer 3 heures.
Tu es un expert en expressions régulières. Crée une regex pour le besoin suivant : **Objectif** : [DÉCRIRE CE QUE LA REGEX DOIT MATCHER / EXTRAIRE / REMPLACER] **Exemples de textes qui DOIVENT matcher** : - [EXEMPLE 1] - [EXEMPLE 2] - [EXEMPLE 3] **Exemples de textes qui NE DOIVENT PAS matcher** : - [CONTRE-EXEMPLE 1] - [CONTRE-EXEMPLE 2] **Langage cible** : [JavaScript / Python / Go / Java / etc.] Produis : 1. **La regex** avec la syntaxe exacte du langage cible 2. **Explication pas à pas** : chaque partie de la regex commentée 3. **Code d'exemple** : snippet fonctionnel qui utilise la regex 4. **Tests** : les exemples ci-dessus vérifiés (match ou non-match) 5. **Edge cases** : cas limites auxquels je n'ai peut-être pas pensé 6. **Performance** : la regex est-elle sujette au catastrophic backtracking ? Si oui, version optimisée.
Vous devez porter du code d’un langage à un autre (ex: Python vers TypeScript, Java vers Go). Ce prompt produit une traduction idiomatique.
Tu es un développeur polyglotte expert. Convertis ce code de [LANGAGE SOURCE] vers [LANGAGE CIBLE] : ```[LANGAGE SOURCE] [COLLER LE CODE À CONVERTIR] ``` Règles de conversion : 1. **Code idiomatique** : utilise les patterns et conventions du langage cible, pas une traduction mot à mot 2. **Types** : ajoute le typage fort si le langage cible le supporte 3. **Error handling** : adapte la gestion d'erreurs au style du langage cible (try/catch, Result type, if err != nil, etc.) 4. **Bibliothèques** : remplace les libs spécifiques au langage source par leurs équivalents dans le langage cible 5. **Nommage** : respecte les conventions (camelCase, snake_case, PascalCase selon le langage) Produis : - Le code converti complet - Les imports / dépendances nécessaires - Les différences comportementales à connaître (si le code ne peut pas être traduit 1:1) - Un avertissement si certains patterns n'ont pas d'équivalent direct
Vous tombez sur du code legacy ou complexe que vous ne comprenez pas. Ce prompt produit une explication claire et structurée.
Tu es un développeur senior patient et pédagogue. Explique le code suivant comme si tu l'expliquais à un développeur junior intelligent : ```[LANGAGE] [COLLER LE CODE COMPLEXE ICI] ``` Produis une explication structurée : 1. **Vue d'ensemble** (2-3 phrases) : que fait ce code au global ? Quel problème résout-il ? 2. **Walkthrough ligne par ligne** : explique chaque bloc logique, pas chaque ligne littérale. Utilise des analogies si ça aide. 3. **Concepts clés** : liste les patterns, algorithmes ou concepts techniques utilisés (ex: memoization, observer pattern, recursion) avec une explication courte de chacun 4. **Flow de données** : comment les données circulent dans le code (input → transformations → output) 5. **Pourquoi c'est écrit comme ça** : les choix d'implémentation et leurs raisons probables 6. **Pièges potentiels** : les subtilités que quelqu'un qui modifie ce code devrait connaître Adapte le niveau de détail : plus le code est complexe, plus l'explication doit être détaillée.
Plus vous donnez de contexte (stack technique, taille d’équipe, contraintes), plus la réponse sera pertinente. Un prompt avec contexte est 10x meilleur qu’un prompt générique.
Commencez par "Tu es un..." pour cadrer l’expertise. Un "développeur senior spécialisé en React" donnera des réponses différentes d’un "développeur junior".
Tableau, bullet points, code commenté, JSON — si vous précisez le format de sortie, vous évitez les allers-retours inutiles.
Si la première réponse n’est pas parfaite, affinez avec des follow-ups : "Rends ça plus concis", "Ajoute des exemples", "Focus sur la partie X".
L’IA peut halluciner. Vérifiez les faits, testez le code généré, et ne faites jamais confiance aveuglément à une sortie IA pour des décisions critiques.
Un bon prompt, c'est comme une bonne question en réunion : ça cadre la réponse et ça fait gagner du temps à tout le monde. Ces 20 prompts sont un point de départ — adaptez-les à votre contexte, enrichissez-les avec vos données, et surtout, construisez votre propre bibliothèque au fil du temps.
L'IA ne remplace pas votre expertise. Elle amplifie ce que vous savez déjà faire. Un PM qui sait prioriser obtiendra de meilleurs résultats avec le prompt de priorisation qu'un débutant. Un dev qui comprend les design patterns écrira de meilleurs prompts de refactoring.
La compétence clé n'est pas de savoir écrire des prompts — c'est de savoir quoi demander et quand la réponse est bonne.
Product Managers
HostPulse utilise l'IA pour protéger les hôtes Airbnb. Découvrez comment le screening intelligent peut sécuriser vos réservations.
Découvrir HostPulse