Fondations : lire le registre de vérification d'un build

Il y a trois semaines, j'ai construit un widget de réservation pour une amie qui gère un studio de yoga — une discussion, un plan que j'ai approuvé rapidement parce que j'étais en plein milieu d'autre chose, une exécution, puis une carte de version avec une coche verte que j'ai jetée un œil et laissée de côté. Mardi, elle m'a envoyé un message pour me demander si elle pouvait pointer le site d'un second studio vers la même construction. Avant de dire oui, je suis retourné voir ce que « vérifié » avait réellement signifié trois semaines plus tôt, et c'est là que j'ai vraiment lu l'un de ces rapports pour la première fois, au lieu de simplement faire confiance à la coche.

Il se trouve directement sur la carte de version, à côté de l'aperçu et des actions de code — au même endroit où l'on irait pour redéployer ou revenir en arrière. Première chose que j'ai remarquée : c'est propre à cette version précise, pas à toute la conversation. J'avais itéré sur cette construction cinq fois pour corriger un sélecteur de date cassé, et je m'attendais à moitié à ce que le rapport me raconte l'histoire de tous ces allers-retours. Ce n'est pas le cas. Le rapport de la version 4 ne décrit que la version 4. Il n'a aucune mémoire du fait que la version 2 a été livrée avec un formulaire de connexion qui échouait silencieusement, et il ne me dira pas que la version 5 a discrètement corrigé quelque chose que la version 3 avait cassé. Chaque rapport est un instantané, pas un diff ni un journal des modifications — si je veux l'historique de ce qui a changé d'une version à l'autre, c'est une vue entièrement différente. Celui-ci répond uniquement à « celle-ci est-elle correcte ».

En défilant vers le bas, le rapport se décompose en six lignes :

Les six étaient au vert, et mon premier réflexe a été le même réflexe erroné qu'a probablement la plupart des gens : la sécurité est passée, donc c'est sécurisé ; l'accessibilité est passée, donc c'est accessible. Aucune de ces lectures ne résiste à ce que les vérifications font réellement. La passe sécurité signifie que les problèmes de surface — une concaténation de chaînes dans une requête, une clé d'API exposée dans le bundle client, un eval sur une saisie utilisateur — n'ont pas été détectés. Ce n'est pas une journée avec un testeur d'intrusion. Le studio de mon amie n'accepte pas de paiements via ce widget, seulement des noms et des créneaux horaires, donc le plancher était suffisant pour elle. S'il s'était agi d'un parcours de paiement, j'aurais voulu davantage que ce plancher.

L'accessibilité est celle qui m'a vraiment fait m'arrêter pour vérifier quelque chose, parce que « passe axe » a l'air exhaustif et ne l'est pas. Axe — le moteur automatisé qui tourne en arrière-plan — détecte de façon fiable environ un tiers à la moitié des critères de réussite WCAG : texte alternatif manquant, mauvais ratios de contraste, champs de formulaire sans étiquette, mauvais usage évident d'ARIA. Il ne peut pas vous dire si le sélecteur de date personnalisé que j'avais demandé est utilisable avec un lecteur d'écran, si la navigation au clavier à travers le parcours de réservation en plusieurs étapes place le focus quelque part de sensé, ou si le statut « confirmé » vs « en attente » que j'avais coloré en vert et jaune pose problème à quelqu'un atteint de daltonisme rouge-vert. Cela nécessite qu'une personne parcoure la construction avec les outils que les utilisateurs handicapés utilisent réellement. Axe est un vrai signal, pas rien du tout — c'est le correcteur orthographique de l'accessibilité, pas l'éditeur.

La conformité est la ligne que j'ai failli sauter, parce qu'elle sonne bureaucratique — « contient ce que le plan promettait » — jusqu'à ce que je me rappelle que le plan que j'avais approuvé avait été rédigé pendant que j'étais distrait, et je ne me souvenais sincèrement plus si j'avais demandé des confirmations par e-mail ou juste par SMS. C'est la couche qui vérifie la construction par rapport au plan, pas par rapport à mon intention réelle, et elle est passée, ce qui m'a indiqué que la construction correspondait à ce à quoi j'avais dit oui, pas nécessairement à ce que je voulais dire. J'ai entendu parler de constructions qui étaient solides fonctionnellement et sécurisées et qui ont quand même échoué à cette couche parce qu'une fonctionnalité a été discrètement abandonnée sous la pression du temps. C'est la couche qui garde une construction honnête envers la conversation qui l'a produite, même quand cette conversation elle-même était un peu bâclée.

