L'IA au service de l'ingénierie : les skills de Matt Pocock

Aller vite vers nulle part

L’intégration des LLMs dans le travail quotidien des développeurs souffre de l’absence majeure de cadre. On n’utilise pas l’IA pour quelque chose de précis, pour une tâche déterminée comme adéquate à son usage ; non, on l’utilise simplement.

Quoi que vous fassiez, vous devez utiliser l’IA pour aller plus vite, résoudre les tickets plus vite et faire que votre employeur n’ait pas besoin d’employer un développeur supplémentaire, car vous en valez 3.

C’est l’approche à la fois la plus pauvre et la plus répandue de l’IA dans le monde du développement informatique. Elle me paraît être le syndrome de l’absence de considération pour le code et de la négligence de l’aspect d’ingénierie de nos métiers.

En tant que développeur, nous restons fascinés par l’IA et ce qu’elle nous permet de faire ; nous restons passionnés par sa capacité à anticiper les problématiques et à questionner nos choix architecturaux. Elle offre certainement une approche plus ambitieuse du développement que celles que nous avons pu connaître avant elle.

Cependant, le développement d’applications métier dans des contextes critiques reste un sujet d’ingénierie. Les applications doivent être durables, survivre aux nouveaux besoins, être fiables sur plusieurs années. Les modèles de données doivent pouvoir évoluer, ils doivent être compris et maîtrisés. C’est pourquoi nous ne pourrons jamais, dans un contexte d’entreprise, générer du code plus vite qu’on ne peut le comprendre. Certes, de plus en plus, il est possible de se passer de le lire, selon la sensibilité du périmètre d’intervention ; il n’en reste pas moins inévitable de le maîtriser.

Le prompt ne suffit pas

Les LLMs pour le développement sont ceux qui ont accès à votre système de fichiers et qui ont la capacité d’exécuter des commandes dans le terminal.

L’usage le plus courant des LLMs pour le développement est le débogage ou la génération de code de manière ponctuelle, parfois l’implémentation d’un ticket, l’auto-complétion assistée par IA, la génération d’un bout de code ou la réponse à une question sur la codebase « Quel endpoint permet de récupérer la liste des users de son organisation ? ».

Ces usages sont ceux qui sont les plus accessibles et rapides à appréhender en découvrant les LLMs pour le développement. Cependant, ils sont aussi des portes ouvertes à la destruction de votre codebase. En scalant ce genre de pratique, vous finissez par demander des features complètes avec de simples prompts, ou parfois même des prompts dûment détaillés ; mais le détail que vous aurez pensé à introduire dans votre prompt du lundi, vous l’aurez peut-être omis dans votre prompt du jeudi. C’est pourquoi la qualité du code généré ne doit jamais dépendre uniquement de votre prompt.

Comment ? L’établissement de règles, la base de tout ça consisterait à rédiger un AGENTS.md :

# AGENTS.md

## Contexte
[1-2 phrases sur le projet : stack, objectif, contraintes majeures]

## Style de code
- Ne jamais ajouter de commentaires dans le code.
  Si le besoin de commenter se fait sentir, c'est un signal : renommer les variables/fonctions, extraire une fonction, découper la classe ou le fichier plutôt que d'expliquer en commentaire.
- Respecter les conventions de nommage et l'architecture déjà en place dans le projet avant d'en introduire de nouvelles.

## Architecture
- Avant toute modification sur l'API, lire et respecter les règles décrites dans
  `docs/api-architecture.md`.
- Ne pas introduire de nouvelle dépendance ou de nouveau pattern architectural sans le signaler explicitement dans la réponse.

## Tests
- Faire passer les tests existants avant de considérer une tâche terminée.
- Ajouter ou mettre à jour les tests concernés par toute modification de comportement.

## Git & Commits
- Ne jamais commit sans demande explicite de l'utilisateur.
- Avant de contribuer, lire `CONTRIBUTING.md` et respecter les règles de conventional commits qui y sont définies.
- Ne jamais push ou ouvrir de PR sans validation explicite.

