Comment faire évoluer une application créée par IA sans la casser

Pour faire évoluer une application créée par IA sans la casser, modifiez une seule chose par prompt, vérifiez le résultat dans l'aperçu et sauvegardez un point de contrôle avant de passer à la suite. Décrivez ce que vous voyez plutôt que ce que vous pensez que le code fait, planifiez les gros changements avant de les construire, et quand une modification tourne mal, revenez à la dernière bonne version au lieu de demander à l'IA de corriger sa propre correction.

La première version d'une application prend souvent quelques minutes. La difficulté arrive au cinquantième changement, lorsque chaque nouveau prompt risque de casser ce qui fonctionnait déjà. Ce guide présente la boucle qui évite cela.

La boucle d'itération

1. Choisissez un seul changement. Une fonctionnalité, un bug, une page.
2. Décrivez-le en termes de ce que l'utilisateur voit et fait.
3. Pour les gros changements, planifiez d'abord. Demandez un plan, lisez-le, puis construisez.
4. Vérifiez le résultat dans l'aperçu : le changement et les parcours proches.
5. Sauvegardez un point de contrôle ou un commit.
6. Recommencez.

Chaque étape sert à garder les changements petits et réversibles.

Étape 1 : tenez une liste courte

Avant de rédiger un prompt, notez ce que vous voulez modifier, par ordre d'importance. Cela évite d'envoyer un paragraphe de dix souhaits dans un seul message, et vous donne un moyen de dire « pas maintenant » aux idées qui surgissent en cours de route.

Si un changement est gros, découpez-le. « Ajouter des comptes d'équipe » devient : créer des équipes, inviter un membre, passer d'une équipe à l'autre, limiter les données à l'équipe courante. Chacun est un prompt à part. Rédiger des user stories est un bon moyen de faire ce découpage.

Étape 2 : décrivez ce que vous voyez

L'IA ne voit pas votre écran à moins que vous ne le lui disiez. Désignez des éléments précis et dites ce qui doit se passer :

Sur la page tarifs, sur téléphone, le bouton de la carte Pro est coupé sur le bord droit. Garde la mise en page desktop identique ; sur les écrans de moins de 640 px, empile les cartes et rends les boutons pleine largeur.

Comparez avec « la page tarifs est moche sur mobile ». La première version peut être réalisée et vérifiée en une fois ; la seconde invite à une refonte que vous n'avez pas demandée.

Les captures d'écran aident. Si votre créateur accepte les images, joignez-en une et entourez le problème.

Étape 3 : planifiez avant les gros changements

Pour tout ce qui touche plusieurs parties de l'application — un nouveau modèle de données, les paiements, les rôles utilisateurs — demandez un plan avant toute modification du code :

Ne change pas encore le code. Je veux que les utilisateurs appartiennent à des équipes et ne voient que les projets de leur équipe. Planifie le changement : quelles tables, pages et routes API évoluent, ce qui advient des données des utilisateurs existants, et dans quel ordre tu construirais cela.

Lisez le plan. S'il est faux, corriger un plan coûte beaucoup moins cher que défaire une construction.

Étape 4 : dites ce qui ne doit pas changer

Les outils d'IA « rangent » parfois des choses que vous n'avez pas demandées. Protégez ce qui fonctionne :

Ajoute un filtre par date au tableau des commandes. Ne modifie pas les colonnes du tableau, son style ni le bouton d'export.

Pour les règles valables partout — couleurs de marque, ton, « ne jamais supprimer de données sans confirmation » — placez-les dans un fichier de notes ou un paramètre de connaissances du projet que l'IA lit à chaque fois, plutôt que de les répéter.

Étape 5 : vérifiez plus que la modification

Après chaque prompt, testez :

• La modification elle-même. Fait-elle ce que vous avez demandé, sur ordinateur et sur téléphone ?
• Ses voisins. Les éléments de la même page et les parcours qui utilisent les mêmes données.
• Le chemin critique. Inscription, connexion, action principale, paiement. Un passage de trente secondes après chaque gros changement détecte la plupart des casses tôt.

