Aller au contenu

Coulisses

Ce que nous nousimposons.

Un site vitrine ne prouve pas grand-chose sur celui qui l'a fait. Voici donc comment celui-ci est construit : les contrôles qu'il doit passer avant d'être mis en ligne, ce qu'ils mesurent, et ce qu'ils nous ont appris.

Garde-fous

Ce qui bloque un déploiement

Chaque modification passe par la même séquence avant d'atteindre le site. Elle tourne seule, en une dizaine de minutes, et l'échec d'une seule de ces étapes arrête la mise en ligne. Rien ne part parce que quelqu'un a jugé que c'était sans doute bon.

01

Dépendances vulnérables

Chaque bibliothèque externe est confrontée à la base publique des failles connues. Une alerte haute ou critique arrête tout, et la liste des exceptions tolérées est vide. C'est le contrôle qui protège les données de vos visiteurs, pas notre confort.

02

Types et code mort

Le compilateur vérifie que chaque valeur est bien ce que le code croit qu'elle est, ce qui supprime toute une famille de bugs avant qu'ils existent. Un second outil traque les fichiers, exports et bibliothèques que plus personne n'utilise : un site qui traîne du poids mort devient lent et difficile à faire évoluer.

Tests

Plusieurs centaines de vérifications sur la logique (validation des formulaires, filtrage du spam, limitation de débit), plus des parcours complets rejoués dans deux navigateurs, comme le ferait un visiteur. Si un lien, un formulaire ou une page cesse de fonctionner, le déploiement s'arrête avec.

04

Régression visuelle

Le premier écran de cinq pages est comparé au pixel près à une image de référence. C'est le seul filet qui attrape une page qui fonctionne encore mais s'affiche mal : un bloc décalé de 200 pixels, un dégradé disparu.

05

Performance et accessibilité

Huit pages sont auditées sur la vitesse de chargement, l'accessibilité, les bonnes pratiques et la lisibilité par les moteurs, avec un plancher par catégorie. Chaque dérogation est écrite, avec la mesure qui la justifie.

06

L'automatisation s'audite elle-même

Les scripts qui exécutent tout ce qui précède sont eux-mêmes analysés par deux outils, l'un pour la justesse, l'autre pour la sécurité. Une chaîne automatisée a accès au site : la laisser hors contrôle en ferait le maillon faible.

Relevé

Les chiffres

Aucun n'est saisi à la main. Un script relit les rapports d'audit, exécute les tests, compte ce qu'il trouve, puis écrit un relevé daté que cette page se contente d'afficher.

Mesuré le

La plus basse des huit pages, par catégorie

Performance
88
Accessibilité
100
Bonnes pratiques
Référencement
100

Nous affichons la note la plus basse, pas la moyenne. Une moyenne laisserait une page plus faible se cacher derrière les autres.

Page par page

URLPerformanceAccessibilitéRéférencement
/en9410096100
/fr9110096100
/fr/contact9310096100
/fr/coulisses9210096100
/fr/events9110096100
/fr/faq9210096100
/fr/image9210096100
/fr/journal9610096100
/fr/recrutement9310096100
/fr/social8810096100
/fr/web9310096100

Tests

tests unitaires, répartis dans 35 fichiers
467
parcours de bout en bout
151
comparaisons visuelles
dépendances en production
9

Neuf bibliothèques arrivent jusqu'à votre navigateur, et c'est un choix. Chaque dépendance est une surface d'attaque, un poids à télécharger et une migration future. Tout ce qui pouvait s'écrire en trente lignes a été écrit.

Journal de bord

Ce que les audits nous ont appris

Un outil d'audit donne un avis, pas un verdict. Voici quatre cas où l'outil avait tort, ou raison d'une façon que personne n'attendait. Chacun a changé quelque chose dans la fabrication de ce site.

  1. Une économie estimée n'est pas une mesure

    Un audit annonçait 13,8 Kio à gagner sur un bloc de compatibilité navigateur. Nous l'avons pesé : 630 octets une fois compressé, soit un facteur 22. Ces économies sont modélisées à partir d'un comptage d'octets converti en millisecondes par une formule, elles ne sont pas observées. Le bloc est resté.

  2. Un changement qui améliore la note et dégrade la page

    Découper la feuille de style par page améliorait l'indicateur de blocage du rendu. Mesuré sur la même machine, coup sur coup, il retardait à la fois le premier contenu visible et l'affichage de la plus grande image. Nous l'avons retiré en consignant les chiffres, pour que personne ne réessaie dans six mois.

  3. Un contrôle qui a cessé de contrôler

    Un outil de balayage retirait 10 pages sur 28 de son rapport quand il n'arrivait pas à les enregistrer, au lieu d'échouer. Rejouées seules, ces pages obtenaient 93 à 98 : l'outil se gênait lui-même. Un contrôle capable d'arrêter de vérifier sans le dire est pire que pas de contrôle, il est donc devenu un outil de diagnostic et jamais une barrière.

  4. Surveiller la page d'accueil ne surveille rien

    Les pages sont pré-générées et servies depuis un cache : elles continuent de répondre à l'identique même si le système de contenu est injoignable depuis trois semaines. La panne la plus probable de ce site, c'est un contenu qui se fige sans que rien ne tombe, et aucune surveillance ordinaire ne la verrait. D'où un point de contrôle dédié, qui interroge réellement le système de contenu.

Lecture honnête

Comment lire ces chiffres

Ils sont solides, et ils ont un périmètre. Dire où il s'arrête fait partie du travail.

  • Un score de performance se mesure sur une machine, à un instant, avec un réseau simulé. Il indique une tendance et attrape les régressions, ce qui est exactement ce qu'on lui demande.
  • Un audit automatique d'accessibilité détecte environ un tiers des problèmes réels. Les deux autres tiers demandent quelqu'un qui essaie la page au clavier et au lecteur d'écran, c'est une passe à part.
  • Le relevé porte la date à laquelle il a été pris. Le site a pu bouger depuis, et c'est pour ça que la date est affichée à côté des chiffres plutôt que masquée.
  • Rien de tout ça ne dit si le site est beau, ni s'il raconte la bonne histoire. Ça se décide ailleurs, et ça compte tout autant.

La même rigueur sur votre projet ?

C'est le métier du pôle Web. Dites-nous ce que vous avez à construire.

Parler de votre projet →