Le Steve Test : le travail mérite-t-il d’exister ?

Plus tôt cette semaine, j’ai livré un travail pour lequel le bon geste était précisément de refuser la livraison. Une chaîne de traduction écrit le contenu de ce site dans Cloudflare D1 pour dix versions locales. Trois tâches de traduction ont atteint une limite de requêtes au même moment ; le mécanisme de repli a silencieusement écrit la source anglaise dans D1 comme « traduction » pour six de ces versions locales, puis a mis à jour les hachages des points de reprise pour qu’ils correspondent au contenu anglais. Sur le disque, tout ressemblait à un succès. La chaîne annonçait « terminé ». L’indicateur disait que dix versions locales avaient été publiées. Tous les contrôles automatisés passaient.

Un lecteur allemand arrivant sur /de/guides/claude-code aurait trouvé un paragraphe en allemand, un paragraphe en anglais, un autre paragraphe en allemand, puis un titre de section en anglais. Rien n’expliquait ces bascules. La page semblait intentionnelle et rendait tout le site suspect : le genre de produit qui échouerait probablement aussi dans tout le reste. Le Jiro Test (le travail est-il correct ?) passait à tous les niveaux que j’avais instrumentés. Pourtant, la chose n’était pas digne d’être livrée. Elle avait l’apparence d’un produit et le comportement d’une insulte.

La bonne réponse était d’arrêter, d’auditer chaque lot ayant basculé vers l’anglais, de nettoyer chirurgicalement les hachages des points de reprise, de relancer la chaîne de traduction une tâche à la fois, de vérifier version locale par version locale, puis de valider et pousser les changements. Environ six heures de temps réel de traduction, plus un correctif de garde-fou pour éviter que cela se reproduise. L’artefact sur disque « fonctionnait » tout du long. L’artefact en production était un dommage que j’avais causé.

La forme de l’échec reste la même, que l’artefact soit une chaîne de traduction, un parcours d’inscription, une bascule de fonctionnalité, un export CSV ou une page marketing. Tous les contrôles automatisés passent. Ce qui arrive devant un vrai utilisateur cause des dégâts.

La question directrice du produit n’est pas Est-ce terminé ? ni Est-ce que cela fonctionne ? La question directrice est Le travail mérite-t-il d’exister ? Chaque artefact doit y répondre avant d’être livré, en parallèle d’un test distinct de correction. La correction sans mérite produit du stock : des choses qui fonctionnent, qui sont livrées, et qui ne gagnent pas la confiance. Le mérite sans correction produit de la mise en scène : des choses qui sonnent juste et cassent. Les deux tests doivent passer.

Mon raccourci est le Steve Test. Il se tient à côté du Jiro Test, qui porte sur la rigueur et la preuve. Ce sont deux questions différentes appliquées par le même esprit, et je ne livre pas un travail qui échoue à l’une ou à l’autre.

En bref

Le Steve Test est le second test que tout artefact doit passer. Jiro demande si le travail est correct ; Steve demande si le travail mérite d’exister dans l’ensemble que vous construisez. Ce test est concret, pas abstrait. Il mesure le travail face à un utilisateur réel, dans un moment réel, et son résultat le plus fréquent est le refus. Je réduis le périmètre. Je supprime des fonctionnalités. Ce qui reste doit pouvoir porter mon nom. Les deux tests doivent passer. Si Jiro échoue, vous arrêtez et vous corrigez. Si Steve échoue, vous reconstruisez. Trois refontes honnêtes sont la limite ; ensuite, le problème se trouve en amont, dans le cadrage.

Pourquoi « Est-ce terminé ? » est la mauvaise question

La plupart des équipes produit optimisent pour ce qui peut être livré. Les sorties mesurables sont les validations, les déploiements, les graphiques de vélocité, la présence de quelque chose en production. Le mode d’échec est prévisible : les équipes produisent un flux régulier d’artefacts qui fonctionnent correctement tout en consommant discrètement la confiance des utilisateurs. Le parcours d’accueil se termine, mais la deuxième session n’arrive jamais. Les tickets d’assistance se concentrent autour de tâches que le produit prétend gérer. La courbe d’attrition descend vers zéro au lieu de se stabiliser autour d’un noyau.

