Server et Client Components

Voici le module du bloc Next.js. Pas le plus long, pas le plus technique : le plus structurant. Tout ce qui suit — le routing, le rendu, les Server Actions — n'est que la conséquence d'une seule idée, et cette idée tient en une question que tu devras te poser devant chaque fichier d'un projet Next.js : « où est-ce que ce code s'exécute ? » Prends ton temps ici, relis-le. Beaucoup de texte et peu de code, délibérément : le code n'est que l'illustration d'un déplacement mental.

Le problème que ça résout : quand tout partait dans le navigateur

Pour comprendre pourquoi les Server Components existent, il faut d'abord ressentir la douleur qu'ils soignent. Une application React « classique » — celle que tu construirais avec Vite, ou celle que tu connais déjà sous forme d'app React Native — fonctionne selon un schéma unique : tout le JavaScript est téléchargé par le navigateur, puis exécuté par le navigateur. Le serveur n'est qu'un distributeur de fichiers : il envoie une page HTML quasiment vide, un gros paquet de JavaScript, et il se retire.

Prenons notre fil rouge, RendezVous : une application de prise de rendez-vous en clinique, avec une page qui affiche les services offerts et un formulaire pour réserver un créneau. Voici ce qui se passe, seconde par seconde, quand un patient ouvre cette page dans la version « tout client ».

1. Le navigateur demande la page. Le serveur répond avec un fichier HTML qui contient, en gros, <div id="root"></div> et une balise <script>. L'utilisateur voit… une page blanche.
2. Le navigateur télécharge le JavaScript. Pas seulement ton code : React, le routeur, la bibliothèque de formulaires, celle de dates, les utilitaires… Sur un réseau mobile moyen, ça se compte en secondes. Toujours la page blanche.
3. Le navigateur exécute le JavaScript. React démarre, monte l'arbre, et la page affiche enfin… un squelette vide, faute de données. Un spinner à la place de la liste des services.
4. Maintenant seulement, un useEffect lance un fetch vers l'API pour récupérer les services : un aller-retour réseau de plus. Puis un deuxième fetch pour les disponibilités du praticien, qui ne peut partir qu'après le premier puisqu'il a besoin de l'identifiant du service. Deux allers-retours en file indienne.
5. Enfin, les données arrivent, l'état change, React re-render, et la liste s'affiche.

Les étapes 1 et 3 devraient te dire quelque chose : ce <div id="root"></div> vide, ce <script>, puis React qui « monte l'arbre » — c'est Le clou que Next.js enfonce à ta place, du module React web ↔ React Native : les ponts, autrement dit createRoot(document.getElementById('root')).render(<App />). Dans le schéma tout-client, c'est toi qui plantes ce clou, et rien ne peut s'afficher avant qu'il ne soit planté. Tout ce module raconte ce qui change quand le framework le plante avant toi, sur le serveur.

Fais le compte : entre l'adresse tapée et le premier contenu utile, quatre attentes successives — le HTML, le JS, l'exécution, les données — dont chacune ne peut commencer que quand la précédente est finie. C'est une cascade (en anglais request waterfall) : chaque palier doit se remplir avant que l'eau ne coule au suivant.

Ajoute deux ennuis moins visibles. Le poids du bundle d'abord — le bundle, c'est le gros paquet de JavaScript que le navigateur doit télécharger : tout ton code part chez l'utilisateur, y compris ce qui n'a aucune raison d'y être. Une bibliothèque de dates pèse quelques dizaines de kilo-octets, un client de base de données bien plus, et le téléphone télécharge, décompresse et compile tout ça avant d'afficher un seul mot.

Les secrets ensuite : puisque le code tourne dans le navigateur, il ne peut jamais contenir de clé d'API ni de mot de passe de base de données. Ce n'est pas une question de discipline, c'est physique — tout ce que le navigateur exécute, l'utilisateur peut le lire. Il faut donc obligatoirement une couche d'API intermédiaire, un serveur à écrire, déployer et sécuriser, dont le seul rôle est souvent de recopier une base de données vers du JSON.

Récapitulons les quatre douleurs, parce que les Server Components répondent exactement, une par une, à ces quatre-là : (1) un bundle JavaScript trop gros, (2) des données qui n'arrivent qu'après coup, (3) une cascade de spinners qui s'enchaînent, (4) l'impossibilité de toucher directement aux données sensibles.

