Le standard de l'enchantement

La ligne sous notre nom dit : nous ne nous contentons pas de développer — nous façonnons chaque ligne de code et chaque pixel comme par enchantement. La première personne extérieure au studio à l'avoir lue m'a demandé si enchantement n'était pas un peu fort pour un studio logiciel indépendant qui passera l'essentiel de sa vie à écrire du TypeScript et à relire des pull requests. La question est juste. J'ai gardé le mot, et voici pourquoi.

L'enchantement nomme un effet, pas une méthode. Quand un logiciel paraît légèrement impossible — la liste qui défile sans le moindre à-coup sur un téléphone de quatre ans, le formulaire qui retrouve votre réponse à moitié tapée après une coupure, la mise en production dont personne n'a eu à prévenir personne — vous n'assistez pas à de la magie. Vous assistez à l'absence des douze petites défaillances qu'on vous a appris à attendre. La magie fonctionne en cachant le travail. L'ingénierie fonctionne en choisissant de faire le travail invisible un mardi, alors que personne ne verra jamais la version où vous ne l'aviez pas fait.

L'enchantement n'est pas une humeur. C'est un standard : une liste de choses que nous faisons à chaque fois, et tout particulièrement les semaines où les sauter ne coûterait rien aujourd'hui.

Les standards sont démodés parce qu'ils sonnent comme de la bureaucratie. Ils ne le sont pas. Un standard, c'est ce qui décide à votre place un jeudi à 18 h, quand le client est content, la démo est passée, et que la bonne décision suivante consiste en deux heures de travail supplémentaires qui ne feront aucune différence visible. Le goût seul perd ce débat à tous les coups. Un standard écrit le gagne à peu près une fois sur deux, et c'est là toute la marge qui sépare deux studios.

Nous recrutons des architectes, pas des assembleurs

La distinction n'est ni une question d'ancienneté ni une question de titre. Un assembleur demande ce que dit le ticket. Un architecte demande ce que le ticket implique au dix-huitième mois, quand trois autres fonctionnalités dépendront du raccourci qu'il propose. Les deux écrivent du code qui marche. Un seul des deux reste bon marché à employer la deuxième année.

Taper du code n'a jamais été la compétence rare, et elle l'est de moins en moins de trimestre en trimestre. Ce qui reste rare, c'est le jugement : quel invariant est porteur, quelle abstraction vaut son poids, quelle fonctionnalité demandée est en réalité deux fonctionnalités et un malentendu. Un assembleur ajoute la chose qu'on lui a demandée. Un architecte demande ce qu'il faut supprimer maintenant que la chose existe — et il est prêt à dire non, et voilà ce que je construirais à la place, à moi, par écrit.

Le critère d'embauche est donc un critère de jugement. Je veux que les disputes internes de ce studio portent sur ce qu'on supprime, pas sur ce qu'on ajoute. N'importe qui sait rallonger un backlog.

Dire ce que la chose n'est pas

Tout système a une frontière au-delà de laquelle il cesse d'être vrai. Les caches périment. Les estimations supposent un périmètre. Les modèles sont catégoriques sur des choses qu'ils n'ont jamais vues. Le réflexe du secteur est de laisser cette frontière hors de la phrase et d'espérer que personne ne la rencontre en production. Notre règle va dans l'autre sens : la limite a sa place dans l'interface, dans le même corps de texte que la promesse.

La phrase qui reconnaît une limite fait partie du produit. Si elle n'est pas dans l'interface, nous n'avons pas fini de livrer.

C'est déjà visible aux deux endroits où nous sommes obligés d'être honnêtes. Le calculateur de tarifs place la réserve là où se trouve le chiffre, et non dans un pied de page : une estimation tient jusqu'à ce que le périmètre et le cadrage en décident autrement. La garantie de remboursement énonce chacune de ses conditions dans le même souffle que la promesse. Publier les conditions coûte un peu de conversion et achète la seule chose qui vaille la peine le jour un : un client qui n'aura pas de surprise au troisième mois.

Corollaire, tout aussi contraignant : ce sont les chiffres qui convainquent. « Rapide » est un bulletin sur ce que nous ressentons face à notre propre travail. « 180 ms au 95e centile, sur un Android de milieu de gamme en 4G » est une affirmation que vous pouvez aller réfuter. Les adjectifs demandent qu'on les croie ; les chiffres demandent qu'on les vérifie. Nous préférons être vérifiés — et quand la mesure n'existe pas encore, le geste honnête est de dire qu'elle n'existe pas plutôt que d'aller chercher un adjectif plus gros.

