Cet article a été écrit à l’origine en italien par Paolo Gambardella. Il a été traduit par un agent d’intelligence artificielle et peut contenir des inexactitudes.
Andrew Kelley, le créateur du langage de programmation Zig, a ouvert une conférence avec une question qui dérange : à qui sert vraiment le logiciel qu’on écrit ? La conférence s’intitule “Don’t Take the Black Pill” et elle s’adressait à une salle de développeurs, pas de game designers. Mais c’est exactement la question qu’on devrait se poser chaque fois qu’on conçoit un système de progression.
Un critère plus honnête que le “fun”
La Self-Determination Theory de Deci et Ryan dit qu’une personne va bien — dans un jeu comme dans la vie — quand trois besoins sont satisfaits : l’autonomie (mes choix ont un impact), la compétence (je progresse, et je le vois) et la relation (je ne suis pas seul). Un système peut afficher des métriques de rétention impeccables et pourtant nier les trois à la fois. Ça a un nom : la coercive retention. La progression est là, mais le joueur revient parce qu’un timer expire ou qu’une notification le rappelle, pas parce qu’il a envie de replonger dans le jeu.
Du coercionware, même hors des jeux
Kelley appelle cette catégorie “coercionware” : des logiciels dont le but n’est pas de servir leurs utilisateurs, mais de les manipuler. Les exemples qu’il cite ne viennent pas des jeux — notifications push non sollicitées, A/B tests qui optimisent le clic plutôt que l’expérience, algorithmes de recommandation qui courent après l’engagement au lieu de la valeur. Ce qui m’a frappé, c’est qu’il décrit tout ça comme un choix de design, pas comme un effet de bord. Quelqu’un, en réunion, a décidé que c’était acceptable.
Le même problème, autre étiquette
Dans les jeux, on lui donne d’autres noms : gacha, événements limités dans le temps, season pass conçus pour mettre la pression. Mais c’est le même mécanisme : on retire de l’autonomie pour garantir un retour. J’en parlais la semaine dernière à propos de la dopamine et de l’ocytocine — la relation dans la Self-Determination Theory, c’est au fond le même sujet que l’ocytocine. Un joueur qui revient pour retrouver un univers ou d’autres personnes n’a pas besoin d’être retenu par un timer.
L’habitude qui aide
Il y a une habitude simple que j’applique quand j’évalue une nouvelle feature : jouer l’avocat du diable avec moi-même. Partir du principe qu’elle échoue, et me demander pourquoi. La liste des raisons inclut en général des choses comme “ça perturbe le joueur” ou “ça ne convertit pas assez”. Ça vaut le coup d’en ajouter une : elle échoue parce qu’elle manipule au lieu de servir. Ce n’est pas une question qui émerge toute seule dans une réunion de roadmap. Il faut la poser délibérément, avant de livrer.
La prochaine fois qu’une feature améliore les chiffres, la bonne question n’est pas de savoir si elle fonctionne. C’est de savoir si le joueur la choisit, ou s’il s’est retrouvé coincé dedans.