Ce que nous avons appris en construisant une plateforme d’optimisation automatisée pour les stores

La façon dont une application est trouvée dépend en partie des mots et des images de sa fiche. Pourtant, beaucoup de développeurs indépendants et de petits studios n’avaient aucun processus pour les améliorer. Des outils sérieux existaient pour les gros éditeurs ; les autres travaillaient au tableur occasionnel et à l’intuition.

Le travail est aussi plus large qu’il n’y paraît. Le faire correctement voulait dire répéter six tâches distinctes, dans chaque pays qui comptait :

TapTimize essayait de compresser tout cela en un seul flux de travail. L’argument n’a jamais été qu’un algorithme comprenait votre application mieux que vous. C’était qu’un logiciel pouvait rassembler et organiser assez d’éléments pour qu’une petite équipe prenne une décision correcte chaque semaine plutôt qu’une fois par an.

Ce que les gens voyaient était un tableau de bord Angular. Le plus dur était derrière. Les fiches et les résultats de recherche devaient être collectés pays après pays, transformés en enregistrements cohérents, et revisités assez souvent pour bâtir un historique de classement digne d’être lu.

Dessous tournaient une API Node.js, MongoDB, RabbitMQ et des services Python pour l’analyse, avec Kubernetes et Terraform pour décrire la production et une chaîne CI/CD pour rendre les changements fréquents moins effrayants. Cela paraît beaucoup pour un produit à ses débuts, et ça l’était. Mais le travail était réellement un tas de tâches indépendantes, dont chacune pouvait être lente ou échouer pour des raisons totalement extérieures à notre code.

La file d’attente rendait cette frontière honnête. L’API n’avait pas à attendre pendant que chaque mot-clé de chaque marché était vérifié. Les workers pouvaient réessayer, monter en charge séparément et sauvegarder un travail partiel. Si vous collectez des données chez quelqu’un d’autre, modélisez cela comme des tâches dès le premier jour ; le rattraper plus tard est pénible.

Une position un jour donné n’est qu’une observation. Elle devient une preuve quand vous pouvez y rattacher un pays, une langue, un appareil, un store, les concurrents autour, la version de la fiche alors en ligne et la date de votre dernier changement. Sans cela, un graphique encourage surtout des récits que les données ne soutiennent pas.

Le produit avait donc besoin d’historique plutôt que d’instantanés. Le mouvement a-t-il tenu ? Des termes voisins ont-ils bougé ensemble ? Un changement a-t-il aidé dans un pays sans rien faire dans un autre ?

Et le classement n’a jamais été l’objectif réel. Une meilleure visibilité amène plus de monde sur la fiche ; l’icône, les captures, les avis et la qualité de l’application décident de la suite. Apple et Google rendent aujourd’hui cette séparation plus nette avec les tests de fiche produit et les expériences de listing. Être trouvé et être installé sont liés, mais ce sont deux problèmes différents.

Trouver davantage de mots-clés, comparer les concurrents, collecter les classements et vérifier qu’un titre tient dans la limite de caractères sont de bons candidats à l’automatisation. C’est répétitif, bien défini, et cela s’améliore quand la même méthode est appliquée systématiquement.

Écrire toute la fiche sans que personne ne la lise, c’est autre chose. Un modèle peut croiser votre vocabulaire avec ce que les gens cherchent, mais il ne sait pas quelles promesses sont vraies, quel bénéfice compte le plus pour votre client, ni quelle tournure sonne naturelle au Brésil. La version qui fonctionne génère des propositions et montre les éléments qui les justifient, puis laisse une personne décider.

Cette frontière vous garde aussi honnête. Répéter une expression populaire ne sert à rien si l’application ne fait pas ce que les gens cherchaient. Une fiche a deux publics, le moteur de recherche et l’humain qui décide d’installer, et tromper l’un ou l’autre cesse vite de fonctionner.

Les gens ne cherchent pas de la même façon selon l’endroit. Deux pays peuvent décrire la même tâche avec des mots complètement différents, même quand votre traduction est parfaite. L’encombrement d’un terme et le volume de recherche changent aussi, si bien qu’un mot sans espoir sur un marché peut être une victoire facile sur un autre.

TapTimize traitait chaque langue comme un problème d’optimisation à part entière. Cela faisait plus de données à collecter et plus de textes à gérer, mais cela évitait qu’une liste de mots-clés anglaise soit déguisée en réponse mondiale.

C’est encore vrai avec les outils actuels. Apple permet de localiser les fiches produit et d’orienter des fiches personnalisées vers des contenus et des mots-clés précis ; Google Play prend en charge les fiches localisées et les expériences. La mécanique a évolué, mais la bonne habitude n’a pas changé : associer quelqu’un qui connaît la langue à des chiffres venant de ce marché.

Nous avons commencé à facturer pendant la bêta. Le mémoire de 2018 qui documente le produit relève un revenu mensuel passant d’environ 500 $ à 3 246 $ à la fin mai. Des chiffres petits, de première main, non audités, mais suffisants pour montrer que le problème valait qu’on paie pour le résoudre.

Les clients payants posent des questions complètement différentes de celles des curieux. Ces données datent de quand ? Pourquoi mon marché manque-t-il ? Pourquoi devrais-je croire cette recommandation ? Est-ce que ça me fait gagner assez de temps pour justifier la facture ? C’est cette pression qui a transformé un algorithme malin en quelque chose qui ressemblait à une entreprise.

Je ne cite pas de clients ici. La partie transposable est l’habitude : mesurer ce qui s’est passé, dire d’où vient le chiffre, et ne jamais présenter un bon résultat comme s’il s’agissait d’une prévision.

TapTimize s’est ensuite éloigné des stores vers un simple outil de suivi de position web, avant de fermer. Une rétrospective doit le dire simplement. Un logiciel peut résoudre un vrai problème, trouver des gens prêts à payer, et ne pas devenir pour autant l’entreprise que ses fondateurs voulaient ni un marché capable de la porter.

Ce qui est resté, c’est la boucle complète : prendre une pratique marketing floue, la transformer en tâches qu’une machine peut faire, construire le système qui collecte et analyse, le facturer, écouter ceux qui paient, et changer de direction quand la forme initiale n’a plus de sens.

Si vous construisez aujourd’hui quelque chose de riche en données, c’est la partie à emporter. Un tableau de bord se redessine. Savoir de quelles preuves votre client a réellement besoin, les collecter de façon fiable et rester honnête sur l’endroit où l’automatisation s’arrête, voilà la compétence difficile.