Étude de cas : l'énoncé et les données

Tout ce que tu as lu depuis le début du guide converge ici. On prend un énoncé de test technique réel — un vrai sujet de stage frontend, anonymisé — et on fait ce que presque personne ne fait : on l'ouvre comme un professionnel et on lit les fichiers de données avant d'écrire la moindre ligne. Trois découvertes sortent de cette lecture, et elles décident de toute l'architecture. Le module suivant, Étude de cas : la solution disséquée, écrit le code et apprend à le raconter à l'oral.

À quoi ressemble un test technique de stage

Le format s'est standardisé. On t'envoie un dépôt squelette : un projet déjà initialisé (framework, TypeScript, linter, parfois un fichier de test vide), quelques fichiers de données, et un README qui liste ce qu'on attend. Une durée indicative — deux heures, le plus souvent —, puis tu rends le code et tu viens le présenter à l'oral pendant vingt à trente minutes.

Cette deuxième moitié est la partie que tout le monde sous-estime : c'est là que l'équipe décide, parce que c'est le seul moment où elle peut vérifier ce qui l'intéresse vraiment — non pas « ce candidat sait-il produire du code », mais « ce candidat comprend-il le code qu'il produit ? ». C'est la frontière exacte entre un junior qu'on peut faire progresser et un junior qui reproduit des recettes.

Ce qui est réellement noté n'est ni le nombre de fonctionnalités, ni l'esthétique, ni l'astuce technique. Dans à peu près tous les barèmes, on retrouve les mêmes trois questions, dans cet ordre :

1. Est-ce que ça marche ? Cloner, lancer une commande, faire le parcours principal du début à la fin sans erreur. C'est éliminatoire, et plus fréquent qu'on ne croit : un projet qui ne démarre pas est écarté avant même la lecture du code.
2. Est-ce que c'est lisible ? En ouvrant trois fichiers au hasard, je comprends l'architecture ? Les noms disent-ils ce qu'ils font ? Y a-t-il du copié-collé, une fonction de deux cents lignes ? C'est là qu'un candidat qui a fait moins mais proprement passe devant un candidat qui a tout tenté.
3. Est-ce que tu peux l'expliquer ? Pourquoi ce découpage ? Pourquoi cet état vit-il ici ? Qu'est-ce qui casse si je change telle donnée ? Ça ne se prépare pas la veille : ça se prépare pendant que tu codes.

Retiens la hiérarchie, elle dicte la stratégie du reste du module : un projet minimal, propre et parfaitement expliqué bat systématiquement un projet ambitieux, brouillon et mal maîtrisé. Une équipe recrute quelqu'un avec qui elle va relire du code pendant deux ans ; elle choisit en fonction de ça.

L'énoncé, tel quel

Lis-le une première fois normalement, comme tu le lirais le jour J ; on le relira ensuite ligne par ligne pour en extraire ce qu'il ne dit pas explicitement.

Le contexte

Construire une petite application de prise de rendez-vous pour une clinique d'imagerie médicale. La particularité : les formulaires ne sont pas écrits en dur, ils sont pilotés par une configuration JSON. Selon le service que l'utilisateur choisit, ce n'est pas le même formulaire qui s'affiche.

Le stack imposé

Next.js, TypeScript, Vitest, et CSS vanilla — pas de Tailwind, pas de CSS-in-JS. Cette contrainte n'est pas un caprice : elle sert à voir si tu sais écrire du CSS sans framework, ce que les modules CSS 1 et CSS 2 t'ont préparé à faire. Le stack imposé est déjà une information : on te demande du Next.js, donc on attend que tu utilises ce que Next.js apporte, pas du React générique dans un dossier app/.

Les fichiers de données fournis

• data/services.json — la liste des services offerts par la clinique.
• data/form.json — les configurations de formulaire, chacune associée à une liste de services. La valeur spéciale "*" sert de configuration de repli pour tout service qui n'a pas de configuration dédiée.

Les cinq exigences

1. Une liste déroulante pour choisir un service, qui conditionne l'accès au formulaire.
2. Affichage conditionnel du formulaire selon le service choisi.
3. Champs générés dynamiquement depuis data/form.json.
4. Un console.log de toutes les valeurs à la soumission.
5. Réinitialisation du formulaire après une soumission réussie.

Les six bonus, par ordre de priorité annoncé

1. Remplacer les imports JSON locaux par des routes d'API Next.js.
2. Un CRUD de gestion des services (stockage en mémoire).
3. Pré-sélection du service depuis l'URL (par exemple /bone-scan).
4. Persistance de l'état du formulaire entre les rechargements de page.
5. Historique des soumissions, avec stockage côté serveur.
6. Fonctionnalités libres.