La révélation : « où ce code s'exécute-t-il ? »

Voici l'affirmation à graver, plus radicale qu'elle n'en a l'air : dans l'App Router de Next.js, un composant s'exécute par défaut sur le serveur. Pas « peut s'exécuter », pas « si tu configures quelque chose ». Tu crées app/page.tsx, tu y écris un composant React tout ce qu'il y a de plus normal, et il tournera sur le serveur ; son code ne sera jamais téléchargé par le navigateur.

C'est le retournement complet de ce que tu connais : en React Native, tu ne t'es jamais demandé où tournait WorkoutCard, il n'y avait pas d'autre endroit. Le nom officiel de ces composants qui tournent sur le serveur, c'est Server Components (ou « RSC », React Server Components) ; ceux qui tournent — aussi — dans le navigateur sont les Client Components.

Concrètement : quand une requête arrive, Next.js exécute tes Server Components sur le serveur. Ils vont chercher leurs données, ils rendent leur JSX, et le résultat est sérialisé — converti en une suite d'octets qui peut voyager sur le réseau (voir la section « La frontière et les props sérialisables ») — dans un format compact appelé le RSC Payload. Ce payload n'est ni du HTML ni ton code : c'est une description de l'arbre rendu — le texte, la structure, et des marqueurs qui disent « ici, un Client Component, voici le fichier JavaScript à charger pour lui ». En parallèle, Next.js produit du HTML classique pour que le navigateur ait quelque chose à afficher immédiatement.

Reprends la page RendezVous. Le serveur reçoit la requête, exécute la page, qui interroge directement la base pour obtenir les services — quelques millisecondes, la base est à côté — rend le JSX avec les vraies données dedans, et envoie du HTML déjà rempli. L'utilisateur voit la liste dès la première image : pas de page blanche, pas de spinner, pas de cascade. Et le code qui interroge la base n'a jamais quitté le serveur : il ne pèse rien dans le bundle et ne révèle aucun secret.

// Aucune directive en haut du fichier : dans l'App Router,
// ce composant est donc un SERVER COMPONENT (le défaut).

import { db } from '@/lib/db';

// Remarque le mot-clé `async` : un composant serveur a le droit
// d'être asynchrone, parce qu'il n'est rendu qu'UNE fois, côté serveur.
export default async function PageAccueil() {
  // Requête directe à la base. Les identifiants de connexion
  // vivent dans les variables d'environnement du serveur et
  // ne partiront JAMAIS vers le navigateur.
  const services = await db.service.findMany({ where: { actif: true } });

  // Quand ce JSX est produit, les données sont DÉJÀ dedans.
  return (
    <section>
      <h1>Nos services</h1>
      <ul>
        {services.map((s) => (
          <li key={s.id}>{s.nom} — {s.duree} min</li>
        ))}
      </ul>
    </section>
  );
}

Compare avec la version « tout client » : plus de useState, de useEffect, de spinner, de if (chargement). L'attente n'a pas disparu — elle a été déplacée là où elle est courte et où l'utilisateur ne la subit pas sous forme d'écran vide.

// app/page.tsx — aucune directive
import { db } from '@/lib/db';

export default async function Page() {
  const services = await db.service.findMany();
  console.log('services chargés :', services.length);

  return <ListeServices services={services} />;
}

Ce qu'un Server Component peut et ne peut pas faire

Voici la partie où tout devient intuitif, à condition de ne jamais apprendre la liste par cœur. Chaque capacité et chaque interdiction découle d'un seul fait : le code tourne sur le serveur, avant que l'utilisateur n'ait vu quoi que ce soit. Si tu retiens ça, tu peux régénérer la liste toi-même à tout moment.

Regarde la colonne de droite : pas une seule interdiction arbitraire, que des impossibilités physiques. Demander window sur un serveur, c'est comme demander le numéro de plaque d'un vélo — ce n'est pas interdit, c'est vide de sens.

Fais-toi l'exercice mental sur le cas le plus parlant, l'état. useState promet deux choses : « garde-moi cette valeur d'un rendu à l'autre » et « rappelle ma fonction quand elle change ». Or un Server Component n'a qu'un seul rendu — il produit son HTML, il est jeté, la requête est terminée. Pas de « rendu suivant » où garder la valeur, personne pour rappeler la fonction : le serveur est passé à la requête d'un autre utilisateur. Les deux promesses sont vides ici ; c'est interdit non parce que quelqu'un l'a décidé, mais parce que ça ne veut rien dire.

