frontend-dev

---

name: frontend-dev description: Conseils d'ingénierie frontend de niveau senior couvrant l'architecture, la conception de composants, les performances, les systèmes de design, l'intégration d'API et les tests. Utilisez cette compétence pour toute tâche d'ingénierie frontend : création de composants, revue d'architecture, configuration de projet, débogage des performances, conception d'un système de design, rédaction de tests ou intégration d'API. Déclenchez-la sur des mots-clés comme "composant", "React", "Angular", "TypeScript", "frontend", "UI", "système de design", "performance", "bundle", "gestion d'état", "GraphQL", "Relay", ou tout travail d'interface web. Déclenchez-la également pour des demandes vagues comme "construis-moi une page" ou "ajoute une fonctionnalité" lorsqu'un contexte frontend est présent. Cette compétence couvre TOUS les types de sorties : code, documents d'architecture, recommandations de structure de fichiers, audits de performances et stratégies de test. metadata: version: "1.0.0"

Compétence Frontend Dev

Ingénierie frontend de niveau senior, pragmatique, prête pour la production. L'objectif est toujours un code fonctionnel, maintenable et performant — pas la pureté académique.

Détection de la pile

Avant toute chose, identifiez la pile à partir du contexte. En cas de doute, demandez. Chargez ensuite le fichier de référence approprié.

Pile	Charger
React (sans GraphQL)	references/react.md
React + GraphQL/Relay	references/react-graphql.md
Angular	references/angular.md
TypeScript (toutes piles)	references/typescript.md (charger en plus du fichier de pile)

Chargez toujours references/typescript.md en plus du fichier de pile, sauf si le projet est explicitement en JS uniquement.

---

Principes universels

Ces principes s'appliquent quelle que soit la pile. Ne les sautez pas.

Architecture

• Séparez les préoccupations agressivement : le rendu UI, la logique métier, la récupération de données et les effets secondaires vivent dans des couches différentes. Les composants ne doivent pas contenir d'appels de récupération, de chaînes API brutes ou de règles métier.
• Regroupez par fonctionnalité, pas par type : préférez features/profil-utilisateur/ contenant composant + hook + test + styles plutôt que des dossiers de niveau supérieur components/, hooks/, tests/. Adaptez la structure à la complexité de l'application — ne faites pas de sur-ingénierie pour une petite application.
• Composition plutôt qu'héritage : construisez les UI en composant de petits composants ciblés. Évitez les hiérarchies de composants profondes.
• Pas d'abstraction prématurée : écrivez la chose deux fois, puis abstrahissez. Une abstraction construite sur un seul cas d'utilisation est généralement erronée.

Conception de composants

• Les composants doivent faire une seule chose. Si un composant a plus d'une raison de changer, divisez-le.
• Séparez les composants de présentation (UI pure, aucun effet secondaire) des composants conteneurs/intelligents (données, logique, orchestration).
• Les interfaces des props doivent être explicites et typées. Pas de any, pas de object, pas de {} comme type.
• Par défaut, utilisez des composants contrôlés pour les formulaires.

Performances (bases non négociables)

Objectifs Core Web Vitals (mesurés au 75e percentile des utilisateurs réels) :

• LCP ≤ 2,5 s (chargement)
• INP ≤ 200 ms (interactivité — a remplacé FID en mars 2024)
• CLS ≤ 0,1 (stabilité visuelle)

Règles de performances universelles :

• Ne bloquez jamais le thread principal avec de longues tâches synchrones
• Chargez paresseusement (lazy load) les routes et les composants lourds par défaut
• Définissez des dimensions explicites sur toutes les images et tous les médias (empêche le CLS)
• Utilisez fetchpriority="high" sur les images LCP
• Différez les scripts tiers non critiques
• Évitez le thrashing de mise en page (regroupez les lectures/écritures DOM)
• Activez l'éligibilité bfcache : évitez les écouteurs unload, évitez no-store là où ce n'est pas nécessaire

Systèmes de design et tokens

• Définissez les tokens de design (couleur, espacement, typographie, rayon, ombre) comme la vérité de référence — ne codez jamais en dur les valeurs dans les composants
• Utilisez les propriétés personnalisées CSS (--color-primary) ou un système de tokens (Style Dictionary, config Tailwind) pour centraliser le thème
• Atomic Design comme modèle mental : atomes → molécules → organismes → templates → pages. Ne forcez pas la nomenclature, mais pensez dans cette hiérarchie
• Documentez les composants dans Storybook pour l'isolation, la découvrabilité et les tests de régression visuelle
• L'accessibilité n'est pas optionnelle : WCAG 2.1 AA minimum. Chaque élément interactif nécessite un support clavier, une gestion du focus et ARIA lorsque le HTML sémantique est insuffisant

Intégration d'API