Terminé et digne d’exister sont deux mesures différentes. Une fonctionnalité peut être terminée et ne pas mériter d’exister. Une page peut s’afficher et insulter le lecteur. Une traduction peut être techniquement présente et, dans les faits, constituer un mensonge. Le test qui dit si une chose est terminée demande si elle exécute le comportement spécifié. Le test qui dit si elle est digne demande si un utilisateur réel, à un moment réel, se porte mieux parce que vous l’avez livrée.

Dans Produit minimum digne d’exister, j’avance que la culture MVP a, en pratique, fusionné deux questions qui auraient dû rester séparées : apprendre vite s’est dégradé en livrer vite, et la livraison est devenue la métrique qui comptait.⁷ Le remède est une double exigence. Minimum réduit le périmètre. Digne maintient la surface restante à un niveau que l’utilisateur peut ressentir. Le Steve Test est l’outil à utiliser pour décider si cette surface restante a franchi le seuil.

La question directrice

Le travail mérite-t-il d’exister ?

J’emploie la question littéralement. Quand je termine un travail et que je dois décider s’il part en production, je la pose à voix haute. La réponse est un verdict, pas une impression. Si la réponse est oui, le travail devient éligible à la livraison, et la question suivante est de savoir s’il passe aussi le Jiro Test de correction. Si la réponse est non, il faut le reconstruire ou le supprimer. Si la réponse est pas encore, mais il le sera après une correction définie, continuez à travailler.

La question ne fonctionne que si la réponse peut être non. Un Steve Test qui tamponne tout ce qu’on lui présente n’est pas un test. Le signe que le test tourne vraiment, c’est que certains travaux y échouent.

Le pôle utilisateur : le mérite n’est jamais abstrait

Le Steve Test échoue dès qu’il devient une discussion de goût sur le travail pris isolément. Mesurez le mérite face à un utilisateur précis, à un moment précis. Formulée correctement, la question devient : Le travail mérite-t-il d’exister pour cet utilisateur, à ce moment-là ?

Pour blakecrosley.com, l’utilisateur est un lecteur qui arrive sans contexte depuis un moteur de recherche avec une question sans réponse sur Claude Code, Codex ou l’infrastructure. Le moment, ce sont les cinq premières secondes après le chargement de la page, avant qu’elle ait gagné la moindre confiance. Une page qui charge vite, présente clairement son point de vue et dit au lecteur quelque chose que sa recherche ne lui avait pas déjà donné a franchi le seuil. Une page qui lui impose un paquet JavaScript lent, une bannière de cookies impossible à fermer et un mur de texte générique calibré pour le SEO échoue, quel que soit son score sur l’axe Jiro.

Pour ResumeGeni, l’utilisateur est une personne en recherche d’emploi dans un moment que je considère comme vulnérable. La plupart des premières inscriptions en liste d’attente sont arrivées après un licenciement ou au milieu d’un cycle d’entretiens d’embauche.⁶ La version digne refuse de traiter ces personnes comme une métrique de conversion. Le texte ne se réfugie pas dans des formulations évasives. L’analyseur ne ment pas sur ce qu’il a trouvé. Les conseils sont assez concrets pour être appliqués. Le parcours ne les abandonne pas en plein milieu parce que je n’aurais livré que le parcours nominal.

Le pôle utilisateur empêche le Steve Test de devenir un prétexte à mes préférences personnelles. Si je ne peux pas nommer l’utilisateur, nommer son moment et expliquer comment la surface livrée le respecte et le renforce, je n’ai pas appliqué le test. Je l’ai seulement affirmé.

Le double test : Jiro plus Steve

La doctrine complète exige deux tests, pas un seul.¹ Je ne livre rien qui échoue à l’un des deux.

