Des demandes floues des décideurs transformées en plan d'analyse cadré
« Peux-tu sortir quelques chiffres sur le churn ? » est l'endroit où le temps d'un analyste va mourir — une demande ambiguë qui se transforme en trois cycles de reprise parce que la vraie question n'a jamais été précisée. L'IA excelle à transformer une demande floue en un plan actionnable : les questions de clarification à renvoyer, les définitions d'indicateurs à confirmer, les données nécessaires, et une liste honnête de ce que l'analyse peut et ne peut pas répondre.
Vous êtes analyste de données senior et soucieux(se) du cadrage. Transformez une demande floue d'un décideur en un plan sur lequel je peux agir. La demande brute, telle qu'elle m'est parvenue : {{request}} Données et tables auxquelles j'ai réellement accès : {{data_available}} Délai et usage prévu du résultat : {{deadline_context}} Produisez : 1. Objectif reformulé — ma meilleure interprétation de la vraie question, en une phrase. 2. Questions de clarification — 4 à 6 questions précises à renvoyer avant de commencer (définitions, période, segments, quelle décision cela éclaire). 3. Définitions d'indicateurs proposées — chacune rédigée comme une proposition à confirmer, par exemple « churn = ... (à confirmer avec le demandeur) ». 4. Données et approche — lesquelles de mes tables disponibles j'utiliserais et la méthode d'analyse, à un niveau général. 5. Ce que cela peut et ne peut pas répondre — clairement, y compris si une expérience serait nécessaire pour toute question causale. 6. Livrable au juste format — le plus petit résultat utile pour l'usage et le délai indiqués. Règles : - Ne supposez pas la définition d'un indicateur métier — proposez-la et marquez-la pour confirmation. - Ne promettez pas de conclusions causales à partir de données observationnelles ; signalez où un test est requis. - Utilisez uniquement les sources de données que j'ai listées ; si la question nécessite des données que je n'ai pas, dites-le.
Renseignez vos informations : le prompt se met à jour en direct — puis copiez-le.
Objectif reformulé : Identifier où et quand les utilisateurs très actifs se désengagent, et faire émerger des facteurs candidats, pour éclairer si la rétention doit être une priorité du T3. Questions de clarification à renvoyer : 1. Définir « utilisateur actif » — décile d'usage le plus élevé, seuil de fonctionnalité, ou ancienneté ? 2. « Décrochage » sur quelle fenêtre — 7 jours d'inactivité, résiliation, ou déclassement ? 3. Quelle décision cela éclaire-t-il, et qu'est-ce qui changerait votre avis dans un sens ou dans l'autre ? Indicateur proposé : churn = aucun événement produit pendant 28 jours consécutifs parmi les utilisateurs actifs sur les 28 jours précédents (à confirmer avec le demandeur). Peut répondre à : où et quand le désengagement survient, et les corrélations dans les données d'événements. Ne peut pas répondre sans plus de données : pourquoi ils partent — les tickets support donnent des indices, mais des affirmations causales nécessiteraient une enquête ou un test.
Le flux de travail complet
- Reprenez la demande exactement telle qu'elle est arrivée, ainsi que les données que vous pouvez réellement utiliser
- Renvoyez les questions de clarification au demandeur avant de commencer à construire quoi que ce soit
- Faites confirmer par écrit les définitions d'indicateurs pour que le résultat ne soit pas contesté plus tard
- Cadrez le livrable sur la décision et le délai, et signalez toute question causale nécessitant un test
Attention à
Ne laissez pas l'IA définir vos indicateurs métier. Churn, utilisateur actif et conversion signifient des choses différentes selon les équipes — une définition que le demandeur n'a pas confirmée est une reprise de travail en attente.
Un plan d'analyse n'est honnête que par ses limites. Conservez la section « ne peut pas répondre » — promettre des réponses causales à partir de journaux observationnels est le moyen le plus rapide d'induire une décision en erreur.
Anonymisez la demande. Retirez les noms de clients, les noms de code de projets internes et tout contexte confidentiel avant de la soumettre à un outil d'IA grand public.
D’où ça vient
Chaque cas d’usage de ce site s’appuie sur des témoignages réels rapportés par les analystes de données en exercice — rien n’est inventé par nous.
Plus de cas d’usage de l’IA pour les analystes de données
Requêtes SQL rédigées et déboguées à partir d'un schéma décrit
analyseScripts de nettoyage et de profilage de données en Python, faciles à auditer
communicationSynthèses pour décideurs qui transforment un graphique en décision
rédactionDictionnaires de données et documentation de requêtes rédigés à partir du SQL lui-même
créatifLe bon graphique pour le message, pas seulement pour la donnée
← Les 6 cas d’usage : comment les analystes de données utilisent l’IA