J’ai suivi la formation AI Hero de Matt Pocock. Ce que j’en retiens surtout, c’est l’importance de résister au réflexe d’implémentation immédiate. Avant de confier une fonctionnalité à un agent, il faut clarifier les décisions, lui donner les bonnes informations et définir un résultat vérifiable.
Prenons un cas fictif. Vous dirigez un SaaS B2B et demandez à votre équipe d’ajouter une fonctionnalité :
« Permettre à nos clients d’inviter leurs collègues dans leur espace de travail. »
La demande semble assez précise pour commencer. Un formulaire, un email, un lien d’acceptation. On imagine déjà l’interface.
Pourtant, plusieurs choix restent ouverts. Qui peut inviter ? Quels droits reçoit la personne invitée ? À quel moment consomme-t-elle une place dans l’abonnement ?
Un agent peut proposer des réponses et construire une solution cohérente avec ses hypothèses. Mais ces hypothèses engagent votre produit, vos clients et votre facturation.
C’est là que la méthode enseignée par Matt Pocock m’intéresse : prendre le temps de rendre ces choix explicites avant de lancer le développement.
Faire travailler l’IA sur les questions
Matt propose une technique appelée grilling. L’agent vous interviewe pour explorer une idée et mettre ses hypothèses à l’épreuve.
L’entretien suit un arbre de décisions. Certaines questions peuvent être traitées ensemble. D’autres doivent attendre qu’un choix précédent soit tranché. L’agent cherche lui-même les faits accessibles dans le projet, puis vous soumet les décisions qui demandent votre jugement. Le fonctionnement du grilling
Reprenons notre invitation.
Supposons que vous décidiez qu’un collègue invité consomme une place payante. Cette réponse ouvre une nouvelle question : quand cette place est-elle consommée ?
Si elle l’est dès l’envoi, une invitation jamais acceptée peut immobiliser une place. Si elle l’est à l’acceptation, plusieurs personnes peuvent recevoir une invitation alors qu’il ne reste qu’une place disponible.
Il faut alors décider ce qui arrive à la personne qui accepte trop tard.
Chaque réponse modifie la suite de la discussion. L’intérêt de l’entretien est de parcourir ces dépendances avant qu’un développeur ou un agent les résolve implicitement dans le code.
Pour un fondateur, cela rend visibles les arbitrages qui se cachent derrière une demande apparemment simple. Vous pouvez décider d’une première version plus limitée, reporter un cas complexe ou revoir la promesse faite au client.
Donner à l’agent des informations qu’on peut retrouver
L’entretien doit aussi s’appuyer sur ce qui existe déjà.
Dans notre scénario, le produit possède peut-être une gestion des rôles et des règles de facturation. L’agent doit pouvoir les retrouver avant de proposer un nouveau fonctionnement.
Cela demande de préparer le dépôt, c’est-à-dire l’ensemble du code et des fichiers qui accompagnent le projet. Une documentation contradictoire ou un ancien guide présenté comme actuel risque d’orienter son travail dans la mauvaise direction.
Matt recommande de garder le fichier d’instructions principal court et de renvoyer vers les ressources pertinentes selon la tâche. Ce principe de divulgation progressive évite de charger toutes les consignes à chaque intervention. Son guide sur AGENTS.md
Concrètement, un AGENTS.md ou un CLAUDE.md, selon l’outil utilisé, peut indiquer où consulter les règles métier, comment vérifier les changements et quelles conventions suivre. Les explications détaillées restent dans les documents concernés.
Pour notre invitation, l’instruction utile serait de consulter les règles d’abonnement avant de modifier la gestion des places.
Cela suppose aussi d’entretenir ces documents. Un lien vers une règle obsolète reste une mauvaise information, même dans un fichier parfaitement organisé.
Le critère qui m’intéresse est simple : une personne ou un agent qui découvre le projet peut-il retrouver les informations nécessaires à sa tâche ?
Garder la raison des décisions importantes
Une fois un choix tranché, il faut décider ce qu’on en conserve.
Le code montrera éventuellement qu’une place est consommée à l’acceptation d’une invitation. Il expliquera moins facilement pourquoi ce fonctionnement a été retenu.
C’est le rôle d’un ADR, pour Architecture Decision Record : un document qui conserve le contexte d’une décision, les options envisagées et les conséquences du choix.
Dans notre scénario fictif, si le modèle de consommation des places engage durablement le produit, ce document pourrait expliquer pourquoi l’équipe a retenu l’acceptation plutôt que l’envoi. Il préciserait aussi le compromis accepté concernant les invitations en attente.
Chez Matt, le format reste sélectif. Une décision devient un ADR lorsqu’elle est difficile à inverser, surprenante sans contexte et porte un véritable compromis. Toutes les réponses d’un entretien n’ont donc pas vocation à produire un document. La place des ADR dans sa méthode
Cette mémoire accompagne ensuite le code dans le dépôt. Elle donne au prochain intervenant une chance de comprendre le raisonnement avant de proposer de revenir dessus.
Passer des décisions à des livraisons vérifiables
Après le cadrage vient la spécification.
Dans la méthode de Matt, le skill to-spec synthétise les décisions déjà prises dans la conversation et les informations pertinentes du projet. Il publie cette spécification sous forme d’une issue dans l’outil de suivi configuré. Un skill est ici un ensemble d’instructions qui fait suivre une procédure à l’agent.
La spécification conserve le comportement attendu, les limites du périmètre et les choix nécessaires à l’implémentation. Elle permet à une nouvelle conversation de reprendre le travail. Il faut donc vérifier qu’elle restitue les réponses données pendant l’entretien. Le rôle de to-spec
Pour notre invitation, elle préciserait notamment qui peut inviter, les droits attribués et le comportement lorsque l’abonnement est complet.
Le travail peut ensuite être découpé en tickets verticaux. Chaque ticket vise un comportement vérifiable en traversant les couches techniques nécessaires. Matt appelle aussi ces petites réalisations complètes des tracer bullets. Le découpage avec to-tickets
Un premier ticket de notre scénario pourrait permettre à un administrateur d’inviter un collègue avec un rôle fixe, puis à ce collègue de rejoindre l’espace lorsqu’une place est disponible. Ce ticket comprendrait le parcours nécessaire et ses vérifications.
Un autre traiterait le cas où l’abonnement est complet au moment de l’acceptation. Son traitement dépendrait de ce premier parcours ; l’ordre serait explicite dans l’outil de suivi.
À chaque étape, on peut montrer un résultat et le confronter aux règles convenues. Cela donne aussi au dirigeant une façon concrète de comprendre l’avancement.
J’utilise souvent Linear pour suivre les tâches, ou GitHub Issues selon le projet. L’outil doit être défini et accessible à l’agent, avec des règles claires sur les statuts et les dépendances. L’équipe peut alors retrouver ce qui est prévu, ce qui bloque et ce qui reste à vérifier.
L’implémentation se termine par une vérification du comportement livré et une revue du changement. Le cadrage fournit les critères auxquels comparer le résultat.
Garder un cadrage proportionné
Cette démarche peut elle-même devenir excessive.
Une correction de libellé n’a pas besoin d’un entretien approfondi, d’un ADR et d’une série de tickets. La méthode de Matt prévoit d’ailleurs de passer directement à l’implémentation quand le changement tient dans une seule fenêtre de contexte, c’est-à-dire les informations qu’un agent peut traiter ensemble. La spécification devient surtout utile lorsque le travail dépasse cette capacité et doit être repris dans de nouveaux contextes. Quand utiliser to-spec
Il faut également accepter que certaines questions se règlent en essayant. Si l’équipe hésite sur la compréhension d’une interface, un prototype limité peut apporter plus qu’une longue discussion.
Le cadrage sert à identifier les choix qui conditionnent la suite et à décider comment les traiter. On peut trancher, aller chercher une information ou tester une hypothèse.
Cette approche intervient au moment où l’on transforme une demande encore floue en travail que l’on peut déléguer. Les permissions et les contrôles pendant l’exécution complètent ce cadrage.
Ce qu’il faut retenir
Ce que je retiens d’AI Hero, c’est la continuité entre ces pratiques. L’entretien fait émerger les décisions. Le dépôt donne accès aux informations utiles. Les ADR conservent certains arbitrages durables. La spécification et les tickets organisent ensuite leur mise en œuvre.
Pour un fondateur, l’intérêt est de pouvoir relier ce que l’équipe construit à des choix explicites, puis de vérifier le résultat au fil des livraisons. La quantité de cadrage doit dépendre des ambiguïtés et des conséquences du changement.
Conclusion
Sur votre prochaine fonctionnalité, commencez par demander à l’équipe quelles décisions restent ouvertes et lesquelles conditionnent les autres.
Pour notre invitation de collègues, les droits et la consommation des places changent directement le travail à réaliser. Les clarifier avant de coder donne à l’agent une demande sur laquelle il peut avancer, et à l’équipe des critères pour juger son résultat.
Pour mettre cette démarche en pratique sur votre produit, consultez mon accompagnement à l’usage de l’IA dans les équipes de développement, ou prenons 30 minutes pour examiner le fonctionnement de votre équipe.