16 Skills Data analyst

Copier le SKILL.md

--- name: tech-analyse-produite-par-une-ia-verifiee-avant-diffusion description: "Cadre l’assistant pour aider un ou une data analyst à vérifier une analyse, un graphique ou un tableau de bord produit avec un outil d’IA qui écrit et exécute du code ou interroge les données : définitions et périmètre, jointures et filtres, valeurs recalculées par une autre voie, colonnes ou chiffres inventés, et mention de la part produite par l’outil. À utiliser avant tout envoi à un demandeur, une direction ou un client, et avant la mise en production d’un tableau de bord." --- # Analyse ou tableau de bord produit avec une IA : refaire, vérifier, puis diffuser ## Quand s’en servir Un outil d’IA a produit en quelques minutes une analyse à partir d’un fichier ou d’une base : code exécuté, tableau, graphique, commentaire. Le résultat est présentable et la demande est pressante. Le risque : une jointure qui duplique des lignes, un filtre implicite, une colonne mal comprise, une période décalée, un commentaire qui affirme une cause. La Skill sert entre le résultat de l’outil et la diffusion. ## Ce que l’assistant doit savoir Un résultat se vérifie sur ce qui a réellement été exécuté : code, requête, version des données, et non sur le commentaire de l’outil. Un outil de ce type peut nommer une colonne qui n’existe pas, arrondir sans le dire, exclure des valeurs manquantes sans le signaler, ou présenter une corrélation comme une cause. Les définitions des indicateurs se lisent dans le référentiel de l’organisation, pas dans la reformulation de l’outil. Les données confiées à l’outil doivent être celles que la politique interne autorise pour lui. Si ce sont des données personnelles, la CNIL (questions-réponses du 18 juillet 2024) impose de qualifier le fournisseur avant tout usage : s’il réutilise les saisies pour entraîner ses modèles, il n’agit plus sur instruction documentée, l’article 28 du RGPD ne décrit plus l’opération, et la saisie devient une communication de données à un tiers. L’article 4 du règlement sur l’IA impose, depuis le 2 février 2025, une obligation de maîtrise de l’IA pour le personnel concerné : la vérification décrite ici en est l’application concrète. L’article 50, paragraphe 4, du règlement sur l’IA, applicable depuis le 2 août 2026, ne vise, pour les textes, que ceux qui sont publiés pour informer le public sur des questions d’intérêt public, et l’obligation tombe si le contenu a fait l’objet d’un examen humain ou d’un contrôle éditorial et qu’une personne assume la responsabilité éditoriale de la publication. Pour une analyse diffusée en interne, les socles du site ne relèvent aucune obligation de mention : la règle interne s’applique, et toute autre obligation se vérifie à la source. La diffusion engage la personne qui envoie : la part produite par l’outil se mentionne selon la règle interne, et ce qui n’a pas été vérifié se dit. ## Marche à suivre 1. Récupérer la demande initiale, la définition des indicateurs dans le référentiel, le code ou la requête exécutés, et la version ou l’extraction de données utilisée ; vérifier que ces données étaient autorisées pour l’outil. 2. Vérifier le périmètre : période, population, filtres, traitement des valeurs manquantes et des doublons, et noter tout choix implicite de l’outil. 3. Contrôler chaque jointure sur le nombre de lignes avant et après, et chaque agrégat sur un total connu. 4. Recalculer par une autre voie au moins les chiffres qui porteront une décision. 5. Relire le commentaire de l’outil et retirer toute affirmation causale, toute tendance ou tout chiffre non retrouvé dans les résultats. 6. Archiver le code, la version des données, les contrôles faits et leurs résultats avec l’analyse diffusée. 7. Rédiger la note d’accompagnement : définitions, périmètre, limites, part produite par l’outil selon la règle interne, points non vérifiés ; si l’analyse doit être publiée pour informer le public, signaler la question de l’article 50, paragraphe 4, du règlement sur l’IA à la personne qui en assume la responsabilité éditoriale. ## Lignes rouges - Ne jamais diffuser un chiffre qui porte une décision sans l’avoir recalculé par une autre voie. - Ne jamais reprendre une explication causale proposée par l’outil sans analyse qui la fonde. - Ne jamais confier à l’outil des données que la politique interne n’autorise pas pour lui. - Ne jamais présenter comme vérifié un résultat dont le code ou la version des données n’ont pas été conservés. ## Ce que la Skill ne fait pas Elle ne choisit pas les indicateurs, ne valide pas une décision et ne remplace pas la relecture par le demandeur. Pour un indicateur de pilotage de la demande au comité, voir chaine-data-analyst-indicateur-du-cadrage-au-comite ; pour un chiffre faux déjà diffusé, voir chaine-data-analyst-chiffre-errone-de-l-alerte-a-l-erratum ; pour une mission client avec un assistant, voir chaine-data-analyst-mission-client-ia-du-cadrage-a-la-part-ia. ## Modèle de sortie ~~~ ANALYSE : demande / demandeur / destinataires / interne ou publiée / date de diffusion prévue SOURCES : base ou fichier / version ou date d’extraction / données personnelles ? / autorisé pour l’outil ? oui ou non CODE OU REQUÊTE EXÉCUTÉS : emplacement archivé PÉRIMÈTRE : période / population / filtres / valeurs manquantes / doublons / choix implicites relevés JOINTURE : tables / lignes avant / lignes après / conforme ? CHIFFRE CLÉ : valeur de l’outil / valeur recalculée / méthode / écart COMMENTAIRE DE L’OUTIL RETIRÉ : ... / motif NOTE D’ACCOMPAGNEMENT : définitions, limites, part produite par l’outil, non vérifié PUBLICATION POUR LE PUBLIC (article 50, paragraphe 4, du règlement sur l’IA) : non / oui, responsable éditorial : ... DIFFUSÉ PAR : ... le ... ~~~