Même raisonnement pour onClick. Le HTML que le serveur envoie est du texte : on n'écrit pas une fonction JavaScript dans du texte en espérant qu'elle s'exécute — et même si on le pouvait, elle devrait s'exécuter deux secondes plus tard, dans le navigateur, alors que le serveur a déjà oublié cette requête. La seule façon d'avoir un vrai onClick, c'est que du JavaScript soit présent dans le navigateur. D'où la section suivante.

'use client';

import { db } from '@/lib/db';

export default async function ListeServices() {
  const services = await db.service.findMany();

  return (
    <ul>
      {services.map((s) => <li key={s.id}>{s.nom}</li>)}
    </ul>
  );
}

// app/layout.tsx — aucune directive
import { createContext } from 'react';

export const ThemeContext = createContext('clair');

export default function RootLayout({
  children,
}: { children: React.ReactNode }) {
  return (
    <html lang="fr">
      <body>
        <ThemeContext.Provider value="sombre">
          {children}
        </ThemeContext.Provider>
      </body>
    </html>
  );
}

'use client' : ce que la directive fait vraiment

Passons à l'autre côté. Puisque le défaut est « serveur », il faut un moyen de dire « celui-là, non ». Ce moyen, c'est une ligne de texte placée tout en haut d'un fichier, avant même les import :

'use client';

Une chaîne de caractères seule sur une ligne. Pas un import, pas un appel de fonction : une directive, un marqueur que l'outil de compilation lit avant tout le reste.

Voici la nuance la plus mal comprise de tout l'écosystème : 'use client' ne veut PAS dire « ce composant ne s'exécute que dans le navigateur ». Sa première exécution a lieu côté serveur, pour produire le HTML initial que l'utilisateur verra avant même que le JavaScript n'ait fini de se charger ; ensuite seulement il est ré-exécuté dans le navigateur pour devenir interactif — c'est l'hydratation (React « rebranche » les gestionnaires d'événements sur le HTML déjà présent). Ce que la directive fait vraiment, c'est marquer une frontière : « à partir d'ici, embarque ce fichier dans le bundle client ». Le vocabulaire officiel dit qu'elle déclare une boundary entre deux graphes de modules.

Hydration failed because the server rendered HTML
didn't match the client.

'use client';

export function Header() {
  // ⛔ Exécuté sur le serveur à 14:03:07, puis dans le navigateur à 14:03:09.
  //    Deux HTML différents → erreur d'hydratation.
  const now = new Date().toLocaleTimeString();
  return <p>Il est {now}</p>;
}

'use client';
import { useState, useEffect } from 'react';

export function Horloge() {
  const [heure, setHeure] = useState(new Date().toLocaleTimeString());

  useEffect(() => {
    const id = setInterval(
      () => setHeure(new Date().toLocaleTimeString()),
      1000,
    );
    return () => clearInterval(id);
  }, []);

  return <p>Il est {heure}</p>;
}

Deuxième propriété capitale : la directive est virale vers le bas. Une fois qu'un fichier est marqué 'use client', tous les modules qu'il importe rejoignent le bundle client avec lui, ainsi que les composants qu'il rend directement ; inutile de répéter la directive dans chaque enfant, elle se propage le long des import. Très pratique (une seule ligne, à l'entrée de la zone interactive) et très dangereux si tu la places trop haut : marque-la en haut de ta page principale et tout ce que cette page importe — carte de service, pied de page, formatteur de dates, bibliothèque de validation — bascule dans le navigateur. Tu as réinventé l'application « tout client » de la section « Le problème que ça résout : quand tout partait dans le navigateur », avec en prime la complexité de Next.js.

'use client';
import { useState } from 'react';

export default function AppointmentForm({ services }) {
  const [service, setService] = useState('');
  // … interactivité ici
}

La frontière et les props sérialisables

Dès qu'il y a deux machines, il y a un réseau entre elles, et dès qu'il y a un réseau, il faut convertir les données en quelque chose qui voyage. C'est ce qu'on appelle la sérialisation : transformer une valeur vivante en mémoire en une suite d'octets, puis la reconstruire de l'autre côté. Tu connais déjà le principe par JSON.stringify et le module « HTTP & fetch ».

