PMania 5/6 - Apprendre à l'IA les règles de la maison : les skills

le 28/09/2026 par Reine Ramade

Tags: Product & Design, Product Management

PMania - Chroniques d'un PM augmenté par l'IA, épisode 5 sur 6

Quand un nouveau collaborateur arrive dans une équipe, on ne lui redonne pas les codes de l'entreprise à chaque réunion. On lui remet un livret d'accueil une bonne fois pour toutes, le vocabulaire maison, les process, le format des livrables attendus, et il s'y réfère ensuite tout seul. C'est exactement le rôle d'un skill pour une IA. Sauf que l'arrivant, cette fois, est un assistant ou un agent.

Skill vs contexte général : deux niveaux à ne pas confondre

Dans l'épisode 2, j'expliquais comment donner du contexte permanent à un assistant : un fichier d'instructions générales, un CLAUDE.md ou un AGENTS.md, qui décrit qui vous êtes, votre produit, votre façon de travailler. C'est le contexte de travail : large, général, toujours actif.

Un skill, c'est différent : c'est une compétence précise et récurrente, activée seulement quand la tâche le justifie. Prioriser des features, rédiger des user stories, préparer un atelier, définir un persona, chacune de ces compétences peut devenir un skill à part entière, avec sa propre méthode encodée une fois pour toutes.

Un skill bien construit répond toujours à quatre questions :

Quand l'utiliser ?
Que doit-il faire ?
Comment doit-il procéder ?
À quoi doit ressembler le résultat ?

Et comme pour tout livrable destiné à une IA, le format de référence reste le Markdown (.md), un langage de mise en forme simple, lisible aussi bien par un humain que par une machine, sans clic de bouton pour structurer un titre ou une liste.

💡 Tips : j'utilise Claude au quotidien, c'est donc son implémentation des skills que je prends en exemple dans cet épisode ; le principe reste le même chez la plupart des éditeurs, seul le nom du fichier change.

La vraie structure d'un skill

Techniquement, un skill n'est pas un simple prompt long : c'est un dossier, qui contient obligatoirement un fichier SKILL.md, et facultativement des scripts exécutables, des documents de référence ou des gabarits. C'est la structure définie par la spécification ouverte Agent Skills publiée par Anthropic fin 2025, aujourd'hui reprise par d'autres éditeurs (Microsoft, OpenAI, Atlassian, Figma, Cursor).

“mon-skill/
├── SKILL.md # obligatoire : en-tête de métadonnées + instructions
├── scripts/ # code exécutable
├── references/ # docs chargées à la demande
└── assets/ # gabarits, images”

Le SKILL.md lui-même se compose de deux parties : un en-tête de métadonnées (un nom, une description) et des instructions en langage naturel, rédigées en Markdown. Le détail qui change tout en pratique : c'est la description qui joue le rôle de déclencheur.
L’IA utilise le skill seulement quand elle reconnaît que la demande correspond à sa description. Cette description sert donc de repère : « aide à la priorisation » reste trop vague, tandis que « analyse d’avis stores, de verbatims utilisateurs ou bilan mensuel » indique clairement quand le skill doit être utilisé.

Exemple 1 : le skill « Roadmap Challenger »

Un exemple aide à comprendre la mécanique. Voici le contenu d'un SKILL.md conçu pour challenger une roadmap produit avant un comité :

“---
name: roadmap-challenger
description: Challenge une roadmap produit pour identifier risques, hypothèses et opportunités. À utiliser sur une review de roadmap, une priorisation, un arbitrage produit ou une préparation de comité produit.
—
## Procédure

### Étape 1 : Analyse des objectifs
Identifier : objectifs explicites, objectifs implicites,conflits potentiels

### Étape 2 : Analyse des hypothèses
Pour chaque initiative : hypothèse utilisateur, hypothèse marché, hypothèse technique

### Étape 3 : Analyse des risques
Identifier : dépendances, risques organisationnels, risques techniques, dette produit

### Étape 4 : Challenge
Proposer : ce qui pourrait être supprimé, ce qui pourrait être retardé, ce qui manque

## Quality Checklist
Avant de répondre :
- Ai-je identifié les hypothèses ?
- Ai-je identifié les dépendances ?
- Ai-je proposé au moins une alternative ?
- Ai-je relié chaque critique à un objectif business ?