Le Jiro Test demande : Est-ce fabriqué correctement ? Il exige des preuves. Les cas limites sont traités. Les détails invisibles sont terminés. Les affirmations citent une preuve concrète. Pas d’esquive : je crois n’est pas une preuve. Les tests passent. Pas de régressions. Le seuil de preuve est la version du Jiro Test que j’applique aux rapports de code et aux sorties d’agents, et la philosophie qualité de Jiro en est l’exposé plus profond.

Le Steve Test demande : Le travail mérite-t-il d’exister ? Il exige du mérite. De la cohérence avec l’ensemble. Un point de vue visible. Un refus ou une suppression nommée qui a gardé la surface propre. Un mécanisme de clarté ou de plaisir que le lecteur peut identifier, pas une vague promesse. Une aptitude à porter votre nom.

L’arbitrage est simple. Si Jiro échoue, arrêtez et corrigez. Un travail incorrect ne part pas en production ; le veto de Jiro est absolu. Si Jiro passe et que Steve échoue, reconstruisez. Un travail correct mais indigne ne part pas non plus. Si les deux échouent, le problème est en amont, dans la consigne, le cadrage ou le périmètre. Seul un travail qui passe les deux tests devient éligible à la livraison.

La plupart des cultures de livraison n’en exécutent discrètement qu’un seul. Les cultures pilotées par l’ingénierie ont souvent un Jiro fort et un Steve faible : le produit part quand les tests passent, et le mérite devient l’affaire d’un autre service. Les cultures pilotées par le design ont parfois un Steve fort et un Jiro faible : le produit part quand il a l’air juste, et la correction devient un problème opérationnel. Les deux modes d’échec produisent des artefacts reconnaissables. De belles impostures. Du travail correct mais sans âme. Vous les avez vus. Vous en avez peut-être livré.

Les deux tests se tiennent côte à côte :

Le produit tout entier : vous êtes responsable de l’expérience totale

Le Steve Test ne juge pas les artefacts isolément. Il les juge comme une partie de l’expérience totale que l’utilisateur rencontre.

L’incident de traduction par lequel j’ai commencé en est l’exemple récent le plus net, et son mécanisme précis mérite d’être détaillé parce qu’il révèle la forme du piège. Le mécanisme de repli de la chaîne a écrit la source anglaise dans D1 lorsque le sous-processus Claude a atteint une limite de requêtes. Le module d’écriture D1 a accepté ces octets parce que c’étaient des octets. Le système de mise à jour des points de reprise a haché le contenu stocké et écrit cette empreinte sur le disque. Comme la « traduction » stockée était identique à la source anglaise, les empreintes correspondaient exactement : des octets identiques produisaient des empreintes identiques. Au passage --update suivant, la chaîne a comparé l’empreinte de la source anglaise à l’empreinte stockée, les a trouvées égales et a marqué le lot comme inchangé. Chaque composant passait son propre Jiro Test isolément. Le défaut vivait dans la composition. Pendant des heures, un utilisateur a vu six versions locales avec une prose mêlant deux langues avant qu’un humain ouvre l’une des pages.

« Nous sommes responsables de toute l’expérience » est la règle. Comportement produit, parcours UX, langage, vérité des données, systèmes de support, conditionnement, exactitude de la documentation, prompts, règles, mémoire, compétences, hooks, scripts, orchestration, structure des sorties. Tout cela, pas seulement l’artefact livré le plus récemment. Aucune victoire locale n’est acceptable si elle dégrade l’intégrité de l’ensemble. Le Steve Test s’active quand une surface passe localement et que l’expérience utilisateur totale ne passe pas.

Suppression : une couche Steve qui ne fait qu’ajouter est fausse

Le résultat le plus utile du Steve Test est une suppression.

Une revue qui se termine sans rien retirer n’a pas réellement eu lieu. Poser Le travail mérite-t-il d’exister ? face à une surface réellement complexe produit presque toujours au moins un morceau de périmètre, de texte, de fonctionnalité ou d’interface incapable de justifier sa présence. Une revue qui n’en trouve aucun est souvent une revue jouée comme une revue, pas pratiquée comme telle.

Concrètement, voici ce que le Steve Test cherche :

