Un fichier markdown unique a consommé 92 % de tokens en plus qu'un serveur MCP pour produire le même écran. Ce n'est pas une intuition de consultant : c'est Atlassian qui l'a mesuré, sur son propre design system. Et ce que dit vraiment cette mesure est plus intéressant que le chiffre lui-même.
DESIGN.md, la promesse du fichier unique
Le format s'appelle DESIGN.md. C'est un fichier markdown créé par Google, qui résume ta marque et tes composants dans un seul document que tu colles dans ton prompt. Sur le papier, c'est séduisant : un fichier, portable, et l'IA arrête de générer de la bouillie générique.
Ce qu'Atlassian a mesuré
Atlassian a comparé ce fichier unique à son serveur MCP et à ses skills, sur une tâche simple dans un codebase de production. Le fichier unique a consommé 92 % de tokens en plus, il a été plus lent, et il a produit 2,7 fois plus de variance de consommation d'un run à l'autre. Il avait aussi tendance à recréer des composants au lieu de réutiliser ceux qui existent, donc à fabriquer de la dette.
Le chiffre que je trouve le plus parlant est pourtant ailleurs : le MCP donne à l'agent l'accès à environ 80 % du design system, le fichier unique à 30 %. Pour tenir dans un seul document, Atlassian a dû couper une grande partie des guidelines de ses 50 composants.
La vraie variable : le chargement à la demande
La raison est simple. Un fichier markdown charge tout, tout le temps, même ce dont l'IA n'a pas besoin. Un serveur MCP va chercher le bon composant au bon moment, à la demande.
Une précision compte ici, parce que le raccourci est facile : les skills d'Atlassian sont eux aussi des fichiers markdown, et ils arrivent quasiment au niveau du MCP sur les mêmes tests. Ce qui fait la différence, c'est le chargement à la demande, quelle que soit la techno qui le porte.
Ce que ça change en pratique
C'est ce que je mets en place chez mes clients : le design system découpé et interrogeable, l'IA qui pioche le composant pertinent quand elle en a besoin, au lieu d'un gros pavé figé qu'on espère assez complet.
DESIGN.md reste pratique pour du prototypage rapide, du theming client, ou un environnement sans MCP. Atlassian publie d'ailleurs le sien. Pour un produit en production, ça ne suffit pas.
Honnêteté oblige : Atlassian précise que ces résultats ne sont pas concluants au sens scientifique, et que d'autres modèles ou d'autres design systems donneront d'autres chiffres. L'ordre de grandeur, lui, correspond à ce que j'observe en mission.
La question utile ne porte donc pas sur le fichier que tu donnes à l'IA. Elle porte sur la façon dont tu rends ton design system interrogeable. Un fichier seul ne le fait pas.
Si tu veux augmenter la productivité de tes équipes produit et design avec des outils communs et partagés, contacte-moi. C'est ce que je construis.