Une application, une tâche : pourquoi je ne construis pas de super-app

Je reçois une version de cette suggestion tous les quelques mois : « Tu devrais regrouper le budget, l’hydratation et les rappels dans une seule application — plus de valeur par installation, une seule connexion, plus de temps d’écran. » Ce n’est pas une mauvaise idée dans l’abstrait. Ce n’est simplement pas ce que je construis, et les raisons méritent d’être écrites, parce que ce sont les mêmes raisons qui guident chaque décision que je prends pour chaque application de la gamme.

La pression de fusionner est réelle, et elle ne concerne pas l’utilisateur

Les super-apps n’apparaissent pas parce que quelqu’un s’est assis pour concevoir la meilleure expérience possible pour suivre votre consommation d’eau et votre liste de courses au même endroit. Elles apparaissent parce que la fusion est bonne pour l’entreprise, pas pour la personne qui tient le téléphone. Une installation au lieu de six. Une connexion autour de laquelle construire un profil. Une icône d’application qui rivalise pour une place sur l’écran d’accueil au lieu de six. Chaque métrique de croissance s’améliore quand tout vit sous le même toit.

Rien de tout cela n’est malveillant. Cela optimise simplement autre chose que « est-ce que ceci t’aide à terminer la tâche et à reposer le téléphone ». Un écran de suivi des courses enterré à trois onglets de profondeur dans une application de finance n’est pas plus utile parce qu’il partage une connexion avec votre budget — il est simplement plus difficile à trouver.

Ce qu’une application fusionnée coûte réellement à celui qui l’utilise

Ouvrez une vraie super-app et le signe est toujours le même : un écran d’accueil encombré d’icônes pour des fonctionnalités que vous n’avez jamais touchées, des demandes de permission pour des choses sans rapport avec ce pour quoi vous l’avez ouverte, et une barre de recherche parce que la navigation a cessé de fonctionner comme une carte depuis longtemps. L’application se souvient de vous, mais vous ne pouvez plus vous souvenir d’elle — à quoi elle sert, où les choses se trouvent, ce qu’elle va vous demander ensuite.

Il y a aussi un coût plus subtil. Mélanger les domaines mélange les données. Une application de rappels qui fait aussi du budget doit décider ce qu’une « notification » signifie même à travers deux tâches sans rapport, et la réponse est généralement un écran de réglages avec quarante interrupteurs que personne ne lit. Chaque fonctionnalité que vous n’utilisez pas est toujours là, toujours chargée, toujours une permission que l’application a demandée et que vous avez accordée sans vraiment le vouloir.

Ce que ça coûte à celui qui la construit

Cette partie est souvent oubliée quand on évalue les super-apps de l’extérieur, mais c’est la moitié dans laquelle je vis réellement. Je suis une seule personne. Granyn qui suit vos dépenses et Hydrame qui vous rappelle de boire de l’eau n’ont rien à voir l’un avec l’autre — modèles de données différents, cadence de notification différente, cas limites différents, personnes différentes qui les utilisent pour des raisons différentes à des moments différents de la journée. Les assembler dans une seule base de code n’économise pas d’effort ; ça le multiplie. Une version pour le rappel d’hydratation doit maintenant être testée aussi contre l’écran de budget, parce qu’ils partagent un binaire. Un plantage dans une fonctionnalité fait tomber toute l’application dans les rapports de plantage du store, brouillant le signal pour les deux. L’intégration doit expliquer deux choses sans rapport à quelqu’un venu pour une seule.

Des applications petites et séparées signifient qu’un bug dans l’une a un rayon d’impact d’exactement une application. Une décision de conception que je regrette me coûte une seule réécriture, pas une migration à travers six ensembles de fonctionnalités sans rapport boulonnés sur une coquille partagée. Et surtout : je peux dire non à une demande de fonctionnalité pour Granyn sans que cela devienne un débat sur son appartenance à « l’application », parce qu’il n’y a qu’une seule chose que Granyn est.

Le test que j’utilise réellement

Avant d’ajouter quoi que ce soit, je pose une question simple : un inconnu pourrait-il expliquer ce que fait cette application à partir de son icône et de son nom seuls, après l’avoir utilisée une fois ? Si la réponse commence à avoir besoin d’un « eh bien, elle fait aussi— », c’est que cette fonctionnalité appartient à une autre application, ou n’appartient nulle part. C’est pourquoi OldSchool ne fait que des rappels de médicaments, Stocky ne suit que ce qu’il y a dans votre cuisine, et Mintly est un minuteur de concentration et rien d’autre. Pas parce qu’il me manque des idées pour ce qu’elles pourraient faire d’autre, mais parce que chaque « aussi » est une petite taxe sur la seule chose que l’application faisait vraiment bien.

Où le partage a du sens

Rien de tout cela ne signifie que les applications sont construites isolément les unes des autres. Elles partagent un langage de design, donc passer de l’une à l’autre ne donne pas l’impression de réapprendre un logiciel. Elles partagent la même architecture local-first, sans compte, donc l’histoire de confidentialité est identique partout. Elles partagent des bibliothèques internes pour des choses comme la planification des notifications et la sauvegarde/exportation, parce que c’est de la plomberie, pas une fonctionnalité entre laquelle un utilisateur choisit. Ce qu’elles ne partagent pas, c’est une seule base de données, un seul flux d’intégration, ou une seule raison d’ouvrir l’application. Cette ligne — infrastructure partagée, but séparé — c’est toute la stratégie.

Une super-app est un pari que la commodité l’emporte sur la clarté. Je parie dans l’autre sens : qu’une application que vous comprenez entièrement en cinq secondes vaut plus qu’une application qui fait cinq choses de plus que vous n’utiliserez qu’une fois.