Quand votre appli créée avec l'IA dépasse sa première version : refactoriser ou réécrire
Vous avez lancé quelque chose. Les utilisateurs ont adoré. Maintenant il y a dix utilisateurs, et leurs besoins ne rentrent pas dans la forme que vous avez construite. Voici comment décider s'il faut refactoriser l'appli actuelle ou admettre que c'était un prototype et la reconstruire comme il faut.
Vous avez lancé quelque chose. Les utilisateurs ont adoré. Maintenant il y a dix utilisateurs, et ils veulent des fonctionnalités qui ne rentrent pas dans la forme d’origine. Vous êtes face à un embranchement : rafistoler l’appli pour qu’elle colle au nouveau cas d’usage, ou admettre que la première version était un prototype et la construire comme il faut. C’est la question qui tue plus de petits projets que n’importe quelle autre, parce qu’il n’y a pas de réponse technique — seulement une réponse business.
Le moment où vous réalisez que l’appli marche
La plupart des applis créées avec l’IA commencent comme une chose et en deviennent une autre. Vous avez construit un formulaire d’accueil client pour votre activité de coaching ; maintenant les clients veulent voir leurs anciens rendez-vous et se reprogrammer eux-mêmes. Vous avez construit un outil de scoring de prospects ; maintenant votre équipe commerciale veut des résumés exportés vers son CRM. Vous avez construit un système de classement ; maintenant les gens veulent collaborer à l’intérieur.
Chaque demande est raisonnable. Chacune éloigne un peu l’appli de ce pour quoi elle a été construite. Et à un certain point — au bout de six mois, ou de deux mois, parfois de deux semaines — vous sentez la friction. Tout ce que vous ajoutez se bat contre les fondations. Les nouvelles fonctionnalités exigent « ah, il faut d’abord réorganiser cette partie ». L’appli ralentit. Les changements prennent plus de temps.
Cette sensation est votre signal pour vous demander si c’est toujours la même appli, ou si vous l’avez dépassée.
Ce que la refactorisation rapporte et coûte
Refactoriser, c’est garder la même appli, mais la nettoyer pour pouvoir construire davantage par-dessus. Vous demandez à votre créateur avec IA de réorganiser le code, de scinder un processus trop compliqué, ou de redessiner un écran devenu un fourre-tout de fonctionnalités. Ça prend quelques heures. Ça n’ajoute pas de nouvelles fonctionnalités. Ça rend juste les fondations plus solides.
Quand la refactorisation marche, c’est magique. Vous aviez l’impression de vous battre contre l’appli ; d’un coup, ce n’est plus le cas. Vous ajoutez trois nouvelles fonctionnalités en une semaine, alors qu’avant ça en aurait pris trois.
Mais la refactorisation ne marche que si le problème vient de la forme de ce que vous avez. Si vous avez construit un formulaire d’accueil et que les utilisateurs veulent un formulaire d’accueil plus rapide, refactoriser la partie lente, c’est une après-midi. S’ils veulent un formulaire d’accueil à la fois plus rapide et qui garde un historique, c’est toujours une seule appli, et la refactorisation peut aider. Mais s’ils veulent un historique des rendez-vous, des intégrations de calendrier, des rappels par SMS et de la facturation, vous ne construisez plus un meilleur formulaire d’accueil — vous construisez le back-office d’une activité de coaching. C’est un produit différent.
Ce que la réécriture rapporte et coûte
Réécrire, ça veut dire : vous avez appris ce que l’appli devrait vraiment être, et vous allez la reconstruire de zéro avec cette connaissance. Vous ne jetez pas la première version — vos utilisateurs en dépendent encore. Mais vous construisez une nouvelle appli de fond en comble, éclairée par ce que l’ancienne vous a appris, puis vous migrez les utilisateurs quand elle est prête.
Réécrire donne une impression de gâchis. Vous avez construit quelque chose, et là vous le reconstruisez. C’est le coût psychologique. Le coût pratique, c’est le temps : vous allez passer deux à quatre mois sur la nouvelle version avant qu’elle ne soit prête à recevoir les utilisateurs. Vous n’aurez plus la première version comme béquille — vous avancez sans filet.
Mais la réécriture vous offre une chose que rien d’autre ne peut offrir : la liberté. La nouvelle appli n’est pas contrainte par la forme de l’ancienne. Si l’originale était un simple formulaire et que la nouvelle devrait être un véritable back-office, vous la concevez pour ça dès le départ. Si la performance compte, vous la concevez pour ça. Si la sécurité, les intégrations ou les processus comptent, ce ne sont pas des rajouts a posteriori — ils sont fondamentaux.
Les applis qui réussissent après une reconstruction le doivent souvent au fait que la compréhension qu’avait l’équipe du problème avait tellement dérivé du code d’origine qu’essayer de rafistoler revenait à porter des vêtements qui ne taillent pas vraiment. Réécrire, c’était construire pour soi-même à la place.
Trois questions pour choisir entre les deux
Question 1 : la forme de base est-elle toujours la bonne ?
Votre forme de base, ce sont les un ou deux processus principaux qui définissent l’appli. Pour un formulaire d’accueil de coaching, c’est « le client remplit l’accueil, le coach examine, le coach planifie ». Si vous ajoutez des processus différents — facturation, gestion de calendrier, messagerie client — vous n’étendez pas le cœur, vous greffez des fonctionnalités annexes. C’est le signe que vous construisez un produit différent, donc : réécrire.
Si vous ajoutez des variantes du même cœur — « accueil pour particuliers, accueil pour équipes, accueil avec champs personnalisés » — c’est toujours la même appli. Refactorisez et étendez-la.
Question 2 : si vous refactorisez aujourd’hui, combien de mois avant que la friction ne revienne ?
Soyez honnête. Si la friction disparaît pour six mois, la refactorisation est le bon choix. Si ça va faire mal de nouveau dans deux mois parce que le problème n’est pas la forme du code mais les fondations elles-mêmes, alors réécrire vous épargne les fausses économies d’un double rafistolage. Demandez à votre créateur avec IA : « Si on nettoie ça, dans combien de temps va-t-il falloir recommencer ? » Si la réponse est « sans doute pas longtemps », il est temps de reconstruire.
Question 3 : de quoi vos utilisateurs dépendent-ils réellement ?
Si vous avez trois utilisateurs actifs sur la v1 et que vous pensez à reconstruire, vous pouvez les déplacer en un jour ou deux. Si vous avez cinquante utilisateurs qui dépendent de l’appli actuelle en production, réécrire signifie maintenir les deux versions opérationnelles pendant des mois, ce qui est une autre forme de souffrance.
Le chemin qui marche généralement
La plupart des fondateurs qui reconstruisent avec succès le font en parallèle : ils gardent l’appli d’origine en fonctionnement et utilisent le temps disponible pour construire la nouvelle. Quand la nouvelle a la parité fonctionnelle avec l’ancienne, ils passent une semaine à migrer les données et les utilisateurs, et c’est terminé.
Le chemin qui ne marche généralement pas : refactoriser, refactoriser, refactoriser, jusqu’à ce que, trois refactorisations plus tard, vous réalisiez que l’architecture est toujours mauvaise, et que vous êtes désormais trop investi dans l’« ancienne » version pour l’admettre et tout recommencer.
Le bon moment pour décider
La prochaine fois que vous sentez la friction, demandez-vous : « Est-ce que je fais en sorte que cette appli fasse mieux ce qu’elle était censée faire ? Ou est-ce que je lui demande d’être quelque chose pour quoi elle n’a jamais été conçue ? » Si c’est la première, refactorisez. Si c’est la seconde, il n’y a aucune honte à construire ce qu’elle aurait dû être dès le départ. La plupart des applis qui marchent en sont à la version 2 du cœur, pas à la version 1.