De Novai a TAMSIV : renommer une app en solo

Points clés à retenir : Renommer une application entière (monorepo, package Android, deep links, backend, configs) est un chantier massif — 847 lignes modifiées dans 73 fichiers. La clé : procéder par couches (package Android d'abord, puis configs, puis code source, puis commentaires), tester chaque couche avant de passer à la suivante, et ne surtout pas repousser cette décision. Plus tu attends, plus c'est douloureux.

Il y a des décisions qu'on repousse pendant des semaines. Renommer une application entière, c'est l'une d'elles. Mais fin novembre 2025, j'ai compris que Novai devait mourir pour que TAMSIV naisse. Le nom ne fonctionnait pas, le produit méritait mieux, et chaque jour de retard rendait le chantier plus gros.

Voici le récit complet de ce rebranding en solo — du brainstorming initial au commit final.

Pourquoi le nom Novai ne fonctionnait-il pas ?

Novai, c'était censé évoquer "nouvelle IA". En théorie, ça marchait. En pratique, personne ne faisait le lien. Les retours étaient unanimes :

• Générique : "Novai" ressemble à des dizaines d'autres produits tech. Essaie de googler "Novai" — tu tombes sur des cabinets de conseil, des startups IA, des logiciels SaaS. Impossible de se démarquer.
• Pas mémorable : le nom ne dit rien sur le produit. Une app de productivité vocale ? Un chatbot ? Un outil de data ? Novai pouvait être n'importe quoi.
• Pas de story : un bon nom raconte quelque chose. Novai ne raconte rien.

J'avais besoin d'un nom qui porte le concept. Pas juste un son agréable — un nom qui soit en lui-même un pitch.

Comment le nom TAMSIV est-il né ?

TAMSIV est un acronyme : Tâches Assistées par Mémos Synchronisés, Intelligence Vocale. Chaque lettre décrit une fonctionnalité :

• TA — Tâches : le cœur de l'app, la gestion de tâches
• M — Mémos : les notes vocales structurées par l'IA
• S — Synchronisés : la dimension collaborative et multi-device
• IV — Intelligence Vocale : la voix comme interface principale

Le nom EST le pitch. En 6 lettres, tu sais ce que fait l'application. C'est ce qu'on appelle un nom descriptif — par opposition aux noms évocateurs (comme Apple) ou arbitraires (comme Kodak).

Avantage supplémentaire : "TAMSIV" est unique. Zéro résultat Google avant le lancement. Le SEO part de zéro, mais au moins il n'y a pas de compétition sur le terme. Pour un dev solo, c'est crucial — pas de budget pub pour surpasser un homonyme.

Comment planifier un renommage dans un monorepo ?

Le monorepo TAMSIV a trois composants : frontend/ (React Native), backend/ (Node.js/Express) et website/ (Next.js). Plus de 400 fichiers contenaient "novai" sous différentes formes : novai, Novai, NOVAI, novai://, com.novai.

J'ai procédé par couches, de la plus critique à la moins critique :

1. Couche 1 — Package Android : com.novai → com.tamsiv. C'est la fondation. Si ça casse, plus rien ne compile.
2. Couche 2 — Fichiers de config : build.gradle, package.json, .env, Firebase configs, Supabase URL.
3. Couche 3 — Code source : imports, références, noms de services, endpoints.
4. Couche 4 — Commentaires et docs : README, CHANGELOG, commentaires dans le code.

Chaque couche était testée individuellement avant de passer à la suivante. Ça évite le scénario cauchemar : 400 fichiers modifiés d'un coup, un build qui échoue, et aucune idée de quel changement a causé le problème.

Quels sont les pièges techniques d'un renommage Android ?

Le build.gradle Android utilise le package name à six endroits différents :

• applicationId — l'identifiant unique sur le Play Store
• namespace — le namespace Java/Kotlin pour la génération de code
• manifestPlaceholders — les variables injectées dans AndroidManifest.xml
• signingConfigs — la configuration de signature (keystore)
• resValue — les ressources injectées à la compilation
• buildConfigField — les constantes de build

En oublier un seul, et le build échoue avec un message d'erreur cryptique. J'ai vérifié chaque occurrence manuellement.

Les deep links sont un autre piège. TAMSIV utilise le scheme tamsiv:// pour les liens de parrainage (tamsiv://invite/{code}). Avant le renommage, c'était novai://. La migration doit être propre — pas de période de transition où les deux schemes coexistent, ça crée de la confusion.

Comment gérer le renommage côté backend et infrastructure ?

Le backend n'est pas épargné :

• Logs : chaque log contenait "Novai" en préfixe. Migration vers "TAMSIV".
• Messages d'erreur : les messages user-facing ("Bienvenue sur Novai") doivent correspondre au nouveau nom.
• Variables d'environnement : NOVAI_DB_URL → TAMSIV_DB_URL (même si techniquement, ça change rien, la lisibilité compte).
• Railway : le service s'appelait "novai-backend". Renommage dans le dashboard Railway.
• Supabase : le projet restait le même (les URLs Supabase ne changent pas), mais les commentaires dans les migrations référençaient "Novai".

Côté website, le chantier était similaire : meta tags, Open Graph, footer, mentions légales, CGU, politique de confidentialité — tout ce qui mentionnait "Novai" devait passer à "TAMSIV".

Comment vérifier qu'aucune référence n'a été oubliée ?

Après le renommage, j'ai exécuté un grep -ri "novai" . sur tout le repo. Résultat : zéro occurrence. C'est la seule façon d'être sûr.

Mais le grep ne suffit pas. Il faut aussi :

• Build Android complet : gradlew assembleDebug puis gradlew assembleRelease
• Tests backend : npm test pour vérifier que les endpoints fonctionnent
• Build website : npm run build pour vérifier que Next.js compile sans erreur
• Test des deep links : vérifier que tamsiv://invite/test ouvre bien l'app
• Firebase : vérifier que le google-services.json correspond au nouveau package

J'ai tout fait dans l'ordre. Le build Android a échoué au premier essai — un import com.novai.BuildConfig oublié dans un fichier Java généré. Corrigé, rebuild, OK.

Quel impact un renommage a-t-il sur le Play Store ?

Changer le applicationId signifie créer une nouvelle application sur le Play Store. C'est le point le plus important à comprendre : Google identifie les apps par leur applicationId, pas par leur nom. com.novai et com.tamsiv sont deux apps différentes aux yeux du store.

Conséquences :

• Les notes et avis repartent à zéro
• Les installations ne sont pas transférées
• Les utilisateurs existants doivent réinstaller (ou tu gères une migration côté serveur)

Pour TAMSIV, c'était acceptable — l'app était en alpha avec quelques testeurs. Si tu as des milliers d'utilisateurs, réfléchis très sérieusement avant de changer d'applicationId. Tu peux changer le nom affiché sans toucher au package.

Quelles leçons retenir de ce rebranding ?

Voici les leçons que j'en tire, après 847 lignes modifiées dans 73 fichiers :

1. Fais-le tôt : plus tu attends, plus c'est douloureux. Si ton nom te gêne après 3 mois, il te gênera encore dans un an — avec 10x plus de fichiers à modifier.
2. Un bon nom est un investissement : un nom qui raconte ton produit, c'est du marketing gratuit. TAMSIV se vend tout seul en explication.
3. Procède par couches : du plus critique au moins critique. Teste chaque couche. Ne fais pas un méga-commit de 400 fichiers.
4. Grep est ton ami : un grep -ri final est obligatoire. L'œil humain rate des choses, le regex non.
5. Zéro fonctionnalité nouvelle : accepte que cette journée ne produit rien de visible pour l'utilisateur. C'est de la dette technique payée d'avance.

Comment choisir un bon nom pour ton app ?

Si tu es dans la phase de choix de nom, voici mes critères :

• Googleable : le nom doit être unique. Tape-le dans Google avant de t'engager.
• Prononçable : si les gens ne peuvent pas le dire à voix haute, ils ne le recommanderont pas.
• Descriptif ou mémorable : soit le nom décrit le produit (TAMSIV), soit il est tellement unique qu'il reste en tête (Spotify).
• Disponible : domaine, package Android, username sur les réseaux sociaux. Vérifie tout avant de choisir.
• Court : 6 lettres maximum idéal. Au-delà, ça devient difficile à retenir et à taper.

Des outils comme Namelix ou NameMesh peuvent aider au brainstorming, mais la décision finale est toujours humaine. Mon conseil : demande à 5 personnes de répéter le nom après l'avoir entendu une seule fois. Si 4 sur 5 le retiennent, c'est un bon signe.

Le renommage a-t-il changé quelque chose pour le produit ?

Oui, et pas que techniquement. Avoir un nom qui porte du sens a changé ma façon de parler du produit. En build in public, quand je dis "TAMSIV — Tâches Assistées par Mémos Synchronisés, Intelligence Vocale", les gens comprennent immédiatement. Avec "Novai", je devais toujours expliquer.

Le parcours de 650+ commits de TAMSIV est indissociable de cette décision. Le renommage n'est pas un détail technique — c'est un moment fondateur. L'app a trouvé son identité ce jour-là.

Une journée pour zéro fonctionnalité nouvelle. Mais TAMSIV avait enfin son nom.

FAQ

Combien de temps dure un renommage complet d'application ?

Pour TAMSIV (monorepo avec frontend React Native, backend Node.js et website Next.js), ça a pris une journée complète. Le volume : 847 lignes modifiées dans 73 fichiers. Le temps dépend principalement du nombre de composants et de la taille du codebase.

Peut-on renommer une app déjà publiée sur le Play Store ?

Tu peux changer le nom affiché (titre) sans problème. Mais changer le applicationId (com.example.app) crée une nouvelle application aux yeux de Google. Les avis, installations et classement ne sont pas transférés. Pour une app en production avec des milliers d'utilisateurs, c'est rarement recommandé.

Faut-il un acronyme pour un bon nom d'application ?

Non, c'est un choix parmi d'autres. L'acronyme fonctionne quand chaque lettre a un sens clair et que le mot résultant est prononçable. "TAMSIV" passe ce test. Mais des noms comme "Notion" ou "Linear" fonctionnent aussi très bien sans être des acronymes.

Comment éviter de casser les liens existants après un renommage ?

Si tu as des deep links, des liens partagés ou des QR codes en circulation avec l'ancien scheme, tu dois maintenir une redirection temporaire. Pour les URLs web, un redirect 301 fait l'affaire. Pour les deep links mobiles, tu peux déclarer les deux schemes dans le manifest pendant une période de transition.

Le rebranding impacte-t-il le SEO ?

Pour le site web, oui. Si tu changes de domaine, il faut des redirections 301 propres et prévenir Google via la Search Console. Si tu gardes le même domaine (comme TAMSIV), l'impact est minime — il suffit de mettre à jour les meta tags et le contenu. Le nouveau nom sera indexé en quelques jours.