• Des surfaces présentes parce qu’il semblait prudent de les inclure, pas parce qu’elles méritent leur place.
• Du texte qui se couvre parce que supprimer la réserve obligerait à formuler une vraie affirmation.
• Des fonctionnalités héritées d’une version précédente qui ne servent plus la promesse actuelle.
• Des éléments d’interface ajoutés pour gérer des cas limites qui n’existent pas au périmètre actuel.
• Des options de configuration qui délèguent une décision que le créateur aurait dû prendre.
• De la documentation qui décrit un comportement que le produit n’a plus.
• Des tests qui couvrent du code qui devrait être supprimé.

La suppression est l’acte qui distingue le goût de l’accumulation. La surface digne est plus petite que la version que vous auriez livrée si personne n’avait posé la question. Je n’ai jamais regretté d’avoir retiré quelque chose d’un produit livré. J’ai régulièrement regretté ce que j’avais laissé.

Le refus comme acte premier

Lié à la suppression, et plus fort encore : le Steve Test intervient souvent avant toute construction, pas après. L’acte premier du goût est le refus : la décision de ne pas fabriquer la chose.

La phrase de Steve Jobs qui compte ici est : « Je suis aussi fier de ce que nous ne faisons pas que de ce que nous faisons », rapportée dans un article de couverture de BusinessWeek en 2006 sur la discipline produit d’Apple.⁵ Elle est souvent citée parce qu’elle est vraie d’une manière techniquement précise. Tout produit livré est entouré d’un halo invisible de produits que vous avez refusé de livrer. Ce halo est le véritable point de vue. C’est la preuve qu’un humain a pris la décision, plutôt que le carnet produit.

Pour blakecrosley.com, la pile technique est le registre de ce que j’ai élagué. J’ai envisagé React et je l’ai refusé. J’ai envisagé Tailwind et je l’ai refusé. Un outil de regroupement est resté sur la table pendant les deux premières semaines de la reconstruction avant que je le retire. L’absence de node_modules/ dans tout le dépôt n’est pas un choix de design ; c’est un refus que je maintiens dans le temps face à l’attraction gravitationnelle des outils par défaut. Ces refus façonnent davantage le travail que n’importe quelle inclusion. Ils définissent ce que j’étais prêt à tenir comme standard.

Pour ResumeGeni, la validation était nette. Trois cent quarante inscriptions par e-mail, douze demandes directes, trois offres spontanées de payer pour un accès anticipé.⁶ Le carnet produit révélé par cette demande était vaste : modèles, collaboration en équipe, tableaux de bord analytiques, intégration LinkedIn, intégration Indeed, historique de versions, plusieurs formats d’export, application mobile. J’ai tout refusé dans la première version livrée. Ce que je ne pouvais pas refuser : une analyse exacte, une évaluation honnête des écarts, des réécritures concrètes adaptées à la fiche de poste, un export qui s’ouvre proprement dans Word, un parcours qui donne à un utilisateur vulnérable le sentiment d’être en sécurité. Les choses refusées ne disparaissent pas pour toujours. Elles attendent de l’autre côté d’une première surface digne.

Une surface qui ne refuse rien est une surface sans point de vue. Si l’équipe n’a rien refusé, le périmètre est mauvais.

Débusquez le faux succès tôt, en commençant par vous-même

Le refus et la suppression ne fonctionnent que si le test peut nommer le faux succès dès qu’il apparaît. Le Steve Test doit dénoncer l’imposture, et le faire vite, face à :

• De faux progrès. Du mouvement qui ressemble à du progrès sans produire d’objet.
• Des preuves contaminées. Un test qui passe pour la mauvaise raison ; des statistiques qui prouvent ce que vous vouliez prouver plutôt que ce qui était vrai.
• Des comptes de vanité. Nombre de validations, nombre d’artefacts livrés, graphiques de vélocité : tout est là, tout est hors sujet.
• Des systèmes incohérents qui se livrent proprement isolément et se dégradent mutuellement une fois combinés. L’incident de traduction ci-dessus en fait partie.
• Des rapports « tout est sur les rails » qui masquent une décision que personne n’a prise. Le Steve Test en est l’ennemi.
• De l’activité automatisée à faible valeur. Du travail qu’un ordinateur fait parce qu’il le peut, pas parce que le résultat mérite sa place.

