Skills IA : l'erreur qu'on a déjà faite avec l'agilité

Quand une équipe démarre son passage à l'IA agentique par la rédaction de trente skills partagés, elle ne structure pas sa pratique : elle tente d'acheter de la méthode sans payer le prix de la compréhension. C'est exactement ce que le monde du logiciel a déjà fait avec l'agilité, et on connaît le résultat.

Je vois ce schéma se répéter chez des prospects, des clients et dans mon réseau depuis quelques mois. Le mouvement est presque toujours le même : on découvre les agents de code, on comprend qu'il faut leur donner du contexte, et on en déduit qu'il faut écrire des skills. Beaucoup de skills. Le plus vite possible, pour que toute l'équipe en profite.

Créer des skills n'a rien de critique en soi. C'est même une bonne pratique quand il s'agit d'éviter de répéter la même chose vingt fois. Mais dans la plupart des cas que j'observe, ces fichiers servent à masquer un problème qu'on préfère ne pas regarder : personne n'a formé les développeurs à comprendre ce qu'ils font avec l'IA.

Le précédent que tout le monde a oublié

Rappelez-vous comment l'agilité s'est diffusée dans les entreprises. Plutôt que de former l'ensemble des équipes aux principes, de leur donner la capacité de choisir leurs propres pratiques et de les ajuster, on a formé des Scrum Masters. Ceux-ci ont déployé à peu près le même rituel partout : des sprints de deux semaines, un daily debout, un board à trois colonnes, une rétrospective qu'on saute dès que le planning se tend.

Et ça a marché. Pas d'ambiguïté là-dessus : passer d'un cycle en V, ou de l'absence totale de méthode, à quelque chose de cadencé et de réactif était un progrès réel. Les équipes ont livré plus souvent, les retours sont arrivés plus tôt.

Mais le gain a plafonné très vite, et bien en dessous de ce qu'une équipe qui aurait vraiment compris le sujet aurait obtenu. Une équipe qui saisit pourquoi la réactivité au changement compte n'a pas besoin qu'on lui impose des sprints : elle invente le rythme qui convient à son produit. Une équipe qui a compris la valeur du feedback ne saute pas la rétrospective quand ça chauffe, parce que c'est précisément là qu'elle en a le plus besoin.

Ce diagnostic n'est pas le mien. Martin Fowler, co-signataire du manifeste agile, l'a formulé en 2018 sous le nom d'Agile Industrial Complex : cette industrie de consultants et de managers qui imposent des « bonnes pratiques » au lieu de laisser les équipes décider de leur façon de travailler. Sa position, qu'il tenait déjà en 2006, est sans ambiguïté : il préfère une équipe travaillant de façon non agile mais choisie par elle-même, plutôt qu'une équipe à qui l'on impose ses pratiques favorites. Imposer un process à une équipe, dit-il, est frontalement contraire aux principes mêmes de l'agilité.

Le même mécanisme, vingt ans plus tard

Les skills reproduisent ce mouvement avec une fidélité troublante.

Ils sont intellectuellement plaisants à concevoir. Ils sont bien plus simples à appréhender que le vrai saut conceptuel de l'IA agentique, celui qui consiste à ne plus écrire ni relire chaque ligne de code. Et ils donnent la sensation grisante de pouvoir verser toute la connaissance des développeurs seniors dans quelques fichiers markdown, puis de la distribuer à l'équipe entière.

Le calcul implicite est le suivant : si le processus est figé dans le fichier, on économise le travail de faire comprendre la méthodologie. C'est le même raccourci qu'avec le Scrum Master, transposé à l'outillage.

Le problème apparaît chez les développeurs les moins expérimentés, et c'est là que le coût se paie. Un junior à qui l'on donne un skill applique. Il n'a aucune raison de comprendre pourquoi tel arbitrage a été retenu plutôt qu'un autre, parce que le fichier ne contient que la conclusion, jamais le raisonnement. Si on lui avait expliqué le pourquoi, le comment serait venu tout seul, et il aurait su quoi faire dans les vingt situations que le skill ne couvre pas.