L'enquête — lire l'énoncé comme un professionnel

Le module change de genre ici : on arrête de décrire le format, on mène l'enquête sur ce sujet précis. Et voici la chose la plus contre-intuitive du module : le jour du test, tu ne dois pas commencer par coder. Tu commences par une phase de lecture d'environ vingt minutes, l'éditeur ouvert uniquement pour regarder. Ces vingt minutes ne produisent aucune ligne de code et pourtant elles déterminent la note.

1. Inventorier ce qu'on t'a donné

Parcours l'arborescence du dépôt en entier, pas en diagonale. Tu cherches quatre choses. Quels fichiers de données sont fournis ? Quelle configuration est déjà en place (tsconfig.json, next.config, un alias @/, un fichier de test d'exemple) ? Quelles dépendances sont installées — une dépendance présente dans le package.json est une autorisation implicite, parfois une invitation ? Y a-t-il du code de départ qu'on attend que tu complètes plutôt que de remplacer ?

Cinq minutes, et deux catastrophes évitées : réécrire à la main ce qui était déjà fourni, et passer à côté d'une convention du dépôt que l'évaluateur s'attendait à te voir suivre.

2. Ouvrir les données. Vraiment les ouvrir.

L'étape décisive, et celle qu'on saute le plus souvent parce qu'un fichier JSON a l'air ennuyeux. Erreur : dans un exercice piloté par des données, toute la difficulté est dans les données. L'énoncé décrit une intention ; les données décrivent la réalité, et c'est la réalité qu'il faut coder.

Ouvre chaque fichier et pose-toi mécaniquement ces questions : quelles sont les clés, et laquelle est facultative ? Quelles valeurs possibles pour un champ qui ressemble à un type ? Y a-t-il des valeurs spéciales, des sentinelles, des jokers ? Tous les éléments ont-ils la même forme ? Et surtout, la question qui rapporte le plus : y a-t-il des cas non couverts — des entrées d'un fichier sans correspondance dans l'autre ?

3. Hiérarchiser sans état d'âme

L'énoncé te donne une hiérarchie et tu la respectes à la lettre : les cinq exigences d'abord, entièrement, avant le moindre bonus. Pas « quasiment ». Les cinq. La raison est arithmétique : les exigences sont notées en tout-ou-rien — une exigence à moitié faite vaut zéro et donne l'impression que tu n'as pas lu l'énoncé — alors qu'un bonus absent ne coûte presque rien si tu peux expliquer pourquoi tu l'as écarté. L'asymétrie est totale, et pourtant l'immense majorité des candidats se précipite sur les bonus parce qu'ils sont plus amusants.

4. Décider ce que tu ne feras pas

Le geste le plus professionnel de la journée, et personne ne le fait. Avant de commencer, écris — idéalement dans le README — la liste de ce que tu as choisi de ne pas faire, avec une raison en une ligne. « Pas de CRUD de services : le bonus le plus coûteux en interface et le moins lié au cœur de l'exercice. » « Pas de persistance : elle ajoute une source de vérité concurrente à l'état React. »

Cette liste transforme une absence en décision. Sans elle, l'évaluateur voit un candidat qui n'a pas eu le temps ; avec elle, un candidat qui a arbitré. Et elle te donne, à l'oral, des réponses toutes prêtes à « qu'est-ce que tu aurais fait avec plus de temps ? ».

Ce que les données t'apprennent

Appliquons la méthode. Voici les deux fichiers tels qu'ils sont fournis : lis-les pour de vrai avant de continuer, trois découvertes s'y cachent et chacune change la structure du code.

[
  "Bone Scan",
  "Dental Imaging",
  "Ultrasound",
  "Gallium Scintigraphy",
  "Radiography (X-Ray)",
  "Computed Tomography (CT-Scan)",
  "Virtual Colonoscopy"
]

Sept services. Un tableau de chaînes brutes — pas d'objets, pas d'identifiants : la chaîne est l'identifiant. Retiens-le, ça aura des conséquences.

[
  {
    "title": "Dental radiology appointment",
    "services": ["Dental Imaging"],
    "fields": [
      { "name": "first_name", "label": "First Name", "type": "text" },
      { "name": "last_name", "label": "Last Name", "type": "text" },
      { "name": "email", "label": "Email", "type": "email" },
      { "name": "phone_number", "label": "Phone Number", "type": "phone" },
      { "name": "country", "label": "Country", "type": "dropdown",
        "options": ["Canada", "USA"] }
    ]
  },
  {
    "title": "Radiology appointment",
    "services": ["Ultrasound", "Gallium Scintigraphy", "Radiography (X-Ray)",
                 "Computed Tomography (CT-Scan)", "Virtual Colonoscopy"],
    "fields": [
      { "name": "first_name", "label": "First Name", "type": "text" },
      { "name": "last_name", "label": "Last Name", "type": "text" },
      { "name": "email", "label": "Email", "type": "email" },
      { "name": "phone_number", "label": "Phone Number", "type": "phone" },
      { "name": "details", "label": "Details", "type": "textarea" }
    ]
  },
  {
    "title": "Appointment",
    "services": ["*"],
    "fields": [
      { "name": "first_name", "label": "First Name", "type": "text" },
      { "name": "last_name", "label": "Last Name", "type": "text" }
    ]
  }
]

