Une interface utile ne naît pas d’une couche de peinture.
Les vues du chapitre précédent possèdent déjà une structure et un sens. Le travail front-end commence maintenant : créer une identité visuelle cohérente, adapter la disposition aux écrans, rendre les actions évidentes et ajouter seulement les comportements qui améliorent réellement le parcours.
Nous n’allons pas cacher un HTML fragile derrière des effets. CSS renforcera la hiérarchie et la lisibilité; JavaScript restera progressif; les images seront choisies pour leur utilité; le cache sera traité comme une partie du déploiement.
Donnez une interface responsive à l’application de tâches, ajoutez une confirmation de suppression, optimisez les images et garantissez que chaque nouvelle version des ressources apparaît immédiatement après déploiement.
Comprendre les ressources du navigateur
Une page HTML décrit le contenu, mais son apparence et une partie de son comportement proviennent de ressources séparées : feuilles CSS, scripts JavaScript, images, polices et icônes. Le navigateur les demande après avoir reçu le document.
Cette séparation permet au même CSS de servir plusieurs pages et au cache de conserver un fichier déjà téléchargé. Elle impose aussi des URL correctes, une organisation prévisible et une stratégie lorsque le contenu change.
Dans PHPAML classique, les fichiers qui doivent être accessibles directement vivent dans public. Le code privé, la configuration et les données ne doivent jamais être exposés par le serveur Web.
public contient uniquement ce que le navigateur doit pouvoir demander directement.
Organiser CSS, scripts et images
Commencez avec une arborescence simple : public/css, public/js et public/assets. À l’intérieur, créez des sous-dossiers lorsqu’une vraie frontière apparaît, pas pour remplir une architecture vide.
Un fichier app.css porte les fondations communes. Les styles propres aux tâches peuvent vivre dans tasks.css lorsque le volume le justifie. Nommez les fichiers selon leur responsabilité plutôt que leur date ou leur auteur.
Les logos, favicons, sitemap et robots.txt restent directement dans public lorsqu’une URL stable est utile. Les images de contenu peuvent être organisées dans assets/images avec des noms descriptifs.
L’organisation doit rendre une ressource facile à trouver et difficile à exposer par erreur.
Construire une base CSS cohérente
Avant de styliser chaque carte, définissez les règles globales : box-sizing, couleurs, typographie, largeur de lecture, espaces et styles de focus. Ces décisions créent une cohérence que des corrections isolées ne peuvent pas offrir.
Utilisez des variables CSS pour les couleurs, rayons, ombres et espacements répétés. Elles permettent d’ajuster le système sans rechercher des dizaines de valeurs et préparent naturellement les thèmes.
Évitez les sélecteurs trop généraux qui modifient toutes les balises sans intention. Des classes explicites comme task-card ou form-error rendent l’effet d’une règle visible dans le template.
Un design solide commence par un petit système, pas par une accumulation de corrections.
:root {
--surface: #ffffff;
--text: #17181a;
--accent: #6540d9;
--space-3: 0.75rem;
--space-6: 1.5rem;
}
*, *::before, *::after { box-sizing: border-box; }
body { margin: 0; color: var(--text); background: var(--surface); }
.task-grid { display: grid; gap: var(--space-6); }
@media (min-width: 48rem) {
.task-grid { grid-template-columns: repeat(2, minmax(0, 1fr)); }
}Créer une mise en page responsive
Responsive ne signifie pas réduire toute la page. Le contenu doit changer de disposition selon l’espace : colonnes qui deviennent une pile, navigation adaptée, boutons suffisamment larges et textes qui conservent une mesure lisible.
Commencez par le mobile, où les contraintes obligent à hiérarchiser. Ajoutez ensuite des media queries lorsque le contenu bénéficie réellement d’une autre disposition, plutôt que de viser une liste arbitraire d’appareils.
Utilisez min(), max(), clamp(), grid et flex pour créer des dimensions fluides. Vérifiez les textes longs, le zoom, l’orientation paysage et les tableaux; le cas moyen ne révèle pas tous les débordements.
Les points de rupture appartiennent au contenu, pas à une marque de téléphone.
Styliser formulaires et états
Un formulaire doit rendre immédiatement visibles label, champ, aide, erreur et action principale. Les espacements et contrastes expliquent la structure avant même que l’utilisateur lise chaque mot.
Définissez des états hover, focus-visible, disabled, invalid et loading. Ne supprimez jamais le contour de focus sans alternative évidente, et ne représentez pas une erreur uniquement par la couleur.
Gardez les contrôles assez grands pour le tactile. Un bouton désactivé doit expliquer pourquoi lorsque la raison n’est pas évidente, et un envoi en cours doit empêcher les doubles soumissions.
Chaque état interactif doit rester visible, compréhensible et accessible.
Ajouter du JavaScript progressif
Le JavaScript améliore une expérience qui fonctionne déjà : confirmation avant suppression, aperçu d’image, compteur de caractères ou menu mobile. Le contenu essentiel et les formulaires doivent conserver un chemin fonctionnel sans script lorsque cela est raisonnable.
Chargez le script avec defer ou comme module afin de ne pas bloquer l’analyse HTML. Attachez le comportement à des attributs data explicites plutôt qu’à des classes destinées uniquement au style.
Un gestionnaire doit être petit, nettoyer ses effets et respecter clavier comme souris. Évitez de reconstruire un second framework dans chaque page; pour une interface entièrement réactive, AML View et Engine seront étudiés plus tard.
Le JavaScript améliore le document; il ne doit pas cacher les fondations du parcours.
document.addEventListener('click', (event) => {
const button = event.target.closest('[data-confirm-delete]');
if (!button) return;
const name = button.dataset.taskName ?? 'this task';
if (!window.confirm(`Delete "${name}"?`)) {
event.preventDefault();
}
});Confirmer une suppression correctement
Une suppression est difficile à annuler. Le bouton doit donc annoncer précisément la ressource concernée et ouvrir une confirmation avant l’envoi du formulaire DELETE.
La boîte native confirm() suffit pour une première protection. Une modale personnalisée exige davantage : déplacement du focus, fermeture avec Échap, retour du focus au déclencheur et libellés accessibles.
La confirmation côté navigateur ne remplace aucune sécurité serveur. Le contrôleur doit toujours vérifier CSRF, identité et autorisation, car un client peut contourner entièrement JavaScript.
L’interface prévient l’erreur humaine; le serveur impose la sécurité.
Choisir et optimiser les images
Une image doit avoir une fonction : expliquer, identifier ou renforcer la hiérarchie. Une décoration lourde qui ralentit la page sans ajouter de sens doit être supprimée.
Choisissez un format adapté : SVG pour les icônes vectorielles maîtrisées, PNG pour la transparence précise, WebP ou AVIF pour les photographies modernes. Redimensionnez les fichiers à une taille proche de leur affichage réel.
Ajoutez width et height pour réserver l’espace, loading=lazy pour les images hors écran et un texte alternatif qui décrit la fonction. Une image purement décorative utilise un alt vide afin de ne pas polluer la lecture vocale.
La meilleure image est utile, correctement dimensionnée et accessible.
Comprendre le cache navigateur
Le cache accélère le site en réutilisant app.css ou app.js. Mais si l’URL reste identique après une modification, certains visiteurs peuvent conserver une ancienne version et croire que le déploiement a échoué.
Le cache busting ajoute une empreinte ou une version au nom : app.a4f82.css. Lorsque le contenu change, l’URL change; les anciens fichiers peuvent rester longtemps en cache sans bloquer la mise à jour.
En développement, forcez une actualisation seulement pour diagnostiquer. En production, préférez des noms versionnés et des en-têtes cohérents plutôt que demander à chaque utilisateur de vider son cache.
Une ressource immuable peut être longtemps cachée si chaque changement produit une nouvelle URL.
<link rel="stylesheet" href="/css/app.a4f82.css">
<script src="/js/app.91be2.js" defer></script>Auditer performance et comportement
Une page visuellement réussie peut rester lente ou fragile. Inspectez les requêtes, tailles transférées, erreurs console, décalages de mise en page et scripts qui bloquent le rendu.
Testez clavier, tactile, zoom et préférences prefers-reduced-motion. Une animation doit aider à comprendre un changement, rester brève et pouvoir être réduite pour les utilisateurs sensibles au mouvement.
Vérifiez le site sur un réseau lent et avec le cache vide, puis avec le cache chaud. Mesurez avant d’optimiser afin de corriger les ressources qui coûtent réellement du temps.
La qualité front-end combine design, accessibilité, robustesse et performance mesurée.
Atelier guidé
Finalisez l’interface des tâches.
- Créez les variables et fondations CSS.
- Stylisez navigation, cartes, formulaires et états.
- Adaptez la page au mobile et à la tablette.
- Ajoutez une confirmation de suppression progressive.
- Optimisez logo, favicon et images de contenu.
- Ajoutez focus-visible et reduced-motion.
- Versionnez CSS et JavaScript pour le cache.
- Auditez réseau, console, clavier et écran mobile.
Correction raisonnée
Retirez tout ce qui n’aide pas le parcours.
Une bonne correction n’ajoute pas le maximum d’effets. Elle vérifie que la hiérarchie reste claire, que toutes les actions fonctionnent sans surprise, que le mobile ne déborde pas et que le poids des ressources correspond à leur utilité.
En résumé
Le front-end sert le contenu, les actions et les personnes.
Vous savez maintenant organiser les ressources publiques, construire un petit système CSS, adapter la page au mobile, ajouter du JavaScript progressif, protéger les suppressions et diagnostiquer le cache. Ces techniques restent utiles même lorsque vous passerez à AML View.
- gardez public limité aux ressources directement accessibles
- commencez par une structure et des états accessibles
- utilisez JavaScript comme amélioration progressive
- optimisez formats, dimensions et chargement des images
- versionnez les fichiers pour maîtriser le cache
Au chapitre 8, nous quitterons temporairement la présentation pour configurer SQLite et les migrations qui donneront une persistance durable à l’application.