Sommaire
Série « Apprendre à coder avec l’IA » — Article 3/7
RSS
Le RSS envoie les nouveaux articles dans le lecteur de votre choix, sans algorithme ni newsletter.
TL;DR
Un skill peut rendre une méthode de travail réutilisable. Il ne garantit ni l’exactitude technique ni la compatibilité avec ton projet. Avant de l’installer, inspecte sa source, ses instructions, ses scripts, ses versions et ses effets. Commence avec peu de skills et adapte-les à l’existant.
Un skill n’est pas une compétence magique téléchargée dans l’agent
Le terme donne parfois une fausse impression.
On installe un skill React, un skill TypeScript ou un skill de sécurité, puis on suppose que l’agent connaît désormais les meilleures pratiques de ces technologies.
En réalité, un skill est surtout un ensemble d’instructions, de ressources et parfois de scripts permettant à un agent de reproduire une méthode spécialisée. La documentation de Claude Code et celle de Codex détaillent leurs mécanismes actuels.
Un skill peut être excellent, dépassé, trop général, dangereux ou simplement incompatible avec ton dépôt.
Il ne remplace donc pas la documentation officielle. Il organise une manière de travailler avec elle.
Règle de projet, documentation et skill : trois rôles différents
Pour éviter la confusion :
| Élément | Rôle principal | Exemple |
|---|---|---|
| Documentation officielle | Décrire le fonctionnement actuel d’une technologie | App Router, TypeScript, tests Next.js |
AGENTS.md ou CLAUDE.md |
Conserver les conventions durables du dépôt | commandes, architecture, interdictions |
| Skill | Décrire un workflow spécialisé et réutilisable | revue React, audit sécurité, création de tests |
Mettre toute la documentation React dans le fichier de règles du dépôt gaspille du contexte. Transformer une simple convention de nommage en skill séparé complique inutilement le projet.
Le bon mécanisme dépend de la portée de l’instruction.
Où chercher en priorité
On recommande cet ordre :
- Les skills et exemples officiels de l’éditeur de l’outil.
- La documentation officielle de la technologie concernée.
- Les ressources maintenues par une organisation reconnue.
- Les skills communautaires inspectés manuellement.
- Un skill créé spécifiquement à partir des besoins réels du projet.
Un nombre d’étoiles ou de téléchargements peut signaler une adoption. Il ne prouve pas que les instructions sont correctes aujourd’hui.
Pour notre dashboard, les références techniques resteront React, Next.js et TypeScript. Le skill doit orienter l’agent vers ces sources, pas les réinventer.
La grille d’inspection avant installation
Avant d’ajouter un skill, réponds à ces questions.
La provenance
- Qui le maintient ?
- Le dépôt ou l’auteur est-il identifiable ?
- Existe-t-il un historique de modifications ?
- La licence autorise-t-elle son utilisation ?
L’actualité technique
- Quelles versions de React, Next.js et TypeScript sont visées ?
- Le skill distingue-t-il App Router et Pages Router ?
- Les commandes proposées existent-elles encore ?
- Les liens pointent-ils vers des références officielles ?
Les actions possibles
- Contient-il des scripts exécutables ?
- Installe-t-il des dépendances ?
- Accède-t-il au réseau ?
- Peut-il lire des variables d’environnement ou des fichiers sensibles ?
- Modifie-t-il la configuration globale de l’outil ?
La compatibilité
- Respecte-t-il l’architecture existante ?
- Impose-t-il une bibliothèque concurrente de celle déjà utilisée ?
- Contredit-il les règles du dépôt ?
- Suppose-t-il la présence d’outils absents ?
Si tu ne comprends pas un script, ne l’exécute pas simplement parce qu’il accompagne un skill.
Le piège des skills contradictoires
Imaginons quatre skills installés :
- l’un impose Jest ;
- l’autre configure Vitest ;
- le troisième demande de tester tous les composants par snapshots ;
- le quatrième privilégie uniquement les tests de comportement.
L’agent dispose de plus de contexte, mais pas d’une meilleure direction.
Les contradictions augmentent le bruit et rendent les décisions difficiles à expliquer. Pour un junior, deux ou trois workflows fiables sont plus utiles qu’une collection de vingt skills.
Les skills utiles pour notre mini-dashboard
On commencerais avec trois besoins, pas nécessairement trois packages externes :
Une revue TypeScript
Objectif : repérer any, les assertions risquées, les types trop larges et l’absence de validation aux frontières externes.
Une revue React et Next.js
Objectif : vérifier la responsabilité des composants, l’emplacement de la récupération des données et les frontières client/serveur.
Une stratégie de tests
Objectif : partir des comportements attendus, choisir le bon niveau de test et éviter les assertions qui ne prouvent rien.
Si aucun skill fiable ne correspond exactement à ces besoins, mieux vaut écrire une procédure courte adaptée au dépôt.
Créer un skill minimal à partir d’un problème réel
Un bon premier skill pourrait formaliser la revue d’une carte de métrique :
# Revue d’une métrique du dashboard
## Objectif
Vérifier qu’une métrique externe est typée, validée, affichée et testée correctement.
## Procédure
1. Identifier la forme reçue depuis l’API.
2. Vérifier la validation à l’exécution.
3. Contrôler le traitement des valeurs absentes et hors limites.
4. Examiner les états chargement, succès et erreur.
5. Vérifier au moins un test nominal et un test d’erreur.
6. Produire les observations avant de proposer des modifications.
Ce skill n’essaie pas d’enseigner tout React. Il transforme un contrôle précis en workflow reproductible.
Tester un skill sans lui confier le projet
Commence par une tâche en lecture seule :
Applique le workflow de revue TypeScript à `MetricCard.tsx`.
Ne modifie aucun fichier.
Pour chaque observation :
- cite le code concerné ;
- explique le risque ;
- classe la priorité ;
- propose une vérification.
Évalue ensuite le résultat : les remarques sont-elles exactes, spécifiques et compatibles avec le dépôt ? Le skill ignore-t-il des règles importantes ? Produit-il du bruit ?
Ce test limité permet de corriger le workflow avant qu’il influence toute l’application.
Adapter au lieu de remplacer
Sur un projet existant, commence toujours par l’inventaire : dépendances, conventions, scripts, tests et décisions d’architecture.
Si le dépôt utilise déjà Vitest, un skill ne doit pas installer Jest sans raison. Si une validation de données existe déjà, il doit l’utiliser. Si une règle est propre à un sous-dossier, elle ne doit pas nécessairement s’appliquer partout.
Le skill sert le projet. Le projet ne doit pas se déformer pour satisfaire les préférences du skill.
Un garde-fou, pas une preuve de qualité
Un bon skill réduit les erreurs répétitives et rend une méthode explicite. Il ne rend pas le contrôle humain facultatif.
La compétence du junior se construit justement lorsqu’il apprend à décider : cette instruction est-elle correcte, actuelle, utile et vérifiable ?
Dans le prochain article, nous utiliserons Claude Code ou Codex comme professeur : l’agent donnera des indices, relira nos tentatives et nous aidera à comprendre sans prendre immédiatement le clavier.
