Design systems IA-native

Le problème : la dérive stylistique

Un modèle génératif livré à lui-même produit des visuels plausibles mais incohérents : une palette différente à chaque graphique, une mise en page différente à chaque deck, un logo approximatif. Pour un humain, l’identité visuelle est une évidence ; pour un agent, c’est une contrainte qui doit être architecturée — sinon elle s’érode à chaque génération.

Nika OS traite le design comme il traite la sécurité : par des invariants, pas par des rappels dans les prompts.

La charte comme code

Chaque identité visuelle (le design system) vit dans un kit versionné consommé par toutes les primitives de rendu :

• Tokens — couleurs, polices, ratios de mise en page, logo, déclinés en variables importables (module Python pour matplotlib, CSS custom properties pour le web, gabarits pour les decks).
• Fonctions de marque — apply_style(), brand_axes(), add_brand_header() : le graphique sort brandé par construction, pas par retouche.
• Statut kernel — la charte est une donnée kernel : aucune mutation automatique du harnais ne peut la modifier. Un agent qui « invente » une palette est en erreur, pas en création.

L’effet : deux livrables produits à six mois d’intervalle, par deux pods différents, sur deux backends CLI différents, sont visuellement de la même main.

Routage déterministe des moteurs de rendu

Le choix du bon rendu est une décision d’ingénierie, pas une préférence esthétique du modèle. Une skill de décision route chaque intention visuelle vers le moteur adapté :

Intention	Moteur routé	Pourquoi
Graphique statistique	matplotlib + kit de marque	Reproductible, brandé par code
Dashboard interactif	HTML/JS (D3, React) autonome	Filtres, vues, auto-refresh
Deck de présentation	Outil de design natif piloté	Qualité de mise en page humaine
Document imprimable	Générateur PDF avec tokens	Typographie et pagination contrôlées
Diagramme d’architecture	Mermaid thémé	Versionnable en texte

C’est la doctrine algos comme tools appliquée au design : le LLM décide quoi montrer, un moteur déterministe décide comment le dessiner.

Piloter les outils de design natifs

Pour les livrables bureautiques (présentations, documents), la génération programmatique brute produit un rendu « machine ». Nika OS préfère piloter les copilotes IA natifs des applications (l’assistant intégré de la suite bureautique web) : l’agent travaille dans l’outil, sur le vrai moteur de rendu, avec les vrais gabarits — et le résultat a la qualité d’un document fait main.

Ce pattern — un agent qui pilote un autre agent spécialisé dans son application — généralise : l’orchestrateur fournit l’intention, le contexte et la charte ; le copilote natif exécute dans son environnement.

QA visuelle : l’agent regarde ce qu’il livre

Dernier maillon : aucun livrable visuel ne part sans avoir été regardé. La boucle de QA visuelle :

1. Rendre le livrable dans son format final (screenshot du dashboard, rasterisation du deck, rendu du PDF).
2. Inspecter le rendu avec un modèle de vision : conformité à la charte (couleurs, polices, logo), lisibilité, éléments cassés, débordements.
3. Corriger et re-rendre jusqu’à conformité — ou escalader si le défaut persiste.

Cette boucle attrape la classe de bugs que le code ne voit pas : la police de substitution, le graphique vide, le texte qui déborde de sa boîte, le logo pixelisé. Le rendu final est confronté à ce que l’utilisateur verra — pas à ce que le code croit avoir produit.

Pourquoi « IA-native »

Un design system classique outille des designers humains. Un design system IA-native outille des agents : tokens lisibles par code, fonctions de marque invocables, règles de routage explicites, QA automatisable. C’est ce qui permet de déléguer la production visuelle à un essaim de pods sans déléguer l’identité visuelle elle-même.

Voir aussi

• Doctrines — algos comme tools et le kernel/pod split, dont la charte-comme-donnée-kernel est un cas particulier.
• Observabilité et contrôleurs — le jugement de livrable (LLM-as-judge) dont la QA visuelle est la déclinaison visuelle.