Ce risque a un nom dans la littérature technique : le cargo cult, cette reproduction rituelle de structures dont on ignore la fonction. Ce qui est documenté dans le cas de l'IA, c'est que le dommage principal n'est pas l'erreur elle-même, mais la fausse confiance qu'elle installe. La règle qui circule dans les équipes matures est d'ailleurs limpide : n'acceptez jamais une production de l'IA que vous ne sauriez pas expliquer à quelqu'un de plus junior que vous.

Le critère qui sépare les bons skills des mauvais

Deux exemples tirés de mes propres outils, dont l'un à mes dépens.

J'ai écrit très tôt un skill de rédaction d'articles. Il décrivait la structure attendue, le ton, les règles de maillage interne. Je ne l'utilise pratiquement plus, et c'est une bonne nouvelle : à force d'écrire, j'ai compris bien plus finement ce qu'on attend d'un article, pour un lecteur humain comme pour le référencement. J'ai pu bâtir autour un système de documentation et de règles qui remplace avantageusement ce fichier initial. En cessant de m'appuyer dessus, j'ai été forcé de comprendre le domaine, et j'ai pu aller nettement plus loin que ce que le skill autorisait.

À l'inverse, le skill qui génère mes images via une API d'IA générative reste excellent. Il encapsule un appel technique, la gestion des credentials, le téléchargement et l'optimisation du fichier. Ce sont des étapes fastidieuses, sans valeur ajoutée intellectuelle, et parfaitement stables. Surtout, il ne fige aucun parti pris graphique : le style visuel change d'un projet à l'autre, et c'est moi qui le décide à chaque fois. Ce skill est une brique de base sur laquelle je construis, pas un moule dans lequel je coule.

La différence tient en une phrase : automatisez ce qui est mécanique, formez sur ce qui relève du jugement. Un skill qui vous fait gagner trente minutes de plomberie est un bon investissement. Un skill qui prend une décision à votre place est une dette de compétence.

« Mais on ne peut pas tout expliquer à quarante personnes »

C'est l'objection légitime, et je l'entends souvent. À l'échelle, on ne peut effectivement pas s'asseoir avec chaque développeur pour dérouler le raisonnement complet. Les skills ont là une vraie valeur de diffusion.

Ma thèse n'est pas qu'il faut choisir entre les skills et la formation. Elle est que les skills sans formation produisent une équipe qui exécute sans comprendre, et qui sera bloquée au premier cas non prévu. Le bon ordre consiste à faire comprendre le raisonnement à une équipe pilote, puis à laisser cette équipe écrire les skills qui codifient ce qu'elle a compris. Les skills deviennent alors la trace d'une compréhension partagée, et non son substitut. C'est précisément cette séquence que j'ai décrite dans le déploiement de l'IA agentique dans une équipe de quarante personnes.

Il y a aussi une question de calendrier. Le Scrum Master a été utile : il a fait passer des organisations entières d'un état à un autre. L'erreur n'a pas été de commencer par là, elle a été de s'y arrêter pendant vingt ans. Les skills peuvent parfaitement jouer ce rôle de béquille au démarrage. Ils deviennent un plafond le jour où plus personne ne se demande pourquoi ils disent ce qu'ils disent.

Ce que je regarderais dans votre situation

Si votre équipe accumule les skills depuis quelques semaines, posez trois questions. Combien de vos développeurs sauraient expliquer, sans ouvrir le fichier, pourquoi tel skill impose telle façon de faire ? Combien de ces skills encapsulent une mécanique plutôt qu'un jugement ? Et quand un cas sort du cadre prévu, que se passe-t-il concrètement ?

Si les réponses vous mettent mal à l'aise, le problème n'est pas dans vos skills. Il est en amont, et aucun fichier ne le résoudra. C'est d'ailleurs le même constat que je fais ailleurs : l'IA n'invente pas l'expertise, elle l'amplifie. Amplifier une compréhension absente ne donne rien.