Le mois dernier, j'ai perdu la majeure partie d'un vendredi à cause d'un skill Claude Code « battle-tested » que quelqu'un avait balancé sur un Discord. Quatre cents étoiles. Le README avait un diagramme. Il avalait aussi chaque erreur de l'API qu'il encapsulait, si bien que quand cette API a commencé à retourner des 429, mon agent a continué sa route. Avec aplomb. En écrivant des données inutilisables dans une vraie table que j'ai dû nettoyer à la main.
C'est un skill bâclé. Et le repérer avant qu'il ne touche quoi que ce soit d'important est devenu discrètement une partie du métier. Il y en a des milliers maintenant, et ils ont tous l'air parfaits sur une capture d'écran.
Voici la liste que je parcours avant de faire confiance à un AI agent skill, un serveur MCP ou une règle Cursor. Pas de la théorie. Ce que j'aurais voulu vérifier avant ce vendredi-là.
Ce qu'est vraiment un skill bâclé
Un skill bâclé affiche une compétence qu'il n'a pas. Il est conçu pour être adopté, pas pour survivre au contact de la production. Bon nom, README confiant, gif de démo où le soleil brille toujours. Puis il s'effondre à la seconde où la réalité cesse d'être le chemin heureux.
Le signe révélateur, c'est l'écart entre son apparence soignée et à quel point il a réellement été mis à l'épreuve. Le code qui tourne en production depuis un moment porte des cicatrices : des clauses de garde bizarres, un commentaire qui dit « ne supprimez pas ça, leçon apprise à la dure », un retry que quelqu'un a clairement ajouté à 2 h du matin. Le bâclé n'a rien de tout ça. Il a une bonne rédaction.
On le voit partout — skills Claude Code, règles Cursor, serveurs MCP, templates d'agents. N'importe qui peut en publier un en une après-midi, et un modèle écrira volontiers un README convaincant pour l'accompagner. L'offre est montée en flèche. La qualité n'a pas bougé.
Comment évaluer un AI agent skill : le contrôle en 5 points
Je ne lis pas tout de haut en bas. Je pars à la chasse aux odeurs spécifiques, dans cet ordre.
1. Gère-t-il le chemin malheureux ? Je fais un grep pour la gestion des erreurs avant de lire la moindre logique principale. Pas de try/catch, pas de branches d'erreur, pas de retry, pas de timeout ? Alors il a été écrit face à un démo et testé face à un démo. Un skill incapable de dire au modèle « ça a échoué, voilà pourquoi, arrête » laissera votre agent halluciner en plein échec. C'est le genre dangereux. Il ne plante pas. Il ment, et il le fait avec brio.
2. Dit-il au modèle quand NE PAS agir ? Presque personne ne vérifie ça. Un bon skill intègre des limites dans ses instructions : quand se retirer, quand demander d'abord, ce qu'il ne faut jamais toucher. Le bâclé ne décrit que ce qu'il fait bien. Pas de « en cas de doute, arrête-toi ». Donnez ça à un agent autonome et vous avez mis un outil électrique entre les mains de quelque chose qui ne sait pas où sont ses propres mains.
3. Les inputs sont-ils validés ou simplement supposés ? Trouvez où les données entrent. Est-ce que quelque chose est vérifié ? Le bâclé suppose que le modèle retourne toujours du JSON propre, que le fichier existe toujours, que le champ est toujours rempli. La production, c'est exactement là où ce champ revient null pendant que vous dormez.
4. Quel est le dernier commit, et qu'était-il ? Un skill qui n'a pas été touché depuis huit mois, assis au-dessus d'outils qui publient des changements cassants chaque mois, est un fossile. Lisez aussi ce que les commits disent réellement. Tout « update README » et aucun « fix edge case » ? Personne ne l'exécute vraiment. L'usage réel génère de vraies corrections de bugs. L'historique des commits vous dira la vérité que le README ne dira pas.
5. Quel est le rayon d'explosion ? La question la plus bête, le plus grand gain. Qu'est-ce que cette chose peut réellement toucher ? Un skill qui prétend formater vos messages de commit mais détient discrètement un accès en écriture à tout le dépôt plus une sortie réseau est une responsabilité déguisée en assistant utile. La portée doit correspondre au travail. Quand elle ne correspond pas, toute l'histoire est là.
La plupart de tout ça est rapide. Quelques grep et un coup d'œil à l'historique des commits permet d'attraper les déchets évidents avant d'y avoir investi du vrai temps.
La partie qui coûte vraiment
Voilà ce qu'on peut dire sur l'évaluation correcte des skills. L'audit n'est pas difficile. C'est le volume qui use, et ça ne s'arrête pas.
On ne vérifie jamais un seul. On choisit parmi neuf qui prétendent tous faire le même travail, et ils sont éparpillés. GitHub. Deux Discord différents. Quelques listes « awesome-skills » devenues obsolètes au printemps. Un fil Reddit. Le billet de blog de quelqu'un. Chaque candidat veut le grep, le reniflage de commit, la vérification de portée, l'onglet issues pour voir si quelqu'un a déjà rencontré le bug qu'on craint. Chacun est une nouvelle pile d'onglets.
J'ai essayé d'en faire le compte une fois. J'avais besoin d'un skill correct pour une intégration MCP. Trouver les candidats, ouvrir chaque dépôt, lire les parties suspectes, vérifier les issues, déterminer quel fork était actif et lequel était abandonné. J'ai compté quelque chose comme neuf heures sur deux jours. Pour un seul emplacement dans ma chaîne d'outils.
Et la réponse devient obsolète. Le skill que j'ai choisi était solide en mai. L'est-il encore ? Aucune idée, et rien ne me le dit. Les étoiles sont un vote de popularité figé dans le passé. Les comptages de téléchargements ne savent pas si la chose a cassé mardi dernier quand l'API upstream a changé la forme de sa réponse. Il n'y a nulle part de signal pour « celui-ci a commencé à échouer cette semaine ». Alors je ferai tout l'audit à nouveau le trimestre prochain, depuis zéro.
Chaque développeur à qui j'ai parlé de ça décrit la même routine. L'ouvrir, lui faire un grep, plisser les yeux sur les commits, espérer. Seul. Les notes de personne ne passent à personne d'autre. On redécouvre chacun en privé, un vendredi gaspillé à la fois, que le même skill populaire avale silencieusement ses erreurs.
À retenir
La liste fonctionne. Gestion des erreurs. Conditions d'arrêt. Validation des inputs. La vérité dans l'historique des commits. Rayon d'explosion. Faites-les tourner et vous éviterez la plupart des dégâts. Collez-les au-dessus de votre moniteur si vous voulez.
Mais faites-les tourner pendant quelques mois et le vrai problème émerge. La recherche n'est pas la partie coûteuse. La chasse l'est, et le fait que vous la faites seul, à chaque fois, contre une liste que personne ne maintient à jour.
Un skill qui a l'air prêt pour la production et un qui l'est vraiment sont à environ dix minutes de lecture l'un de l'autre. Le problème, c'est que presque personne n'a dix minutes tranquilles et un endroit de confiance où commencer.
Vérifiez le rayon d'explosion en premier. C'est la question la moins chère, et c'est celle qui m'a sauvé quand aucune autre ne l'avait fait.