Trois configurations pour sept services. L'écart entre ces deux nombres est le cœur de l'exercice.

Découverte n° 1 — les type du JSON ne sont pas des types HTML

Regarde les valeurs de type : text, email, phone, dropdown, textarea. Les deux premières sont des valeurs légales de l'attribut type d'un <input>. Les trois autres, non :

Tu dois donc écrire un petit traducteur entre le vocabulaire de la configuration et celui du HTML. Découverte à haute valeur : le candidat qui ne l'a pas faite écrit <input type={field.type} />, ce qui « fonctionne » à l'écran — et c'est bien là le problème, on y revient dans un exercice plus bas.

Leçon générale : dès qu'une donnée externe contient un champ appelé type, kind ou variant, ne suppose jamais qu'il parle la même langue que ta plateforme. Le fournisseur a nommé les choses selon son domaine ; la traduction vers le tien est ton travail, et elle mérite un endroit clairement identifié plutôt que d'être éparpillée.

Découverte n° 2 — le repli "*" impose un ordre de recherche

La troisième configuration a "services": ["*"] : c'est le repli. Traduisons-le en algorithme, parce que la formulation naïve contient un piège. Si tu écris une seule recherche du genre « trouve la configuration dont la liste contient le service choisi ou l'étoile », le résultat dépend entièrement de l'ordre des éléments dans le fichier. Tant que la configuration joker est la dernière — le cas ici — ça marche par accident ; le jour où quelqu'un réordonne le fichier, tous les services basculent sur le formulaire générique. Ton code aura l'air correct et sera devenu faux sans qu'une ligne ait changé.

La formulation robuste dit exactement ce que dit la règle métier : on cherche d'abord une correspondance exacte ; si et seulement si on n'en trouve pas, on cherche le joker. Deux recherches successives, dans cet ordre, et l'ordre du fichier n'a plus aucune influence.

function findFormConfig(configs, service) {
  return configs.find((c) => c.services.includes(service))
      ?? configs.find((c) => c.services.includes('*'));
}

Découverte n° 3 — deux services n'ont aucune configuration

Compte : la première configuration couvre Dental Imaging, la deuxième cinq services. Six. Or services.json en contient sept : Bone Scan n'apparaît nulle part dans form.json.

Ce n'est pas une erreur du fichier, c'est le test lui-même. Le service orphelin vérifie que ton repli fonctionne, et il est placé volontairement en première position : le tout premier service qu'un évaluateur essaiera d'un clic est celui qui passe par le chemin de repli. Si tu ne l'as pas géré, la démonstration s'écroule à la première interaction.

Conséquence architecturale immédiate : le formulaire générique n'est pas un cas exotique de fin de liste, c'est un chemin de première classe. Il doit s'afficher avec le titre "Appointment", ses deux champs, et fonctionner comme les autres — soumission, journalisation, réinitialisation comprises.

function findFormConfig(configs, service) {
  return configs.find((c) => c.services.includes('*'))
      ?? configs.find((c) => c.services.includes(service));
}

[
  "Bone Scan",
  "Radiography (X-Ray)",
  "Computed Tomography (CT-Scan)"
]

La dissection — l'architecture retenue, et pourquoi

Fin de l'enquête, début de la dissection : les quatre sections qui suivent ouvrent le code pièce par pièce. On peut maintenant décider de la structure. L'objectif n'est pas d'être malin : c'est que quelqu'un qui ouvre le dépôt comprenne le découpage en trente secondes, et que chaque fichier ait une seule raison d'exister.

app/
  layout.tsx                  racine HTML + import du CSS global
  page.tsx                    route "/"          — Server Component
  [service]/page.tsx          route "/bone-scan" — Server Component (bonus 3)
  api/
    services/route.ts         GET  : la liste des services      (bonus 1)
    form-configs/route.ts     GET  : les configurations         (bonus 1)
    submissions/route.ts      GET + POST : l'historique         (bonus 5)
  globals.css