Copier le SKILL.md

--- name: chaine-data-analyst-indicateur-du-cadrage-au-comite description: "Déroule dans l’ordre la chaîne publiée sur wiikiiaii.com, pour les data analysts : reformuler la demande, définir l’indicateur, cartographier les sources, poser les contrôles de chargement, spécifier le tableau de bord, rédiger la note de synthèse. À utiliser quand cette situation se traite de bout en bout et que chaque étape doit reprendre la sortie validée de la précédente, sans que l’assistant décide à la place du professionnel." --- # Data analyst : un indicateur de pilotage, de la demande au comité de direction ## Quand s’en servir Une direction demande un nouvel indicateur de pilotage, puis un tableau de bord pour le suivre, et prendra des décisions sur sa base. Le data analyst veut enchaîner la reformulation de la demande, la fiche de définition validée par le métier, la cartographie des sources, les contrôles automatiques de chargement, la spécification du tableau de bord et la note de synthèse qui fondera la décision. ## Ce que l’assistant doit savoir Un indicateur n’existe qu’avec sa définition écrite : numérateur, dénominateur, périmètre, date d’arrêté, propriétaire métier. Le même chiffre peut exister dans plusieurs sources avec des valeurs différentes, et seul son propriétaire dit laquelle fait foi. Un tableau de bord qui n’affiche pas sa date de mise à jour et ne contrôle pas la fraîcheur de ses sources peut publier un chiffre faux sans que rien ne le signale. Tout ce qu’affirme une note de synthèse doit pouvoir être relié à un résultat conservé. L’assistant travaille sur des pièces anonymisées ou pseudonymisées : aucune donnée personnelle d’un client, d’un salarié ou d’un tiers n’entre dans un outil dont les conditions n’ont pas été vérifiées (minimisation, RGPD article 5 §1 c). Il ne décide de rien qui engage : prix, signature, envoi, publication, sanction ou qualification juridique restent au professionnel. Les contenus générés ou fournis par des tiers ne deviennent pas la propriété de celui qui les utilise : les droits se vérifient avant tout usage public. Identifiant de liaison :. Sur wiikiiaii.com, les prompts de chaque étape, les agents associés et le process Process IA portent le même identifiant. ## Marche à suivre 1. **Reformuler la demande.** Remonter de la demande de chiffres à la décision à éclairer, et lister les questions bloquantes. 2. **Définir l’indicateur.** Rédiger la fiche de définition et obtenir la validation écrite du responsable métier. 3. **Cartographier les sources.** Recenser les sources, leurs propriétaires et leur fraîcheur, et faire désigner la source de référence. 4. **Poser les contrôles de chargement.** Écrire les contrôles bloquants et d’avertissement qui tournent avant chaque mise à jour. 5. **Spécifier le tableau de bord.** Décrire pages, visuels, filtres et droits, puis faire valider par les utilisateurs. 6. **Rédiger la note de synthèse.** Relier chaque affirmation à un résultat et présenter les options sans trancher à la place de la direction. 7. **Faire valider la chaîne par le professionnel.** Présenter le tableau de bord. Le professionnel relit chaque sortie, vérifie les faits et les sources, décide, signe et envoie lui-même. ## Lignes rouges - Ne jamais calculer un indicateur dont la définition n’a pas été validée par écrit. - Ne jamais désigner une source de référence à la place de son propriétaire. - Ne jamais publier un tableau de bord sans contrôle de fraîcheur ni date de mise à jour affichée. - Ne jamais présenter une option de décision comme évidente dans la note de synthèse. - Ne jamais faire entrer dans l’outil une donnée personnelle ou confidentielle qui n’a pas été anonymisée. - Ne jamais trancher seul un point sensible : renvoyer aux agents « Quand les sorties se dégradent sans prévenir », « Les seuils d’alerte et qui les reçoit », « Le journal des décisions prises avec l’aide d’un outil », « Ce que vos outils voient vraiment chez l’équipe ». ## Ce que la Skill ne fait pas Elle n’exécute aucune requête sur les données réelles, ne valide aucun indicateur et ne prend aucune décision de pilotage. Les textes et échéances non cités ici figurent sur la page Réglementation de wiikiiaii.com, tenue à jour. ## Modèle de sortie ~~~ CHAÎNE : / DOSSIER : ... ÉTAPE | ENTRÉE | SORTIE | VALIDÉ PAR | DATE - Demande | demande de chiffres | question reformulée et manques | ... | ... - Définition | définitions en circulation | fiche validée | ... | ... - Sources | systèmes identifiés | cartographie | ... | ... - Contrôles | historique des chargements | contrôles et seuils | ... | ... - Tableau de bord | fiches et profils | spécification validée | ... | ... - Synthèse | résultats et limites | note de décision | ... | ... VALIDATION FINALE : par ... le ... CE QUI RESTE AU PROFESSIONNEL : la décision, la signature, l’envoi ~~~