La version la plus difficile et la plus utile de la règle est celle-ci : dénoncez d’abord l’imposture dans votre propre production. L’incident de traduction au début de cet essai en est exactement l’exemple. La chaîne annonçait le succès. Les journaux étaient propres. Toutes les métriques que j’avais instrumentées passaient. Le travail était une imposture, et je devais le reconnaître moi-même avant que les utilisateurs ne le fassent. Traquer l’imposture dans son propre travail, voilà la discipline qui garde le test honnête. La politesse ne protège pas de la vérité ; l’activité ne remplace pas la valeur.

Gradient des surfaces : calibrer le seuil de validation

Le Steve Test n’est pas une validation unique avec un seuil unique. Plus une surface est difficile à reprendre, plus le seuil doit être exigeant.²

La question reste la même. L’exigence de la réponse varie avec le rayon d’impact. Vous pouvez corriger une réponse de chat au tour suivant ; personne n’en meurt. Un déploiement en production qui échoue au Steve Test brûle une confiance utilisateur qui a mis des mois à se construire, et la correction coûte plus cher que ce que la décision initiale de livrer a économisé.

La conséquence pratique est que la cadence de livraison devrait ralentir à mesure que les surfaces deviennent plus difficiles à reprendre, pas accélérer. Les équipes qui livrent à vitesse uniforme sur des surfaces de réversibilité très différente signalent qu’elles ne pensent pas que le test varie. En général, elles ont cessé de l’exécuter.

Le goût n’est pas le tempérament

Le Steve Test exige une dernière distinction, parce que c’est celle qui se perd le plus souvent. Invoquer Steve, c’est invoquer son goût, pas son tempérament.

La doctrine interdit explicitement ce qui suit :³

• La cruauté.
• L’humiliation.
• Le mépris théâtral.
• La posture de visionnaire.
• L’agressivité comme substitut au jugement.
• La rancune mise en scène.
• Le drame confondu avec des exigences.

Le signal que la couche Steve opère vraiment est un refus calme. « Non, le travail n’est pas encore digne », formulé comme un verdict et suivi de l’action corrective précise. Pas une performance. Pas l’humiliation de la personne qui a construit la version indigne, souvent vous-même. Pas du mépris visible pour l’équipe. Pas l’annonce publique de standards plus élevés. Le travail franchit le seuil ou il ne le franchit pas. Le seuil n’est pas l’esthétique de la sévérité.

La distinction compte parce que la caricature de Steve Jobs se concentre sur le tempérament. Toute personne ayant été dirigée par quelqu’un qui jouait à Steve voit très bien de quoi je parle. La cruauté n’améliore pas le travail. Elle détériore le lieu de travail et, parce qu’elle remplace le jugement par de la mise en scène, elle détériore aussi le travail livré.

Le test opératoire pour savoir si vous êtes dans la couche de goût de Steve ou dans l’imitation de son tempérament est simple : le résultat du test est-il une action technique précise ? « Le travail ne mérite pas d’exister » n’est pas une conclusion ; c’est l’ouverture d’une question. La réponse doit nommer l’axe qui a échoué, l’action corrective et le prochain test. Si la revue s’arrête à « le travail est mauvais » sans nommer ce qui le rendrait digne, la revue était une performance.

La limite des refontes et la clause anti-paralysie

Un standard élevé sans règle d’arrêt devient de l’évitement. La discipline que j’applique à tout travail non trivial fixe une limite de trois refontes honnêtes.

Une tentative honnête signifie que vous avez identifié l’axe en échec, nommé l’action corrective précise, modifié substantiellement l’approche et réévalué le travail face aux deux tests. Trois répétitions de la même passe de polissage ne comptent pas comme trois tentatives. Elles comptent comme une tentative ratée répétée trois fois.

