Skills de Matt Pocock : la spécification avant le code

Le 3 février 2026, Matt Pocock, formateur connu pour ses cours Total TypeScript, a ouvert sur GitHub un dépôt de « skills », ces fiches d’instructions que les agents de programmation chargent à la demande. Son mot d’ordre : faire de la « vraie ingénierie », pas du « vibe coding », qui consiste à accepter le code généré sans le lire. Au 29 octobre 2026, le dépôt compte plus de 306 000 étoiles, l’équivalent d’un favori sur GitHub, et plus de 25 700 copies (forks). Selon la courbe de Star History, il avait franchi environ 200 000 étoiles début août, six mois après sa création.

Ce succès ne tient pas à des skills qui écrivent du code plus vite. Les plus populaires servent à parler avec l’agent avant qu’il code. Dans le développement agentique, le goulot d’étranglement n’est plus l’écriture du code, mais l’expression du besoin. Pour une direction qui pilote des projets logiciels, c’est un retour aux fondamentaux de la maîtrise d’ouvrage.

Ce que contient le dépôt

• Un départ modeste (international · GitHub) : le jour de sa création, le dépôt contient 7 skills, dont la rédaction d’un document d’exigences (« write-a-prd ») et le développement piloté par les tests (« tdd »). Il est publié sous licence MIT.
• Un diagnostic (Royaume-Uni · AI Hero) : réécrite le 28 avril 2026, la présentation du dépôt désigne le désalignement comme la panne la plus fréquente : on croit avoir été compris, puis on découvre ce qui a été construit. Le remède proposé est une séance de questions ; les skills qui la conduisent sont, selon l’auteur, ses plus populaires.
• Une chaîne de travail (international · GitHub) : la séance de questions (« grill-me » ou « grill-with-docs »), puis la spécification (« to-spec »), le découpage en tickets (« to-tickets »), l’implémentation pilotée par les tests (« implement »), la revue de code (« code-review ») et, pour finir, un bilan de session (« retro »).
• Des noms stabilisés à l’été (international · GitHub) : version 1.0 le 17 juin 2026 ; depuis la version 1.1 du 8 juillet, « to-spec » et « to-tickets » remplacent les anciens noms. Le paquet 1.3.2, publié le 29 octobre, distribue 27 skills.
• Plusieurs agents (international · GitHub) : installation documentée pour Claude Code (États-Unis · Anthropic), Codex (États-Unis · OpenAI), GitHub Copilot et Gemini CLI (États-Unis · Google).
• Une curation stricte (international · GitHub) : aucune proposition de nouveau skill n’est acceptée, et une demande de modification doit décrire une panne observée lors d’une session réelle.

Ce qui reste à démontrer

• L’usage réel : une étoile n’est pas un déploiement. À notre connaissance, aucune mesure publique ne relie ces skills à des gains de qualité ou de délai.
• La stabilité : le dépôt reflète la pratique d’une personne et change souvent ; des skills sont renommés ou retirés. Une équipe qui l’adopte hérite de ce rythme.
• La comparaison avec les cadres concurrents : à notre connaissance, aucune évaluation indépendante ne départage ces skills et Spec Kit (international · GitHub).

Le vrai enjeu : la spécification redevient le livrable

Le skill central, « grilling », décrit une méthode d’entretien. L’agent pose ses questions par séries, propose pour chacune la réponse qu’il recommande, et n’agit qu’une fois la compréhension partagée confirmée. Il cherche lui-même les faits dans le code et l’environnement, sans les demander à l’utilisateur. La règle est explicite : les faits sont le travail de l’agent, les décisions restent celles de l’humain. C’est le partage classique des rôles entre maîtrise d’œuvre et maîtrise d’ouvrage.

Le modèle de « to-spec » demande l’énoncé du problème du point de vue de l’utilisateur, une liste longue de récits utilisateurs (« en tant que…, je veux…, afin de… »), les décisions d’implémentation et de test, et ce qui est hors périmètre. La revue de code juge ensuite le résultat sur deux axes séparés : le respect des normes du dépôt, et la fidélité à la spécification. Le premier relève de la qualité ; le second ressemble beaucoup à une recette.

La présentation du dépôt oppose ces skills aux méthodes qui « possèdent le processus » et en nomme trois : GSD, BMAD et Spec Kit, la boîte à outils ouverte par GitHub en août 2025, qui dépasse 143 000 étoiles. Matt Pocock défend des briques petites et modifiables ; les deux approches convergent pourtant : la spécification précède le code. En septembre 2026, un entretien (international · The Pragmatic Engineer) posait d’ailleurs la question d’une « programmation stratégique », notion empruntée à l’informaticien John Ousterhout, comme avenir du métier de développeur.

Trois points de vigilance

1. Une spécification ne vaut que par la personne qui répond. La séance de questions interroge celui qui est devant l’agent. Si un développeur répond à la place du métier, la spécification enregistre des suppositions. Le dépôt prévoit d’ailleurs un skill, « to-questionnaire », pour adresser les questions à la personne qui détient la réponse.

2. La vitesse déplace le risque vers la recette. Quand le code arrive plus vite, la vérification devient le goulot. Une revue faite par un agent sur le travail d’un autre agent ne remplace pas la recette fonctionnelle par le métier, sur des cas réels.

3. Un skill tiers reste du code tiers. Installé comme extension, le paquet se met à jour seul : votre processus de développement peut changer sans décision de votre part. Figer la version et relire les changements s’imposent, comme pour toute dépendance.

Ce qu’une direction de projets logiciels doit exiger

1. Une spécification écrite avant toute génération de code : problème, solution, récits utilisateurs, hors périmètre, versionnée dans l’outil de tickets.
2. Le métier dans la séance de questions : celui qui décide répond ; le développeur arbitre la technique.
3. Des tickets courts et ordonnés : chacun livre une tranche vérifiable de bout en bout et déclare ce qui le bloque.
4. Un glossaire du projet : les termes métier, définis une fois et partagés par l’équipe comme par l’agent, avec un registre des décisions d’architecture.
5. Une recette à deux niveaux : une revue de conformité à la spécification, puis une validation par le métier sur des cas réels.
6. Un indicateur de délai : le temps entre une spécification validée et une livraison recettée, plutôt que le volume de code produit.
7. Des skills gérés comme des dépendances : version figée, relecture avant mise à jour, propriétaire désigné.

Un agent code ce qu’on lui dit ; la maîtrise d’ouvrage décide de ce qu’on lui dit.

La question à poser lundi matin

À votre chef de projet : « Pour le dernier ticket confié à un agent, qui a rédigé le besoin, qui a répondu à ses questions, et qui a recetté le résultat ? »