components/
  PriseDeRendezVous.tsx       'use client' — la frontière client, possede le service choisi
  ServiceSelector.tsx      la liste deroulante, purement presentationnelle
  DynamicForm.tsx     possede les values, la validation, la soumission
  Field.tsx                   traduit UN champ de config en element HTML

lib/
  types.ts                    Field, FormConfig, FormValues
  data.ts                  lecture des JSON — la SEULE porte d'entree des data
  configuration.ts            findFormConfig + slugs d'URL
  validation.ts               le validateur pur, generique

data/
  services.json               fournis par l'enonce, non modifies
  form.json

Quatorze fichiers. Chacun tient en moins de quatre-vingts lignes, et son nom dit ce qu'il fait.

components/
  PriseDeRendezVous.tsx       la frontière client, possède le service choisi
  ServiceSelector.tsx      la liste déroulante
  DynamicForm.tsx     possède les valeurs saisies
  Field.tsx                   traduit UN champ de config en élément HTML

lib/
  types.ts          data.ts          configuration.ts          validation.ts

Le découpage en composants, et la frontière client

La chaîne est une cascade à quatre étages, et chaque étage a une responsabilité unique :

1. La page (Server Component) charge les données et ne fait rien d'autre. Elle n'a aucun état, aucun gestionnaire d'événement, et son code ne part jamais dans le navigateur.
2. PriseDeRendezVous (Client Component) est la frontière. C'est elle qui porte le 'use client', qui détient le service sélectionné, et qui décide quoi afficher.
3. DynamicForm détient les valeurs saisies, les erreurs et l'état d'envoi. Il ne sait rien des services : on lui donne une configuration, il la rend.
4. Field ne connaît qu'un champ. C'est le traducteur config → HTML, et le seul endroit du projet qui sait qu'un "phone" devient un type="tel".

Un détail à savoir expliquer à l'oral : seul PriseDeRendezVous porte la directive 'use client'. Les trois autres n'en ont pas besoin, parce que la directive ne marque pas « ce fichier est un composant client » mais « ici commence le sous-arbre client » — tout ce qui est importé depuis un composant client devient automatiquement du code client (module Server et Client Components). En mettre partout n'est pas fatal, mais c'est du bruit ; savoir dire pourquoi une seule suffit est un signal de compréhension fort.

Où vit l'état, et pourquoi là

La question d'architecture la plus probable à l'oral. Deux états, deux endroits, deux raisons.

Le service choisi vit dans PriseDeRendezVous. Pourquoi si haut ? Parce que deux composants frères en dépendent : le sélecteur, qui affiche la valeur courante, et le formulaire, qui existe ou non selon elle. Quand une donnée est nécessaire à deux frères, elle vit chez leur premier ancêtre commun — le lifting state up, règle générale et pas astuce. La descendre dans le sélecteur l'obligerait à prévenir son parent d'une valeur qu'il détient lui-même : deux copies de la vérité.

Les valeurs saisies vivent dans DynamicForm. Pourquoi si bas ? Parce que personne d'autre n'en a besoin : le sélecteur se moque de ce que tu tapes dans « Email », et les remonter ferait redessiner le sélecteur à chaque frappe. La règle miroir : un état descend aussi bas que possible et remonte seulement quand quelqu'un d'autre en a besoin. Ces deux phrases répondent à quatre-vingt pour cent des questions d'architecture posées en entrevue junior.

export function PriseDeRendezVous({ services, configurations }: Props) {
  const [service, setService] = useState('');
  const [values, setValues] = useState<FormValues>({});   // ← remonté ici

  return (
    <section>
      <ServiceSelector services={services} value={service} onChange={setService} />
      <DynamicForm values={values} onChange={setValues} />
    </section>
  );
}

Le typage : une union discriminée sur le type de champ

Reste à décrire un champ en TypeScript. La solution paresseuse — { name: string; label: string; type: string; options?: string[] } — compile et est mauvaise pour deux raisons : type: string autorise n'importe quelle chaîne (les fautes de frappe passent), et options devient facultatif partout, y compris là où il est obligatoire — donc tu écris field.options?.map(...) même dans la branche où tu sais que les options existent.

La bonne modélisation est une union discriminée : on ne décrit pas « un champ avec des options facultatives » mais « soit un champ simple, soit une liste déroulante qui a forcément des options ». type sert de discriminant : dès que TypeScript voit field.type === 'dropdown', il sait de quelle branche il s'agit et débloque field.options comme un tableau garanti présent.

type FieldConfig =
  | { name: string; label: string; type: 'text' | 'email' | 'phone' | 'textarea' }
  | { name: string; label: string; type: 'dropdown'; options: string[] };

function countOptions(field: FieldConfig): number {
  if (field.type === 'dropdown') {
    return field.options.length;   // (a)
  }
  return field.options.length;     // (b)
}