Ce qui doit être vrai avant qu'on ajoute de l'IA à une app

Ton iPhone est plein de choses que tu y as mises. Des recettes capturées depuis une page web. Des listes à moitié faites dans Notes. Un PDF que quelqu’un t’a envoyé par mail. Une photo d’un entraînement écrit sur un tableau blanc. Un mémo vocal de toi en train de te raconter comment tu factures un client. C’est déjà là. Tu l’as mis là parce que c’est là que ça va.

Alors quand une nouvelle app arrive qui pourrait en théorie utiliser tout ça, la question n’est pas de savoir si l’app est bonne. La question est de savoir si elle peut venir te chercher là où tes affaires vivent déjà, ou si elle s’attend à ce que tu retapes tout depuis le début. Une app qui te fait retaper une recette que tu as déjà capturée, ou relister les étapes que tu as déjà écrites dans Notes, te demande un travail qui n’a rien à voir avec ce que tu essaies vraiment de faire. Les données sont là. C’est l’app qui est l’obstacle.

C’est à ça que servent vraiment les fonctions d’IA, quand elles servent à quelque chose. Pas à impressionner. Pas pour le discours marketing. À combler l’écart entre ce que la personne a déjà et ce que la nouvelle app a besoin que ce soit.

Les fonctions d’IA qui débarquent dans les apps en ce moment ne manquent pas. Beaucoup sont bonnes. Beaucoup sont là parce que les investisseurs veulent les voir, ou parce que l’équipe avait un quota, ou parce que tous les autres le font et ne pas en avoir a commencé à ressembler à un problème. On est un petit studio. On n’a pas ces pressions, et on n’a pas la bande passante pour construire des fonctions pour une autre raison que parce qu’elles aident. Alors on a mis par écrit ce qu’une fonction d’IA doit être pour entrer ne serait-ce que dans une app de Gums & Bones.

Il y a trois choses, et chacune est un non net si elle échoue.

La première, c’est qu’elle doit aider la personne à faire ce pour quoi l’app est faite. Patter existe pour aider les gens à construire des routines et laisser ces routines devenir des habitudes. Une fonction d’IA dans Patter doit pousser dans ce sens — rendre le démarrage d’une routine plus facile, en affiner une, te débloquer face à l’écran blanc. Permettre à quelqu’un de donner à Patter une page web, une note ou la photo d’une liste et de récupérer un brouillon de routine qu’il peut éditer, ça colle. Un générateur qui ferait une jolie icône pour chaque routine, non. Pas parce que c’est mauvais. C’est bien. C’est juste que ça n’a rien à voir avec la raison pour laquelle quelqu’un ouvre Patter. Chaque app qu’on fait a un but, assez étroit pour tenir sur une carte postale, et une fonction d’IA sert ce but, sinon elle n’entre pas.

La deuxième, c’est qu’elle doit s’inscrire dans la façon dont on construit déjà. Nos apps sont un achat unique, pas d’abonnement, pas de pub, pas de compte, pas d’analytics, pas de cloud. Visser dessus une fonction d’IA qui ferait discrètement sauter l’un quelconque de ces points aurait défait le reste du studio. Donc la fonction doit fonctionner à l’intérieur de ces contraintes : sur l’appareil de la personne, payée par nous et pas par elle, sans télémétrie qui remonte.

La troisième, c’est que la personne doit avoir le contrôle complet. L’IA ne tourne jamais en arrière-plan. Elle ne lit jamais quoi que ce soit que la personne ne lui ait pas explicitement remis. Elle ne traite jamais en silence le contenu de la personne pour être « utile ». Elle tourne quand la personne lui demande de tourner, sur le contenu que la personne lui donne, et le résultat est montré à la personne avant que quoi que ce soit ne soit sauvegardé. Il n’y a pas de demi-version de ça. Soit la personne est aux commandes à chaque fois, soit on ne construit pas la fonction. Un résumeur qui lirait en douce tes notes en arrière-plan pour faire émerger des « insights » ne passerait pas, peu importe à quel point ces insights se révéleraient utiles. Tu ne te demanderas jamais si nos apps ont passé un modèle sur tes données sans te le dire. La réponse est non.

Et ce que l’IA produit est un brouillon que la personne peut regarder, pas un changement sur quoi que ce soit qu’elle avait déjà. On ne réécrit pas le contenu de la personne. La photo, la note, la capture d’écran, le PDF — ce que tu as remis à l’app reste exactement comme c’était. Ce que l’IA sort est une chose à part, posée à côté de l’original, à toi de la garder ou de la jeter.

Voilà les trois. But, intégration, contrôle. La plupart des idées de fonctions d’IA — la plupart des nôtres y compris — ne passent pas les trois, et c’est tout l’intérêt de les avoir mises par écrit. La liste est là pour dire non.

Il y a une quatrième chose qui n’est pas un critère mais qui compte autant que les critères. Quelle IA une fonction utilise est en soi une décision de design. En ce moment, le modèle d’Apple sur l’appareil est la seule option qu’on connaisse qui nous laisse respecter les trois règles ci-dessus sans une longue liste de compromis. Il tourne sur l’appareil de la personne, il ne nous coûte rien à utiliser, il ne voit pas ce qu’il traite, et Apple n’essaie pas de vendre un palier d’abonnement par-dessus. Il a aussi un accès direct — avec la permission de la personne — aux choses qui sont déjà sur le téléphone, ce qui est toute la raison pour laquelle ça vaut la peine. Si ça change un jour, ou si une meilleure option apparaît qui passe la même barre, on reconsidérera. On n’est pas loyaux à un modèle. On est loyaux aux règles.

Une question raisonnable à ce stade : pourquoi prendre la peine d’écrire ça ? La plupart des studios de notre taille ne publient pas de position sur l’IA. La réponse honnête, c’est qu’on va prendre ces décisions tout seuls, souvent, vite, et pendant longtemps. Mettre les règles sur le papier, c’est surtout pour nous. Ça veut dire que la prochaine fois qu’on est tentés de construire quelque chose parce que ça ferait bien en démo ou parce que tous les autres l’ont sorti, il y a un texte qu’on doit regarder d’abord. Les critères disent non à notre place, pour qu’on n’ait pas à le refaire à zéro chaque fois.

Tu as toute légitimité pour nous y tenir.