Nettoyer au démontage est une position morale

Voici le plus petit exemple que je connaisse de ce standard, et celui que j'utilise pour l'expliquer à ceux qui trouvent tout cela abstrait. Un composant interactif acquiert des choses tant qu'il vit : minuteurs, écouteurs d'événements, sockets, observateurs, frames d'animation, un contexte GPU. Rien dans le langage ne vous force à les rendre quand le composant disparaît. Sautez l'étape et l'application marche quand même — les tests passent, la démo se déroule bien, la fonctionnalité part en production.

Puis quelqu'un navigue vingt minutes dans votre produit. Les minuteurs abandonnés se déclenchent toujours, tous. Le téléphone chauffe, le ventilateur du portable s'emballe, l'onglet qui allait très bien sur votre bureau meurt dans le train de banlieue. Personne ne signale ce bug sous la forme vous avez oublié une fonction de nettoyage ; on le signale sous la forme « l'appli est lourde », ou plus souvent on ne signale rien et on cesse de s'en servir.

Je parle de position morale parce que ça coûte un après-midi et n'achète rien qu'on puisse montrer en démo. On le fait pour une machine qu'on ne verra jamais, appartenant à quelqu'un qui ne saura jamais qu'on lui a épargné ça. Cet instinct se propage à tout ce qui se trouve au-dessus : des sessions qui se terminent vraiment, des tâches qui s'arrêtent quand on les annule, des caches dont quelqu'un a choisi l'expiration exprès, des fonctionnalités qu'on retire dès qu'elles ne méritent plus leur maintenance. Un logiciel qui ne range pas derrière lui est un logiciel qui ne respecte pas la machine dont il est l'invité.

Pourquoi un petit studio publie ses tarifs

L'asymétrie d'information est le tour préféré de ce métier, et le plus ancien. « Contactez-nous pour un tarif » ne signifie pas que le prix est compliqué ; cela signifie que le prix est négociable dans une direction qui dépend de ce que l'agence devine de votre budget. Le chiffre existe avant l'appel. L'appel sert à décider qui l'apprend en premier.

Nous avons publié le nôtre dès le premier jour, arithmétique à l'écran — unités par poste, multiplicateurs, fourchette, semaines. Vous pouvez obtenir un chiffre à deux heures du matin sans rencontrer personne, et s'il ne vous convient pas, vous aurez perdu quatre-vingt-dix secondes au lieu de deux réunions et une semaine de politesses.

Cela a un coût réel, et je préfère l'énoncer plutôt que faire croire que le choix était gratuit. Cela livre notre grille tarifaire à la concurrence, cela invite à une comparaison sur le prix avec des gens qui nous casseront volontiers, et cela supprime l'option de facturer différemment deux clients pour un travail identique. Je ne veux pas de cette option. Un prix qu'on serait gêné de publier est un prix qu'on devrait être gêné de facturer.

La garantie de remboursement à 100 % est la même idée avec une étiquette de prix. Si le projet ne part pas en production avant l'échéance contractuelle, vous ne payez pas. Elle convertit notre confiance, d'adjectif en engagement porté de notre côté de la table — la seule forme de confiance sur laquelle un acheteur puisse agir.

Il existe une version de tout cela qui s'applique avant même que quiconque devienne client, et c'est la partie que la plupart des studios traitent comme de la décoration. Ce que nous devons à un visiteur : des pages qui chargent vite sur le téléphone qu'il possède réellement, un prix qu'il trouve sans livrer son adresse e-mail, pas de compte à rebours qui se réinitialise au rechargement, pas de fenêtre cookies conçue pour que le mauvais bouton soit le plus facile à atteindre, pas de widget qui se fait passer pour une personne ravie de vous aider. Les dark patterns ne sont qu'un standard braqué sur le client au lieu du code.

Rien de tout cela n'est impressionnant en première semaine. N'importe qui peut tenir un standard tant que le studio est petit, que l'agenda est vide et qu'aucune échéance n'a encore montré les dents. La raison de l'écrire maintenant est précisément qu'il deviendra gênant plus tard, et qu'un standard écrit est réfutable là où une valeur d'entreprise ne l'est jamais. Le site est en ligne depuis six jours et les tarifs sont publics depuis la première heure. Les deux sont vérifiables. Vérifiez-les, s'il vous plaît.