D'où la règle : toute prop qui traverse la frontière serveur → client doit être sérialisable. Ce n'est pas une préférence stylistique, c'est une contrainte de transport. Une valeur qui ne peut pas être décrite en octets ne peut pas être remise au navigateur, point.

La ligne la plus utile du tableau est la première de la colonne de droite — les fonctions — parce que c'est celle sur laquelle tu vas te cogner. Tu voudras écrire ce que tu as toujours écrit en React : passer un callback du parent vers l'enfant (les données descendent, les événements remontent — module « Le modèle mental de React »). Mais si le parent est un Server Component et l'enfant un Client Component, ce callback devrait littéralement traverser Internet. Impossible : on ne met pas du code exécutable dans un flux de données, et de toute façon le serveur qui a créé cette fonction a terminé son travail depuis longtemps.

// PAGE SERVEUR (pas de 'use client' ici)
export default async function Page() {
  const services = await db.service.findMany();

  // ❌ `onSelect` est une FONCTION. Elle ne peut pas
  //    franchir la frontière serveur → client.
  return <ServiceSelector
           services={services}
           onSelect={(id) => console.log(id)}
         />;
}

services passe sans problème (c'est un tableau d'objets simples). onSelect, lui, bloque tout.

Le message d'erreur que tu verras alors ressemble à ceci — et maintenant tu peux le lire en entier au lieu de le subir :

Error: Functions cannot be passed directly to Client Components
unless you explicitly expose it by marking it with "use server".

Traduction : « une fonction ne traverse pas, sauf si c'est une Server Action. »

Décortique-le mot à mot, c'est un excellent entraînement. « Functions cannot be passed directly to Client Components » : on te dit quoi (une fonction) et où (vers un Client Component). « unless you explicitly expose it by marking it with "use server" » : on te donne la seule échappatoire, les Server Actions, que le module « Route Handlers & Server Actions » détaille. Ce que le navigateur reçoit alors n'est pas la fonction mais une référence, une adresse à rappeler ; le code reste au chaud sur le serveur. Il existe une variante encore plus fréquente de ce message, quand tu écris directement un onClick dans du JSX de Server Component :

Error: Event handlers cannot be passed to Client Component props.
  <button onClick={function onClick}>
If you need interactivity, consider converting part of this
to a Client Component.

Même cause, autre habillage. La dernière phrase te souffle même la solution : découpe, et rends cette partie-là cliente.

Et la bonne nouvelle du tableau : les Date traversent très bien. Beaucoup de tutoriels datés racontent qu'il faut les convertir en chaînes avant de les passer, parce qu'ils raisonnent avec JSON.stringify en tête ; or le format de sérialisation de React est plus riche que JSON — il gère nativement Date, Map, Set, les bigint et les tableaux typés. Ce qui casse vraiment, ce sont les instances de classes maison, un objet d'ORM avec des méthodes dessus par exemple : les données passeraient, les méthodes disparaîtraient, et React refuse plutôt que de te livrer un objet mutilé.

// app/page.tsx  — pas de directive
import EnTete from './en-tete';                 // pas de directive
import PanneauReservation from './panneau';     // 'use client'
import ResumeClinique from './resume';          // pas de directive

export default async function Page() {
  return (
    <>
      <EnTete />
      <PanneauReservation>
        <ResumeClinique />
      </PanneauReservation>
    </>
  );
}

Le patron de composition : les Client Components aux feuilles

On arrive au patron que tu dois savoir dessiner au tableau sans hésiter. Il tient en une image : un arbre majoritairement serveur, avec de petites îles clientes tout en bas, aux feuilles. Pas une grosse zone cliente en haut. Des petits îlots interactifs, aussi bas et aussi petits que possible.

Pourquoi « en bas » ? Parce que la viralité de 'use client' descend : plus tu poses la frontière haut, plus la zone qu'elle capture est grande et plus tu expédies de JavaScript inutile au navigateur. La question à te poser devant chaque composant est donc simple — « celui-ci a-t-il vraiment besoin de mémoire ou de réagir à un clic ? ». Si la réponse est non, et c'est non la plupart du temps, laisse-le serveur. Appliquons à RendezVous : la page affiche la liste des services (données, aucune interactivité) et un formulaire de réservation (état, validation, clics). Le découpage s'impose de lui-même.

