Retour à tous les articles
Article

Agent Skills ou prompts : quand utiliser chacun

Auteur:

Un prompt formule une demande à l’IA ; un Agent Skill regroupe des consignes réutilisables. Un exemple de rapport hebdomadaire aide à choisir entre les deux.

Un dossier ouvert contenant une fiche d’instructions ajustée à son format

Chaque vendredi, vous demandez à un assistant IA de transformer vos notes de travail en bilan hebdomadaire. Vous répétez les mêmes règles : séparer le travail terminé des projets, garder les blocages visibles et ne jamais inventer de date limite. Les faits changent chaque semaine ; les règles du rapport restent les mêmes.

Un prompt enregistré peut suffire. Un Agent Skill devient intéressant lorsque vous voulez maintenir ces règles récurrentes sous forme de module réutilisable par un agent compatible. Un Skill ne remplace pas les prompts, ne fournit pas les faits manquants et ne garantit pas l’exactitude du rapport.

La présentation d’Agent Skills décrit un format fondé sur des dossiers pour partager connaissances et procédures réutilisables. C’est ici le sens technique de « Skill », et non l’affirmation que le modèle a acquis une nouvelle capacité par entraînement. Les détails du format ont été vérifiés le 7 septembre 2026.

Comparer ce qui reste fixe et ce qui change

QuestionPrompt pour une demandeAgent Skill
Où se trouvent les règles récurrentes ?Dans le texte fourni ou réutiliséDans un module d’instructions maintenu
Où se trouvent les faits de la semaine ?Dans l’entrée actuelleToujours dans l’entrée actuelle ou une source accessible
Exemples et modèles sont-ils possibles ?Ils peuvent figurer dans la demandeIls peuvent être joints comme ressources
Que doit prendre en charge l’application ?Recevoir la demande et l’entrée utilesDécouvrir et utiliser le Skill, avec les outils requis
Qu’est-ce qui prouve que le résultat est exploitable ?La vérification du rapportLes mêmes vérifications

Un prompt peut être long et réutilisable ; un Skill peut être court et ne contenir que des consignes. La longueur ne les distingue pas. La différence pratique tient à la façon de stocker, rendre disponible et maintenir la procédure récurrente.

Essayer la demande récurrente avant de créer un module

Voici des notes hebdomadaires fictives :

Brouillon de la page d’aide terminé lundi.
Relecture demandée à Mina ; aucune réponse à ce jour.
Publier après relecture. Aucune date de publication convenue.
Bug de recherche reproduit ; correction non commencée.

Pour un bilan ponctuel, cette demande décrit suffisamment le travail :

Transforme ces notes en bilan hebdomadaire avec trois sections :
Terminé, En attente d’un tiers et Prochaines tâches.
Préserve la différence entre travail terminé et travail prévu.
N’invente ni responsables, ni dates, ni validations, ni avancement.
Si un fait essentiel manque, indique qu’il n’est pas confirmé.

[Collez les notes de cette semaine.]

Un rapport affirmant « Mina a validé le brouillon ; publication vendredi » échoue deux fois. Demander un texte soigné n’autorise aucune de ces inventions. Vos repères sont les suivants : le brouillon est terminé, la relecture reste en attente, aucune date n’est convenue et le bug est reproduit mais non corrigé.

Si vous rédigez rarement ce bilan, enregistrez la demande dans un document et collez-la au besoin. Vous obtenez ainsi des instructions réutilisables sans nouvelle installation ni maintenance.

Un Skill isole la partie récurrente

Pour un agent compatible, les mêmes règles pourraient être placées dans SKILL.md, au sein d’un dossier weekly-update. La spécification du format exige un nom et une description dans des métadonnées YAML, suivis d’instructions Markdown.

Voici un exemple minimal de conception, ni Skill installé ni résultat de benchmark :

---
name: weekly-update
description: Transformer des notes de travail en bilan hebdomadaire factuel. À utiliser pour rédiger un rapport d’état récurrent à partir des notes fournies.
---

# Bilan hebdomadaire

Lire les notes fournies. S’il n’y en a aucune, les demander.

Rédiger trois sections :
- Terminé
- En attente d’un tiers
- Prochaines tâches

Séparer le travail prévu du travail terminé.
N’inventer ni responsables, ni dates, ni validations, ni avancement.
Signaler les informations essentielles manquantes comme non confirmées.
Avant de rendre le rapport, vérifier chaque état par rapport aux notes sources.
Rendre un brouillon ; ne l’envoyer à personne.

Les notes de la semaine ne doivent pas rester dans ces instructions. Si « Mina n’a pas répondu » est inscrit dans le Skill, ce fait peut être périmé dès la semaine suivante. Fournissez les faits nouveaux avec chaque demande et gardez le processus récurrent dans le module.

La demande du moment peut alors se concentrer sur l’entrée variable : « Utilise le Skill weekly-update pour rédiger le rapport de cette semaine à partir de ces notes. » L’agent doit encore trouver et suivre le Skill. Respectez les instructions d’installation et d’appel de votre client : créer un dossier quelque part sur l’ordinateur ne le rend pas automatiquement disponible.

Mettre en module ne remplace pas les tests

Le format permet de découvrir une brève description avant de charger les instructions complètes au besoin. De longues consignes réutilisables restent ainsi hors des tâches sans rapport. Cela ne prouve pas que chaque client activera le bon Skill quelle que soit la formulation.

Comparez le prompt enregistré et le Skill avec les mêmes notes fictives. Cherchez les faits exacts, pas seulement les bons titres. Retirez ensuite toutes les notes : la procédure demande-t-elle l’entrée manquante ou invente-t-elle un rapport ? Enfin, fournissez une relecture confirmée et vérifiez que seul l’état concerné change.

Ce sont des cas d’acceptation suggérés. Nous n’avons pas mesuré cet exemple sur plusieurs clients et ne revendiquons aucun gain de précision ou de vitesse. Le retour d’ingénierie d’Anthropic recommande lui aussi de partir de tâches représentatives et de problèmes observés plutôt que de supposer qu’un gros module est meilleur.

Un Skill peut également contenir des scripts. Lisez-les avant d’utiliser un module tiers, surtout s’il demande un accès aux fichiers ou des connexions externes. Des instructions pour rédiger un rapport ne sont pas du code qui l’envoie. La présence du module n’autorise pas toutes les actions qu’il mentionne.

Quand la maintenance d’un Skill vaut-elle la peine ?

Envisagez un Skill lorsque plusieurs éléments reviennent ensemble : règles de rapport, modèle, exemples acceptables ou procédure utilisant des outils. Un module maintenu offre un endroit unique pour les mettre à jour et répéter les contrôles après modification.

Conservez un prompt enregistré lorsque la tâche est occasionnelle, les règles brèves ou l’application incompatible. Déplacer des consignes ambiguës dans un fichier ne les clarifie pas. Obtenez d’abord un rapport vérifiable, puis séparez les règles récurrentes des faits qui changent chaque semaine.

Références