Construire une usine de skills Claude et MCP

Pour faire fonctionner la chaîne éditoriale, j'ai réparti les consignes entre des documents de méthode, des skills et des agents. Le problème à résoudre était concret : pouvoir modifier une règle sans la retrouver recopiée dans plusieurs outils.

Je suis Jim. Cet article est le bonus technique de la série sur notre fabrique de contenu Eurofiscalis. Après la chaîne éditoriale et le maillage, je détaille comment tout ça est construit avec des skills Claude, des agents et du MCP. Ces choix peuvent servir si tu construis aussi un processus avec plusieurs tâches et plusieurs outils.

Sur mon site personnel construit avec Claude, j'avais déjà rencontré la même limite : l'outil accélère l'exécution, mais le cadrage reste à faire.

D'abord, deux mots : skill et MCP

Un skill, c'est un ensemble d'instructions et de ressources pour une tâche. Un mode d'emploi que Claude charge quand une tâche précise se présente : rédiger un article, le publier, le traduire. Plutôt que réexpliquer la méthode à chaque fois dans un prompt, on l'écrit une fois, proprement, et Claude s'en sert quand il faut.

Le MCP est un standard de connexion entre applications IA et systèmes externes. Chez nous, il ouvre deux portes : écrire dans le CMS (créer, modifier, publier une page) et lire les données de Search Console.

Une règle recopiée demande plusieurs corrections

Au début, une même règle de méthode (un seuil, une contrainte de longueur, une convention de nommage) se retrouvait recopiée dans plusieurs skills et plusieurs agents. Une modification demandait alors de vérifier chaque copie.

Un jour, modifier un seul seuil m'a demandé onze modifications, à onze endroits différents, parce que la règle avait été dupliquée partout. Onze occasions de me tromper, d'en oublier une, de laisser deux versions contradictoires vivre côte à côte. C'est ce qui m'a conduit à revoir l'organisation des consignes.

Trois couches, une seule direction

De ce constat est née la règle qui structure tout le système. Trois couches, et une dépendance qui ne va que dans un sens.

Le second cerveau : les références. C'est là que vit la méthode, les règles, les conventions. Des fiches, indépendantes de tout outil. Si une règle change, elle change ici.

Les skills : l'application. Ils prennent la méthode et l'appliquent au cas Eurofiscalis : le CMS, les tokens, les gates, le maillage. Ils ne réécrivent pas la méthode, ils la lisent.

Les agents : l'exécution. Chacun fait une tâche précise (analyser la concurrence, écrire les métadonnées), en suivant une procédure et en rendant un résultat dans un format défini.

Les agents et leurs contrats

Entre les skills et les agents, des données circulent. Et le format de ces données n'est pas uniforme : il est choisi par celui qui va les lire.

Une sortie que je relis à la main lors d'une validation reste en Markdown, lisible. Une sortie injectée telle quelle dans un autre outil part en JSON strict, pour pouvoir valider sa structure avant de l'utiliser. Une donnée traitée par un autre agent prend le format qui l'arrange.

Je ne cherche donc pas à imposer le même format à toutes les sorties. Un rapport que je dois relire doit rester lisible par un humain, pas devenir un pavé de JSON. Le bon format dépend de qui lit.

Et un détail qui a son importance : les sections de ces sorties sont fixes et nommées. Renommer une section peut casser la tâche qui attend ce nom. Comme dans n'importe quel logiciel, l'interface entre deux briques est un contrat qu'on ne modifie pas à la légère.

MCP : le pont vers le CMS

Avec les connexions MCP de notre projet, Claude crée un nouveau document en brouillon ou modifie une page existante en conservant son état de publication. Il interroge Search Console pour savoir sur quelles requêtes une page ressort. Ces opérations dépendent des outils exposés et des droits accordés. MCP n'est pas le seul moyen de relier un assistant à un outil.

Une précision, parce que le sujet est sensible : les accès sont cadrés, et la chaîne prévoit deux validations humaines et un accord avant la publication. Le pont sert à travailler plus vite, pas à laisser la machine publier dans ton dos.

Éviter deux versions concurrentes d'un livrable

Un autre problème venait de la production des documents. À un moment, deux outils différents produisaient le même document, chacun de son côté. Au premier changement, les deux versions ont pris des chemins légèrement différents. On s'est retrouvés avec deux documents qui ne disaient pas tout à fait la même chose.

On a donc retenu une voie principale de production pour ce document. Si une seconde voie sert à vérifier le résultat, il faut définir comment comparer les sorties et laquelle fait référence.

Ce que je retiens

Cette organisation me sert à séparer ce que l'on veut faire, les consignes de chaque tâche et les opérations sur les outils. Sur un corpus de 2700 pages en sept langues, cette séparation facilite les corrections. Elle ne remplace pas les validations de la chaîne éditoriale : un résultat bien formaté peut encore être faux ou mal rédigé.