Quand un produit en devient deux : comment scinder votre appli créée avec l'IA sans tout recommencer
Votre appli créée avec l'IA a commencé comme un seul produit. Puis vous avez réalisé qu'elle en cachait deux. Voici comment scinder proprement une appli IA — sans abandonner ce que vous avez déjà livré.
Vous êtes parti d’une seule idée. Vous l’avez décrite à votre créateur d’applis avec IA, vous l’avez regardé générer les écrans, vous avez peaufiné les aspérités et livré quelque chose de réel. Les gens ont commencé à l’utiliser. Et puis, doucement au début, un schéma est apparu dans les retours : la moitié de vos utilisateurs voulaient une chose, l’autre moitié en voulait une autre. Ils ne se disputaient pas autour de la même fonctionnalité. Ils réclamaient deux produits différents.
C’est le moment où beaucoup de fondateurs paniquent et démarrent un deuxième projet de zéro. Ils ne devraient pas. Il existe une façon plus propre de scinder une appli IA quand votre produit unique se révèle en être deux — et elle conserve généralement la majeure partie de ce que vous avez déjà construit. Cet article explique comment repérer la scission, quand la faire, et les trois formes qu’elle tend à prendre.
Comment vous découvrez que vous avez deux produits
Le signal ne ressemble presque jamais à une demande de fonctionnalité. Il ressemble à de la friction.
Une appli de productivité que j’ai vue traverser ça avait une histoire claire. Elle était vendue comme un « agenda personnel ». Les utilisateurs ont commencé à se présenter en deux variantes. Un groupe l’utilisait pour planifier sa propre semaine et le traitait comme un carnet privé. L’autre groupe dirigeait de petites équipes et voulait attribuer des tâches à d’autres personnes. Les deux étaient assez contents pour continuer à utiliser le même produit, mais chaque mise à jour ravissait un groupe et agaçait l’autre. L’équipe pensait avoir un problème de priorisation de fonctionnalités. Elle avait en fait un problème de marque. Elle avait une appli perso et une appli d’équipe partageant un seul code, une seule page d’accueil et une seule page de tarifs.
Vous saurez que vous avez franchi cette ligne quand l’un de ces points devient vrai :
- Votre page d’atterrissage doit enfouir sa véritable promesse derrière un langage générique, parce que deux publics ne croiront pas aux mêmes mots.
- Chaque nouvelle fonctionnalité s’accompagne d’un « mais pour l’autre type d’utilisateur, ça devrait marcher différemment ».
- Vos réponses au support se mettent à bifurquer : « si vous l’utilisez pour vous-même… » vs « si vous gérez une équipe… ».
- Un nombre non négligeable d’utilisateurs maintiennent deux comptes distincts pour garder les deux modes séparés.
Si vous observez deux de ces points ou plus, vous n’avez pas un problème de fonctionnalités. Vous avez une scission de produit qui ne demande qu’à se faire.
Les trois formes d’une scission
Vous n’êtes pas obligé de choisir une forme dès le premier jour. Vous pouvez généralement essayer la plus légère d’abord, puis monter en gamme. Mais il est utile de connaître le menu avant de commencer à le décrire à votre créateur d’applis avec IA, parce que les mots que vous emploierez façonneront ce qui sera généré.
Forme 1 : une appli, deux portes
La version la plus légère. Vous gardez un seul code. Vous ajoutez une question au premier lancement — « Êtes-vous ici pour vous-même ou pour une équipe ? » — et vous utilisez la réponse pour afficher un jeu de pages et une navigation différents. Même stockage de données. Même connexion. Même facturation. Juste une surface différente.
La plupart des créateurs d’applis avec IA gèrent bien ça si vous le décrivez comme une « appli à deux modes ». Le point de vigilance, c’est que les deux modes ne doivent pas partager des écrans truffés d’affichages-et-masquages conditionnels. On finit alors avec une seule appli encombrée qui prétend en être deux. Dites au créateur que les deux portes sont séparées — pages d’accueil différentes, pages de paramètres différentes, états vides différents. Les quelques écrans qui se chevauchent vraiment (paramètres du compte, facturation) peuvent être partagés.
Quand ça marche : quand les deux publics veulent un cadrage différent mais les mêmes objets sous-jacents. L’exemple agenda-contre-équipe entre dans cette catégorie. Ce que vous planifiez reste une tâche ; seules changent les règles autour de l’attribution, du partage et de la notification.
Quand ça ne marche pas : quand les deux publics attendent des objets entièrement différents. Un « espace client » et un « outil d’administration interne » n’ont presque aucun recouvrement, même s’ils ont l’air de parler de la même entreprise.
Forme 2 : deux applis, un seul backend
La forme intermédiaire. Vous scindez la façade du produit en deux applis distinctes — deux URL, deux pages d’atterrissage, deux parcours d’accueil, deux grilles tarifaires — mais toutes deux lisent dans la même base de données en dessous. Un client peut avoir un compte sur les deux. Un administrateur peut voir les données des deux.
C’est ce que nous avons fait récemment dans l’entreprise qui édite ce blog. Nous avions une seule appli qui essayait de servir deux publics : les ingénieurs qui évaluaient notre plateforme d’agents, et les créateurs qui utilisaient notre créateur d’applis avec IA. Même backend, même authentification, même base de données — mais la façade s’était dédoublée, et le message était confus. Nous l’avons scindée en deux applis de façade, une pour chaque public. Le backend est resté exactement le même.
Cette forme est la bonne réponse quand :
- Les deux publics achètent pour des raisons différentes.
- Ils seraient déroutés ou rebutés par le message marketing de l’autre public.
- Les données qui les intéressent ont à peu près la même forme, mais sont cadrées différemment.
- Vous ne voulez pas maintenir deux bases de données ni deux dispositifs de facturation.
Dites à votre créateur d’applis avec IA que vous voulez une « deuxième appli de façade qui partage l’API existante ». La plupart des créateurs d’applis avec IA modernes savent échafauder un projet jumeau et le pointer vers votre backend existant. Le piège à éviter : copier-coller les composants de la première appli à l’identique, puis éditer les deux copies à perpétuité. Demandez au créateur d’extraire les parties partagées (écrans d’authentification, widgets de formulaire communs) dans une petite bibliothèque que les deux applis utilisent. Vous vous épargnerez des mois de corrections en double plus tard.
Forme 3 : deux applis, deux backends
La scission la plus lourde. Vous avez réellement deux produits. Ils ne partagent pas de données, ils ne partagent pas d’utilisateurs, et ils ne devraient pas partager de feuille de route. Le bon mouvement est de les séparer entièrement : codes distincts, bases de données distinctes, domaines distincts.
C’est le bon mouvement moins souvent qu’on ne le pense. C’est tentant, parce que ça paraît propre. La réalité, c’est que deux applis totalement séparées, ça veut dire deux fois tout à faire tourner — deux pipelines de déploiement, deux astreintes, deux intégrations de facturation, deux jeux de docs d’aide. Ne vous tournez vers cette forme que si les produits ne se chevauchent vraiment pas. Un bon test : si un utilisateur du produit A ne serait jamais un utilisateur du produit B, vous avez probablement besoin de la Forme 3. Si la plupart de vos utilisateurs pourraient plausiblement vouloir les deux, vous voulez presque certainement la Forme 2.
Quand vous faites ça avec un créateur d’applis avec IA, le plus simple est de copier votre projet existant comme point de départ pour le second, puis de demander au créateur de retirer les fonctionnalités qui n’y ont pas leur place et d’ajouter celles qui doivent y être. Ne démarrez pas le second projet d’une page blanche. Vous avez déjà beaucoup appris en construisant le premier, et le créateur d’applis avec IA captera ce contexte si vous le laissez faire.
Ce qu’il faut faire avant de scinder quoi que ce soit
Avant de décrire la scission à votre créateur d’applis avec IA, faites trois petites choses. Elles valent plus qu’il n’y paraît.
D’abord, écrivez la nouvelle page d’accueil pour chaque côté. Deux paragraphes chacune. La promesse, le public, l’unique chose que vous voulez qu’ils fassent. Si vous ne parvenez pas à écrire deux pages d’accueil différentes, c’est que vous n’avez pas encore vraiment deux produits — vous avez juste deux segments d’un seul produit, et vous devriez régler ça par le message, pas par l’architecture.
Ensuite, listez quels écrans sont partagés et lesquels ne le sont pas. Soyez honnête. « La connexion est partagée. L’accueil est différent. Le tableau de bord est différent. Les paramètres sont en grande partie partagés. La facturation est partagée. » Cette liste devient le brief que vous remettez au créateur d’applis avec IA. Elle évite beaucoup d’allers-retours.
Enfin, décidez ce qui est identique en dessous. Mêmes utilisateurs ? Mêmes données ? Mêmes paiements ? Chaque « oui » vous tire vers la Forme 1 ou 2. Chaque « non » vous tire vers la Forme 3. Il n’y a pas de bonne réponse — seulement celle qui correspond au fonctionnement réel de votre produit.
Ce qui change après la scission
Deux choses deviennent plus faciles et une chose devient plus difficile.
Le marketing devient plus facile. Chaque appli a sa propre promesse claire. Chaque page d’atterrissage peut parler à un seul public sans tourner autour du pot. Votre taux de conversion grimpe généralement d’au moins un côté, parfois des deux.
L’accueil devient plus facile. Un nouvel utilisateur atterrit sur une page qui parle de lui, pas sur une page qui essaie de parler à tout le monde.
Ce qui devient plus difficile, c’est de garder les parties partagées synchronisées. Si vous corrigez un bug dans le parcours de connexion, vous voulez qu’il soit corrigé dans les deux applis. Si vous changez l’apparence de l’écran de facturation, vous voulez que les deux applis le reflètent. La discipline qu’il vous faut — et c’est vrai que vous fassiez du vibe coding avec un créateur d’applis avec IA ou que vous construisiez avec une équipe de développeurs humains — est de garder les parties partagées vraiment partagées. Ne dupliquez pas. Ne forkez pas. Soit vous extrayez l’écran partagé dans une petite bibliothèque que les deux applis utilisent, soit vous acceptez d’avoir deux applis véritablement séparées et vous l’assumez.
Une petite question pour finir
Si vous faisiez passer la promesse de votre appli actuelle à cinq inconnus et qu’ils la décrivaient chacun différemment — mais en deux catégories distinctes — vous vivez probablement déjà avec la scission. La seule question est de savoir si vous continuez à payer la taxe d’un produit confus, ou si vous faites le travail d’assumer honnêtement que vous en avez deux.
Vous n’avez pas à décider aujourd’hui. Mais la prochaine fois que votre créateur d’applis avec IA vous demandera « que dois-je construire ensuite ? », gardez en tête que la réponse la plus utile n’est peut-être pas une nouvelle fonctionnalité. Ce pourrait être une nouvelle porte d’entrée.
Si ça vous a parlé, vous aimerez peut-être aussi notre article plus ancien sur construire pour votre équipe vs construire pour vos clients — même type de décision, une étape plus tôt dans la vie de votre produit.