## Commandes
- Consulter `README.md` pour les commandes usuelles (install, build, lint, tests, run local).
- Ne pas halluciner de commande : si elle n'est pas documentée, demander avant d'inventer.

## Périmètre
- Ne pas modifier de fichiers hors du scope de la tâche demandée sans le signaler.
- En cas de doute sur une décision d'architecture ou de sécurité, s'arrêter et demander confirmation plutôt que de trancher seul.

C’est une très bonne chose de faite. Elle permet de stabiliser certains comportements. Votre agent devient légèrement plus prévisible.

Avec cet exemple le plus basique, je souhaite mettre le doigt sur une chose bien précise : ce qui rend votre assistant IA fiable et robuste, ce qui le rend plus proche d’un outil pour ingénieur que d’un jouet pour junior, est sa capacité à reproduire le même résultat pour une même demande. Avec ces règles établies, vous vous assurez qu’en demandant à votre LLM de corriger le bug du ticket #12345, il ne commitera rien, il ne commentera rien, le code qu’il proposera ne cassera pas les tests en place de l’application, le code qu’il proposera sera accompagné de tests pour le couvrir, le code qu’il proposera tiendra compte des contraintes d’architecture documentées dans docs/api-architecture.md, etc.

L'anatomie d'un Skill : l'ingénierie déterministe

Ainsi, maintenant que nous avons compris que le critère numéro 1 qui nous intéresse en tant qu’ingénieur est la reproductibilité d’une tâche à partir d’une même intention, nous souhaitons avoir mieux qu’un simple fichier markdown à la racine de notre projet pour garantir sa capacité à produire des résultats reproductibles.

C’est à ce moment-là que nous pouvons nous pencher sur l’outil le plus populaire des LLMs à ce jour : les skills.

Un skill n'est pas un garde-fou passif comme le fichier AGENTS.md. Il ne dit plus seulement « respecte l'architecture », mais il donne des guidelines précises : « suis ce plan d'action d'ingénieur étape par étape pour cette tâche ». Il va agir comme un verrou comportemental de l’agent, l’obligeant à agir d’une certaine façon selon le contexte et la demande.

skills.sh est une librairie de skills open-source.

Il existe des centaines de skills. L’erreur la plus courante est de penser qu’avoir un maximum de skills rendra votre IA surpuissante ; cependant, comme nous l’avons évoqué, ces skills agissent comme des contraintes de comportement : elles imposent des suites d’actions, des manières d’agir qui peuvent entrer en conflit entre elles.

C’est pourquoi il est préférable de limiter leur nombre au nécessaire. Aussi, pour éviter les risques de conflits tout en s’équipant correctement, il est préférable d’utiliser un package cohérent, comme le propose le repository de skills de Matt Pocock.

De l'interrogatoire au ticket : le pipeline Pocock

Les skills de Matt Pocock ne visent pas à rendre votre assistant IA surpuissant et capable de tout réaliser à partir d’un seul prompt rudimentaire. Au contraire, ce skill vise à réconcilier l’usage de l’IA avec l’ingénierie du logiciel.

Pour ce faire, elle impose une pipeline à vos agents qui correspond à une méthode fiable et reproductible de travail.

Capture d’écran de la vidéo A complete AI Coding workflow de Matt Pocock.

Ce pipeline d'exécution transforme un agent imprévisible en un moteur de génération déterministe grâce à une stricte séparation des responsabilités :

