Une capacité peut être un skill. Il ne faut pas qu'elle le soit.

Le 19 août, je partageais mon écran avec un dev freelance. Vingt-deux secondes après le début de l’enregistrement, il me coupe : « quand tu parles de capacité, on est d’accord, c’est la même chose que les skills pour les agents IA ? »

J’ai dit non. Puis j’ai mis deux minutes à expliquer pourquoi, en tournant autour du pot, avant de tomber sur la phrase qui résume tout : ça peut l’être, mais il ne faut pas que ça le soit.

Ça ressemble à une chicane de vocabulaire. C’est en fait la ligne qui sépare un système que je peux facturer d’un système qui me coûte de l’argent à chaque exécution.

La même capacité, deux exécutions

Prenons la plus simple de mes capacités : cross-poster un contenu sur plusieurs plateformes.

Un post arrive. S’il est déjà bon, si c’est moi qui l’ai écrit et que je veux le sortir tel quel, il n’y a rien à décider. La capacité formate, authentifie, publie, note ce qui est parti où. C’est trois appels d’API et une écriture en base. Aucun modèle n’est réveillé, la sortie est la même à chaque fois, et l’exécution coûte quelques centimes.

Maintenant le même post arrive en brouillon, mal fichu, écrit à l’arrache un dimanche soir. Là il faut aller rechercher le contexte de la company, le ton, les preuves déjà utilisées, et réécrire avant de publier. Ça, aucun script ne le fait. Il faut un modèle, donc il faut un skill.

Même capacité. Même point d’entrée. Deux chemins qui ne coûtent pas le même prix et ne mettent pas le même temps.

Si j’avais appelé cette capacité « un skill », j’aurais enfermé la première branche dans la deuxième. Chaque publication propre serait passée par un modèle, pour rien. C’est exactement ce qui arrive quand on décide du vocabulaire avant d’avoir regardé ce qui se passe à l’exécution.

L’escalier va toujours vers le bas

Ma méthode tient en quatre marches, et je les descends toujours dans le même sens.

Première marche, le skill. Au démarrage, c’est là que je pose tout. C’est ce qui fait avancer le plus vite : je décris ce que je veux en français, le modèle se débrouille, la capacité existe le jour même. Je n’ai rien contre le prototype fait comme ça, c’est même la seule façon raisonnable de commencer.

Deuxième marche, l’appel d’API. Dès que le comportement se stabilise, je regarde ce qui, dans ce skill, n’avait aucune raison d’être décidé par un modèle. Publier sur trois plateformes n’est pas une décision, c’est une procédure. Ça descend.

Troisième marche, le script. Ce qui reste et qui n’a pas d’API dédiée devient un script à moi, versionné, testé, avec un comportement que je peux relire.

Quatrième marche, le code. Ce qui doit tenir dans le temps et supporter des cas tordus finit en vrai code, dans le produit, avec ses tests.

Et quand une partie ne peut vraiment pas descendre, je la laisse en haut. Mais je l’isole. Le skill ne garde alors que le morceau réellement indéterministe, celui qui exige du jugement, et tout ce qui l’entoure part en appels d’API.

Le travail n’est jamais de choisir entre les deux mondes. Il est de faire descendre, semaine après semaine, ce qui peut descendre.

Pourquoi le mot compte quand même

J’aurais pu appeler ça un tool. J’aurais pu ne rien appeler du tout et continuer à dire « mon truc qui poste ».

Sauf que je me suis déjà fait avoir par le vocabulaire des autres. En entretien, il y a quelques mois, je n’ai pas su expliquer ce qu’était un harness. Je connaissais la chose, j’en avais construit une, et le mot m’a échappé sur le moment. Depuis, les termes que tout le monde emploie sans que personne ne sache ce qu’ils recouvrent m’agacent sérieusement. J’ai décidé de nommer mes briques moi-même, avec des mots qui décrivent ce qu’elles font vraiment.

Ce n’est pas un caprice de nomenclature. Le nom que je donne à une brique décide de la manière dont je la construis. « Skill » contient déjà l’idée qu’un modèle sera dans la boucle, à chaque fois. « Capacité » ne contient que l’idée d’un résultat, et me laisse libre de choisir, appel par appel, ce qui doit y penser.

Le dev en face m’a fait la seule objection qui vaille : quand tu vends à quelqu’un qui n’est pas technique, le terme n’est pas le problème, ce que tu vends c’est le résultat et ce que ça lui apporte. Il a raison, et ça ne contredit rien. Le vocabulaire ne sert pas à vendre, il sert à construire juste. Comme je l’écris ailleurs : la valeur n’est pas dans l’agent, elle est dans le process qu’on lui donne.

Ce que ça coûte à faire tourner

Voilà où la distinction se voit sur une facture.

L’orchestrateur qui fait tourner mes capacités est installé sur un MacBook Pro qui a 10 ans, un i7, 16 Go de RAM. Il ne calcule rien. Il ne fait qu’orchestrer : il lit ce qui arrive, il choisit la branche, il passe des appels d’API.

Ce n’est possible que parce que la plus grosse partie de ce qui tourne est déterministe. Si chaque exécution devait réveiller un modèle, il faudrait autre chose que cette machine, et surtout il faudrait payer chaque publication au prix d’une réflexion, alors que c’était juste une procédure.

C’est le même calcul pour n’importe qui achète ce genre de système. Ce qui fait le prix mensuel, ce n’est pas le nombre de fonctionnalités, c’est la proportion de ce qui, dans le système, a encore besoin de penser. Quand un prestataire ne sait pas répondre à cette question, c’est que tout est resté sur la première marche.

Le garde-fou

Descendre l’escalier ne veut pas dire enlever l’humain de la boucle.

Autonome dans l’exécution, contrôlé dans le résultat. Une capacité publie toute seule parce que la règle qu’elle applique a été tranchée une fois, par moi. Ce qui descend, c’est l’exécution du geste. Ce qui ne descend jamais, c’est la décision de ce qu’on publie, à qui, et à quel prix.

C’est d’ailleurs le vrai test. Si tu dois relire chaque sortie de ton automatisation, elle est encore entièrement sur la première marche, et tu as changé de corvée sans en supprimer une.

La phrase que je garde

Deux minutes de bafouillage pour arriver là, mais elle tient debout toute seule.

Une capacité peut être un skill. Il ne faut juste pas qu’elle le soit.

Le jour où elle l’est obligatoirement, ce n’est plus une capacité que tu as construite, c’est une dépendance que tu paies à l’exécution.

Et toi, dans ce que tu fais tourner en ce moment, combien de fois par jour tu réveilles un modèle pour lui faire exécuter une procédure ?