Imaginez que vous venez d'inviter un assistant robotique super intelligent et incroyablement rapide dans votre chambre pour vous aider à construire une cabane dans un arbre. Ce robot connaît tout sur le bois, les clous et la physique, mais il ne connaît pas votre style spécifique. Il ne sait pas que vous peignez toujours la rambarde en bleu, ou que vous avez une règle bizarre consistant à n'utiliser jamais de clous de moins de deux pouces. Si vous voulez que le robot construise la cabane exactement comme vous l'aimez, vous devez le lui dire. Mais si vous devez expliquer chaque petit détail à chaque fois que vous demandez de l'aide, vous serez épuisé, et le robot pourrait être confus.

C'est le monde des « Agents IA » — des programmes informatiques intelligents qui accomplissent des tâches pour nous. Pour qu'ils soient vraiment utiles, les développeurs leur donnent des « Compétences » (Skills). Considérez une Compétence non pas comme un sort magique, mais comme un petit manuel d'instructions ou une boîte à outils que vous remettez au robot. C'est un fichier qui dit : « Hé, quand tu vois un travail comme celui-ci, voici exactement comment je veux que tu le fasses. » La grande question que les scientifiques et les ingénieurs se posent est la suivante : comment écrire ces manuels pour que le robot les suive réellement ? Si nous les écrivons mal, le robot pourrait les ignorer ou rater son travail. Si nous les écrivons bien, le robot devient un véritable expert de votre façon de faire.

Le document que vous allez lire, écrit par Giuseppe Destefanis, soutient que l'écriture de ces « Compétences » ne doit pas être traitée comme l'écriture d'une note informelle ou d'un poème. Au contraire, cela doit être traité comme du génie logiciel. Tout comme un programmeur construit une application fiable avec des règles claires, un code propre et des contrôles de sécurité, nous devrions construire les Compétences IA avec ce même soin. Le document suggère qu'une Compétence est en réalité un morceau de logiciel déguisé. Elle possède une « interface » (une étiquette qui vous dit ce qu'elle fait) et une « implémentation » (les instructions réelles). L'auteur propose d'utiliser les mêmes règles strictes que celles que nous utilisons pour construire des programmes informatiques — comme garder les choses simples, séparer le « quoi » du « comment », et les tester soigneusement — pour s'assurer que nos agents d'IA ne partent pas en vrille.

La « Compétence » comme un couteau suisse numérique

Imaginez que vous avez un sac à dos géant et magique qui peut contenir n'importe quoi. À l'intérieur, vous avez une poche spéciale pour « Faire les notes de version ». Cette poche n'est pas juste un morceau de papier ; c'est un kit complet. Il y a une étiquette sur l'extérieur qui dit : « Utilisez-moi lorsque vous devez rédiger un résumé des changements pour une nouvelle version d'un jeu. » Cette étiquette est l'interface. Le robot regarde l'étiquette, voit une tâche qui correspond, et décide d'ouvrir la poche.

À l'intérieur de la poche, vous ne jetez pas simplement un tas de notes désordonnées. Vous avez une recette claire, étape par étape (le corps) et peut-être quelques outils supplémentaires, comme un script qui compte automatiquement les changements ou un guide de style pour la présentation des notes. C'est l'implémentation. Le document appelle cela une « Compétence » (Skill), et il insiste sur le fait que tout ce kit est un artéfact logiciel. C'est une façon sophistiquée de dire qu'il s'agit d'une pièce de technologie qui doit être construite, testée et maintenue, tout comme un jeu vidéo ou un site web.

L'auteur soutient que si vous traitez une Compétence comme une note informelle, elle échouera. Si vous la traitez comme un logiciel, elle fonctionnera. Voici comment le document décompose les règles de construction de ces kits numériques :

1. La règle de la « Responsabilité Unique »

Pensez à un couteau suisse. Si vous essayez de fabriquer un outil qui est à la fois un tournevis, un décapsuleur, une scie, une brosse à dents et un coupe-pizza, il sera médiocre en tout. Le document stipule qu'une Compétence doit faire une seule chose très bien. Si une Compétence tente de faire « tout ce qui concerne le codage », le robot pourrait être confus quant au moment de l'utiliser. Mais si la Compétence est spécifiquement « Rédiger des notes de version à partir de pull requests », le robot sait exactement quand la saisir. Le document suggère qu'une Compétence focalisée est sélectionnée plus de manière fiable par l'IA.

2. L'astuce du « Chargement par Étapes »

Imaginez que vous avez une bibliothèque d'un million de livres. Si vous essayiez de lire tous les livres à la fois pour trouver celui dont vous avez besoin, votre cerveau exploserait. Le document explique que les Compétences d'IA utilisent une astuce intelligente appelée chargement par étapes (staged loading).

