Quand vous gérez des agents IA en production, vos prompts sont votre infrastructure.

Pas au sens figuré : un prompt cassé, c’est un module qui ne se charge pas. Un module qui ne se charge pas, c’est une fonctionnalité entière qui devient invisible pour l’agent.

Je viens de passer une journée à auditer mon système d’agents Hermes, 202 modules, 150+ skills spécialisés. Ce que j’ai trouvé m’a appris plus que n’importe quel article théorique sur l’architecture des prompts.

1. Le déclencheur : un article de Google

Google Developers Blog a publié le 16 juillet 2026 un article intitulé « Building scalable AI agents with modular prompt transpilation ».

Le problème qu’ils décrivent est réel : quand votre système prompt grossit, il devient impossible à maintenir. Une phrase ajoutée pour un workflow peut casser un autre workflow sans que personne le sache avant le déploiement. Les règles de sécurité se dupliquent d’une équipe à l’autre. Les erreurs sont découvertes en production, pas à la compilation.

Leur solution ? Traiter les prompts comme des artefacts logiciels : des fichiers modulaires avec {% include %}, des variables d’environnement, des macros, un transpileur (un programme qui convertit des fichiers sources en un autre fichier source de même niveau d’abstraction — ici, des fragments de prompts compilés en un prompt final) qui résout les dépendances en build time, et des golden files en CI pour détecter les dérives.

J’ai lu l’article. J’ai adoré le concept. Puis je me suis demandé : est-ce que j’ai ce problème ?

2. Mon système : Hermes et ses 202 skills

Je travaille avec Hermes Agent, un framework d’agents open source par Nous Research. L’architecture est simple : chaque agent a accès à une bibliothèque de skills, des fichiers Markdown avec frontmatter YAML qui décrivent une procédure, un workflow, un comportement.

Quand l’agent reçoit une tâche, il parcourt l’index des skills, détermine ceux qui sont pertinents, et les charge à la demande. C’est ce qu’on appelle le progressive disclosure, un concept avancé que Google recommande dans son article.

Concrètement, j’ai :

Catégorie	Skills
SEO	50
Media Buying	29
Copywriting	14
Software Development	14
DevOps	12
Autres	24
Archivés	59
Total	202

Chaque skill est un fichier indépendant, auto-suffisant, avec son propre frontmatter (nom, description, catégorie), son contenu procédural, et parfois des fichiers de référence ou des templates.

3. L’audit : ce que j’ai découvert

J’ai lancé un scan automatique de tous les SKILL.md. Le validateur vérifie :

• Le frontmatter YAML est valide
• Le nom fait moins de 64 caractères
• La description fait moins de 1024 caractères
• Les fichiers de référence ne sont pas vides
• Les références aux agents externes existent encore

Résultat : 19 skills sur 143 actifs avaient un YAML cassé.

Pas un YAML invalide à cause d’une erreur de syntaxe complexe. Un problème bête : des guillemets non échappés dans des chaînes YAML.

# ❌ Ce YAML est cassé
description: "Agent spécialisé en audit — Call when: "audit B2B""

# ✅ Version corrigée
description: "Agent spécialisé en audit — Call when: \"audit B2B\""

Un guillemet double non échappé à l’intérieur d’une chaîne délimitée par des guillemets. Une erreur que n’importe quel linter YAML détecte. Sauf que personne n’avait lancé le linter.

Le résultat ? Ces 19 skills apparaissaient dans l’index de l’agent… sans nom, sans description. L’agent voyait une entrée vide et passait à autre chose. Des skills entièrement rédigés, prêts à être utilisés, totalement invisibles pour l’IA.

C’est l’équivalent d’avoir 19 employés qui viennent au bureau, s’assoient à leur poste, mais personne ne leur a jamais dit ce qu’ils sont censés faire.

4. Pourquoi je n’ai pas besoin du transpileur de Google

J’étais prêt à construire un transpileur Jinja2 avec includes, variables, macros, tout le package que Google décrit.

Puis j’ai regardé mon architecture de plus près.

Le problème que Google résout, c’est le prompt monolithique : un seul fichier gigantesque qui essaie de tout faire. Chez eux, les équipes ajoutent des règles de sécurité, des politiques de PII, des protocoles d’escalade dans le même fichier. Forcément, ça explose.

Mon architecture, c’est l’inverse :

• Chaque skill est un fichier indépendant, pas un fragment qui include un autre
• Pas de dépendances entre skills, pas de graphe, pas de résolution d’imports
• Chargement à la demande (skill_view()), le contenu complet n’entre dans le contexte que quand l’agent en a besoin
• L’index dans le system prompt ne contient que noms + descriptions (environ 150 caractères par skill, soit 5 000 tokens compressés environ)

Ajouter un transpileur avec {% include %} n’aurait rien apporté. Mon problème n’était pas la composition des prompts, c’était l’absence de validation.

5. Ce que j’ai construit à la place

Un validateur de skills, un cronjob, et une leçon.

Le validateur

Un script Python de 150 lignes qui scanne tous les SKILL.md et vérifie :

🧪 Skills Validator — 143 skills, 143 clean, 0 issues (0.2s)
✅ Tous les skills sont valides.

Il tourne en mode --quiet : rien à signaler = pas de sortie. Problème détecté = rapport détaillé.

Le cronjob

Tous les lundis à 9h, le validateur s’exécute automatiquement. Si tout va bien, rien ne se passe, silence radio. Si un skill est cassé, le rapport arrive directement dans mon chat Telegram.

Pourquoi c’est mieux qu’un transpileur :

• Pas d’over-engineering pour un problème que je n’ai pas
• Détection précoce vs résolution au build time
• Zéro infrastructure supplémentaire, le script tient dans un fichier

Ce que j’en retiens

J’ai passé du temps à lire un article de Google sur l’architecture des prompts. C’était intéressant, c’était bien écrit. Mais le vrai problème était ailleurs, plus simple, plus concret.

19 skills invisibles. Pendant des jours. Peut-être des semaines.

6. Ce que ça change pour vous

Si vous utilisez des agents IA, Hermes, Claude Code, n’importe quel système avec des skills ou des instructions modulables, posez-vous ces questions :

1. Quand avez-vous vérifié pour la dernière fois que tous vos modules sont valides ? Si votre assistant charge des instructions depuis des fichiers, une simple erreur de syntaxe peut rendre un module entier invisible.

2. Avez-vous un validateur automatique ? Si vous devez y penser, ça n’arrive pas. Automatisez-le. Un cronjob qui ne fait rien 99 % du temps, c’est parfait, ce sont les 1 % qui comptent.

3. Connaissez-vous la différence entre un problème théorique et votre problème réel ? L’article de Google est excellent. Mais le transpileur modulaire n’était pas mon problème. Mon problème, c’était l’absence de filet de sécurité.

Tu veux en discuter ? Contacte-moi.