← Sommaire
TSRS 1 · Jour 5 · Vendredi
Cours · Jour 5

WebViews, Audit & Déploiement

Intégrer le web dans une application mobile, valider la conformité et industrialiser la mise en ligne.

C'est quoi une WebView ?

Une WebView est un navigateur « embarqué » à l'intérieur d'une application mobile native (.apk / .ipa) : pas de barre d'adresse, pas de boutons précédent/suivant. Beaucoup d'outils d'administration de terrain affichent en réalité une page HTML/CSS/JS dans une WebView.

Conséquences pour ton interface :

  • Pas de bouton retour → la navigation doit être intégrée à la page.
  • Encoche et barre de statut → prévoir les « Safe Areas » pour ne rien masquer.
  • Pas de survol (hover) → tout doit rester lisible au doigt, avec des états clairs.

Les 3 réglages CSS « application native »

1. Bloquer la sélection de texte parasite

Sur mobile, un appui long sélectionne le texte des boutons/menus — inutile et gênant dans une app.

.menu, .btn {
  user-select: none;
}

2. Supprimer le délai de double-tap

Les navigateurs mobiles attendent ~300 ms après un tap pour voir si c'est un double-tap (zoom). Dans une app, ça donne une sensation de lenteur.

body {
  touch-action: manipulation;
}

3. Gérer les Safe Areas (encoches)

Les fonctions env(safe-area-inset-*) donnent la taille des zones masquées par l'encoche ou la barre du téléphone. On les ajoute au padding pour que rien ne soit recouvert.

/* nécessite viewport-fit=cover dans la balise viewport */
.header {
  padding-top: calc(1rem + env(safe-area-inset-top));
}
À ne pas oublier Les Safe Areas ne s'activent que si la balise viewport contient viewport-fit=cover.

Accessibilité SecOps (WCAG / ARIA)

Le piège de la couleur seule

Un ingénieur daltonien ne distingue pas forcément un voyant rouge d'un vert. Règle d'or : double codage — chaque statut combine couleur + icône + texte explicite (« ✖ CRITIQUE », « ✔ UP »).

Les attributs ARIA

role="alert" (ou role="status") sur le bloc des alertes force les lecteurs d'écran à annoncer immédiatement tout nouvel événement injecté dans la page.

<div class="alerts" role="alert" aria-live="assertive">
  ...
</div>

Le contraste

Ratio minimal de 4.5:1 entre le texte et son fond (norme WCAG AA). Vérifiable dans l'inspecteur F12 (au survol d'une couleur).

La recette technique (audit final)

CritèrePoint de contrôle
FluiditéAucun défilement horizontal, à toutes les résolutions.
Zones de contactÉléments cliquables ≥ 44px de hauteur.
PerformancePoids total de la page < 1,5 Mo.
ContrasteRatio ≥ 4.5:1 pour le texte.

Lighthouse et le debug à distance

  • Lighthouse (onglet dans F12) mesure le LCP (vitesse d'affichage) et le CLS (stabilité de la mise en page au chargement).
  • Android : câble USB + débogage USB + chrome://inspect sur le PC pour inspecter le vrai téléphone.
  • iOS : Inspecteur Web dans les réglages Safari + menu Développement de Safari sur macOS.

Industrialisation : Git et le déploiement continu

Le flux de travail moderne pour mettre en production :

  1. Développement local (VS Code, ta VM).
  2. Versionnement : git add . → git commit -m "message" → git push vers GitHub.
  3. Déploiement continu : GitHub Pages (ou Netlify) publie automatiquement le site à chaque push validé.
Dans ton cas Ton VPS joue déjà le rôle d'hébergement. GitHub Pages est l'alternative « zéro serveur » : le dépôt Git devient lui-même le site.

Checklist avant de rendre

  • user-select: none sur menus et boutons.
  • touch-action: manipulation sur le body.
  • Safe Areas gérées via env(safe-area-inset-*) + viewport-fit=cover.
  • role="alert" sur le bloc des alertes critiques.
  • Statuts en double codage : texte + icône + couleur.
  • Aucun scroll horizontal, cibles ≥ 44px, contraste ≥ 4.5:1.
  • Code propre, prêt à être poussé sur GitHub.