Sous les six lignes se trouvait une liste plus longue, divisée en deux catégories, et c'est là que j'ai passé le plus de temps. Les éléments « à corriger obligatoirement » ne sont pas des problèmes actuels de la construction — ce sont des reçus. Une ligne indiquait que la couche de revue avait signalé un cas où une chaîne de date était interpolée directement dans une requête, et qu'elle avait déjà été corrigée avant que cette version soit marquée comme terminée. Je ne regardais pas une blessure ouverte ; je regardais une cicatrice. Cette distinction compte, car si vous lisez un élément « à corriger » comme un avertissement en direct, vous perdrez du temps à vous inquiéter d'une chose déjà réglée.

La liste consultative était plus longue, et il s'agissait surtout de choses que j'aurais moi-même formulées si j'avais examiné le code d'un collègue sans vouloir bloquer la fusion : « envisager d'extraire le bloc répété de rendu des créneaux dans un composant partagé », « ce point d'accès n'a pas de limitation de débit, ce qui convient pour un outil de planification interne mais mérite d'être reconsidéré s'il devient public. » Rien dans cette liste n'était un défaut. C'étaient des jugements qu'un vérificateur a portés en n'ayant que le plan et le code sous les yeux, et pour un planificateur interne de studio de yoga, chacun de ces jugements était raisonnable. Si le studio de mon amie avait été une franchise avec le widget intégré sur cinquante pages de sites, j'aurais voulu contester celui sur la limitation de débit — cette classification dépend d'un contexte que le vérificateur ne peut que deviner, et quand une supposition vous semble erronée, la bonne réaction est de le dire dans le chat, pas de supposer que l'étiquette est définitive.

Ce qui m'a frappé, en regardant une liste consultative de taille conséquente à côté d'une colonne « à corriger » vide, c'est que j'aurais presque pris sa longueur pour une mauvaise nouvelle. Ce n'en est pas une. Une construction sans aucune note consultative a soit bénéficié d'une vérification restreinte, soit eu de la chance ; une construction avec une pile d'éléments « à envisager » et rien en attente dans la colonne « à corriger » est celle qui a réellement été examinée avec soin. La colonne consultative est censée être ce qu'il reste une fois les vrais problèmes résolus.

L'autre chose que je me suis forcé à faire, puisque ce rapport datait de trois semaines, a été de vérifier quelles couches s'étaient réellement exécutées avant de faire confiance aux verdicts. Les six étaient présentes ici, mais j'ai depuis vu une construction où l'accessibilité était simplement absente de la liste plutôt que marquée réussie ou échouée — ce n'est pas la même chose qu'être ignorée comme sans importance, c'est un signe que la vérification ne s'est pas exécutée pour ce type de site ou cette configuration de drapeaux, et lire une absence comme une réussite silencieuse est exactement l'erreur que ce format invite si l'on survole rapidement.

Rien de tout cela ne m'a dit si le parcours de réservation du studio de yoga convertissait réellement, si les gens l'abandonnaient à l'étape du choix du créneau, ou si l'idée même d'un widget personnalisé plutôt que d'un simple lien vers Calendly était le bon choix au départ. La vérification prouve qu'une construction fonctionne comme promis, pas que la promesse était la bonne à faire — ce sont des questions distinctes, et j'ai vu des constructions passer chaque couche sans encombre et pourtant échouer auprès des utilisateurs réels parce que « fonctionne correctement » et « résout le bon problème » se recoupent moins qu'on ne l'espérerait. La partie qui répond réellement à la seconde question est la boucle de mesure, et les deux sont censées être lues ensemble. Un rapport de vérification propre sur une fonctionnalité que personne n'utilise pour réserver reste une fonctionnalité que personne n'utilise pour réserver.