Les AI Skills comme levier architectural : qualité du output et économie de tokens
Ce que les architectes ratent en abordant les LLM comme des boîtes noires
La majorité des équipes d’ingénierie abordent encore les modèles de langage de la même façon qu’elles abordaient les APIs REST au début des années 2010 : on envoie une requête, on espère une réponse cohérente, et on gère le delta entre l’espéré et l’obtenu par des post-traitements ou des tentatives manuelles. Cette posture est compréhensible, mais elle rate l’essentiel. Les LLM ne sont pas des boîtes noires uniformes. Ce sont des systèmes dont le comportement est profondément conditionné par la structure du contexte qu’on leur fournit, et les “AI skills” sont précisément la réponse architecturale à ce constat.
Un skill IA, au sens où l’utilisent des outils comme SpecKit, Superpower ou les modules TopMax UX/UI, est une unité de contexte pré-structurée qui conditionne le comportement du modèle sur un domaine ou une tâche précise. Ce n’est pas un simple prompt sauvegardé. C’est une capsule d’expertise déployable, versionnée, composable, qui agit sur plusieurs dimensions simultanément : le registre du modèle, sa stratégie de raisonnement, ses contraintes de format, ses exemples de référence et parfois ses outils accessibles. Comprendre ce mécanisme comme on comprend un pattern d’architecture, c’est-à-dire en identifiant ses avantages, ses compromis et ses conditions d’application, est devenu une compétence distincte pour quiconque conçoit des systèmes IA sérieux.
L’anatomie d’un skill : bien plus qu’un system prompt enrichi
Avant d’examiner l’impact sur la qualité et les tokens, il faut décrire précisément ce qu’est un skill dans sa forme la plus aboutie. On peut distinguer quatre couches.
La première couche est la couche de persona et de posture. Elle définit qui parle, depuis quel point de vue, avec quelle autorité épistémique. Un skill “architecte senior .NET” ne dit pas simplement au modèle d’écrire du C#. Il lui dit d’adopter une pensée en termes de frontières de contexte bornés, de contrats d’interface, de compromis entre cohérence éventuelle et cohérence forte. Cette couche agit sur le registre sémantique global du modèle et sur ses priorités implicites quand plusieurs options coexistent.
La deuxième couche est la couche de stratégie de raisonnement. Elle précise comment le modèle doit décomposer le problème avant de produire sa réponse. Certains skills imposent une phase d’exploration des contraintes avant toute synthèse. D’autres imposent un raisonnement comparatif explicite sur plusieurs options avant de converger. Cette couche est particulièrement importante pour les tâches où la qualité du résultat dépend fortement de la qualité du chemin de raisonnement, comme la conception d’API, l’analyse de sécurité ou la modélisation de données.
La troisième couche est la couche de format et de contraintes de sortie. Elle spécifie la structure attendue du livrable : en-têtes, granularité, longueur cible, éléments obligatoires et éléments interdits. C’est ici que les skills UX/UI comme ceux proposés dans TopMax deviennent particulièrement intéressants, car la qualité d’une maquette ou d’un composant généré dépend autant de la structuration de la demande que du modèle lui-même.
La quatrième couche est la couche d’exemples de référence. Les few-shot examples intégrés dans un skill ne sont pas des décorations. Ils encodent une sémantique que les trois premières couches ne peuvent pas exprimer propositionnellement. Un exemple de code bien architecturé en entrée de contexte active des patterns latents dans le modèle que nul instruction textuelle ne peut cibler directement.
Ces quatre couches agissent en synergie. Retirer l’une d’elles dégrade la qualité du résultat de façon non linéaire, ce qui explique pourquoi un “prompt enrichi” bricolé à la main n’atteint jamais la robustesse d’un skill conçu systématiquement.
SpecKit, Superpower, TopMax UX/UI : trois visions du même problème
Ces outils partagent l’objectif de rendre les skills déployables et composables, mais ils l’abordent avec des philosophies distinctes qui méritent une lecture architecturale.
SpecKit est centré sur la génération de spécifications techniques. Son positionnement est celui d’un outil pour équipes produit et ingénierie qui veulent réduire l’écart entre une expression de besoin en langage naturel et un livrable suffisamment précis pour être directement exploitable par un développeur ou un agent de codage. L’originalité de SpecKit tient à sa gestion des ambiguïtés : le skill ne produit pas une spécification au premier essai mais orchestre un dialogue structuré de clarification avant de converger. Cette approche est architecturalement saine parce qu’elle traite l’ambiguïté là où elle se trouve, dans l’input, plutôt que de la propager dans le output.
Superpower adopte une approche différente. Son modèle de skill est davantage orienté vers l’amplification du workflow individuel : bibliothèques de prompts structurés, accès à des modèles spécialisés selon le type de tâche, et composition de chaînes de skills pour des workflows complexes. Ce qui est architecturalement notable dans Superpower est sa gestion de la mémoire contextuelle : les skills peuvent s’appuyer sur des contextes persistants qui survivent aux limites de la fenêtre de contexte native du modèle. Pour un architecte qui construit des pipelines d’agents longue durée, cette capacité est loin d’être anecdotique.
TopMax dans son volet UX/UI représente une spécialisation sectorielle poussée. Ses skills sont entraînés sur des corpus de design systems, de guidelines d’accessibilité, de patterns de composants modernes, et ils produisent des outputs qui respectent des conventions que les modèles généralistes approximent sans les maîtriser : tokens de design cohérents, hiérarchies visuelles respectant les principes de Gestalt, composants avec les bonnes propriétés d’accessibilité ARIA. La qualité de ses outputs en contexte UI est sensiblement supérieure à celle d’un prompt générique demandant “crée un composant React accessible”, et c’est précisément parce que le skill encapsule une expertise que le modèle généraliste ne peut pas inférer de façon fiable depuis son entraînement seul.
L’impact sur la qualité : une analyse en trois dimensions
Mesurer la “qualité” d’un output IA est un exercice difficile, mais on peut le décomposer en trois dimensions que les skills influencent de façon différenciée.
La première dimension est la fidélité fonctionnelle : l’output fait-il ce qui était demandé ? Les skills améliorent cette dimension en réduisant l’espace d’interprétation du modèle. Moins le modèle a besoin d’inférer l’intention sous-jacente, moins il risque de produire quelque chose qui répond à une lecture plausible mais non voulue de la demande. Dans les tâches de génération de code, cette réduction de l’ambiguïté d’interprétation se traduit concrètement par une réduction du nombre d’itérations nécessaires pour atteindre un résultat exploitable. Des mesures empiriques dans des équipes utilisant des skills structurés montrent des gains de l’ordre de 40 à 60% sur le nombre de cycles de correction, ce qui représente un impact direct sur la vélocité de développement.
La deuxième dimension est la cohérence structurelle : l’output respecte-t-il les conventions, les standards et les contraintes architecturales du contexte cible ? C’est ici que les skills font le plus grande différence par rapport aux prompts ad hoc. Un prompt générique peut produire un excellent composant React à la demande, mais sans contrainte explicite, il ignorera les conventions du design system existant, utilisera une gestion d’état incompatible avec l’architecture en place, ou produira une interface accessible à 80% mais pas aux 20% restants qui importent pour une mise en conformité RGAA. Un skill bien conçu encode ces contraintes architecturales une fois pour toutes et les applique systématiquement à chaque invocation.
La troisième dimension est la robustesse aux variations d’input : l’output maintient-il sa qualité quand la demande est formulée différemment ou quand le contexte change légèrement ? C’est la dimension la plus difficile à améliorer et celle où les skills les plus matures, comme ceux de SpecKit avec leur phase de clarification, apportent le plus de valeur. Un skill qui orchestre une étape de reformulation avant de générer réduit considérablement la variance de la qualité du résultat en fonction de la formulation de la demande.
L’économie des tokens : un sujet d’architecture à part entière
La question des tokens est souvent traitée comme une question d’optimisation des coûts, ce qui est réducteur. C’est en réalité une question d’architecture dont les implications dépassent la ligne budgétaire.
Un skill bien conçu consomme plus de tokens en entrée qu’un prompt nu. C’est inévitable et c’est son prix. La question pertinente n’est pas “combien de tokens coûte ce skill ?” mais “quel est le coût total en tokens pour atteindre un résultat de qualité acceptable avec et sans skill ?”. La réponse est systématiquement favorable au skill dès lors que la tâche atteint un certain niveau de complexité, pour une raison simple : le coût d’un skill est fixe à chaque invocation, tandis que le coût d’une session de correction itérative sans skill est variable et souvent beaucoup plus élevé.
Prenons un exemple concret. La génération d’un composant UI conforme à un design system sans skill implique typiquement : une première tentative qui ignore certaines contraintes, une ou deux corrections ciblées en réponse à des révisions, et parfois une refonte partielle quand une incohérence structurelle plus profonde est détectée. Sur un pipeline GPT-4o ou Claude Sonnet, cette séquence peut facilement consommer 8 000 à 15 000 tokens au total en comptant l’historique de conversation qui grossit à chaque tour. Un skill UX/UI bien conçu consomme 2 000 à 4 000 tokens en entrée mais produit un premier résultat directement utilisable dans 70 à 80% des cas, ramenant le coût moyen total à 3 000 à 5 000 tokens. Le skill coûte plus par appel isolé, mais coûte deux à trois fois moins sur l’ensemble du workflow.
Cette arithmétique a une implication architecturale importante : la position du skill dans le pipeline conditionne son retour sur investissement. Un skill invoqué à la fin d’une chaîne d’agents, quand le contexte est déjà partiellement construit par des étapes précédentes, bénéficiera d’un contexte enrichi mais paiera le coût de la fenêtre accumulée. À l’inverse, un skill invoqué en début de pipeline, avant que le contexte ne soit chargé, maximise son rapport qualité/tokens mais risque de manquer d’informations de domaine. La bonne architecture est celle qui positionne les skills au point de la chaîne où le rapport entre information disponible et coût de contexte est optimal.
Il faut également mentionner la question des skills écrits en anglais pour des workflows qui produisent des outputs en français. C’est une optimisation non triviale : les tokenizers des modèles dominants (GPT-4, Claude, Gemini) sont tous calibrés sur des corpus à majorité anglophone. Un même contenu sémantique exprimé en anglais consomme systématiquement moins de tokens qu’en français, avec des ratios qui varient entre 1,2 et 1,8 selon la densité lexicale. Pour un skill invoqué des milliers de fois par jour dans un pipeline de production, écrire le skill en anglais tout en dirigeant le modèle vers une réponse en français représente une économie réelle et mesurable.
Patterns d’intégration architecturale des skills
Du point de vue d’un architecte qui conçoit un système IA, les skills ne sont pas des entités isolées mais des composants à intégrer dans une architecture. Plusieurs patterns d’intégration méritent d’être identifiés.
Le pattern de skill stationnaire est le plus simple : un skill est associé à un agent ou à un endpoint spécifique, et il est chargé à chaque invocation de cet agent. C’est le pattern approprié pour des tâches bien définies et répétitives où le domaine ne varie pas. La génération de documentation d’API, la validation de schémas GraphQL, ou la production de tests unitaires pour un style de code défini sont des cas d’usage typiques. Ce pattern est facile à monitorer et à optimiser car le coût en tokens est prédictible.
Le pattern de skill conditionnel introduit une couche de routing : un agent d’orchestration analyse la nature de la tâche entrante et sélectionne le skill approprié parmi un catalogue. Ce pattern est plus complexe à implémenter mais il permet d’éviter la surcharge de contexte qui résulte du chargement systématique de tous les skills potentiellement pertinents. Dans une architecture multiagent où les tâches sont hétérogènes, c’est souvent la seule façon de maintenir le coût moyen en tokens à un niveau acceptable.
Le pattern de skill composé est le plus puissant et le plus délicat. Il consiste à orchestrer une séquence de skills où le output de l’un devient l’input structuré de l’autre. SpecKit illustre ce pattern dans sa gestion des spécifications : un skill de clarification produit une structure de contraintes qui alimente un skill de génération qui produit lui-même une structure validée par un skill de revue. La difficulté de ce pattern est la gestion de la propagation d’erreurs : si un skill amont produit un output de mauvaise qualité, les skills aval l’amplifient plutôt que le corrigent. Il faut donc intégrer des checkpoints de validation intermédiaires, ce qui est coûteux en tokens mais nécessaire pour la robustesse.
Les risques architecturaux des skills : ce que personne ne dit
L’enthousiasme autour des skills IA tend à masquer plusieurs risques sérieux qui méritent d’être nommés.
Le premier est le risque de brittleness par sur-spécification. Un skill qui encode trop de contraintes perd en adaptabilité. Si les contraintes sont conflictuelles dans un cas limite non anticipé, le modèle produit un output dégradé ou tombe dans une boucle de compromis peu satisfaisants. La règle architecturale est que les contraintes d’un skill doivent être les contraintes minimales nécessaires à la qualité cible, pas une liste exhaustive de tout ce qui serait idéalement vrai.
Le deuxième est le risque de dérive silencieuse. Les skills sont des dépendances du système au même titre que les librairies. Quand le modèle sous-jacent est mis à jour, le comportement d’un skill peut changer sans que le skill lui-même ait changé. Un skill qui produisait d’excellents composants React avec GPT-4-turbo peut produire des résultats différents avec GPT-4o ou Claude 3.5 Sonnet, même si les instructions sont identiques. Cela impose un versioning des skills aligné sur le versioning des modèles et des suites de tests de régression de qualité, exactement comme pour n’importe quelle dépendance logicielle.
Le troisième est le risque de couplage implicite. Dans les architectures multiagents, les skills créent des couplages sémantiques qui ne sont pas toujours visibles dans les diagrammes d’architecture. Si deux agents partagent un skill et que ce skill est modifié, les deux agents sont affectés. Si un skill produit un format de sortie que seul un agent aval sait interpréter, on a un couplage de format non documenté. Ces couplages implicites sont des sources de bugs difficiles à diagnostiquer en production.
Vers une ingénierie des skills comme discipline à part entière
La conclusion pour un architecte logiciel est que les skills IA ne sont pas des gadgets de productivité mais des artefacts d’architecture qui méritent les mêmes rigueurs que tout autre composant d’un système complexe : conception documentée, versioning, tests, monitoring et gouvernance de déploiement.
L’émergence d’outils comme SpecKit, Superpower et TopMax UX/UI est le signe que le marché commence à traiter les skills comme des composants logiciels à part entière, avec leurs propres cycles de vie, leurs propres abstractions et leurs propres patterns de composition. Pour les équipes qui construisent des systèmes IA en production, adopter cette discipline dès maintenant, avant que la dette de skills ne devienne aussi difficile à gérer que la dette technique classique, est probablement l’un des investissements architecturaux les plus à fort retour du moment.
Les modèles continueront d’évoluer, les coûts de tokens continueront de baisser, mais la capacité à définir précisément ce qu’on veut que ces modèles produisent, à l’encoder de façon durable et maintenable, et à le composer intelligemment dans des systèmes complexes : c’est là que réside la valeur architecturale durable.