## Format de sortie
Executive Summary / Risks / Assumptions /
Recommendations / Open Questions”

Ce qui frappe dans cette structure, c'est qu'elle ne dit rien du produit spécifique : elle encode une méthode, réutilisable sur n'importe quelle roadmap, tant que le contexte produit est fourni par ailleurs, via le contexte général ou en pièce jointe. C'est précisément cette séparation qui rend un skill puissant : la méthode est stable, le contexte varie. Pour un skill plus complexe, un skill qui doit par exemple exporter un référentiel métier à 30 thématiques avec des règles d'arbitrage, les dossiers references/ et assets/ prennent tout leur sens : on n'encombre pas les instructions elles-mêmes, on les charge à la demande.

Exemple 2 : le CLAUDE.md « racine », un vrai livret d'accueil

À un niveau plus large, un fichier de contexte général ressemble davantage à un livret d'accueil complet. Sans reproduire un exemple interne dans le détail, sa structure type couvre : le profil de l'utilisateur et son périmètre d'expertise, la langue et les règles d'écriture (accents obligatoires, encodage, langue par défaut), le style rédactionnel maison attendu sur tout livrable diffusé (phrases courtes, pas de superlatifs marketing, exemples concrets plutôt qu'abstraits), un lexique des acronymes et termes internes à l'organisation, et un style de collaboration explicite (réponses concises, pas de préambule, privilégier les solutions simples avant de complexifier).

Voici un extrait du mien, la section que tous mes assistants et agents lisent avant de produire quoi que ce soit :

“## Mon profil

Consultante Product Manager en cabinet, généraliste : audit,
delivery, cadrage, coaching, formation, parfois en parallèle.
Secteurs mixtes : public, luxe, énergie, start-up.

**Ce que je délègue le plus** : comptes rendus d'atelier et de
Réunion.

**Ce que je ne mets jamais par écrit** : un nom de personne hors tâche d'action, un chiffre sorti de son contexte.

## Instructions

1. Commence par me demander le why et l'attendu : objectif, destinataire, format. Si une info te manque ensuite, demande-la. N'invente pas, n'extrapole pas, ne comble pas un trou.

2. Écris en français. Anglais technique OK et naturel (EPIC,delivery, scope, MVP, kick-off, vélocité). Anglais marketing : jamais.

3. Structure : titre, intro, chapitres avec micro-intro,puces neutres ou tableau, conclusion, next steps.

4. Mets l'essentiel en gras, sur des groupes de mots. Avant de me rendre quoi que ce soit : les titres et le gras seuls doivent raconter le document.

5. Dépersonnalise. « John Doe soulève que A entraîne B » devient « B, du fait que A ». Exception : les tâches d'action, avec responsable et date.”

C'est là que la métaphore du livret d'accueil prend tout son sens : sans ce document, chaque nouvel arrivant, humain ou IA, redemande les mêmes bases. Avec, l'onboarding devient instantané, et surtout cohérent d'une personne à l'autre.

💡 Tips : ces fichiers .md (SKILL.md, CLAUDE.md) sont plus pratiques à garder dans un espace dédié que dans un chat. Je les organise dans Obsidian, où je peux à la fois prendre mes notes et retrouver facilement mes différents skills.

Exemple 3 : donner un vrai rôle à un agent

Un skill peut aller plus loin qu'une méthode : il peut définir une identité entière. Dans les frameworks agentiques les plus aboutis, chaque agent d'une équipe virtuelle porte une fiche de rôle qui précise son identité, son style de communication et ses principes de travail. Voici à quoi ressemble une fiche de rôle pour un agent « Product Manager » :

“---
name: product-manager
role: Product Manager senior
—

## Identité
Garant de la valeur utilisateur avant la faisabilité technique. Parle au nom des utilisateurs finaux, pas au nom de l'équipe de delivery.

## Style de communication
Direct, factuel, jamais complaisant. Pose des questions avant de valider une décision.

## Principes de travail
- Ne jamais accepter une spec sans être passé par des interviews utilisateurs.
- Toujours poser la question « pourquoi » avant de valider une solution.
- Refuser un scope qui sacrifie l'utilisateur pour tenir une date : on coupe, ou on décale.”

C'est la même logique qu'un skill de méthode, mais appliquée à un rôle entier plutôt qu'à une seule tâche : la méthode devient une posture, stable d'une session à l'autre.

Comment créer son premier skill

La meilleure porte d'entrée reste un process déjà écrit et validé : une grille de priorisation qui existe déjà sur un tableau blanc, un template de compte-rendu que tout le monde utilise sans le documenter formellement.

Choisissez un process récurrent et déjà validé, pas une méthode encore incertaine : on n'encode pas une hypothèse, on encode un savoir-faire éprouvé.
Répondez aux quatre questions structurantes : quand l'utiliser, que doit-il faire, comment procéder, à quoi ressemble le résultat, et traduisez la première en description de déclenchement, pas en titre vague.
Formalisez en Markdown, avec des étapes numérotées et une checklist de qualité avant la sortie. Bonus : la plupart des outils qui gèrent les skills savent en créer un à partir d'un skill dédié à cet effet, inutile de partir d'une page blanche.
Testez-le sur un cas réel, et ajustez ce qui manque, un skill se peaufine par l'usage, pas en une fois.

Huit points reviennent systématiquement dans les skills qui fonctionnent, à vérifier avant diffusion :

Instruction	Critère de qualité
name : identifiant en minuscules avec tirets	Stable : on ne le renomme pas après diffusion.
description : ce que fait le skill et quand l'utiliser	Seul mécanisme de déclenchement : tout le « quand » y vit, jamais dans le corps.
Une description qui pousse, pas qui décrit	Le défaut le plus fréquent reste le sous-déclenchement : mieux vaut écrire « utilise systématiquement ce skill dès que la demande touche X, Y ou Z, même sans citer le mot Z ».
Le pourquoi de chaque règle, explicité	Une règle expliquée se suit mieux qu'une règle en majuscules : des MUST et des ALWAYS partout signalent un skill mal écrit.
Un format de sortie donné en gabarit	Le plan exact du livrable, écrit tel quel dans le skill.
Deux ou trois exemples entrée/sortie	Ils valent mieux que dix lignes d'explication.
Des pointeurs explicites vers les ressources	« Lis references/gabarit-cadrage.md avant de rédiger » : sans pointeur, le fichier n'est jamais ouvert.

À l'échelle d'une équipe entière plutôt que d'une seule personne, la même logique se rejoue en plus structuré :

on identifie les domaines d'activité du cycle de vie produit qui gagneraient à être outillés (recherche utilisateur, rédaction de user stories, priorisation),
on découpe chaque domaine en sous-activités skillables,
on vérifie qu'un savoir-faire spécifique à l'équipe justifie vraiment d'en faire un skill plutôt que de réinventer ce qui existe déjà dans les bibliothèques publiques,
puis on le valide avec les experts du domaine avant de l'ajouter au catalogue commun.

C'est exactement la démarche que nous sommes en train de structurer chez OCTO dans l’Atelier Produit & Design : industrialiser la capitalisation, sans perdre la touche métier qui fait la valeur de chaque skill.

Le vrai bénéfice : la cohérence d'équipe, pas d'une personne

C'est le point que je retiens le plus de cet exercice : sans skill, chaque usage repart de zéro, et le résultat dépend entièrement de la qualité du prompt de la personne qui l'a écrit ce jour-là. Avec un skill partagé, l'expérience devient cumulative : le savoir-faire d'une seule bonne session de priorisation profite à toute l'équipe, indéfiniment, sans qu'on ait à reformer chaque nouveau membre.

“Un skill transforme un savoir-faire individuel en réflexe collectif.”

C'est un changement discret, mais c'est probablement le levier le plus sous-estimé de toute cette série.

Ce qu'il faut retenir

Un skill transforme un savoir-faire d'équipe en réflexe : ce n'est pas la même chose qu'un contexte général permanent.
Sans skill, chaque usage repart de zéro ; avec, l'expérience devient cumulative à l'échelle de toute l'équipe.
Un bon skill répond à quatre questions : quand l'utiliser, que doit-il faire, comment procéder, à quoi doit ressembler le résultat.

Commencez par un process déjà écrit et validé par l'équipe, pas par une méthode encore incertaine.

Il ne reste plus qu'à assembler toutes les pièces de cette série, l'IA dans nos dossiers, les agents, les specs, les skills, dans un seul workflow, de bout en bout. C'est l'objet du dernier épisode.

PMania, chroniques d'un PM augmenté par l'IA