• Niveau 1 (L'Étiquette) : D'abord, le robot ne voit que l'étiquette sur la poche (le nom et une courte description). Cela coûte très peu de « puissance cérébrale » (tokens).
• Niveau 2 (La Recette) : Si le robot pense que la tâche correspond à l'étiquette, il ouvre la poche et lit la recette principale.
• Niveau 3 (Les Outils) : Il ne sort les outils supplémentaires (scripts ou fichiers de référence) que si la recette dit spécifiquement : « Oh, j'ai besoin de vérifier ce fichier spécifique maintenant. »

Cela signifie que vous pouvez avoir une Compétence avec une immense bibliothèque de matériel de référence à l'intérieur, et le robot ne sera pas submergé, sauf s'il a réellement besoin d'utiliser ce matériel. C'est comme avoir une énorme boîte à outils mais n'ouvrir que le tiroir dont vous avez besoin.

3. La « Description » est le Déclencheur

La partie la plus importante d'une Compétence est la description sur l'étiquette. Le document prévient que si vous écrivez une étiquette vague comme « Gère les versions », le robot ne saura pas quand l'utiliser. Elle doit être spécifique : « Rédige des notes de version à partir des pull requests fusionnées entre deux balises de version. À utiliser lors de la préparation d'une version. » Le robot fait correspondre la tâche à cette description. Si la description est floue, le robot pourrait manquer la Compétence, ou choisir la mauvaise. Le document suggère que la description est le « contrat » entre vous et le robot.

4. Tester avec l'« Évaluation Comportementale »

Dans la programmation informatique normale, vous pouvez tester une fonction en l'exécutant et en vérifiant si la réponse est exactement « 5 ». Mais l'IA est différente. Le robot peut vous donner une réponse légèrement différente à chaque fois, même s'il fait la bonne chose. Le document affirme que vous ne pouvez pas tester une Compétence avec un simple contrôle « succès/échec ». Au lieu de cela, vous devez utiliser l'évaluation comportementale. Cela signifie que vous soumettez la Compétence à un certain nombre de tâches réelles, vous l'exécutez de nombreuses fois et vous regardez si elle accomplit correctement sa tâche la plupart du temps. C'est comme tester une nouvelle recette en la cuisinant dix fois et en la goûtant, plutôt que de simplement vérifier si les ingrédients sont sur la liste.

La Grande Confusion : Compétences vs Autres Outils

L'une des plus grandes contributions du document est de clarifier la confusion entre différentes manières de dire à une IA quoi faire. L'auteur compare les Compétences à d'autres outils comme les Hooks (Crochets), les Slash Commands (Commandes Slash) et les Fichiers de Mémoire.

Imaginez que vous dirigez une pièce de théâtre.

• Les Fichiers de Mémoire sont comme un script qui est toujours présent sur la scène, visible pour les acteurs (l'IA) à chaque instant de la représentation. Ils fournissent un contexte de projet permanent qui ne s'efface jamais, garantissant que le robot dispose toujours de cette information, même s'ils ne forcent pas une action spécifique.
• Les Commandes Slash sont comme un régisseur qui crie : « Hé, fais le tour de magie maintenant ! » C'est vous (l'utilisateur) qui devez donner la commande. Le robot attend votre signal.
• Les Hooks sont comme un mécanisme de sécurité automatisé et strict. Si l'acteur essaie de sauter de la scène sans harnais, le mécanisme de sécurité exécute de manière déterministe une règle pour le rattraper ou arrêter l'action. Le robot ne peut pas l'ignorer ; cela se produit à chaque fois que l'événement spécifique survient, peu importe ce que le robot décide.
• Les Compétences sont comme un kit procédural spécialisé chargé à la demande. Lorsqu'un robot rencontre une tâche, il fait correspondre la description et charge les instructions spécifiques pour gérer ce domaine. C'est une source de connaissances expertes que le robot récupère activement pour résoudre un problème, plutôt qu'une simple suggestion passive.

Le document trace une ligne claire : si vous avez besoin que quelque chose se produise à chaque fois (comme un contrôle de sécurité avant d'enregistrer un fichier), vous devez utiliser un Hook. Si vous voulez que le robot utilise son cerveau pour décider si une procédure spécifique est nécessaire, vous utilisez une Compétence. L'auteur souligne que confondre les deux est une erreur courante. Si vous écrivez une règle de sécurité à l'intérieur d'une Compétence, le robot pourrait décider de l'ignorer. Si vous écrivez une suggestion flexible à l'intérieur d'un Hook, le robot pourrait rester bloqué à faire la même chose même quand il ne le devrait pas.

Le Problème de la « Confiance »

Enfin, le document aborde une idée effrayante mais importante : la Confiance. Si vous téléchargez une Compétence provenant de quelqu'un d'autre (un tiers), vous le laissez écrire des instructions que votre robot suivra. Cette Compétence pourrait contenir des scripts qui suppriment des fichiers ou envoient des données sur Internet. Le document soutient que vous devez traiter une Compétence exactement comme un logiciel que vous téléchargez sur Internet. Vous ne devriez pas simplement cliquer sur « installer ». Vous devez lire le code, vérifier les scripts et vous assurer qu'ils sont sûrs. Le robot fera tout ce que la Compétence lui dicte, vous devez donc être le gardien.

L'Essentiel

Le document de Giuseppe Destefanis est un appel à l'action pour tous ceux qui construisent des outils d'IA. Il dit : « Arrêtez de traiter les instructions d'IA comme des notes informelles. Commencez à les traiter comme du véritable génie logiciel. »

En utilisant les principes du génie logiciel — garder les choses simples, séparer l'étiquette du contenu, tester avec des scénarios réels et savoir exactement quand utiliser une Compétence plutôt qu'un Hook — nous pouvons construire des agents d'IA qui ne sont pas seulement intelligents, mais aussi fiables et sûrs. Le document ne promet pas que cela résoudra tous les problèmes de l'IA, mais il suggère que si nous construisons nos Compétences avec le même soin que nous construisons nos applications, nous pouvons rendre nos assistants numériques beaucoup plus dignes de confiance. Il s'agit de passer de « espérer que le robot réussisse » à « l'ingénierie pour que le robot réussisse ».