Personas IA et revue Tailwind : méthode et limites
Intégrez des personas IA à votre revue Tailwind sans alourdir chaque requête. Routage par fichiers, tests d’accessibilité et limites à connaître.
Des personas IA dans une revue Tailwind : ce qui aide vraiment, et ce qui ne suffit pas
Ajouter des agents spécialisés à une revue de code semble simple : on choisit quelques personas, on leur envoie les changements, puis on attend des retours sur l'interface, l'accessibilité ou la cohérence du design. En pratique, tout ne se joue pas sur le nombre d'agents. Le vrai sujet, c'est le contexte, le routage et la vérification.
Sur une base d'environ 140 composants bâtis avec Tailwind CSS v4 par-dessus des primitives Radix, l'ajout de personas issus du dépôt agency-agents a aidé à structurer les retours avant la revue humaine. Mais ça a aussi mis en évidence deux limites assez nettes : un persona peut conseiller, sans prouver ; et un prompt ne corrige pas, à lui seul, une architecture CSS ou React bancale.
Voici une façon de router les bons agents vers les bons changements, d'éviter de noyer le contexte, et de transformer les remarques d'accessibilité en éléments vérifiables. On discutera aussi des compromis à connaître (animations, usage de hidden, et maintenance des prompts).
Pourquoi intégrer des personas à la revue de code ?
Un persona d'agent, c'est une consigne structurée : une mission, des règles, un flux de travail et des critères de livraison. Dans le dépôt msitarzewski/agency-agents, les définitions sont stockées dans des fichiers Markdown versionnés. L'ensemble compte 232 agents répartis en 16 divisions, sous licence MIT. Pour une revue d'interface, les personas pertinents peuvent inclure un concepteur d'interface, un architecte UX, un agent orienté personnalité visuelle, et un spécialiste accessibilité.
L'objectif n'est pas de demander à un chatbot de « faire le boulot du designer ». Plutôt, on rend certains angles de revue plus réguliers : un agent accessibilité peut attirer l'attention sur le déplacement du focus dans une boîte de dialogue ; un agent UX peut questionner la hiérarchie visuelle ou le comportement d'un composant dans plusieurs contextes.
Cette aide est surtout utile quand elle intervient avant la revue humaine. Elle peut pointer une question à vérifier ou signaler une incohérence probable. En revanche, elle ne remplace ni la garantie de « bon comportement », ni le respect effectif des normes.
Le coût caché du chargement global
Le dépôt fournit un script de conversion vers plusieurs outils. C'est pratique, mais les modes d'installation côté utilisateur et côté projet peuvent diverger (monorepo, CI, etc.). Un fichier installé dans la configuration personnelle d'un développeur n'est pas forcément celui que l'intégration continue utilise, ni celui employé par le reste de l'équipe. Résultat : on peut croire que « les mêmes règles » s'appliquent partout, alors que ce n'est pas le cas.
Autre piège : certains environnements concatènent toutes les définitions d'agents dans un fichier de conventions. Avec 232 personas, le document devient vite lourd. Si l'outil charge ce contenu à chaque requête, même quand le changement n'a rien à voir avec l'interface, on paie ce coût en contexte et on peut aussi subir de la latence ou une consommation inutile.
Sur le papier, l'idée marche. Dans la réalité, on mélange souvent deux sujets : rendre les personas disponibles et décider lesquels sont pertinents pour un diff donné. Pour un dépôt applicatif, le deuxième point est celui à traiter en premier.
Un modèle d'usage pragmatique
Traitez les personas comme des relecteurs spécialisés, pas comme des contrôles qualité automatiques. Pour chaque changement, le système devrait répondre à trois questions :
- Quels fichiers ont changé ?
- Quelles compétences sont utiles pour ces fichiers ?
- Quelles vérifications déterministes doivent accompagner les remarques de l'agent ?
Ces réponses doivent rester distinctes. Le routage sélectionne le contexte ; l'agent formule des observations ; les tests et les outils statiques vérifient ce qui peut l'être. Cette séparation évite d'attribuer à un modèle une garantie qu'il ne peut pas fournir.
Comment router les personas selon les fichiers modifiés ?
Plutôt que de charger tous les prompts à chaque requête, associez les profils aux chemins concernés. Par exemple, les composants peuvent déclencher une revue d'interface et d'accessibilité, tandis que les styles peuvent solliciter un architecte UX ou une revue de cohérence visuelle.
import { readFileSync } from 'node:fs';
const ROUTES: Record<string, string[]> = {
'src/components/': ['design-ui-designer', 'accessibility-auditor'],
'src/styles/': ['design-ux-architect', 'design-whimsy-injector'],
};
const AGENT_ROOT = process.env.AGENCY_AGENTS ?? '~/.claude/agents';
export function personasFor(paths: string[]): string[] {
const hits = new Set<string>();
for (const path of paths) {
for (const [prefix, agents] of Object.entries(ROUTES)) {
if (path.startsWith(prefix)) agents.forEach((agent) => hits.add(agent));
}
}
return [...hits];
}
export function load(agent: string): string {
return readFileSync(`${AGENT_ROOT}/${agent}.md`, 'utf8');
}
Le Set évite de lancer le même agent plusieurs fois quand plusieurs chemins matchent une règle. Le routage par préfixe reste volontairement simple. Sur une petite base de code, c'est souvent suffisant, à condition d'être cohérent sur les chemins : racine, séparateurs normalisés, et gestion explicite des renommages ou suppressions.
Faire évoluer le routage sans créer une nouvelle dette
Quand le dépôt grandit, la table de préfixes peut devenir trop grossière. Un composant partagé, un fichier de test ou un changement global peuvent se retrouver dans des répertoires différents tout en participant au même comportement. À partir de là, il faut garder le routage lisible et l'ajuster à l'organisation réelle du code, plutôt que d'empiler des exceptions jusqu'à ne plus s'y retrouver.
Quelques règles simples limitent la casse :
- Commencez avec peu de personas et des routes explicites.
- Ajoutez une route quand un besoin de revue récurrent devient évident, pas parce qu'un persona existe.
- Enregistrez les associations dans le dépôt pour que l'équipe applique le même comportement.
- Testez la fonction de routage avec des chemins représentatifs, y compris ceux qui ne doivent rien déclencher.
- Mesurez le temps et le coût avant d'augmenter le nombre de relecteurs.
Dans l'intégration étudiée, les prompts étaient envoyés en parallèle. Un relais multi-fournisseurs a été utilisé pour répartir les appels. Sur les deux fournisseurs testés, la variation médiane du délai avant le premier jeton était d'environ 35 ms, sans troncature d'agents d'environ 3 000 jetons. Ça décrit la config observée ; ce n'est pas une loi générale. La latence dépend des fournisseurs, du réseau, de la charge et du volume réellement envoyé.
Du coup, l'indicateur le plus utile n'est pas seulement « combien de temps pour un appel ». Il faut regarder le coût par commit, le délai total avant retour, le taux de remarques utiles et la proportion de faux positifs. Si quatre agents tournent à chaque commit, même quelques secondes et quelques appels en plus finissent par devenir une facture régulière.
Pourquoi les conseils d'un agent ne remplacent pas les tests
Un persona peut rappeler qu'une boîte de dialogue doit gérer le focus et qu'il faut vérifier la navigation au clavier. C'est une bonne direction. Mais dans le cas observé, le composant paraissait correct en lisant le code, alors que le focus s'échappait à la touche Tab.
Le problème venait de l'intégration : le contenu Radix DialogContent était enveloppé dans un portail personnalisé pour gérer l'ordre d'empilement. Le nœud du portail était monté en dehors du sous-arbre attendu par Radix. L'agent pouvait dire « vérifiez le focus » ; il ne pouvait pas déduire avec certitude le comportement réel de ce mix à partir d'une consigne Markdown.
La différence est essentielle : un prompt oriente l'attention, une assertion vérifie un comportement. Donc, il faut convertir les recommandations importantes en tests reproductibles. Pour une boîte de dialogue : ouverture au clavier, placement initial du focus, confinement pendant la navigation, fermeture avec Échap, puis restitution du focus vers l'élément déclencheur.
Associer chaque risque à un contrôle adapté
Tous les retours d'un agent ne se valident pas de la même façon. Une remarque sur la hiérarchie visuelle demande souvent une revue humaine. À l'inverse, un contrôle de focus ou une relation entre deux éléments peut être automatisée.
| Risque relevé | Contrôle adapté |
|---|---|
| Le focus quitte une boîte de dialogue | Test clavier de bout en bout avec assertions sur l'élément actif |
| Un bouton ne décrit pas l'état d'un panneau | Test DOM sur aria-expanded et aria-controls |
| Une règle de style enfreint une convention | Lint ou contrôle statique, si la règle est formaliseer |
| Une animation ignore la préférence de mouvement réduit | Test de configuration CSS et vérification ciblée dans le navigateur |
| Une mise en page se dégrade dans une barre latérale | Tests visuels dans plusieurs conteneurs et largeurs pertinentes |
Les tests ne doivent pas être ajoutés « au cas où » à chaque suggestion. L'idée, c'est de cibler les comportements où la régression coûte cher, ou qui sont difficiles à repérer après déploiement. Mais si le même avertissement revient à chaque revue, c'est souvent un signe qu'il faut créer une règle ou un test plutôt que de continuer à alimenter le prompt.
Pour aller plus loin, vous pouvez relier cette démarche à vos ressources internes sur les tests d'accessibilité automatisés et la revue de code assistée par IA. L'important : des liens vers des contenus réellement publiés et utiles, pas juste des ancres créées pour la forme.
Corriger les problèmes de composants sans confondre animation et performance
Les prompts ne « réparent » pas une architecture d'interface. Un exemple fréquent : un panneau repliable qui mesure sa hauteur puis met à jour l'état React à chaque étape d'une animation. Lectures et écritures répétées, recalculs de mise en page : c'est mécanique. Ajouter une consigne générale « pensez à la performance » ne change rien au mécanisme.
Mieux vaut commencer par une question simple : est-ce que JavaScript doit vraiment mesurer la hauteur ? Pour un panneau simple, une transition CSS peut suffire, avec une structure qui masque le débordement et une mise en page adaptée au contexte du composant. Les conteneurs CSS aident aussi à ajuster l'affichage selon la largeur disponible dans le composant parent, au lieu de raisonner uniquement à partir de la largeur de la fenêtre.
Exemple de structure pour un panneau repliable
Le code suivant illustre les relations d'accessibilité et une animation CSS sans mesure de hauteur côté JavaScript. Il faut le tester dans les navigateurs et avec les technologies d'assistance visées par votre produit.
import { useId, useState } from 'react';
export function Disclosure({
label,
children,
}: {
label: string;
children: React.ReactNode;
}) {
const [open, setOpen] = useState(false);
const id = useId();
return (
<div className='@container'>
<button
type='button'
aria-expanded={open}
aria-controls={`${id}-panel`}
onClick={() => setOpen((value) => !value)}
className='flex w-full items-center justify-between rounded-lg px-3 py-2
text-sm font-medium focus-visible:outline focus-visible:outline-2
focus-visible:outline-offset-2 motion-safe:transition-colors'
>
{label}
</button>
<div
id={`${id}-panel`}
role='region'
aria-labelledby={`${id}-trigger`}
data-open={open}
className='grid transition-[grid-template-rows] duration-300
data-[open=true]:grid-rows-[1fr] data-[open=false]:grid-rows-[0fr]'
>
<div className='overflow-hidden px-3 pb-3 text-sm'>
{children}
</div>
</div>
</div>
);
}
Cet exemple sert de point de départ, pas de composant prêt à publier tel quel. En particulier, il faudra ajouter l'identifiant du déclencheur pour aria-labelledby, décider quoi faire quand le panneau est fermé (contenu inactif ou non), et vérifier le comportement au clavier. Si le contenu fermé reste dans le DOM, il ne doit pas rester atteignable via tabulation. Selon le besoin, vous pouvez le retirer du rendu ou gérer correctement son inactivité.
Côté performance : une transition de grid-template-rows évite les mesures répétées via JavaScript, mais elle n'est pas forcément exécutée uniquement par le compositeur. Selon le navigateur et le contexte, une animation de grille peut entraîner des calculs de mise en page. Le « bon » arbitrage dépend de votre cas réel : dans les endroits où le composant est très fréquent ou coûteux, il faut le profiler.
Attention à l'attribut hidden et aux mouvements réduits
L'attribut HTML hidden retire généralement l'élément du rendu, de l'arbre d'accessibilité et de l'ordre de tabulation. C'est pratique pour un panneau totalement fermé. Le revers : il coupe aussi la possibilité d'animer la fermeture. Dès que l'élément est hidden, il n'est plus affiché.
À l'inverse, une classe qui masque seulement visuellement sans rendre l'élément inactif peut laisser des contrôles accessibles au clavier.
Donc, il faut choisir clairement ce que vous attendez. Si l'animation de fermeture est indispensable, utilisez une logique de fermeture qui garde temporairement le panneau rendu, puis le rend inactif et le masque une fois la transition terminée. Si l'animation n'est pas nécessaire, hidden est une option simple et robuste. Et si vous essayez de combiner les deux approches, vérifiez le CSS généré et testez réellement le comportement : les styles Tailwind et les règles du navigateur peuvent interagir de façon surprenante.
Pour les animations, respectez aussi prefers-reduced-motion. Une règle globale qui coupe presque tout peut agir comme garde-fou, mais elle peut aussi impacter des composants tiers ou des états visuels qui s'appuient sur des transitions. Souvent, une approche plus ciblée (variantes Tailwind liées au mouvement réduit ou règles CSS limitées au composant) se maintient mieux.
Enfin, les conteneurs CSS répondent à un besoin concret : un composant peut se retrouver dans une barre latérale étroite ou dans une zone principale large, indépendamment de la fenêtre globale. Les requêtes de conteneur sont souvent plus pertinentes que des breakpoints globaux pour des composants réutilisables. Là aussi : testez dans des contextes réels, pas « au feeling » avec des seuils.
Conclusion
Les personas d'agents peuvent apporter une vraie valeur à une revue de composants Tailwind, à condition de les traiter comme des relecteurs spécialisés, pas comme des validateurs. Routez-les selon les fichiers modifiés, réduisez le contexte envoyé, versionnez les règles et mesurez l'utilité réelle.
Surtout : transformez les recommandations importantes en tests. Un agent peut vous alerter sur le confinement du focus ; seule une assertion exercée sur votre intégration peut confirmer que le focus reste bien dans la boîte de dialogue. Pareil pour la performance : une consigne ne remplace ni la correction d'une boucle de mesure, ni le profilage d'une animation.
Commencez avec quelques personas, des tests ciblés et des règles de routage simples. Si un nouveau prompt change les décisions de revue, traitez-le comme du code : diff lisible, validation, versionnement et retour d'expérience. Un système imparfait, mais vérifié, reste plus utile qu'un grand catalogue d'agents dont personne ne mesure les effets.