Ce que « prêt pour la production » veut dire

« Prêt pour la production » s’emploie comme un synonyme de « terminé ». Ce n’en est pas un. Cela signifie que l’interface tient encore quand les conditions cessent d’être idéales — et les conditions d’un fichier de design le sont toujours.

L’écart entre un design validé et un frontend livrable est fait, pour l’essentiel, d’états que personne n’a dessinés. C’est dans cet écart que les projets perdent leurs trois dernières semaines.

Les états que personne n’a dessinés

Une maquette montre un état : le bon. Les vraies données en ont davantage, et chacun demande une décision de quelqu’un :

• Vide. Un compte neuf, sans projets, sans messages, sans historique. La réponse la plus fréquente est un panneau blanc, qui se lit comme une panne plutôt que comme un début.
• En chargement. Pas un indicateur au centre de la page : qu’est-ce qui est en attente, précisément, et la mise en page garde-t-elle sa forme pendant l’attente pour que rien ne saute.
• En erreur. Ce qu’on dit à la personne, et ce qu’elle peut faire ensuite. « Une erreur est survenue » n’est pas une décision, c’est son absence.
• Partiel. La moitié des données est arrivée. Fréquent dès qu’un écran agrège plusieurs sources, et presque jamais dessiné.
• Trop. Un nom de quarante caractères, une liste de 900 lignes, une description dans laquelle quelqu’un a collé un essai.
• Périmé. L’écran était juste il y a quatre minutes. Le dit-il ?

Six états par composant significatif, et cela avant toute traduction de l’interface. Les trancher pendant le développement revient à laisser un développeur deviner des réponses de design sous contrainte de délai. Les trancher pendant le design coûte un après-midi.

Le texte qui refuse de rester en place

Toute interface avec une deuxième langue porte en elle un problème de mise en page. L’allemand et le français sont sensiblement plus longs que l’anglais à phrase équivalente, et un bouton dimensionné sur son libellé anglais se retrouve à passer à la ligne, à être tronqué, ou à pousser son voisin hors de la rangée.

La solution n’a rien d’astucieux : concevoir le composant pour qu’il survive à son libellé réaliste le plus long plutôt qu’au plus court, et le vérifier avec les chaînes réellement traduites plutôt qu’avec du texte de remplissage. C’est une vérification de dix minutes qui attrape régulièrement des problèmes une semaine avant le lancement au lieu d’une semaine après.

Ce qui existe avant le JavaScript

Entre la requête et le moment où votre application devient interactive, quelque chose est à l’écran. Sur un ordinateur portable rapide, cet intervalle est imperceptible. Sur un téléphone milieu de gamme et une mauvaise connexion, il dure des secondes.

Les questions sont donc : qu’est-ce qui est visible pendant cette fenêtre, la mise en page bouge-t-elle quand le vrai contenu arrive, et que reçoit un client qui n’exécute jamais de JavaScript — un aperçu de lien, un lecteur de flux, un robot d’IA ? Pour une application monopage, la réponse honnête est souvent : un document vide, et ceux qui en dépendent l’ignorent le plus souvent.

Des frontières typées et un build qui refuse

« Prêt pour la production » signifie aussi que la base de code peut être modifiée par quelqu’un qui ne l’a pas écrite. C’est autant une question d’outillage que d’artisanat.

TypeScript sur les frontières — réponses d’API, valeurs de formulaire, données stockées — transforme une hypothèse fausse en erreur de compilation à l’entrée plutôt qu’en panne d’exécution au fond d’un composant. Cet argument est développé à part dans TypeScript avant de passer à l’échelle.

Ce qu’il faut ajouter ici, c’est que le build doit refuser, pas seulement signaler. Un contrôle qui affiche un avertissement se fait dépasser au défilement. Un contrôle qui fait échouer le build se fait corriger. La règle que nous appliquons : si un défaut est invisible en relecture et visible pour l’utilisateur, le build doit s’arrêter.

Les défauts qui n’existent qu’en production

C’est la catégorie qui sépare « ça marche chez moi » de « prêt pour la production », parce que ces bugs sont par définition impossibles à attraper en local. En-têtes de sécurité, règles de cache, redirections et configuration d’hébergement n’existent pas dans un serveur de développement.

Un exemple concret, pris sur ce site. Les polices web étaient chargées avec le motif standard non bloquant : demander la feuille de style comme « print », puis la basculer sur écran une fois arrivée, au moyen d’un gestionnaire en attribut sur la balise. Correct, largement recommandé, et silencieusement mort en production — la politique de sécurité du contenu du site ne couvre pas les gestionnaires d’événements en ligne, la bascule ne s’est donc jamais exécutée. La feuille de style se téléchargeait, restait limitée à l’impression, et chaque page s’affichait avec les polices système. Rien n’a levé d’erreur. Rien n’a fait échouer un build. C’était simplement un peu faux pour tout le monde, et conforme au design dans tous les environnements locaux.

Aucun processus astucieux n’empêche cette catégorie de défaut. Il n’y a que le fait de vérifier le site déployé plutôt que le site local, avec les en-têtes réellement appliqués — et de traiter « ça a l’air correct chez moi » comme le début de la vérification plutôt que comme sa fin.

Ce que devrait contenir une passation

Quand design et développement sont séparés, le fichier n’est pas le livrable. Ce dont un développeur a besoin pour ne pas deviner :

1. 01Tous les états ci-dessus, pour chaque composant qui en a.
2. 02Le comportement aux points de rupture intermédiaires, pas seulement aux trois qui ont été dessinés.
3. 03Quelles valeurs sont des jetons — espacement, couleur, échelle typographique — et lesquelles sont des exceptions.
4. 04Ce qui est interactif, ce qui se passe au survol, au focus et au clavier, et quel est l’ordre de focus.
5. 05Ce qui bouge, et ce que cela devient quand la personne a demandé une réduction des animations.
6. 06La chaîne la plus longue réellement possible pour chaque libellé, pas celle de la démonstration.

Un designer et un développeur dans la même pièce répondent à ces questions au fil de l’eau, ce qui est le principal argument pratique pour ne pas les séparer. Quand ils le sont, les réponses doivent être écrites, sinon elles sont inventées.

Comment cela se traduit dans le travail

Appstruct travaille avec React, Next.js, TypeScript et les technologies web modernes pour concevoir et développer des produits numériques prêts pour la production — ce qui signifie en pratique que les décisions de design et les décisions de développement ci-dessus sont prises par les mêmes personnes plutôt que transmises entre deux groupes.

Lowkar, une place de marché automobile construite avec React et Next.js, est l’étude de cas où cela se voit le mieux : les parcours de mise en ligne pour concessionnaires et la recherche mobile sont exactement le genre de surfaces où les états vides, partiels et surchargés sont le cas ordinaire plutôt que l’exception.

Si vous avez un design validé et un développement qui découvre sans cesse de nouveaux cas limites, dites-nous ce que vous construisez.