10 erreurs classiques à éviter lors d'un entretien technique React

React est devenu la techno frontend la plus testée en entretien sur le marché français — devant Vue.js et Angular dans la majorité des offres backend/frontend en 2026. Mais beaucoup de candidats échouent sur les mêmes pièges, parfois par mécanisation des tutoriels sans avoir intégré le modèle mental de React. Voici les 10 erreurs les plus fréquentes observées en entretien, avec la réponse attendue.

1. Confondre re-render et nouvelle exécution du composant

Erreur classique : penser qu'un composant qui re-render "recrée" tous ses hooks. Faux. Une fonction-composant est exécutée à chaque render, mais l'identité des hooks (useState, useRef, etc.) est préservée par React grâce à l'ordre d'appel. C'est pour cela que vous ne pouvez pas appeler un hook conditionnellement — l'ordre doit rester stable entre les renders.

2. Mauvaise gestion des dépendances dans useEffect

C'est l'erreur n°1 en entretien React. Soit le candidat oublie une dépendance (et son effet utilise une closure obsolète), soit il en met trop (et l'effet se ré-exécute en boucle). La bonne réponse :

• Toutes les variables externes utilisées dans l'effet doivent être listées (la règle eslint-plugin-react-hooks le force).
• Si une dépendance change trop souvent, le bon réflexe est de la stabiliser avec useCallback/useMemo, ou de dériver l'état plutôt que de le synchroniser via useEffect.
• Ne jamais désactiver l'avertissement eslint sans très bonne raison documentée.

3. Utiliser useEffect pour de l'état dérivé

Anti-pattern fréquent : avoir un useState pour un "fullName" et un useEffect qui le met à jour quand firstName ou lastName changent. La doc React est explicite : on ne synchronise pas un état dérivé via useEffect. On le calcule directement pendant le render :

const fullName = ${firstName} ${lastName}`` — point. Pas de state, pas d'effet. Cette correction simple sauve énormément de bugs et de re-renders inutiles.

4. Muter directement un state

Faire state.items.push(newItem) puis setState(state) ne déclenche pas de re-render — la référence n'a pas changé. React utilise l'égalité référentielle (Object.is) pour détecter les changements. Bonne réponse : créer une nouvelle référence avec setState(prev => [...prev.items, newItem]) ou un équivalent immuable. Mentionner Immer comme alternative ergonomique pour les structures profondes est un bon signal.

5. Utiliser l'index comme key dans une liste dynamique

Classique. key={index} dans une liste qui peut être réordonnée, filtrée ou modifiée casse la réconciliation de React : les composants enfants gardent les mauvais états locaux. La bonne pratique : utiliser un identifiant stable et unique (item.id). L'index n'est acceptable que pour des listes strictement statiques et non réordonnées.

6. Abuser de useMemo et useCallback "par sécurité"

Erreur inverse mais tout aussi fréquente : envelopper toutes les fonctions et calculs dans useCallback/useMemo "pour optimiser". En réalité, ces hooks ont eux-mêmes un coût (mémoire, comparaison de dépendances) et sont inutiles si le composant qui les consomme n'est pas memoïsé avec React.memo. La bonne réponse en entretien :

useMemo et useCallback ne sont utiles que dans deux cas : un calcul réellement coûteux qu'on veut éviter de refaire, ou une référence qu'on passe à un enfant memoïsé pour éviter de casser sa memoïsation. En dehors de ces cas, c'est du bruit.

7. Mal comprendre la propagation des contextes

Le piège : penser qu'un useContext ne re-render que les composants qui utilisent la valeur du contexte. Faux — tout consommateur du contexte re-render quand la valeur change, même s'il n'utilise qu'un sous-champ de l'objet. Solutions courantes : splitter le contexte en plusieurs (un par préoccupation), ou utiliser une librairie comme Zustand ou Jotai pour un état global plus granulaire.

8. Confondre composants serveur et composants client (Next.js App Router)

Sujet désormais incontournable en 2026 sur les entretiens Next.js. La règle clé : les composants sont serveur par défaut dans l'App Router. Le "use client" doit être ajouté dès qu'on utilise un hook (useState, useEffect), un événement (onClick), ou des APIs navigateur (window, localStorage).

Erreur classique : tout marquer en "use client" pour ne pas se poser de questions. Cela annule l'intérêt du SSR et augmente la taille du bundle JS. La bonne approche : garder les composants serveur le plus haut possible dans l'arbre, et descendre la frontière client le plus bas possible.

9. Ignorer les Suspense boundaries et les erreurs asynchrones

Avec React 18+ et le data fetching moderne, savoir poser une Suspense au bon endroit pour afficher un fallback de chargement, et un ErrorBoundary pour capturer les erreurs, est attendu sur les profils mid et senior. Mentionner que les composants serveur Next.js peuvent suspend nativement via await est un bon signal de maîtrise actuelle de l'écosystème.

10. Donner des réponses théoriques sans expérience pratique

Le dernier piège n'est pas technique : c'est discursif. Beaucoup de candidats récitent des définitions sans pouvoir donner d'exemple concret tiré de leur expérience. Les recruteurs détectent immédiatement ce signal. Préparez 2-3 anecdotes précises pour les sujets clés : un bug de performance que vous avez résolu, un refacto d'état mal géré, une migration class → hooks. C'est ce qui fait la différence entre un "je connais" et un "j'ai utilisé".

Pour aller plus loin

Les meilleures sources actuelles pour approfondir : la documentation officielle React (entièrement réécrite en 2023, beaucoup plus pédagogique), le blog Vercel pour Next.js, et les conférences React Summit / React Advanced disponibles sur YouTube. Évitez les tutoriels de plus de 18 mois — l'écosystème évolue vite et beaucoup de patterns recommandés en 2022 sont aujourd'hui des anti-patterns.