Si quelque chose cloche, décrivez-le précisément : voir comment rédiger un bon rapport de bug.

Étape 6 : revenez en arrière au lieu d'empiler

Quand une modification casse quelque chose et que la première correction ne fonctionne pas, arrêtez-vous. Chaque « correctif » supplémentaire repose sur un état cassé, et les problèmes s'aggravent.

À la place :

1. Revenez à la dernière version qui fonctionnait (un point de contrôle ou un commit Git).
2. Identifiez ce qui était flou dans le prompt.
3. Recommencez avec une demande plus petite ou plus claire.

Ce changement a cassé l'enregistrement des brouillons. J'ai fait un retour en arrière. Cette fois : ajoute seulement l'indicateur de sauvegarde automatique, sous forme de texte dans l'en-tête. Ne modifie pas la façon dont les brouillons sont enregistrés.

Étape 7 : sachez quand reconstruire est la bonne solution

Reconstruire de zéro fait perdre beaucoup de détails qui fonctionnent. Cela n'en vaut la peine que lorsque :

• L'idée du produit a complètement changé.
• La structure sous-jacente ne peut pas supporter ce dont vous avez maintenant besoin — par exemple, elle a été conçue comme un site statique et il faut désormais des comptes et une base de données.
• Le projet est encore presque vide.

Si vous reconstruisez, listez ce qu'il faut garder : nom, couleurs, textes, parties appréciées des utilisateurs.

Exemples de prompts

Avant de continuer, résume le fonctionnement actuel de l'application : les pages, les données stockées et ce que tu considères comme fragile.

Je veux ajouter des réservations récurrentes. Quelle est la version la plus petite qui serait utile ? Propose-la en trois changements séparés que nous pourrons faire un par un.

Examine les trois derniers changements pour repérer tout ce qui aurait pu casser le tunnel de paiement. Ne modifie rien pour l'instant.

Erreurs fréquentes

• Dix demandes dans un seul prompt. Certaines sont faites, d'autres à moitié, et vous ne savez pas lesquelles.
• Un retour vague. « C'est cassé » ou « rends ça meilleur » produit des suppositions.
• Ne jamais vérifier les voisins. Une modification d'un composant partagé casse trois autres pages.
• Corriger les corrections. Quatre prompts dans un bug, revenez en arrière.
• Répéter le contexte à chaque fois au lieu de garder les règles permanentes dans les notes du projet.
• Reconstruire quand on est bloqué. La plupart des moments « tout recommencer » reviennent en fait à « revenir deux étapes en arrière ».

Liste de contrôle

• Un objectif par prompt.
• Je décris ce que je vois et ce qui devrait se passer.
• Les gros changements donnent lieu à un plan avant tout code.
• Je précise ce qui ne doit pas changer.
• Après chaque changement, je teste celui-ci, ses voisins et le chemin critique.
• Je sauvegarde un point de contrôle ou un commit après chaque changement qui fonctionne.
• Quand une correction échoue, je reviens en arrière plutôt que d'empiler les corrections.
• Les règles permanentes sont dans les notes du projet que l'IA lit à chaque fois.

Faire évoluer une application sur Mythex

Mythex repose sur cette boucle :

• Modes Plan, Build et Ask. Plan discute de l'approche avant toute modification ; Ask répond sans changer le code ; Build réalise la modification. Voir Chat.
• Points de contrôle. Après chaque tour réussi, Mythex enregistre un point de contrôle Git ; Revenir à ce point permet de revenir en arrière. Vous pouvez aussi modifier un message précédent et choisir Abandonner et renvoyer pour essayer un autre prompt à partir de ce point. Voir Faire évoluer sans tout reconstruire.
• Connaissances. Paramètres du projet → Connaissances contient des notes permanentes que l'agent suit à chaque message.
• /test demande à l'agent de parcourir l'aperçu comme un utilisateur après un gros changement.

Les demandes plus petites coûtent aussi moins de crédits. Pour rédiger les prompts eux-mêmes, consultez comment écrire des prompts pour les créateurs d'applications IA ; si quelque chose casse, comment déboguer une application créée par IA.

Questions