Fast - La puissance des logiciels rapides

• Dans le développement logiciel, il est rare que l’on demande explicitement de la rapidité (fast), mais les logiciels rapides transforment le comportement des utilisateurs
• Des technologies comme les déploiements rapides et le streaming en temps réel améliorent de manière spectaculaire l’efficacité au travail et le travail à distance
• Les logiciels lents provoquent une friction cognitive et nuisent fortement, en pratique, à la productivité des utilisateurs
• Les logiciels rapides ne masquent pas la complexité ; ils expriment la simplicité et la concentration
• À l’avenir, l’industrie du développement accordera de plus en plus d’importance à l’optimisation des performances et de l’expérience

---

Un secteur logiciel qui ne demande pas la rapidité

• Dans l’industrie du logiciel, on demande surtout des fonctionnalités, des prix, des intégrations de données, mais il est rare que la « rapidité » soit demandée directement
• Pourtant, les logiciels rapides ont le pouvoir de changer le comportement même des utilisateurs
• Lorsque le temps de déploiement du code tombe à quelques secondes, la fréquence de déploiement des développeurs augmente elle aussi
• Les fonctions de complétion automatique de code basées sur l’IA facilitent le prototypage dans des langages peu familiers
• Les technologies de streaming en temps réel ouvrent de nouvelles possibilités pour le travail à distance

Les limites des logiciels lents

• Les logiciels lents nous imposent plus de contraintes qu’on ne le pense
• Par exemple, avec le WiFi d’un avion, il est difficile d’accomplir un travail vraiment productif
  • On peut tout au plus envoyer des messages Slack ou répondre à des e-mails,
  • Google Docs fonctionne souvent mal,
  • et l’expérience finit souvent par pousser l’utilisateur à abandonner
• À l’inverse, des services comme Instagram offrent une expérience rapide et constante

Les effets des logiciels rapides

• La rapidité donne une impression de magie
• Les logiciels rapides suppriment la friction cognitive et, comme Raycast ou Superhuman, semblent réagir avec un temps d’avance sur les attentes
• Le temps de réponse inférieur à 100 ms de Superhuman et son excellent support des raccourcis transforment l’expérience de l’e-mail
• La fonction de virement instantané de Mercury surprend elle aussi des utilisateurs habitués à la lenteur des opérations bancaires
• La vitesse de ces outils n’est pas forcément louée explicitement, mais c’est bien ce qui leur donne, aux yeux des utilisateurs, un caractère presque magique

Rapidité, simplicité et concentration

• La rapidité est synonyme de simplicité, une valeur de plus en plus rare dans l’environnement logiciel moderne
• Pour qu’un logiciel soit rapide, il faut faire l’effort de supprimer les fonctionnalités inutiles
• Des outils de gestion de projet épurés comme Linear offrent une expérience nettement plus rapide que des applications d’entreprise comme Workday ou Oracle
• La rapidité est une marque de respect envers l’utilisateur, qui montre que tout ce qui est superflu a été rigoureusement éliminé

Les efforts cachés nécessaires pour aller vite

• Créer un logiciel rapide exige des optimisations backend complexes
• Chez Cash App, on s’efforce de n’ajouter que les étapes strictement nécessaires au parcours utilisateur, en traitant la complexité en interne
• Lors de l’envoi d’une photo, Instagram lance l’upload pendant que l’utilisateur saisit la légende, ce qui donne l’impression d’un envoi immédiat
• La rapidité n’est pas seulement un accomplissement technique, c’est le résultat de priorités claires et de la concentration

La rapidité comme plaisir et motivation

• Les logiciels rapides procurent en eux-mêmes du plaisir et de la satisfaction
• Même dans de petits détails comme la mesure de la vitesse de frappe (WPM) ou le réglage des raccourcis, les utilisateurs apprécient l’expérience de devenir plus rapides

La relativité de la rapidité

