Les utilisateurs s’en moquent — mais vous, vous devriez vous en soucier

• Les utilisateurs se préoccupent davantage du fonctionnement du produit que des propriétés intrinsèques du code lui-même, mais un mauvais code a des effets indirects directs sur les performances, les bugs et la vitesse de développement
• Dire que « les utilisateurs ne se soucient ni de la stack technique ni des tests » est superficiellement vrai, mais plus la qualité du code est faible, plus il devient difficile et lent de corriger des bugs et d’ajouter des fonctionnalités
• Comme dans les analogies de l’inspection d’un pont, d’un pilote ivre ou de fondations instables d’un immeuble, même si l’utilisateur ne voit pas le processus lui-même, le résultat a un impact sur la sécurité et la confiance
• Des entreprises comme AirBnB, OpenAI et Meta peuvent faire passer ce type de problèmes grâce à leur domination du marché, un soutien massif du VC et une légalité douteuse, mais toutes les entreprises ne sont pas dans cette position
• Le succès logiciel est le résultat de multiples préoccupations et points de vue qui agissent ensemble, des ventes techniques à la stack technique, de l’expérience utilisateur jusqu’aux identifiants uniques

---

Des clichés répétés et leurs limites

• Dans l’industrie logicielle, on entend sans cesse des formules comme « le client ne se soucie pas des tests, il veut juste que le produit fonctionne », « les utilisateurs ne se soucient pas de la stack technique », « l’élégance de l’ingénierie n’est pas équivalente à la valeur marché », ou encore « les utilisateurs ne se soucient pas de savoir si le produit a été écrit par une IA ou par un humain, ni du framework utilisé, ils veulent juste qu’il fonctionne »
• Toutes ces formules sont des variantes d’un même thème : « le client s’en moque », présentées comme un pragmatisme lucide qui dirait la réalité froide
• Si l’on applique la même logique à d’autres domaines, le caractère superficiel du problème apparaît
  • Dire que les usagers de la route ne se soucient pas de l’inspection finale d’un pont, mais seulement du fait qu’il supporte leur voiture
  • Dire que les passagers ne se soucient pas de savoir si le pilote a bu, mais seulement que l’avion arrive à l’heure
  • Dire que les employés de bureau ne se soucient pas de la stabilité des fondations d’un immeuble de grande hauteur, mais seulement de gagner de l’argent
• Ces analogies sont superficiellement vraies, mais elles ignorent des effets indirects évidents
• Il est vrai que les clients ne s’intéressent pas aux propriétés intrinsèques du code informatique, mais la qualité du code a un effet sur les performances, la présence de bugs, le temps nécessaire pour corriger les bugs et le temps nécessaire pour ajouter des fonctionnalités
• Plus le code est mauvais, plus il devient difficile et lent de résoudre ces problèmes
• L’auteur souligne que des entreprises comme AirBnB, OpenAI et Meta peuvent repousser ces inquiétudes grâce à une énorme emprise sur le marché, à un soutien massif du VC et à une légalité douteuse
• Conclusion : si l’on n’est pas une entreprise de ce type, il est difficile de masquer les problèmes de la même manière

La persistance de la « sagesse populaire » et les multiples préoccupations du logiciel

• La persistance de la sagesse populaire

  • L’idée selon laquelle seuls les effets de premier ordre comptent existe dans le logiciel comme une croyance populaire très répandue
  • Les gens ont tendance à minimiser ou à dévaloriser ce dans quoi ils ne sont pas bons
  • Lorsqu’on estime ne pas être capable de produire du bon code, on en vient facilement à considérer non seulement que le bon code n’a pas d’importance, mais aussi que ceux qui savent en produire sont eux-mêmes le problème
  • Dans cette perspective, ceux qui bloquent une mise en production pour des raisons dont le client ne se soucie pas sont traités comme le problème
  • Cette attitude fonctionne comme un mécanisme de défense de l’ego permettant d’éviter ses propres faiblesses et d’externaliser la responsabilité sur les autres

• Nous vivons en société

  • Un travail logiciel sérieux est un mélange de préoccupations et de points de vue différents
  • Des ventes techniques à la stack technique, de l’expérience utilisateur jusqu’aux identifiants uniques, de nombreux éléments entrent dans un effort logiciel
  • Tous ces éléments contribuent au succès ou à l’échec

[GN⁺]

Avis sur Lobste.rs

• Ce genre de phrase peut être bonne ou mauvaise, autant dans la manière de la transmettre que de la lire
  Par exemple, dire « le client ne se soucie absolument pas des tests ; il se soucie de savoir si le produit fonctionne » peut se lire non pas comme « expédiez des bugs », mais comme une invitation à se concentrer sur le fait que le produit fonctionne réellement plutôt que sur une idéologie des tests particulière
  Les tests ne sont qu’un des moyens de faire fonctionner le code ; ainsi, si la couverture de tests est élevée et que tout passe mais que le produit ne marche pas, c’est un échec ; à l’inverse, si le produit fonctionne bien grâce à d’autres approches que les tests, c’est acceptable, et si on détecte bien les bugs sans suivre une doctrine formelle, cela peut aussi être acceptable
  Du point de vue des utilisateurs et du business, « l’absence du produit/de la fonctionnalité » peut aussi être un bug ; corriger des bugs existants et livrer des fonctionnalités ne sont donc pas toujours des activités proprement séparées
  Cela dit, j’ai aussi déjà vu ce genre de phrase utilisée pour dire en pratique « bâclez le travail et livrez de la merde »

  • Sur l’idée que « du point de vue des utilisateurs et du business, l’absence du produit/de la fonctionnalité est aussi un bug », il y a un point que, comme auteur, je n’ai pas traité explicitement
    Je rejette totalement l’idée qu’une programmation médiocre puisse être « pragmatique », même à l’échelle de plusieurs mois
    Dans une base de code mal conçue et insuffisamment testée, développer de nouvelles fonctionnalités est lent et coûteux
  • Il y a aussi beaucoup d’ingénieurs qui pensent que « plus il y a de tests unitaires, mieux c’est » ou qui passent des jours à optimiser du code qui n’est même pas un goulot d’étranglement ; dans ces cas-là, les interprétations ci-dessus sont assez pertinentes
    Les développeurs devraient être conscients de là où leur temps crée de la valeur, et idéalement la direction devrait aussi comprendre pourquoi ils travaillent sur ces sujets
    Quand un manque de compréhension se combine à une mauvaise structure d’incitations, on finit effectivement par « bâcler le travail et livrer de la merde »

