Créer des applis IA que les gens adorent : leçons du studio

Une appli IA est facile à commencer et difficile à bien finir. La démo marche du premier coup, les captures d’écran ont l’air magiques, puis vous passez les six mois suivants sur les parties ingrates : ce qui se passe quand le modèle se trompe, comment quelqu’un comprend l’appli dans les trente premières secondes, ce que vous facturez, et ce à quoi vous dites non. Chez Sépia, un petit studio à Montréal, nous concevons et lançons des applis IA ciblées de bout en bout — MyoScore, PrettyType, Debate — et l’essentiel de ce que nous avons appris à la dure se trouve dans les articles rassemblés ici. Ceci est la vue d’ensemble. Les analyses détaillées, c’est là que sont les détails.

Si vous êtes un créateur qui lance avec une petite équipe, le piège n’est pas le manque d’idées. C’est l’inverse. L’IA rend presque n’importe quelle fonctionnalité atteignable, donc la discipline passe de peut-on la construire à devrait-on, et qu’est-ce que sa maintenance nous coûte. Tout ce qui suit découle de cette question.

Le focus bat l’étendue, à tous les coups

Les décisions les plus coûteuses que vous prenez sont les fonctionnalités que vous gardez. Chacune ajoute de la surface à tester, à présenter, à expliquer et à maintenir — pour toujours. Les petites équipes ne perdent pas parce qu’elles construisent trop peu ; elles perdent parce qu’elles s’éparpillent et livrent six choses médiocres au lieu d’une seule réellement bonne.

Nous avons écrit sur pourquoi les applis ciblées battent les applis surchargées, et la version courte, c’est que le focus est une fonctionnalité que les utilisateurs ressentent. Un outil qui fait une chose clairement gagne la confiance plus vite qu’une suite qui en fait dix correctement. Le revers est opérationnel : une appli ciblée est quelque chose qu’une petite équipe peut réellement lancer et maintenir en vie sans s’épuiser. La contrainte n’est pas une limite. C’est la stratégie.

• Coupez tôt, pas tard. La fonctionnalité dont vous doutez sera celle qui vous noiera dans les cas particuliers.
• La profondeur plutôt que l’étendue. Un flux de travail qui semble fini bat cinq qui semblent en bêta.
• Dites non officiellement. Notez ce que l’appli n’est pas, pour que la dérive du périmètre ait quelque chose à quoi se heurter.

Le modèle est un composant, pas le produit

Voici l’erreur que nous voyons le plus : traiter le modèle comme l’expérience entière. Ce n’est pas le cas. Le modèle est une partie — une partie puissante et imprévisible — logée à l’intérieur d’un produit fait d’interface, de textes, de réglages par défaut, d’états d’erreur, et des mille petits choix qui décident si quelqu’un fait confiance au résultat.

Les utilisateurs ne font pas l’expérience de votre modèle. Ils font l’expérience de votre appli un mauvais jour : la réponse lente, la réponse fausse avec assurance, le résultat dont ils ne peuvent pas dire s’il est juste. Le vrai travail consiste donc à concevoir autour d’un résultat imparfait — et c’est le cœur de concevoir des fonctionnalités IA dignes de confiance, auxquelles les gens croient vraiment. La confiance n’est pas une promesse marketing. Elle se construit à partir de l’honnêteté sur l’incertitude, d’un échec gracieux, et du fait de donner aux gens un moyen de vérifier ou de corriger ce que le modèle a produit.

Une fonctionnalité IA qui a raison 90 % du temps et qui est honnête sur les 10 % restants bat une fonctionnalité qui a raison 95 % du temps et reste silencieuse quand elle se trompe. Les utilisateurs pardonnent les erreurs qu’ils voient venir. Ils ne pardonnent pas d’avoir été induits en erreur.

L’IA change les règles du design

Le design mobile classique suppose un résultat déterministe : on appuie sur un bouton, on obtient un résultat connu. L’IA brise cette hypothèse. Les réponses varient, la latence est réelle, et l’écran doit communiquer la confiance, la progression et le raté occasionnel — sans donner l’impression que tout est fragile.

Ce changement touche tout, des états de chargement à la façon de présenter un résultat dont vous n’êtes pas tout à fait sûr, c’est pourquoi nous lui avons consacré un article dédié sur comment l’IA réécrit les règles du design mobile. Quelques principes sur lesquels nous revenons sans cesse :

• Concevez pour l’attente. La latence fait désormais partie de l’UX. Faites-la paraître intentionnelle, pas cassée.
• Montrez votre niveau de confiance. Laissez l’interface signaler quand le résultat est solide par opposition à une meilleure estimation.
• Rendez la correction peu coûteuse. Plus il est facile de corriger ou de régénérer, moins une mauvaise réponse vous coûte en confiance.

Onboarding et prix : là où les bonnes applis meurent en silence

Vous pouvez construire une appli ciblée, digne de confiance et bien conçue, et perdre quand même des gens dès la première minute — ou ne pas gagner un sou avec ceux qui restent. L’onboarding et le prix sont les deux endroits où la majeure partie de la valeur soit se concrétise, soit s’échappe, et tous deux reçoivent bien moins d’attention qu’ils ne le méritent.

L’onboarding d’une appli IA est un problème à part entière, car vous n’enseignez pas seulement la navigation, vous fixez les attentes sur ce que le modèle peut et ne peut pas faire. Promettez trop et la première mauvaise réponse ressemble à une trahison ; promettez trop peu et les gens ne voient jamais la magie. Nous abordons cet équilibre dans l’onboarding d’une appli IA sans perdre son public — amener les utilisateurs à une vraie victoire rapidement, avant que les explications ne commencent.

Le prix, c’est là que les créateurs indépendants flanchent le plus, surtout quand il y a un coût par requête derrière chaque interaction. Sous-facturez et vous subventionnez vos propres utilisateurs jusqu’à la ruine ; compliquez trop et personne ne convertit. Notre point de vue sur fixer le prix d’une appli indépendante sans flancher consiste à facturer pour la valeur que vous livrez, à rester honnête sur votre économie unitaire, et à ne pas s’excuser d’avoir besoin que l’activité fonctionne.

Décider quoi construire ensuite

La feuille de route de tout studio est en réalité une série de paris. Avec une petite équipe et des coûts réels par fonctionnalité, se tromper deux fois de suite peut couler un trimestre. Le plus difficile n’est pas de générer des idées — c’est d’avoir un processus assez honnête pour tuer celles qui ne rapporteront pas, y compris celles auxquelles vous tenez personnellement.

Nous avons exposé notre cadre réel dans comment nous décidons quoi construire ensuite : comment nous pesons l’attrait pour l’utilisateur face au coût de maintenance, comment nous distinguons une demande bruyante d’un vrai besoin, et pourquoi ne pas construire quelque chose est souvent la décision au plus fort levier que vous prendrez de tout le mois. Cela relie le reste : focus, confiance et économie apparaissent tous au moment où il faut choisir.

Par où commencer

Si vous débutez et que vous cherchez à savoir si vous pouvez seulement lancer cela avec l’équipe dont vous disposez, commencez par ce qu’il faut pour lancer avec une petite équipe. Si vous avez déjà quelque chose en ligne et que vous luttez contre les mauvaises réponses et une confiance tiède, allez directement à concevoir des fonctionnalités IA dignes de confiance. Rien de tout cela n’est de la théorie. C’est le résidu de vrais lancements d’applis, de ce que nous avons raté en partie, et de ce que nous avons noté que nous ferions différemment — pour que vous puissiez éviter quelques-unes des erreurs que nous n’avons pas évitées.