• Les workflows basés sur l’IA et les LLM offrent une expérience incomparablement plus rapide que les méthodes traditionnelles
• Par exemple, confier une recherche à un LLM en 6 minutes peut produire, par rapport au passé, une productivité plus de 10 000 fois supérieure
• Mais il reste encore de nombreuses lacunes dans les processus de développement, de build et de déploiement des applications IA par rapport à l’ère logicielle précédente
• À l’heure actuelle, l’accent est davantage mis sur les nouvelles fonctionnalités que sur les performances et l’expérience
• À l’avenir, une dynamique donnant la priorité aux optimisations — faible latence, design d’interface, connectivité, fiabilité — devrait s’imposer
• Cela ouvrira davantage de nouvelles possibilités et d’évolutions de l’expérience utilisateur

Références

• Voici quelques lectures complémentaires utiles sur la rapidité
  • Patrick Collison: https://patrickcollison.com/fast
  • Charlie Marsh: https://notes.crmarsh.com/python-tooling-could-be-much-much-faster
  • Paul Graham: https://www.paulgraham.com/growth.html

[GN⁺]

Commentaires Hacker News

• Je suis vraiment reconnaissant envers YCom de maintenir l’interface de HN rapide et bien tenue. J’ai déjà quitté Slashdot juste après qu’ils ont tout refait en « UI moderne », transformant le site en un espace rempli de blanc et difficile à parcourir visuellement. Avant, c’était un site que je lisais tous les jours.
  • La densité d’information et la possibilité de trouver vite ce qu’on cherche sont complètement à l’opposé de la notion d’« engagement ». Souvent, les sites sont rendus volontairement plus complexes pour faire monter le temps passé dessus et mieux séduire les annonceurs. Les pages chargent délibérément lentement pour provoquer des clics ratés et pousser à la « conversion ». En pratique, tromper les gens rapporte souvent plus qu’être centré sur l’utilisateur.
  • HN est le site que j’ouvre pour vérifier si ma connexion Internet fonctionne. Au milieu de tout le bloat du web, c’est vraiment quelque chose qui brille.
  • L’UI de HN a quand même besoin d’améliorations, surtout sur mobile. Le contraste est faible, les boutons sont trop petits donc pénibles à utiliser, il n’y a pas de mode sombre, etc. J’ai une version de ce que je considère comme une UI idéale, faite en Elm, entièrement côté client, avec l’API Firebase de HN : https://seville.protostome.com/
  • Je ne pense pas que Slashdot ait décliné à cause de son UI. Sa vraie valeur venait des commentaires laissés à ses débuts par des SME de très haut niveau. Après la vente du site, la baisse de qualité des utilisateurs, la mauvaise modération et les départs ont probablement lancé le déclin. Je trouve encore étonnant que le site existe toujours.
  • Le site orange (HN) ne prend toujours pas en charge les balises de lien Markdown.
• J’ai souvent l’impression que les workflows avec LLM sont en réalité plus lents. La fonction « refactor » d’un IDE termine en 1 seconde, mais si je confie ça à un assistant IA, il lui faut 30 secondes, et une approche « agent » peut prendre 15 minutes. Par exemple, j’ai confié à un agent du code d’endpoint HTTP et j’ai d’abord cru qu’il avait « fait en 10 minutes un travail d’une journée », mais en y revenant, la logique était bancale et la gestion des erreurs maladroite. Au final, j’ai passé environ 5 heures à tout réécrire moi-même pour obtenir des tests meilleurs que selon mes propres standards initiaux et une gestion des erreurs plus solide que ce que j’aurais fait spontanément. Il existe aussi une étude sur le sujet : https://www.reddit.com/r/programming/comments/1lxh8ip/study_finds_that_ai_tools_make_experienced/
  • J’ai déjà écrit plusieurs fois sur ce sujet. À mon avis, le fait que les LLM courent après les scores de benchmark va dans le mauvais sens pour des outils de programmation. D’après mon expérience, ils se trompent avec une probabilité assez élevée, donc il faut toujours vérifier le résultat. Cela allonge les allers-retours avec le LLM, et comme les réponses sont lentes, j’ai souvent l’impression que je pourrais aller plus vite en faisant tout moi-même à la main. Ce que je voudrais, c’est un agent qui réponde en moins d’une seconde, même s’il n’est qu’au niveau de 60 % sur les benchmarks.
  • Le seul domaine où un LLM m’a vraiment fait gagner du temps, c’est comme version avancée de find/replace dans du code. Par exemple, si je lui demande de remplacer dans plusieurs endroits la « logique liée à XXX » par autre chose, il répond plutôt bien. Ça m’épargne beaucoup de recherches et de modifications manuelles. En revanche, je n’ai jamais essayé ça sur un code vraiment énorme.
  • Ça dépend du contexte. Pour le refactoring, si l’IDE ou le language server le prend en charge, c’est bien plus rapide, mais en dehors de ça, les LLM peuvent aider. Par exemple, hier j’ai bricolé une logique de normalisation d’URL en MVP, et il y avait beaucoup de cas de validation parce que les données client contenaient des URL sous des formes variées. J’ai donné à Claude les cas client les plus fréquents en lui demandant de produire des « test cases couvrants minimaux », et j’ai eu un résultat en 5 à 10 secondes. À partir de là, j’ai utilisé la fonction d’agent Opus de Zed pour créer le fichier de tests, puis j’ai revu les cas, supprimé le superflu et amélioré un peu la logique. Cette méthode a été bien plus rapide que tout faire seul.
  • J’entends souvent, en ligne comme hors ligne, que sur des tâches senior on gagne 40 à 60 % de vitesse. Cela dit, on n’en est pas encore au point de pouvoir faire semblant de travailler en se reposant uniquement sur des agents IA.
