Pipeline de briefing zero-trust, tenu à un budget de performance mesuré

1. 01

   Frontière de confiance : rien venant du navigateur n’est cru. L’origine, la taille du corps, le schéma, le pot de miel et le temps de remplissage, un contrôle anti-robot et un assainisseur s’exécutent sur le serveur, dans cet ordre. Une requête qui échoue à l’un d’eux est refusée, jamais réparée.

2. 02

   Minimisation des données : pas de cookies, pas d’analytique, rien de stocké dans le navigateur. Le seul tiers est un contrôle anti-robot, chargé à la dernière étape du formulaire et seulement là où la livraison est branchée.

3. 03

   Cadence d’images : le rythme propre de l’écran est conservé pendant le défilement. Dans le défilement échantillonné, l’intervalle entre images est de 16,7 ms à la médiane et de 16,9 ms au 99e centile sur un écran à 60 Hz, une image par rafraîchissement.

1. 01

   Pipeline de livraison : navigateur, contrôle d’origine et limite de débit, validation du schéma, contrôle anti-robot, assainisseur et classe de priorité, puis livraison par webhook signé (HMAC-SHA256, idempotent) ou par SMTP sur TLS vers la boîte du studio. Chaque étape peut refuser ; un refus termine la requête et propose au visiteur un brouillon d’e-mail. Le système se ferme en cas de panne.

2. 02

   Rendu : pages rendues côté serveur sous une Content-Security-Policy appliquée, avec un nonce par requête. Le framework démarre après le premier rendu de contenu, derrière un seul script de chargement, si bien que le premier rendu ne l’attend pas. Les sections sous la ligne de flottaison sont dessinées à la demande selon une hauteur de substitution mesurée.

3. 03

   Cryptographie à découvert : un simulateur de sécurité sur la page signe et scelle un message dans le navigateur du visiteur avec Web Crypto (HMAC-SHA256, AES-256-GCM), avec les mêmes fonctions et les mêmes tests que l’architecture de référence.

1. 01

   Avant chaque version, un audit de conception de plus de deux cents contrôles et un test de fumée HTTP de plus de cent quatre-vingts s’exécutent sur un build de production, suivis d’un parcours en navigateur réel sur deux fenêtres ; un contrôle en ligne tourne après la mise en production.

2. 02

   L’accessibilité est analysée avec axe sur les pages, les langues et les fenêtres (aucune violation). La Content-Security-Policy est exercée dans un navigateur réel sur le site en ligne (aucune violation, aucune erreur de console). La carte de partage est dessinée et comparée dans chaque langue dans laquelle le site est publié.

3. 03

   Le mouvement de la mise en page est testé tel qu’il se produit : hauteurs de substitution à moins de 15 % de la hauteur dessinée, et choisir un niveau de budget ne déplace rien. La mesure de décalage de mise en page du navigateur ignore les décalages survenant dans les 500 ms suivant un clic ; le test compare donc les positions et les hauteurs.

La livraison est vérifiée de bout en bout face à un récepteur SMTP local avec un vrai jeton de contrôle anti-robot. Aucune affirmation n’est faite sur l’acceptation par un fournisseur de messagerie particulier.