Mise en production et projet final

Mise en production et projet final

1. Construire, publier, et ce qui casse en production

   Le passage en production n'est pas une étape technique, c'est un changement de environnement. Ce qui marche en développement peut échouer en production pour des raisons qui n'ont rien à voir avec le code.

   Les trois variables d'environnement à contrôler

   1. l'URL de l'API : si elle est écrite en dur dans le code, le build de production pointe encore sur l'environnement de développement. Symptôme caractéristique : l'application se charge et n'affiche aucune donnée, sans erreur visible ;
   2. le mode de production du framework : les vérifications de développement, les messages d'erreur détaillés et les outils de diagnostic sont normalement désactivés ou remplacés. Une application en mode développement en production est lente et bavarde ;
   3. le chemin des ressources : selon la configuration, l'application est servie à la racine du domaine ou dans un sous-répertoire. Un chemin absolu code en dur casse la seconde situation — et seulement celle-ci, donc seulement en production.

   Le piège du cache navigateur

   Après un déploiement, l'utilisateur peut continuer de voir l'ancienne version si les fichiers portent le même nom. Le nom des fichiers produits doit contenir une empreinte de leur contenu : quand le contenu change, le nom change, et le navigateur recharge. C'est le mécanisme de versionnement des ressources, et son absence se traduit par des signalements de bogues du type « vous avez oublié de déployer ».

   La liste de vérification avant mise en ligne

   • build de production réussi, sans avertissement bloquant ;
   • configuration lue depuis l'environnement, jamais en dur ;
   • versions des ressources vérifiées ;
   • parcours critique testé sur la vraie URL, pas en local ;
   • console du navigateur sans erreur ni avertissement ;
   • page lisible sans JavaScript au moins pour le contenu principal, ou rendu serveur mis en place si le référencement l'exige.

2. Sécurité côté client

   Le navigateur est un environnement hostile. Tout ce qui s'y exécute peut être lu et modifié par l'utilisateur. La conséquence est une règle unique, à ne jamais négocier.

   La règle

   Une vérification faite dans le navigateur n'est pas une sécurité, c'est un confort d'affichage. Masquer un bouton, désactiver un champ, mettre une condition dans l'interface : l'utilisateur voit une application proprement presentee, et la requete qu'il avait interdite part quand même s'il l'envoie lui-même.

   Où la sécurité doit se trouver

   • authentification et autorisation : vérifiées côté serveur, sur chaque requête, sans exception ;
   • validation des données : le client valide pour le confort, le serveur valide pour la sécurité. Les règles doivent exister des deux côtés, et c'est celle du serveur qui fait foi ;
   • données sensibles : rien de secret dans le code livré au navigateur, quoi qu'en dise la désignation « secret côté client ». Il est dans le fichier que l'utilisateur peut ouvrir ;
   • injections : toute donnée saisie par l'utilisateur est une donnée non fiable. Le parametrage d'une requete échappe au paramétrage, pas au filtrage manuel.

   Les deux fuites habituelles

   Les secrets dans le paquet livré. Une clé d'API embarquée dans le JavaScript est publique : le paquet se télécharge. Si la clé doit rester côté serveur, l'appel doit passer par votre serveur.

   Le stockage local persistant. Le stockage local du navigateur n'est pas protégé : il est lisible par tout script de la même origine, et il survit à la fermeture du navigateur. Un jeton de session qui y dort est un jeton qui finira dans une sauvegarde de navigateur ou sur un poste partagé.

3. Projet final et évaluation

   Le projet

   Réaliser en React, Angular ou Vue — au choix, avec justification écrite du choix — une application petite mais complète : authentification, liste paginée avec recherche, formulaire de création et de modification, détail, gestion des états de chargement et d'erreur.

   Ce qui est évalué, dans cet ordre

   1. les états : chargement, vide, erreur, succès. Une application qui n'affiche que le cas favorable est incomplète, quelle que soit la qualité du reste ;
   2. la séparation des responsabilités : l'état vit-il dans les composants, ou dans une source unique et explicite ?
   3. l'accessibilité : navigation au clavier complète, focus visible, hiérarchie des titres correcte, contrastes conformes ;
   4. la sécurité : aucune vérification de sécurité faite uniquement côté client, aucun secret dans le paquet ;
   5. les tests : règles métier, cas limites, erreurs réseau. Pas de test de rendu cosmétique ;
   6. la mise en production : build propre, configuration par environnement, ressources versionnées.

   Le point qui distingue les niveaux

   Ce n'est pas le nombre d'écrans. C'est la gestion des situations peu frequentes : une réponse en erreur du serveur affichée proprement, une double soumission bloquée, une recherche dont les réponses arrivent dans le désordre et n'écrasent pas le résultat courant. Ces trois points séparent une application qui marche d'une application qui tient en production — et ce sont exactement ceux que les entreprises signalent le plus souvent après la livraison.

   La justification du choix de framework

   Le livrable inclut un paragraphe expliquant le choix, avec le critère qui l'a déterminé et ce qu'il a coûté. C'est la compétence la plus transférable du cours : dans un service réel, on ne choisira pas le framework le plus connu, on choisira celui que l'équipe saura maintenir.