• C’est une anecdote de début de carrière, quand je me suis fait une réputation comme ingénieur logiciel capable d’accélérer les choses. À l’époque, la connaissance des algorithmes et la capacité à lire la sortie des compilateurs comptaient énormément, et c’était l’ère où Carmak et Abrash devenaient des stars. À 22 ans, j’ai participé pour la première fois à une réunion avec le client d’une grande multinationale, et on nous a dit que la vitesse de notre produit posait problème. J’ai été complètement sidéré d’entendre un VP de cette entreprise dire : « Une seconde gagnée nous rapporte un million de dollars de bénéfice annuel en plus. » C’était le moment décisif où j’ai découvert qu’on pouvait rattacher la performance aussi directement à l’argent. Vingt ans plus tard, ça reste l’un des grands moments de ma carrière. Et un autre ingénieur a alors demandé au VP, pour plaisanter, « si on descend à 0 seconde, est-ce qu’on gagne une quantité infinie d’argent ? » Personne n’a ri dans la salle, mais moi, j’ai trouvé ça assez drôle.
  • Réduire de 1 seconde à 0 seconde, ou de 2 secondes à 1 seconde, ça ajouterait à chaque fois un million de dollars ? La logique selon laquelle ça créerait un montant infini est quand même curieuse.
  • Je me demande au final si vous avez réellement réussi à aller plus vite.
• Je réagis parce que je suis d’accord avec la première phrase du billet. Les utilisateurs ne demandent pas explicitement aux développeurs « faites-le vite », mais si ce n’est pas rapide, ils n’accordent pas leur confiance. Si Rust avait été plus lent que Ruby, personne ne s’y serait intéressé. Rust attire l’attention parce qu’on dit qu’il est « plus rapide que C++ ». Sur HN aussi, dès qu’un truc est « rapide », tout le monde s’emballe presque automatiquement. Il suffit que ce soit ne serait-ce qu’un peu plus rapide pour capter l’attention.
  • C’est surtout vrai pour la petite couche de programmeurs qui écrivent sur HN. La plupart des développeurs et des utilisateurs ordinaires se soucient assez peu de la lenteur tant que l’UI est pratique. Même des data scientists très pros utilisent souvent un Github Desktop propre et net plutôt qu’une commande ultra rapide.
  • Je pense que la conclusion est fausse. Le « rapide » est un différenciateur puissant quand on fournit le même ensemble de fonctionnalités plus vite. Les gens accourent pour un « X plus rapide que X », mais ils peuvent aussi migrer pour plus de fonctionnalités, un meilleur UX, un meilleur prix ou une meilleure qualité, et ils peuvent très bien choisir quelque chose de plus lent.
  • Pour les langages ou les runtimes, la vitesse est importante, mais quand on choisit un framework, d’autres facteurs comptent davantage : les fonctionnalités, la compatibilité, etc. Même quelque chose d’aussi lent qu’Electron est massivement utilisé.
  • En pratique, on vit dans un monde où une grande partie des apps, surtout web, sont incroyablement lentes. Il est très courant qu’après une action utilisateur il faille attendre plusieurs secondes avant d’avoir une réaction. Même si l’on dit que « le rapide est roi », la réalité est l’inverse.
  • Si les utilisateurs de HN aiment autant le « rapide », c’est parce qu’ils savent que la plupart des technologies qu’on utilise aujourd’hui sont beaucoup trop lentes, et qu’on pourrait fondamentalement les rendre plus rapides.