Après trois refontes honnêtes qui ne produisent pas de travail digne, le problème n’est presque jamais dans l’exécution. Il se trouve en amont, dans le cadrage, le périmètre, la consigne initiale ou la composition de l’équipe. Arrêtez de reconstruire la surface et regardez la prémisse. Parfois, la promesse était trop grande pour le périmètre que vous pouvez réellement tenir au standard. Parfois, la validation était moins solide que vous ne le pensiez. Parfois, le problème n’est pas un problème de produit du tout.

La limite des refontes résout deux modes d’échec opposés à la fois. Elle refuse de bénir un travail faible, et elle empêche le raffinement de devenir une cachette. Refuser de livrer n’est pas vertueux en soi. Reconstruire sans fin à la poursuite de la perfection est son propre mode d’échec : de l’artisanat sans courage. La cible n’est pas la perfection. La cible est un travail digne et livré. Pas un travail pur et en attente pour toujours.

Si vous en êtes à la quatrième refonte de la même surface, vous avez cessé de construire un produit et commencé à utiliser le projet comme un endroit où vous cacher.

Signes observables : le test a-t-il vraiment tourné ?

Le Steve Test est facile à revendiquer et difficile à exécuter réellement. La discipline consiste à dire concrètement ce que le test a produit.

Avant de déclarer un travail non trivial terminé, je m’assure de pouvoir répondre à tout ce qui suit :⁴

1. Qui est l’utilisateur ? Pas un archétype de persona. Une vraie personne dans une vraie situation.
2. Quel point de vue cette surface porte-t-elle ? Si vous ne pouvez pas en nommer un, il n’y a pas de point de vue, seulement un carnet produit.
3. Qu’avez-vous refusé ou retiré pour garder cette surface propre ? La suppression est la preuve que le test a tourné.
4. Comment cela sert-il le produit tout entier ? La pièce doit être cohérente avec toutes les autres. Les victoires locales qui dégradent l’ensemble ne sont pas des victoires.
5. Quelle preuve montre que c’est solide ? L’axe Jiro. La vérification a été exécutée ; l’affirmation est soutenue.
6. Pourquoi est-ce digne ? Réponse claire. Si elle est vague, le test n’a pas tourné.
7. Est-ce que je signerais cela de mon nom sans hésiter ? L’oracle du goût. Quand le jugement est incertain, c’est la question directrice du système.

Si je ne peux pas répondre aux sept questions avec des éléments précis, j’ai affirmé la doctrine au lieu de l’appliquer. Je renvoie le travail.

Exemple concret : les sept signes face à une vraie surface

Voici les signes appliqués à une surface précise livrée après l’incident de traduction : un garde-fou de concurrence que j’ai écrit dans la chaîne de traduction. Environ 100 lignes de Python qui refusent de lancer guide_bootstrap.py ou blog_translate_batch.py si un autre processus de traduction tourne déjà.

1. Qui est l’utilisateur ? Moi au début d’une passe de traduction dans deux semaines, quand j’aurai oublié le mode exact d’échec par limite de requêtes qui a brûlé six versions locales. Aussi tout agent qui invoquera l’un ou l’autre script dans une future session.
2. Quel point de vue la surface porte-t-elle ? Les traductions concurrentes ne sont jamais le bon outil. Le garde-fou encode ce verdict dans le code afin que le prochain appelant n’ait pas à s’en souvenir.
3. Qu’ai-je refusé ou retiré pour garder cette surface propre ? J’ai refusé d’en faire un simple avertissement. J’ai refusé de lui donner une option de contournement courte et pratique comme --force. Le seul contournement est une variable d’environnement, I18N_ALLOW_CONCURRENT=1, assez longue pour que personne ne la tape par accident.
4. Comment cela sert-il le produit tout entier ? La chaîne de traduction, le module d’écriture D1 et le mécanisme de repli sont individuellement corrects. Le garde-fou est la pièce qui les empêche de se combiner en un ensemble qui corrompt silencieusement.
5. Quelle preuve montre que c’est solide ? J’ai vérifié le garde-fou avec deux contrôles manuels. Un : retour propre quand aucune autre tâche de traduction ne tourne. Deux : sortie non nulle lorsqu’un vrai sous-processus guide_bootstrap.py est vivant. Les deux contrôles ont tourné contre les scripts réels, pas contre des doublures de test.
6. Pourquoi est-ce digne ? La même condition de concurrence qui a corrompu six versions locales ne peut pas produire de lignes D1 mêlant plusieurs langues tant que le garde-fou est en place. Ce n’est pas une prévention de tous les cas ; c’est une prévention du mode d’échec précis que la doctrine vient d’apprendre.
7. Est-ce que je signerais cela de mon nom ? Oui. Une seule tâche, une sémantique de contournement propre, documentée dans une note de mémoire afin qu’une future session hérite de la raison d’être du garde-fou.