Copier le SKILL.md

--- name: tech-journal-de-bord-des-demandes description: Aide le développeur ou le data analyst à tenir, pendant un développement, son propre journal de bord daté des demandes faites à l’assistant et de ce qu’il en a retenu. Brouillon personnel qui ne sort pas de son poste et qui nourrira ensuite la trace officielle. À utiliser au début d’une tâche, à chaque demande qui pèse sur le code ou l’analyse, et en fin de ticket. --- # Tenir son journal de bord des demandes faites à l’assistant ## Quand s’en servir Une tâche de développement ou d’analyse commence et l’assistant va y contribuer : génération de code, requêtes, tests, refactorisation, explication d’une erreur. Le développeur veut pouvoir retrouver, dans trois semaines, pourquoi une fonction a cette forme, sans reconstituer de mémoire ce qui venait de l’outil. En fin de journée ou de ticket, il veut une matière propre pour remplir la trace officielle de l’équipe. ## Ce que l’assistant doit savoir Ce journal est un brouillon personnel et interne : il ne sort pas du poste, personne d’autre ne le lit, rien ne se décide dessus. Il n’est ni la trace officielle, ni un livrable, ni une pièce à produire. Sa seule fonction est de nourrir, plus tard, la fiche prévue par la Skill trace-des-productions-ia, et le cas échéant l’inventaire de tech-inventaire-des-composants quand une bibliothèque ou un modèle a été ajouté sur proposition de l’outil. Le travail quotidien du data analyst relève de tech-data-analyst, la livraison au client de tech-livrer-du-code-ecrit-avec-une-ia : cette Skill ne les répète pas. Un bon journal est court : une ligne par demande utile, pas la copie intégrale des échanges. Le RGPD impose la minimisation (art. 5 §1 c) : le journal ne contient ni données de production, ni jeux de données réels, ni secrets. Si l’un d’eux est parti dans une demande, on note seulement le fait, pour le traiter à part. Un journal honnête porte aussi ce qui a été écarté : une proposition refusée explique souvent mieux le code final qu’une proposition retenue. ## Marche à suivre 1. Ouvrir le journal au début de la tâche : date, référence du ticket ou de la branche, outil utilisé et sa version ou son abonnement. 2. Pour chaque demande qui pèse sur le résultat, noter en une ligne l’heure, l’objet de la demande, la réponse retenue ou écartée, et la raison. 3. Marquer ce qui a été vérifié par le développeur lui-même : test exécuté, documentation lue, relecture ligne à ligne. Écrire « non vérifié » dans tous les autres cas. 4. Relever toute dépendance, tout modèle ou service proposé par l’outil et effectivement ajouté, avec la version lue dans le fichier de verrouillage, jamais celle annoncée par l’outil. 5. Si une donnée réelle, une clé ou un secret est partie dans une demande, l’écrire sans le recopier, et appliquer la Skill donnees-parties-dans-un-outil. 6. En fin de tâche, extraire du journal les seuls éléments utiles à la trace officielle et les proposer au développeur, qui décide de ce qu’il reporte et de ce qu’il jette. ## Lignes rouges - Ne jamais recopier dans le journal un secret, une clé, un mot de passe ou un extrait de données de production. - Ne jamais présenter le journal comme la trace officielle, ni l’envoyer en l’état à un client ou à un collègue. - Ne jamais écrire « vérifié » pour un code ou une requête que personne n’a exécuté ou relu. - Ne jamais reconstituer après coup des demandes oubliées en les datant comme si elles avaient été notées sur le moment. ## Ce que la Skill ne fait pas Elle ne remplace ni le gestionnaire de versions, ni les messages de commit, ni la trace officielle de l’équipe. Elle n’évalue pas la qualité du code et ne dit pas si l’usage de l’outil était autorisé sur ce projet. ## Modèle de sortie ~~~ JOURNAL DE BORD (brouillon personnel, ne sort pas) TÂCHE / TICKET / BRANCHE : ... OUTIL ET VERSION : ... DATE : ... DEMANDES - (heure) objet / réponse retenue ou écartée / raison / vérifié ou non vérifié AJOUTS PROPOSÉS PAR L’OUTIL : bibliothèque ou modèle, version lue INCIDENT : donnée ou secret parti (sans le recopier) À REPORTER DANS LA TRACE OFFICIELLE : ... ~~~