• N'appelez jamais les API directement depuis les composants. Utilisez une couche de données : hooks personnalisés, services ou une bibliothèque de requêtes
• Gérez explicitement les trois états : chargement, erreur, succès — ne supposez jamais le chemin heureux
• Utilisez des mises à jour optimistes pour les performances perçues par l'utilisateur sur les mutations
• Validez les réponses API à la frontière (Zod, io-ts ou équivalent) — ne faites pas confiance à la forme des données externes
• Centralisez les URL de base de l'API et l'injection du token d'authentification — ne les dispersez jamais dans les composants

Stratégie de test

Approche en trois couches :

1. Tests unitaires : fonctions pures, utilitaires, hooks personnalisés (Jest / Vitest)
2. Tests de composants : comportement de rendu, interactions utilisateur, changements d'état (Testing Library — testez le comportement, pas l'implémentation)
3. Tests E2E : parcours utilisateur critiques uniquement (Playwright ou Cypress)

Règles :

• Testez le comportement du point de vue de l'utilisateur, pas l'implémentation interne
• Pas de snapshots pour la logique — ils sont fragiles. Utilisez les snapshots uniquement pour les régressions visuelles intentionnelles
• Visez une couverture élevée sur la logique métier, pas sur le code d'infrastructure
• Regroupez les fichiers de test avec le code qu'ils testent : Button.test.tsx à côté de Button.tsx

Navigation dans le code (tsserver)

Le flux de travail général LSP par recherche de texte vit dans la compétence dev-standards ("Navigation dans le code"). Notes spécifiques à TypeScript :

L'outil LSP achemine vers tsserver pour TS/TSX. Les opérations sur un seul fichier sont fiables à froid : documentSymbol, hover, goToDefinition.

Attention — tsserver indexe paresseusement (contrairement à gopls). Une requête entre fichiers (findReferences/workspaceSymbol) exécutée contre un serveur froid peut sous-compter silencieusement : elle ne connaît que les fichiers déjà chargés dans son projet et renvoie un résultat confiant mais incomplet (par exemple, uniquement la déclaration). Protégez-vous-en :

• Traitez un nombre de références suspect bas comme non vérifié.
• Interrogez findReferences depuis un site d'utilisation (un fichier qui importe le symbole), pas la déclaration en isolation — cela force le graphe du projet à se charger.
• Pour les décisions "est-ce encore utilisé quelque part ?" (suppression de code mort, renommage sécurisé), confirmez avec grep — une sous-comptabilisation ici est dangereuse.

Outils par défaut (2025)

• Bundler : Vite (par défaut pour les nouveaux projets) ; Webpack 5 pour les grandes configurations d'entreprise qui l'utilisent déjà
• Linting : ESLint + @typescript-eslint + Prettier (formatage séparé du linting)
• Gestionnaire de paquets : pnpm préféré pour les monorepos ; npm ou yarn acceptables
• Monorepo : Nx ou Turborepo pour les espaces de travail multi-paquets
• CI : Exécutez la vérification de type, le linting, les tests et la construction sur chaque PR. Ne fusionnez jamais des pipelines rouges.

---

Modes de sortie

Lors de la production de résultats, suivez ces directives :

Code de composant : incluez les types, gérez les cas limites, suivez les modèles de la pile à partir du fichier de référence. Fournissez le composant + son test dans la même réponse, sauf si la taille l'interdit.

Architecture / structure de fichiers : montrez d'abord l'arborescence des répertoires, puis expliquez le raisonnement. Soyez tranché — donnez une bonne structure, pas un menu d'options.

Audit de performances : listez les résultats par sévérité (Critique / Avertissement / Info). Pour chaque résultat : ce que c'est, pourquoi c'est important, comment le corriger.

Configuration du système de design : structure des tokens d'abord, puis primitives de composants, puis configuration de la documentation.

Intégration d'API : montrez le modèle de couche de données pour la pile spécifique, puis le composant qui le consomme.

Test : montrez les tests à côté du code testé. Suivez AAA (Arrange / Agir / Assert).

---

Compétence accompagnatrice

Cette compétence couvre l'ingénierie. Pour l'esthétique visuelle — choix typographiques, systèmes de couleurs, conception de mouvements, composition spatiale et éviter l'esthétique générique de l'IA — référez-vous à la compétence frontend-design. Pour les tâches qui nécessitent les deux (par exemple "construis un tableau de bord qui a fière allure"), utilisez les deux compétences ensemble : frontend-dev pour l'architecture et la qualité du code, frontend-design pour l'orientation visuelle.

Fichiers de référence

Lisez-les avant de produire une sortie spécifique à la pile :

• references/typescript.md — Mode strict TypeScript, modèles, pièges courants
• references/react.md — React 19, Next.js, hooks, gestion d'état, stratégies de rendu
• references/react-graphql.md — Relay, fragments colocalisés, modèles GraphQL dans React
• references/angular.md — Angular v22, Signaux, Composants autonomes, sans zone, NgRx