Ce que doit avoir un frontend professionnel et comment le structurer

Un frontend n'est pas « la jolie partie »

Pour l'utilisateur de votre entreprise, le frontend est le produit : c'est là que se gagne ou se perd le devis, l'inscription ou le paiement. Et pourtant, c'est l'une des parties les moins auditées. Un système peut avoir un backend impeccable et un frontend que personne ne peut maintenir, qui se lit mal sur un téléphone, que Google ne comprend pas ou qui se casse chaque fois que la marque change.

Voici la liste de ce que, à notre avis, un frontend professionnel doit avoir, et pourquoi. Ce n'est pas une recette : c'est ce qu'il convient de demander à votre équipe ou à votre prestataire, et comment reconnaître s'il l'a.

1. Des composants avec une direction, pas un dossier de « trucs »

Une interface professionnelle se construit avec de petites pièces réutilisables. La documentation de React elle-même le formule ainsi : un composant doit idéalement ne s'occuper que d'une seule chose, et s'il grossit, on le découpe en sous-composants.

Un vocabulaire utile est celui de l'Atomic Design (Brad Frost) : les atomes (un bouton, un champ), les molécules (un champ avec son libellé et son erreur) et les organismes (un en-tête, un formulaire complet). Nous l'étendons avec des sections et des pages lorsque cela aide à gouverner le produit. C'est une convention, pas une loi. Ce qui lui donne de la valeur, c'est une règle unique : la dépendance va dans un seul sens. Une pièce de base ne connaît pas les pièces de produit qui l'utilisent.

Et une discipline qui évite beaucoup de dépenses : abstraire tard. Un motif devient un composant partagé quand il s'est déjà répété et que ses variantes se sont stabilisées ; abstraire plus tôt coûte souvent plus cher qu'un doublon visible.

Savez-vous aujourd'hui quels écrans changent si la couleur principale de votre marque change demain ?

2. Un design system avec des tokens

Un token de design est, selon la définition du groupe qui travaille sur son format, une information dotée d'un nom lisible : au minimum, une paire nom et valeur (par exemple, la couleur du texte principal). Le principe est simple : la couleur, la typographie et l'espacement ne s'écrivent pas dans le composant ; ils proviennent d'un token. Changer de marque revient à changer une valeur, et non à modifier chaque écran.

Une précision honnête : le format standard de tokens du Design Tokens Community Group reste un brouillon, et son propre texte demande de ne pas l'implémenter pour l'instant. Les tokens peuvent être définis dès aujourd'hui dans votre système et exportés lorsque le standard se stabilisera.

3. Storybook, et ce qui est livré avec

Un composant sans documentation est difficile à bien utiliser pour qui ne l'a pas écrit. Storybook permet de construire et de relire chaque composant de manière isolée, avec ses variantes et ses cas difficiles à atteindre, et il fait office de documentation générée à partir des histoires elles-mêmes (sa fonction d'autodocumentation la produit à partir des métadonnées du composant), de sorte qu'elle reste proche du code ; cela dit, elle vaut ce que valent les histoires : elles doivent refléter l'usage réel. Pour une entreprise, l'important est ce qu'elle reçoit : un catalogue navigable que le design, la QA et le métier peuvent ouvrir, et non une capture d'écran dans une conversation.

Comment l'organiser pour qu'il serve de contrat —avec hiérarchie, états et revues— nous l'expliquons à part : Comment structurer un Storybook qui serve de contrat. Ici, seulement l'exigence : un catalogue qui dépend de la mémoire de quelqu'un pour être publié finit par être périmé ; publiez-le automatiquement à l'approbation des changements.

4. Des tests à trois niveaux, et pourquoi un seul ne suffit pas

• Tests unitaires et de composant (avec Jest ou son équivalent moderne), qui vérifient la logique et le comportement visible.
• Tests de bout en bout (par exemple avec Playwright), qui parcourent les flux qui font vivre l'entreprise : l'inscription, le devis, le paiement. Son guide de bonnes pratiques demande de tester ce que voit l'utilisateur et non les détails internes, et de garder chaque test isolé des autres.
• Accessibilité et régression visuelle. La comparaison de captures aide à détecter un changement que personne n'a ouvert, même si la documentation de Playwright elle-même avertit que le rendu varie selon le système d'exploitation, le navigateur et le matériel, et que les références doivent donc être générées dans le même environnement que celui où l'on compare.

