Skills d’agents : un workflow qui devient celui de l’équipe

Une skill, pour un agent IA qui écrit du code, est un ensemble d’instructions réutilisables que l’agent charge quand il rencontre une tâche récurrente : la procédure de migration maison, les conventions de tests, le format des notes de release, la façon dont on ajoute un endpoint dans votre API. Concrètement, c’est un fichier texte versionné dans vos repos, relu comme du code, et disponible pour tous les agents de l’équipe.

C’est le mécanisme le plus sous-estimé de l’ingénierie agentique, parce qu’il répond à un problème que toutes les équipes rencontrent au bout de trois semaines : chaque développeur réexplique les mêmes choses à son agent, session après session, et les bonnes façons de faire restent dans la tête de ceux qui les ont trouvées.

Une skill d’agent, concrètement

Prenez une tâche que votre équipe fait dix fois par mois, par exemple ajouter un endpoint. La skill décrit ce que votre documentation ne dit jamais tout à fait : où se rangent les fichiers, quelles conventions de nommage, quel format d’erreur, quels tests sont attendus et comment les lancer, quelles étapes de vérification avant d’ouvrir la pull request. L’agent qui charge cette skill produit du code qui ressemble au vôtre, du premier coup, au lieu d’un code plausible qu’il faut reprendre.

Les premiers candidats se repèrent facilement : ce sont les prompts que vos développeurs retapent. L’écriture de tests selon vos conventions (souvent la première délégation rentable), les migrations de schéma, la mise à jour des traductions, la préparation d’une release, le triage des erreurs remontées par le monitoring. Une tâche récurrente, cadrée, avec un résultat vérifiable : c’est le profil idéal.

Du workflow individuel au patrimoine d’équipe

Dans chaque équipe que nous croisons, il y a un développeur qui a trouvé une façon remarquablement efficace de faire travailler son agent. Sans mécanisme de partage, ce savoir-faire reste le sien, et il part avec lui.

Écrire la skill change la nature de ce savoir. Elle le rend explicite : formuler la procédure oblige à trancher des ambiguïtés que tout le monde contournait à l’oral. Elle le rend critiquable : une skill proposée en pull request, c’est le workflow d’une personne soumis à la revue de l’équipe, et il en sort presque toujours amélioré. Elle le rend cumulatif, surtout : la version de mars s’améliore en juin, et les nouveaux arrivants (humains comme agents) en héritent le premier jour.

C’est le même mouvement que la revue de code a opéré pour la qualité : un standard implicite devenu un artefact partagé.

Constituer la bibliothèque versionnée

Le fonctionnement qui tient dans la durée ressemble à ceci. Les skills vivent dans le repo, à côté du code qu’elles concernent, et suivent le même cycle : pull request, relecture, historique. Chaque skill a un propriétaire, celui qui répond de sa mise à jour quand la procédure change. On commence petit, trois à cinq skills issues des prompts les plus retapés, et on n’ajoute une skill que lorsqu’une tâche a été faite plusieurs fois : écrire la skill avant d’avoir la pratique produit de la fiction.

La forme compte. Une bonne skill est courte, spécifique et vérifiable : elle dit quoi faire, dans quel ordre, et comment vérifier que c’est fait. Les pavés de vingt paragraphes qui veulent tout couvrir diluent l’instruction utile, et l’agent les suit d’autant moins bien. Si votre skill dépasse une page, c’est probablement deux skills.

Ce chantier suppose une base de code où les vérifications existent : une skill qui dit "lance les tests" ne vaut que si les tests tournent vite et disent la vérité. C’est l’une des raisons de préparer la base de code avant d’industrialiser la délégation.

Les pièges à connaître

Le premier est la skill périmée : la procédure a changé, la skill non, et l’agent applique consciencieusement l’ancienne. Une skill fausse est pire qu’une absence de skill, d’où l’importance du propriétaire. Le deuxième est la duplication entre équipes, chacune maintenant sa variante de la même procédure : mutualisez ce qui est commun, gardez local ce qui est local. Le troisième est la bibliothèque musée, remplie de skills que personne ne charge : regardez l’usage, supprimez sans état d’âme.

Cette bibliothèque est ce qui reste quand nous partons : en ingénierie agentique, nous la constituons avec vos seniors, sur vos tâches réelles, et le savoir-faire de vos meilleurs développeurs finit en actif versionné dans vos repos, pas en souvenir.