• Anti-improvisation (grill-with-docs) : ce skill empêche l'IA de combler les zones d'ombre avec des probabilités. Il la force à questionner et à neutraliser toute supposition bloquante avant d'envisager une solution technique.
• Sanctuarisation des décisions (to-spec) : le résultat de cet interrogatoire n'est pas perdu dans l'historique du chat. Les conclusions sont figées et converties en un contrat d'architecture formel et immuable.
• Externalisation de la connaissance (to-tickets) : la découpe en tickets verticaux sort la réflexion du huis clos entre le développeur et l'IA pour la rendre persistante. L'équipe peut ainsi auditer, critiquer et valider les solutions proposées. La conception verticale garantit également que chaque incrément peut être développé de bout en bout sans créer de dépendance circulaire.
• Exécution prévisible (implement) : lorsqu'on invoque enfin ce skill, l'IA ne réfléchit plus à l'architecture globale. Elle exécute une tâche ultra-ciblée (le ticket) adossée à un contrat validé (la spec). Le résultat devient mécaniquement déterministe et strictement aligné sur le besoin initial.

Un agent IA encadré par ce niveau de rigueur produit un code infiniment plus fiable et prévisible qu'un modèle laissé en roue libre dans une simple fenêtre de discussion.

Pour visualiser l'intégration de ce type de workflow en conditions réelles d'entreprise, j'ai modélisé l'organigramme suivant.

Organigramme de l’application du set de skills Matt Pocock à l’échelle d’une organisation.

• /triage fait passer les issues (et PR externes) par une state machine : needs-triage → needs-info / ready-for-agent / ready-for-human / wontfix, en vérifiant que le bug/la PR est réel avant de poster un brief pour un autre agent.
• /prototype est un code jetable, déclenché automatiquement par l'agent, pour trancher une question de design : soit une logique/state model (app terminal), soit plusieurs variantes d'UI (basculables par URL).
• /handoff compresse la conversation en cours dans un doc de passation pour qu'un autre agent reprenne le travail, en renvoyant vers les specs/tickets existants plutôt qu'en les dupliquant.

C’est un grand organigramme et il ne représente pas la manière dont vous devez travailler, mais plutôt un cadre idéal. Comme aucun cadre n’est idéal, vous ne serez probablement jamais amenés à travailler de cette manière de bout en bout dans une organisation. Notamment concernant la partie 4. Développement multi-agent, qui peut tout de même s’avérer être une catastrophe si l’ensemble des autres étapes n’est pas parfaitement maîtrisé, notamment la partie Revue validée.

Dans un contexte de développement assisté par IA, la résolution de ticket autonome n’est pas une fin mais une évidence au fil de l’augmentation de sa maîtrise. Beaucoup de tickets ne nécessitent pas de solliciter un être humain pour l’implémenter (seulement quand le scope a bien été défini, comme le permet la grilling session suivie de la traduction en spec puis en tickets verticaux de la suite de skills de Matt Pocock). Cependant, la review se doit d’être réalisée par des humains dans 100 % des cas, pas simplement pour garantir un code qui fonctionne et une absence de bug, mais pour garantir une maîtrise de la codebase et sa pérennité.

Le skill review dédié à l’IA ne doit lui servir qu’à faire une auto-critique du code généré par lui-même afin de proposer un code mieux fini en revue aux développeurs.

Conclusion : la rigueur avant l'outil

En définitive, confier ses besoins à une IA sans la contraindre aux réalités de la production est un risque majeur. Une IA utilisée hors sol, dépourvue de workflow rigoureux, détruit la maintenabilité d'un projet. À l'inverse, lorsqu'elle est traitée comme un collaborateur qui doit justifier ses choix et s'insérer dans une mécanique d'ingénierie stricte, elle devient un atout décisif. L'outil s'adapte à la rigueur de notre métier, et non l'inverse.

Tout se résume finalement à deux principes fondamentaux :

• la prévisibilité des actions garantit la fiabilité de l'outil,
• la maîtrise absolue du code soumis assure la pérennité de l'application.

La suite de skills de Matt Pocock se démarque des autres skills que l’on peut trouver parce qu’il est une démonstration concrète de cette interprétation dans le monde réel. Chaque skill qu’il contient s’inscrit dans une suite logique d’un processus de développement, tout en restant pour chaque skill un outil utilisable indépendamment des autres.