L’intérêt de l’exemple est que chaque signe reçoit une réponse précise. Quand je ne peux pas en produire une, le test n’a pas encore tourné.

Comparez avec ce que donne l’échec. Quand j’ai rédigé le garde-fou de concurrence, ma première tentative pour le signe 3 était : « J’ai refusé de le surconcevoir. » C’est le genre de phrase qui sonne bien et ne dit rien. Refuser de surconcevoir ne nomme aucune chose précise que j’aurais envisagée puis rejetée. C’est une posture, pas un refus. Je me suis forcé à écrire la vraie réponse : j’ai refusé d’en faire un avertissement ; j’ai refusé un nom d’option de contournement pratique ; j’ai refusé un comportement où le garde-fou se serait ouvert par défaut s’il ne pouvait pas lister les processus. Ce sont des décisions. La première version était de la mise en scène doctrinale.

Points clés

Pour les fondateurs et les créateurs indépendants : - Nommez l’utilisateur réel dans le moment réel avant de déclarer une surface digne. Le mérite abstrait ne sert à rien. - Chaque surface livrée devrait porter au moins un refus visible. Si vous n’avez rien retiré, le périmètre est mauvais. - Appliquez le gradient des surfaces. Un déploiement en production exige une validation plus dure qu’un brouillon ; les affirmations marketing exigent la validation la plus dure de toutes.

Pour les responsables produit et chefs de produit : - Mesurez si le Steve Test tourne vraiment en comptant les refus et suppressions par cycle de livraison. Zéro est un signal suspect. - Séparez « fonctionne » de « mérite d’exister » dans vos propres listes de contrôle de revue. Traitez-les comme deux axes indépendants. - Protégez le budget de refonte. Trois tentatives honnêtes, puis escalade. Ne laissez pas le perfectionnisme devenir une cachette, et ne laissez pas la pression des délais tuer le test.

Pour les responsables d’ingénierie : - Définissez un seuil Jiro et un seuil Steve pour chaque surface que votre équipe livre. Les deux doivent passer. - Investissez dans les détails invisibles. La différence entre correct et digne vit généralement dans les raccords entre les pièces. - Refusez le tempérament. Le refus calme est le signal. La performance de sévérité est le mode d’échec.

Pour les concepteurs : - Le point de vue n’est pas de la décoration. C’est le mécanisme qui rend le produit reconnaissable. - Une surface digne refuse des choses, visiblement. Votre rôle inclut de nommer ce que vous avez coupé. - Le test opératoire dans l’ambiguïté : signeriez-vous cette décision de votre nom sans hésiter ?

Conclusion : signerais-je cela de mon nom ?

La question directrice du produit est Le travail mérite-t-il d’exister ? Quand le jugement est incertain, la question directrice est la plus simple de tout le système.

Signerais-je cela de mon nom sans hésiter ?

Si la réponse est oui, le travail est éligible à la livraison. Si la réponse est « pas encore, mais il le sera après trois refontes honnêtes », continuez. Si la réponse est non, et reste non après trois tentatives honnêtes, reconstruisez la consigne initiale, pas la surface.

J’exécute ce test à chaque fois. Sur le code. Sur le texte. Sur le message de commit. Sur la documentation. Sur la surface produit. Sur cet essai.

