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 , soit il y a 12 jours

La plus basse des huit pages, par catégorie

Performance
89
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
/en9110096100
/fr9110096100
/fr/contact9410096100
/fr/coulisses9310096100
/fr/events9110096100
/fr/faq9210096100
/fr/image9210096100
/fr/journal9310096100
/fr/recrutement9410096100
/fr/social8910096100
/fr/web9410096100

Tests

tests unitaires, répartis dans 37 fichiers
481
parcours de bout en bout
167
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.

Journal des passes

Ce qui a changé, et quand

Les grandes passes seulement, pas chaque modification. La plus récente est en haut, avec son âge : une page qui parle de rigueur doit dire quand elle a été touchée pour la dernière fois.

Dernière passe , soit il y a 13 jours

  1. Le vocabulaire, et le journal en anglais

    Une passe sur le contenu plutôt que sur la machinerie.

    • Un glossaire de 78 termes du métier, avec ce que chaque mot ne veut pas dire.
    • Les neuf articles du journal traduits et publiés en anglais.
    • Chaque étude de cas ramène désormais vers les pôles qu'elle démontre.
    • Deux tests qui verrouillaient l'absence d'articles anglais ont été retournés, pas supprimés.
  2. Ce qui était fait atteint enfin le visiteur

    Aucune de ces choses n'était à faire : elles étaient faites, et personne ne pouvait les voir.

    • Sous-titres publiés sur les quatre réalisations, dernier manquement WCAG de niveau A du site.
    • Transcription dépliable sous chaque vidéo, rendue côté serveur, donc lisible par un moteur.
    • Deux études de cas publiées, et la rubrique enfin annoncée dans la navigation.
    • Cinquante et un commits déployés d'un coup.
  3. Audit complet, et sa première moitié

    Vingt-sept constats, dont quatre critiques, qui disaient tous la même chose.

    • Le journal rendu atteignable : il existait, et aucun lien du site n'y menait.
    • Un fil d'Ariane visible sur les pages profondes, et complet dans le balisage.
    • Le contrôle anti-robot des formulaires différé au premier geste du visiteur.
    • Des budgets de performance par profil de page, et un framework qui ne s'annonce plus dans les en-têtes.
  4. La chaîne de contrôle prend sa forme actuelle

    C'est la passe qui a produit la plupart des garde-fous décrits plus haut.

    • Les données structurées validées en intégration continue, l'équivalent du test de résultats enrichis.
    • WCAG 2.2 verrouillé, dont la taille minimale des cibles tactiles.
    • Régression visuelle sur cinq pages, comparées au pixel près.
    • Les scripts d'automatisation eux-mêmes analysés, pour la justesse et pour la sécurité.
    • Un découpage de la feuille de style retiré après mesure : il améliorait la note et dégradait la page.
  5. Les fondations

    La première passe, celle qui a posé ce que cette page décrit.

    • Le Studio de contenu sorti de l'application publique : trente-trois vulnérabilités ramenées à cinq.
    • Les pages de contenu passées en rendu statique, servies depuis un cache.
    • Un audit d'accessibilité automatisé à chaque déploiement.
    • Un outil qui traque le code mort, et les premiers fichiers réellement supprimés.

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