• Honnêtement, ceux qui disent ce genre de chose donnent souvent l’impression de ne pas beaucoup se soucier non plus des utilisateurs
  Pour que les utilisateurs reçoivent un produit qui fonctionne, il faut intégrer dans le processus de développement des mécanismes qui augmentent cette probabilité, comme je l’ai déjà dit dans un commentaire il y a quelques jours
  Cet état d’esprit apparaît souvent dans des situations où les utilisateurs n’ont aucun vrai moyen de faire des retours sur le produit, et où il n’y a pas non plus de véritables indicateurs d’usage
  Il existe aussi de nombreux scénarios d’échec qui affectent les utilisateurs même s’ils ne les voient pas immédiatement ou ne s’en soucient pas sur le moment
  La sécurité, par exemple : un utilisateur peut ne pas se préoccuper du fait que ce n’est « pas sûr » tant que ses données n’apparaissent pas dans une fuite en ligne ; de même, il peut ne pas percevoir les performances comme un problème tant qu’il ne sait pas qu’elles pourraient être bien meilleures

  • Ce genre de sujet est difficile à expliquer à un public généraliste
    Il est difficile d’obtenir de bons résultats en optimisant un seul élément d’un processus d’amélioration, mais pour faire avancer la discussion, on est souvent obligé de procéder ainsi
    Il est donc utile d’ajuster le cadre du débat en alignant les circuits de retour pour identifier où se situe réellement le problème visible
    Je vois ce type d’article comme une tentative de faire réfléchir à des éléments qui influencent la réussite d’un projet logiciel tout en pouvant sembler mutuellement exclusifs
    Il y a de la valeur à mettre en mots et à défendre des choses que seuls les gens dotés d’une intuition technique perçoivent ; mais beaucoup de techniciens semblent mal équilibrer ce travail invisible ou peinent à le défendre efficacement, et c’est aussi un point que je continue à travailler

• Se soucier de l’interne est important, et en pratique cela profite aussi aux utilisateurs

• J’aime bien cette perspective
  Je ne veux pas basculer dans l’extrême inverse, celui de la sur-ingénierie, mais j’aimerais qu’on sorte de cette mentalité du « avancer vite et tout casser »
  D’après mon expérience, c’est presque une épidémie dans le monde du développement web
  J’aimerais que l’afflux de logiciels de mauvaise qualité rendu possible par les LLM pousse au contraire les utilisateurs à récompenser les logiciels fiables
  Je deviens de plus en plus un développeur grug brain, donc je ne sais pas si c’est un ressenti largement partagé, mais je suis fatigué du « ajoutons juste une fonctionnalité de plus »
  On fait souvent l’erreur de mesurer le coût d’un logiciel uniquement à sa date de sortie, en excluant presque entièrement les coûts de maintenance sur toute sa durée de vie
  On dit « ce n’est pas compliqué, ça prendra moins d’une semaine ! », mais on ne parle pas du temps qu’il faudra ensuite consacrer chaque année — 2 à 4 semaines — à la maintenance, aux corrections, aux extensions, aux mises à jour, à l’intégration et à la documentation

• Je dis souvent quelque chose dans le même esprit
  « L’utilisateur final ne se soucie pas de savoir si le logiciel a une couverture de tests de 100 %, ni s’il est écrit à 100 % en assembleur non documenté avec des labels comme lbl0. Il se soucie de l’exactitude, des performances et de l’expérience utilisateur »
  Mais l’ingénierie logicielle permet justement d’atteindre plus facilement ces objectifs et de maintenir la qualité à un bon niveau
  Le problème, c’est que cette voie aussi peut dériver vers le cargo cult et la sur-ingénierie, et j’en suis moi-même clairement coupable
  Malgré tout, il faut au final livrer une vraie valeur aux utilisateurs

• Comme chez Boeing et Airbus, il existe des résultats optimaux démontrables
  La question n’est pas de savoir pourquoi les avions des deux entreprises se ressemblent autant, ni qui a conçu quoi en premier ou qui a copié qui
  Personne n’a copié : les meilleurs ingénieurs du monde, répartis dans des équipes différentes, conçoivent sous les mêmes contraintes, et tout design qui s’en écarte devient par définition inférieur
  Il faut se situer sur la frontière de Pareto, sinon on se fait éliminer
  Dans notre domaine aussi, il existe quelque part un optimum ; la question est de savoir si l’on dispose des outils, du budget et des bonnes personnes pour l’atteindre, et s’il y a assez d’utilisateurs pour pouvoir déterminer si on l’a effectivement atteint ou non