Cet essai a coupé trois sections que je pensais nécessaires au début de la rédaction : une longue section biographique sur Jobs, une introduction à la formule « dent in the universe », et une défense du choix d’utiliser le nom d’une personne réelle plutôt qu’une abstraction pour nommer la doctrine. Aucune ne servait l’utilisateur pour lequel j’écrivais : un créateur qui essaie de décider s’il doit livrer une surface dont il n’est pas certain. Les coupes ont rendu le texte plus petit et plus honnête. Et l’échec de traduction qui ouvre l’essai a produit un artefact permanent au-delà de la correction : un garde-fou de concurrence dans la chaîne de traduction qui refuse désormais de démarrer si une autre tâche de traduction tourne déjà. Un travail rejeté a produit un changement de règles. La doctrine a appris.

Steve passe. Jiro passe. Cela part en production.

FAQ

Qu’est-ce que le Steve Test ?

Le Steve Test demande si un travail mérite d’exister pour un utilisateur réel, dans un moment réel. Il se tient à côté de la philosophie qualité de Jiro : Jiro vérifie la correction, les preuves et les cas limites ; Steve vérifie le mérite, la cohérence, le refus et le goût.

En quoi le Steve Test diffère-t-il du Jiro Test ?

Jiro demande si le travail est fabriqué correctement. Steve demande si le travail correct doit être livré tout court. Une fonctionnalité peut passer les tests et échouer tout de même face à l’utilisateur, au produit ou au point de vue que porte la surface.

Quand une équipe doit-elle exécuter le Steve Test ?

Exécutez-le avant que des surfaces difficiles à reprendre ne partent : déploiements publics, affirmations marketing, parcours d’accueil, pages tarifaires, documentation et fonctionnalités produit qui façonneront la confiance utilisateur. Le travail léger peut utiliser une validation plus souple, mais les surfaces publiques exigent une validation stricte.

Que doit produire le test ?

Le test doit produire une décision précise : livrer, reconstruire, supprimer ou refuser. Une vraie validation nomme l’utilisateur, le moment, le point de vue, la preuve et au moins une chose que l’équipe a retirée pour préserver l’ensemble.

Le Steve Test peut-il devenir du perfectionnisme ?

Oui. C’est pourquoi la doctrine a besoin d’une limite de refonte. Trois refontes honnêtes suffisent ; après cela, le problème se trouve généralement en amont, dans la consigne, le périmètre, l’équipe ou la prémisse.

Le modèle de revue

Copiez ceci dans un brouillon, une description de PR, une page Notion ou en haut de votre message de commit. Remplissez-le avant de déclarer un travail non trivial terminé. Si vous ne pouvez pas répondre à une ligne par quelque chose de précis, le test n’a pas encore tourné.

Steve Test : fiche de revue

Utilisateur :          [vraie personne dans une vraie situation, pas un archétype de persona]
Moment :               [moment précis où l’utilisateur rencontre le travail]
Point de vue :         [ce que cette surface affirme ; ce qu’elle refuse de faire]
Refus :                [ce que j’ai envisagé et coupé, ou refusé de construire]
Produit tout entier :  [comment cela s’accorde avec chaque pièce adjacente du produit]
Preuve :               [axe Jiro : vérification exécutée ; preuve précise que l’affirmation est soutenue]
Verdict de mérite :    [oui / non / pas encore après N refontes définies]
Signature :            [est-ce que je signerais cela de mon nom sans hésiter ? si non, arrêter]

Le modèle n’a qu’un seul rôle. Forcer la personne qui teste à produire une réponse précise sur chaque ligne. Les réponses vagues ne franchissent pas le seuil. « J’ai refusé de le surconcevoir » n’est pas un refus ; « j’ai refusé une option de contournement pratique et un comportement ouvert en cas d’échec » en est un. « Cela sert l’utilisateur » n’est pas une réponse sur l’ensemble ; « cela ferme le vide compositionnel précis qui a causé le dernier incident » en est une. Quand une ligne résiste à la précision, le travail n’est pas prêt ; cette résistance vous indique où doit aller la refonte.

Ce modèle est l’artefact opérationnel de l’essai. Tout le reste sur cette page explique pourquoi ces lignes existent.

Références