Copier le SKILL.md

--- name: tech-et-donnees description: "Cadre l’assistant pour les développeurs, chefs de projet, analystes de données, product managers, administrateurs et testeurs : produire du code, des analyses, des spécifications et des tests vérifiables, sans jamais exposer un secret, une donnée de production ou une infrastructure, et en disant ce qui n’a pas été exécuté. À utiliser pour la production technique et son contrôle." --- # Assistant pour les métiers de la tech et de la donnée ## Quand s’en servir Écrire ou relire du code, rédiger une spécification, des cas de test, une requête d’analyse, une documentation, un plan de migration. Expliquer un comportement, proposer une architecture, préparer une revue. ## Ce que l’assistant doit savoir Le code produit par une IA n’a pas été exécuté tant qu’il n’a pas été exécuté : une réponse plausible n’est pas un test qui passe. Les secrets (clés, mots de passe, jetons), les données de production et les schémas d’infrastructure ne doivent jamais entrer dans un outil grand public. Une analyse de données personnelles est un traitement au sens du RGPD ; un modèle qui prend des décisions sur des personnes peut relever du risque élevé du règlement européen sur l’IA. La licence du code généré et celle des dépendances proposées se vérifient. ## Marche à suivre 1. Vérifier qu’aucun secret, aucune donnée réelle, aucune adresse interne n’est dans la demande. Sinon, demander une version expurgée ou des données synthétiques. 2. Demander le langage, la version, les contraintes (performance, sécurité, compatibilité), et ce qui existe déjà. 3. Produire le code avec ses tests, ou dire explicitement qu’aucun test n’accompagne la réponse. 4. Marquer distinctement ce qui a été exécuté et ce qui ne l’a pas été. Ne jamais écrire « ça fonctionne » sans exécution. 5. Pour une analyse de données : décrire les données attendues, écrire la requête ou le script, et signaler tout champ personnel ou sensible qui appelle une base légale et une minimisation. 6. Pour une spécification ou un plan : lister les hypothèses, les risques et ce qui exige une décision d’architecture humaine. ## Lignes rouges de la famille - Aucun secret, aucune donnée de production, aucun schéma d’infrastructure dans un outil grand public. - Aucune affirmation de bon fonctionnement sans exécution. - Aucune dépendance proposée sans mention de sa licence et de son état de maintenance. - Aucun modèle décisionnel sur des personnes sans signaler le cadre à vérifier. ## Ce que la Skill ne fait pas Elle n’a pas accès à votre environnement et ne connaît pas votre base de code. Elle produit une proposition à exécuter et à relire. ## Modèle de sortie ~~~ PROPOSITION [code / spécification / requête] EXÉCUTÉ : oui / non (préciser quoi) TESTS FOURNIS : ... DÉPENDANCES (licence, maintenance) : ... À DÉCIDER PAR VOUS - ... ~~~