Sur l'accessibilité, une limite qu'il convient de dire à voix haute : selon la documentation de Playwright, les tests automatiques détectent certains problèmes courants, mais beaucoup ne se découvrent que par une revue manuelle. Automatisez ce qui peut l'être et réservez la revue humaine, au clavier et au lecteur d'écran, aux flux critiques.

Le niveau qu'il convient d'exiger est WCAG 2.2 AA. Deux exemples concrets du standard : le texte doit avoir un contraste d'au moins 4,5:1 (3:1 pour le grand texte), et les éléments sur lesquels on appuie ou clique doivent mesurer au moins 24 par 24 pixels CSS, sauf exceptions.

Combien de vos flux critiques ont un test qui s'exécute seul à chaque changement ?

5. CI/CD du frontend : ce qu'on doit pouvoir arrêter

Le pipeline d'un frontend est le moyen d'éviter que la qualité ne dépende de la bonne volonté de quiconque. Il doit au minimum vérifier le style, les types, les tests et la construction, et contrôler les dépendances présentant des vulnérabilités connues (npm audit envoie la description des dépendances au registre et renvoie un rapport de vulnérabilités connues ; c'est un contrôle utile, mais pas une analyse de sécurité suffisante à lui seul). Chaque étape peut arrêter la livraison ; le détail de la construction d'un chemin de mise en production se trouve dans Livrer sans crainte sur votre propre infrastructure.

Sur l'analyse de qualité, ce qu'elle doit satisfaire. Le portail qualité par défaut de SonarQube Server, « Sonar way » (selon sa documentation actuelle ; c'est la configuration d'un produit, pas une définition universelle de la qualité), pose quatre conditions sur le code nouveau : aucun nouveau problème, points sensibles de sécurité examinés, couverture d'au moins 80 % et duplication de 3 % ou moins. Ce qui est précieux, c'est la philosophie : il ne s'agit pas de corriger tout l'ancien, mais de ne pas ajouter de nouvelle dette. Et une nuance qui compte pour nous : un portail désactivé ou qui ne s'exécute pas n'est pas la même chose qu'un portail qui passe. Exigez de voir l'exécution, pas seulement la couleur du tableau de bord.

6. SEO et lecture par l'IA : un contenu explorable et vérifiable

Si votre site est public, son contenu important doit être accessible à un moteur de recherche et, lorsque c'est pertinent, aux assistants d'IA. Il faut le vérifier sur le HTML réellement livré et rendu, et non le supposer. Google recommande des titres uniques et descriptifs et des descriptions propres à chaque page, et avertit que si le contenu important est caché derrière du JavaScript, il peut ne pas être compris. Le guide de web.dev sur les stratégies de rendu explique le compromis : le rendu statique à la construction offre les meilleurs temps de réponse, mais passe mal à l'échelle avec de nombreuses URL uniques ; le rendu côté client oblige à surveiller le poids du JavaScript.

Sur cette base, trois pratiques : des données structurées en JSON-LD (le format que Google recommande comme le plus facile à maintenir à grande échelle), une adresse canonique par page pour éviter les doublons et, s'il y a plusieurs langues, l'indication des versions alternatives par langue (ce sont deux mécanismes distincts). Et une proposition, llms.txt, qui offre aux agents un résumé du site en Markdown. Ce n'est pas un standard officiel : c'est une proposition ouverte de la communauté, et les différents agents d'IA se comportent de manière différente, il n'existe donc pas d'exigence universelle comme pour les moteurs de recherche. La meilleure condition est que ces vérifications fassent partie de la construction et non d'une liste dont quelqu'un se souvient à la fin.

7. Performance : on la mesure avec ce que vit l'utilisateur

Google définit trois signaux d'expérience, évalués au 75e centile des chargements de page, segmentés entre mobile et ordinateur. Ils se mesurent avec l'usage réel de vos utilisateurs ; un test sur une seule machine oriente, mais ne remplace pas cette mesure :

• LCP (la rapidité d'apparition du contenu principal) : 2,5 secondes ou moins.
• INP (la rapidité de réponse à un toucher ou à une touche) : 200 millisecondes ou moins.
• CLS (l'ampleur des déplacements du contenu pendant le chargement) : 0,1 ou moins.

Deux idées d'ingénierie soutiennent ces chiffres. La première : ne pas charger d'emblée ce qui n'est pas utilisé d'emblée. React permet de découper le code et de ne charger un composant que lorsqu'il est nécessaire.

// Illustratif, tiré de la documentation de React (lazy + Suspense).
const VistaPrevia = lazy(() => import('./VistaPrevia.js'));

<Suspense fallback={<Cargando />}>
  <VistaPrevia />
</Suspense>

La seconde : ne pas appliquer cette idée à ce que l'utilisateur voit en premier. Selon web.dev, l'image candidate au LCP ne doit jamais être chargée en différé, car on retarde justement ce que mesure ce signal.

8. Sécurité : le navigateur est un territoire hostile

Tout ce qui parvient au navigateur est public ; aucun secret n'y vit. Deux idées centrales :

• XSS. React échappe par défaut ce qu'il affiche, mais il offre une échappatoire, dangerouslySetInnerHTML, que sa propre documentation qualifie de dangereuse : avec un contenu non fiable, il est trivial d'introduire une vulnérabilité. L'OWASP recommande d'assainir avec une bibliothèque spécialisée, et avertit qu'aucune technique seule n'empêche le XSS.
• Défense en profondeur. Une politique de sécurité du contenu (CSP) restreint ce que le code de la page peut faire (d'où il charge des ressources et à quoi il se connecte, entre autres) et aide contre le XSS et le clickjacking. MDN est clair : elle ne remplace pas l'assainissement ; elle s'utilise en plus de celui-ci.

Et une règle simple de jugement : ne laissez pas dans le navigateur, lisibles par n'importe quel script, des identifiants réutilisables ni des données sensibles. Et n'oubliez pas que la validation côté client ne remplace jamais celle du serveur : l'autorisation se décide toujours côté serveur.

9. Après la mise en production : résilience et observabilité

Un frontend professionnel part du principe que quelque chose va échouer. Chaque appel à un service a ses états de chargement, de vide, d'erreur et de nouvelle tentative, et une défaillance s'affiche, elle ne se cache pas derrière un écran blanc. Et quelqu'un doit être informé de l'erreur avant que le client ne la signale : erreurs du navigateur capturées avec un contexte minimal et sans données personnelles, et signaux de performance de la section 7 surveillés auprès d'utilisateurs réels. Si le site charge des balises d'analyse ou de tiers, ce sont aussi du code : elles pèsent sur la performance et doivent rester dans le budget.

Il convient aussi de convenir de ce qui est pris en charge : navigateurs, appareils modestes et réseaux lents. Un design system, enfin, a besoin d'un responsable, de versions et d'un moyen de retirer des composants sans casser ceux qui les utilisent.

Quelles preuves demander avant d'approuver

Pour un comité, un frontend s'approuve avec des preuves, pas avec une démonstration. Demandez : le catalogue de composants publié ; le rapport de tests de la dernière livraison, avec son décompte lu dans le résumé ; le résultat du portail qualité avec la condition qui a échoué, le cas échéant ; la revue d'accessibilité avec sa partie manuelle ; les signaux de performance avec des données réelles ; et qui autorise une exception et comment elle est consignée.

Ce que presque toute équipe reporte

Deux choses : les tests de bout en bout de tous les flux critiques, et qu'une défaillance d'accessibilité arrête la publication au lieu de simplement avertir. Un contrôle qui ne peut pas arrêter un changement est une suggestion. Nous le disons parce que le nier ne règle rien, et parce que c'est précisément ce qu'il convient de demander à n'importe quelle équipe, y compris la vôtre.

Conclusion

On ne reconnaît pas un frontend professionnel à son apparence le jour du lancement, mais à ce qu'il supporte ensuite : un changement de marque, un auditeur, un téléphone modeste, un moteur de recherche, un attaquant. Quand cela échoue, le coût n'est pas technique : ce sont des ventes perdues, des reprises et un audit difficile à réussir. Chez Hábil, nous sommes experts en la matière. Nous construisons le frontend de votre produit avec des composants gouvernés, un design system, des tests, de l'accessibilité, de la performance et de la sécurité contrôlés à chaque changement, et nous pouvons commencer par confronter votre parcours digital prioritaire à cette liste.