• À l’inverse, quand quelque chose est « trop » rapide, on peut aussi douter que ça ait vraiment fonctionné. Dans le cas de TurboTax, l’analyse réelle prenait moins d’une seconde, mais en ajoutant volontairement un faux écran de chargement, les gens faisaient davantage confiance au produit et l’appréciaient plus. Même si le traitement était en réalité bien plus court, on l’a fait paraître plus lent pour inspirer la confiance sur le fait qu’un vrai examen avait bien eu lieu.
• La vitesse compte aussi du point de vue des coûts. Dans le cloud, quand on paie à la seconde, il est impossible d’offrir un service de transcription bon marché à l’échelle de l’entreprise sans tout optimiser. Par exemple, l’image que j’ai construite est 2,5 fois plus petite que la version open source suivante, ce qui donne des cold boots plus rapides, des coûts plus bas et un meilleur service : https://speechischeap.com
  • S3 est-il lent ou rapide ? En réalité, les deux. Une requête unique est lente, mais si on en envoie plusieurs en parallèle, on a une impression de rapidité. Au fond, le « rapide » est parfois essentiel à la survie, et parfois une forme d’esthétique.
  • Moi, à l’inverse, j’exécute le service sur du matériel grand public, ce qui revient bien moins cher que le cloud. Je n’ai pas besoin de m’inquiéter de la taille des images (le bare metal est plus rapide). J’offre aussi gratuitement une transcription à 20 000 minutes par minute, avec une limite de 5 secondes par requête. Je développe également des alternatives open source et cross-platform liées à cela : https://geppetto.app https://github.com/Mozilla-Ocho/llamafile/tree/main/whisper.cpp https://github.com/cjpais/whisperfile https://handy.computer Si la transformation des services de transcription vous intéresse, contactez-moi.
  • J’attends d’outils comme PAPER, au moins sous Linux, qu’ils tiennent dans moins de 2 Mo au total à l’installation, cache compris. pip fait 10 à 15 Mo, pipx est encore plus gros, et uv fait 35 Mo. J’essaie de faire plus petit que ça.
  • Le fait que ce soit rapide ne veut pas dire que c’est léger et efficace pour autant. Parfois, on atteint la vitesse en déployant massivement du matériel coûteux.
• Chaque fois que je vois un article se plaindre des virements bancaires américains, je dois me le rappeler. Au Royaume-Uni, en Suisse et ailleurs, les virements sont presque instantanés. Je me demande pourquoi c’est si lent aux États-Unis.
  • Les banques régionales américaines n’ont pratiquement pas de programmeurs en interne et dépendent de « core processors ». Du coup, les mises à niveau des systèmes avancent très lentement. L’introduction de Faster ACH a pris des années, et le lobby des banques locales a demandé à la retarder parce qu’elles la jugeaient défavorable à leurs intérêts. Je recommande ce billet qui l’explique très bien : https://www.bitsaboutmoney.com/archive/community-banking-and-fintech/
  • Le calendrier et le traitement par lots d’ACH sont la cause de cette lenteur. Le transfert lui-même peut être immédiat, mais en général le règlement est regroupé et traité à minuit. C’est aussi pour ça que Venmo et Zelle sont populaires aux États-Unis. En Suisse aussi, les transferts IBAN sont lents, et pour les paiements en temps réel, c’est surtout TWINT qui domine, avec des QR codes. Le système britannique BACS est lent pour la même raison.
  • Les États-Unis ont bien deux systèmes de paiement en temps réel : RTP et FedNow. Le nombre de banques participantes augmente progressivement : https://real-timepayments.com/Banks-Real-Time-Payments.html Par le passé, on pouvait faire des transferts immédiats via les réseaux de cartes de crédit moyennant de petits frais. Cela dit, les cartes de crédit ont d’autres garanties et règles de remboursement, et en cas de fraude, la perte pour les banques est plus importante.
  • Il y a aussi un aspect positif pour les consommateurs. Par exemple, lorsqu’un prélèvement automatique tente de retirer de l’argent d’un compte sans provision, la banque envoie plusieurs e-mails d’avertissement. Si tout était instantané, ce serait immédiatement problématique, alors qu’avec le système actuel on a le temps d’être notifié et d’agir soi-même pour éviter des pénalités ou des frais. Le fait que ce ne soit pas instantané laisse à la banque le temps de prévenir et au client le temps de réagir.
  • patio11 a écrit un article détaillé sur le sujet : https://www.bitsaboutmoney.com/archive/the-long-shadow-of-checks/