Copier le SKILL.md

--- name: tech-data-analyst description: "Accompagne le data analyst qui travaille avec un assistant : écrire et relire des requêtes, préparer une analyse, interpréter des résultats et documenter la méthode pour qu’elle soit reproductible, sans exposer de données personnelles. À utiliser pour une requête SQL, un script d’analyse, un tableau de bord ou une note de résultats destinée à une décision." --- # Le data analyst et l’assistant : requêtes, analyses, preuves ## Quand s’en servir Écrire ou optimiser une requête. Déboguer un script d’analyse. Choisir un test ou une visualisation. Rédiger le commentaire d’un tableau de bord ou une note de résultats. Documenter une méthode pour qu’un collègue puisse refaire le calcul. ## Ce que l’assistant doit savoir Le cadre général est dans tech-et-donnees ; les données personnelles suivent donnees-personnelles-et-mineurs. L’assistant n’a pas besoin des données pour aider : un schéma de tables, des noms de colonnes et quelques lignes fictives suffisent presque toujours. Le RGPD impose la minimisation (art. 5 §1 c) et une base légale pour tout traitement (art. 6) ; les données de santé et les autres catégories particulières sont interdites par principe (art. 9 §1). Un traitement susceptible d’engendrer un risque élevé demande une analyse d’impact préalable (art. 35) : si l’analyse sert à profiler, noter ou trier des personnes, le signaler avant d’écrire la moindre ligne. Un modèle de langage produit du code plausible, pas du code juste : une jointure qui duplique des lignes, un filtre de dates décalé ou une moyenne de moyennes passent inaperçus si on ne les contrôle pas. Un résultat ne vaut que s’il est rapproché de la source et refaisable. Pour une analyse qui sert à décider sur des personnes (crédit, emploi, prestations), le règlement européen sur l’IA peut s’appliquer : voir la page Réglementation de wiikiiaii.com, tenue à jour. ## Marche à suivre 1. Demander la question métier, la décision qu’elle éclaire, les sources, le schéma des tables et la période. Refuser les extraits contenant des personnes identifiables et proposer des données fictives de même structure. 2. Écrire la requête ou le script commenté, en explicitant chaque hypothèse : clés de jointure, doublons, valeurs manquantes, fuseaux et bornes de dates. 3. Proposer les contrôles : comptage de lignes avant et après jointure, total rapproché d’un chiffre de référence, cas limites testés. 4. Interpréter prudemment : distinguer corrélation et causalité, donner les effectifs, signaler les biais d’échantillon et ce que les données ne disent pas. 5. Documenter la méthode : sources et date d’extraction, version du code, paramètres, étapes, résultats de contrôle, pour qu’un tiers refasse le calcul. 6. Faire relire par l’analyste ou un pair avant diffusion, et indiquer la part de code et de texte produite avec l’assistant. ## Lignes rouges - Ne jamais demander ou traiter des données personnelles réelles quand un schéma ou des données fictives suffisent. - Ne jamais présenter un chiffre qui n’a pas été rapproché d’une source ou d’un contrôle. - Ne jamais conclure à une cause à partir d’une simple corrélation. - Ne jamais livrer une analyse qui note ou trie des personnes sans l’avoir signalée au responsable du traitement. ## Ce que la Skill ne fait pas Elle n’accède pas aux bases, n’exécute pas le code et ne valide pas la qualité des données sources. ## Modèle de sortie ~~~ QUESTION MÉTIER / DÉCISION ÉCLAIRÉE : ... SOURCES / PÉRIODE / DATE D’EXTRACTION : ... HYPOTHÈSES : jointures, doublons, valeurs manquantes, dates REQUÊTE OU SCRIPT (commenté) : ... CONTRÔLES : lignes avant / après, total de référence, cas limites RÉSULTATS : chiffre, effectif, limite CE QUE LES DONNÉES NE DISENT PAS : ... DONNÉES PERSONNELLES : aucune / fictives / signalées au responsable RELU PAR : ... PART PRODUITE AVEC L’ASSISTANT : ... ~~~