Ressources
Ton app faite avec l'IA casse à chaque changement ?
Récupérer ou reconstruire — 10 questions.
Tu es allé plus loin que la plupart des gens : quelque chose qui tourne, sur lequel on clique, qui montre ce que ton produit doit être. Puis chaque nouveau changement s'est mis à casser autre chose.
C'est un mur fréquent, pas un échec personnel. Ce diagnostic te dit lequel de trois chemins correspond à ta situation — avant de passer un mois de plus à tourner en rond dans les prompts.
Réponds par oui ou par non. Dans le doute, réponds non.
Ton chemin se calcule dans ton navigateur, ce qui demande JavaScript. Sans lui, tu peux quand même lire les 10 questions ci-dessous.
À lire d'abord
- Sauvegarde tes données aujourd'hui.
- Prévois le déplacement des données. Les données de tes utilisateurs partent avec toi.
Ton chemin
Stabiliser
Tes fondations sont utilisables. Ce qui manque, c'est le filet de sécurité.
- Arrête d'ajouter des fonctionnalités pendant un moment.
- Ajoute des tests autour de tes parcours clés, pour que chaque changement prouve qu'il ne les a pas cassés.
- Nettoie ce qui est dupliqué ou inutilisé, puis reprends la construction — prudemment, un changement à la fois.
Effort habituel : quelques jours à quelques semaines.
Ce qu'il faut demander à un développeur, si tu en fais venir un :
- « Avant d'ajouter quoi que ce soit, peux-tu mettre des tests autour de mes trois parcours clés ? »
- « Qu'est-ce que tu supprimerais ou regrouperais en premier, et pourquoi ? »
- « Peux-tu me montrer un changement de bout en bout : le test écrit, le changement fait, les tests au vert ? »
- « Comment je saurai qu'un changement n'a rien cassé ailleurs ? »
Au bout de deux semaines, ça marche si :
- tu peux ajouter une petite fonctionnalité sans que quelque chose d'autre casse ;
- tes parcours clés ont des tests qui tournent à chaque changement ;
- tu peux dire, en mots simples, ce qui a changé chaque semaine.
Si ça casse encore à chaque fois : les fondations sont plus fragiles qu'elles n'en avaient l'air. Refais le diagnostic ; reconstruire en partie sera peut-être le meilleur chemin.
Reconstruire en partie
Une partie mérite d'être gardée — en général les écrans et les données. Le cœur, non.
- Garde ce qui fonctionne et ce que voient les utilisateurs.
- Reconstruis proprement le cœur (données, règles métier, connexion, paiements), avec des tests.
- Rebranche les écrans sur le nouveau cœur, parcours par parcours.
Effort habituel : quelques semaines.
Ce qu'il faut demander à un développeur, si tu en fais venir un :
- « Qu'est-ce que tu gardes exactement, et qu'est-ce que tu reconstruis ? Montre-moi la limite. »
- « Comment on déplace les données existantes vers le nouveau cœur sans en perdre ? »
- « Dans quel ordre on rebranche les écrans — et est-ce que je peux utiliser chaque parcours dès qu'il est rebranché ? »
- « Quel test prouve que le nouveau cœur fait ce que faisait l'ancien ? »
Au bout de deux semaines, ça marche si :
- il existe une liste écrite de ce qui est gardé et de ce qui est reconstruit, et tu es d'accord avec elle ;
- au moins un parcours clé tourne sur le nouveau cœur, avec des tests ;
- tes données ont été copiées vers le nouveau cœur lors d'un essai, sans rien perdre.
Si la reconstruction « partielle » s'étend jusqu'à tout toucher : dis-le tôt. Repartir de ton prototype sera peut-être plus simple.
Repartir de ton prototype
Le code ne vaut pas d'être sauvé. Le prototype, si.
- C'est la meilleure spécification que tu pouvais écrire : chaque écran, chaque parcours, cliquables. La plupart des cahiers des charges sont des documents ; le tien est une démo qui fonctionne.
- Sers-t'en comme périmètre pour une vraie construction, avec des tests dès le premier jour.
- Repartir n'est pas échouer. Ton prototype a prouvé l'idée et montré ce que le produit devait être. C'était son rôle.
Effort habituel : une construction complète — plus rapide que d'habitude, parce que la question la plus difficile (quoi construire) a déjà sa réponse.
Ce qu'il faut demander à un développeur, si tu en fais venir un :
- « Peux-tu utiliser mon prototype comme spécification — écran par écran, parcours par parcours ? »
- « Qu'est-ce que tu retirerais de la V1, et pourquoi ? »
- « Qu'est-ce qui est testé dès le premier jour, et comment je le verrai ? »
- « Que deviennent mes données et mes utilisateurs actuels pendant la bascule ? »
Au bout de deux semaines, ça marche si :
- le périmètre est écrit à partir de ton prototype, avec ce qui est dans la V1, dehors, et pour plus tard ;
- tu as toi-même cliqué sur le premier parcours reconstruit ;
- les tests tournent à chaque changement, et tu les as vus tourner.
Si personne ne se sert de ton prototype comme spécification : tu paies pour redécouvrir des décisions que tu as déjà prises.
- 01 Ton parcours principal fonctionne-t-il de bout en bout aujourd'hui, pour un vrai utilisateur ?
- 02 Peux-tu ajouter une petite fonctionnalité sans casser autre chose ?
- 03 Existe-t-il au moins un test automatisé ?
- 04 Le code est-il dans un dépôt que tu contrôles, avec son historique ?
- 06 Un autre développeur pourrait-il la faire tourner sur son ordinateur, à partir d'instructions écrites ?
- 07 La connexion et les paiements passent-ils par des services éprouvés — et non par du code écrit de zéro ?
- 08 La structure de tes données est-elle restée stable lors de tes derniers changements ?
- 10 Quand tu demandes un changement, arrive-t-il là où tu l'attends — à un seul endroit, pas à dix ?
Ce qu'il ne faut pas faire, quel que soit le chemin
- Ne demande pas à l'IA de « tout réparer » d'un coup.
- N'ajoute pas de fonctionnalités tant que l'application est instable.
- Ne supprime pas le prototype : c'est ta spécification.
- Ne déplace pas de vraies données utilisateurs sans sauvegarde ni essai préalable.
Envie d'un deuxième regard ? Un existant s'évalue pendant notre Sprint de cadrage, avant que quiconque ne chiffre la suite. Product Discovery Sprint
Conçu par NexusInsight. Nous construisons aussi avec l'IA — pilotés par les tests. C'est la méthode qui fait la différence, pas l'outil.