// Aucune directive : SERVER COMPONENT.
import { db } from '@/lib/db';
import AppointmentForm from './formulaire-rendez-vous';

export default async function PageRendezVous() {
  // Les données sont récupérées AVANT le premier affichage,
  // directement depuis la base, sans passer par une API.
  const services = await db.service.findMany({ where: { actif: true } });

  return (
    <main>
      <h1>Prendre rendez-vous</h1>

      {/* Cette liste n'a aucune interactivité : elle reste
          côté serveur, et son code ne part pas au navigateur. */}
      <ul>
        {services.map((s) => (
          <li key={s.id}>{s.nom} — {s.duree} min</li>
        ))}
      </ul>

      {/* Les données traversent la frontière en tant que
          props sérialisables (tableau d'objets simples). */}
      <AppointmentForm services={services} />
    </main>
  );
}

La page fait une chose : aller chercher les données et les distribuer. Elle ne gère aucun état.

'use client';  // ← ici commence le monde du navigateur

import { useState } from 'react';

// Le formulaire reçoit les services DÉJÀ chargés : il n'a
// aucun fetch à faire, aucun spinner à afficher au démarrage.
export default function AppointmentForm({ services }) {
  const [serviceId, setServiceId] = useState('');
  const [nom, setNom] = useState('');

  return (
    <form>
      <select value={serviceId} onChange={(e) => setServiceId(e.target.value)}>
        <option value="">Choisir un service</option>
        {services.map((s) => (
          <option key={s.id} value={s.id}>{s.nom}</option>
        ))}
      </select>

      <input value={nom} onChange={(e) => setNom(e.target.value)} />
      <button type="submit">Réserver</button>
    </form>
  );
}

Un champ contrôlé, exactement comme dans le module « Formulaires 1 — contrôlé ou non ». Rien de nouveau côté React : ce qui est nouveau, c'est que ce fichier est le seul des deux à voyager jusqu'au navigateur.

Quand l'îlot doit contenir du contenu serveur : le trou children

Un cas revient sans arrêt et déroute au début. RendezVous affiche les détails d'un service dans une fenêtre modale : la fenêtre a besoin d'état (ouverte / fermée, animation, fermeture au clic extérieur), c'est forcément un Client Component ; mais son contenu — la fiche tirée de la base — n'a besoin d'aucune interactivité et gagnerait à rester serveur. Comment mettre du serveur dans du client ?

Réponse : on ne l'importe pas, on le fait descendre. Le composant client ouvre un trou avec children, et c'est le parent serveur qui le remplit. Tu as déjà vu ce mécanisme dans le module « Le modèle mental de React » avec le composant Card : un contenant qui ne sait rien de son contenu. Ici, la même idée devient une technique d'architecture.

// modale.tsx — CLIENT : il gère l'état d'ouverture,
// mais ne sait absolument RIEN de son contenu.
'use client';
import { useState } from 'react';

export default function Modal({ children }) {
  const [ouverte, setOuverte] = useState(false);
  return (
    <>
      <button onClick={() => setOuverte(true)}>Détails</button>
      {ouverte && <div className="modale">{children}</div>}
    </>
  );
}

// page.tsx — SERVEUR : il remplit le trou de la modale
// avec un composant serveur qui, lui, touche la base.
import Modal from './modale';
import FicheService from './fiche-service';   // serveur, async

export default function Page() {
  return (
    <Modal>
      <FicheService id="physio" />
    </Modal>
  );
}

FicheService est rendu sur le serveur, puis son résultat déjà calculé est glissé dans children. Son code ne rejoint jamais le bundle client — parce que le fichier modale.tsx ne l'importe pas.

C'est le patron d'entrevue. À la question « comment imbriquer un Server Component dans un Client Component ? », la réponse tient en une phrase : on ne l'importe pas depuis le client, on le passe en children (ou en prop) depuis un parent serveur — parce que la frontière suit les imports et que le JSX est une valeur sérialisable, donc il traverse. Le même patron résout le cas des providers de contexte : le contexte étant un mécanisme client, un provider doit être un Client Component qui rend {children}, et on l'utilise dans le layout serveur en enveloppant les enfants. Les enfants restent serveur, le provider reste client.

// modale.tsx
'use client';
import { useState } from 'react';
import FicheService from './fiche-service';   // serveur, async, touche la base