• J’ai trouvé le billet intéressant, il donne beaucoup de matière à réflexion. Quand la vitesse se ressent vraiment, ce qui compte ce n’est pas tant le débit réel que la « sensation de rapidité », c’est-à-dire la réactivité de l’UI ou la latence à la saisie, cette vitesse qui rend l’usage confortable. C’est pour ça que je préfère Go à Rust. La compilation de Go est suffisamment rapide pour donner l’impression qu’elle n’a même pas besoin d’être mesurée. À l’inverse, si quelque chose semble lent, je le déteste, même si le débit réel est bon par ailleurs, comme avec les startups Java.
  • Même quand on compare Go et Rust, la vitesse de compilation semble vraiment importante. Les builds Rust accumulent beaucoup de dépendances annexes, ce qui donne aux projets une structure qui rappelle JavaScript. Go a comparativement bien moins de dépendances, et j’aime beaucoup cet aspect.
  • C’est bien que les développeurs débattent de ce genre de choses, mais au fond la vraie question est : « quel langage est le plus rapide pour l’utilisateur ? »
• Contrairement à l’idée selon laquelle on n’entend presque jamais « rendez le logiciel plus rapide », dans presque toutes les entreprises où j’ai travaillé, la réactivité des pages et la latence faisaient partie des priorités absolues. Startup ou grand groupe, la vitesse et la latence étaient des objectifs importants, et on examinait toujours de près la rapidité globale du produit, le temps d’affichage des pages et l’absence de délais bizarres.
  • Dans la plupart des entreprises que j’ai connues directement (6 sur 8), on ne me laissait presque jamais de temps pour optimiser les performances, donc je devais le faire en douce. Même dans les endroits qui mesuraient la latence et affirmaient que c’était important, dès qu’il fallait ajouter des fonctionnalités, le sujet passait en pratique au second plan.
  • Beaucoup s’obsèdent sur la vitesse des résultats de recherche, tout en prêtant assez peu attention au rendu de la page ou au volume de données envoyé à l’utilisateur.
• C’est quelque chose que j’ai constaté à répétition dans plusieurs emplois : la plupart des gens sous-estiment la vraie valeur de la vitesse. Ils supposent simplement qu’on fait « le même workflow plus vite ». Par exemple, on peut penser qu’accélérer une grosse expérience lancée pendant la nuit n’aide pas tant que ça. Mais si l’on augmente la vitesse de façon spectaculaire, on peut lancer plusieurs expériences dans la journée, ce qui change complètement l’ordre de grandeur de la productivité.
  • Les gens sous-estiment énormément le coût du context switching. Ils se disent qu’un passage de 30 secondes à 3 secondes sur une commande exécutée 10 fois par jour ne fait gagner que 5 minutes, alors qu’en réalité le coût du changement de contexte est bien plus important.
  • Chaque fois qu’une pipeline CI prend plusieurs heures, je me dis que si elle finissait en moins de 20 minutes, je corrigerais aussi à chaque fois tous les petits avertissements de lint.