export default function Modal({ id }: { id: string }) {
  const [ouverte, setOuverte] = useState(false);
  return (
    <>
      <button onClick={() => setOuverte(true)}>Détails</button>
      {ouverte && <div className="modale"><FicheService id={id} /></div>}
    </>
  );
}

Passer une promesse au client : use() et Suspense

Un dernier scénario, pour que tu saches qu'il existe. Sur la page RendezVous, la liste des services se charge en 20 ms, mais les créneaux disponibles demandent 800 ms à un système de réservation externe : faire await sur les deux dans la page prendrait le contenu rapide en otage. React 19 offre une sortie élégante — un Server Component a le droit de lancer une requête sans l'attendre et de passer la promesse elle-même à un Client Component (elles sont sérialisables, revois le tableau de la section « La frontière et les props sérialisables »). Le composant client la déballe avec le hook use(), pendant qu'une frontière <Suspense> affiche un état d'attente à sa place.

La démonstration complète — le code des deux fichiers, le streaming qui va avec, et le cousin cache() de React qui évite de recharger la même donnée dans trois composants serveur — vit dans son contexte naturel : le module Rendu & data fetching.

Comment lire un fichier Next.js et savoir où il tourne

Voici l'outil pratique du module — celui que tu utiliseras vraiment, en entrevue technique comme au premier jour d'un stage. Quatre coups d'œil, dans cet ordre, et tu sais où tourne le fichier.

Une précision sur le point 3, parce que c'est là qu'on se fait avoir : un fichier sans 'use client' n'est pas forcément un Server Component — si le seul fichier qui l'importe est marqué client, il hérite de la frontière par viralité. Quand un doute subsiste, la question n'est plus « qu'y a-t-il dans ce fichier ? » mais « qui importe ce fichier ? » : remonte la chaîne d'imports jusqu'à une directive, ou jusqu'à un fichier de app/.

Applique cette grille à un vrai projet et tu verras toujours la même forme : une majorité de fichiers sans directive, qui chargent et affichent ; une poignée de fichiers 'use client' aux noms révélateurs — formulaire, modale, menu-deroulant, carrousel. Un projet qui a 'use client' partout n'est pas une fatalité technique, c'est un signe de découpage bâclé — et tu peux le dire, poliment, en entrevue.

import { db } from '@/lib/db';

export default async function CarteService({ id }) {
  const service = await db.service.findUnique({ where: { id } });

  return (
    <article>
      <h2>{service.nom}</h2>
      <button onClick={() => alert(service.description)}>
        En savoir plus
      </button>
    </article>
  );
}

Ce que ça change pour ta tête de développeur mobile

Terminons par le déplacement mental, puisque c'est l'objet réel de ce module. En React Native, tu vis dans un monde mono-lieu : tout ton JavaScript tourne sur l'appareil — composants, hooks, base locale, logique métier, calcul de l'e1RM. Le serveur, quand il y en a un, est une entité extérieure à qui tu parles par HTTP, jamais quelque chose qui exécute ton code React. Confortable : aucune question à se poser, faute d'alternative.

Next.js te fait passer à un monde bi-lieu, et le coût d'entrée est exactement là. Ce n'est pas de la syntaxe nouvelle — tout le code de ce module est du React que tu sais déjà lire — c'est une dimension supplémentaire à garder en tête en permanence. Comme le passage du synchrone à l'asynchrone : la syntaxe de await s'apprend en dix minutes, mais raisonner en « ce code ne s'exécute pas maintenant » prend des semaines. Ici, c'est « ce code ne s'exécute pas ici ».

Une chose ne change pas, et c'est rassurant : ton React reste ton React. Les props descendent, les événements remontent, le JSX est une description, la réconciliation compare deux arbres, les key suivent l'identité des éléments — tout ton investissement dans le modèle mental de React est intégralement transférable. Tu ajoutes simplement une carte à deux territoires par-dessus le moteur que tu connais.

Et il y a un bénéfice inattendu pour toi, parce que tu viens du mobile : l'obsession pour la taille du bundle et le temps avant le premier affichage utile, tu la comprends déjà d'instinct — tu sais ce que coûte un téléphone bas de gamme sur un réseau moyen. Beaucoup de développeurs web de bureau, avec leur fibre, ne le sentent pas. C'est un angle à assumer en entrevue.