Comment améliorer une app créée par IA sans la casser

Pour améliorer une app créée par IA sans la casser, faites un seul changement par consigne, vérifiez-le dans l’aperçu et enregistrez 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 lorsqu’un changement 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 app prend souvent forme en quelques minutes. La partie difficile arrive au cinquantième changement, lorsque chaque nouvelle consigne risque de briser quelque chose qui fonctionnait déjà. Ce guide présente la boucle qui évite cela.

La boucle d’amélioration

1. Choisissez un changement. Une fonction, un bogue, 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 près de lui.
5. Enregistrez un point de contrôle ou un commit.
6. Répétez.

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

Étape 1 : Tenez une courte liste

Avant de formuler une consigne, notez ce que vous voulez changer, par ordre d’importance. Cela évite d’envoyer un paragraphe de dix souhaits dans un seul message, et vous donne une façon de dire « pas maintenant » aux idées qui surgissent en cours de route.

Si un changement est important, 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 active. Chacun est une consigne distincte. Rédiger des récits d’utilisateur est une bonne façon de procéder.

Étape 2 : Décrivez ce que vous voyez

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

Sur la page de tarifs, sur un téléphone, le bouton de la carte Pro est coupé au bord droit. Garde la mise en page de bureau identique; sur les écrans de moins de 640 px, empile les cartes et fais en sorte que les boutons occupent toute la largeur.

Comparez avec « la page de tarifs a mauvaise allure sur mobile ». La première consigne peut être réalisée et vérifiée en une seule fois; la seconde invite à une refonte que vous n’avez pas demandée.

Les captures d’écran aident. Si votre outil 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’app (un nouveau modèle de données, les paiements, les rôles des 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 d’API changent, ce qui arrive aux données des utilisateurs existants, et dans quel ordre tu construirais.

Lisez le plan. S’il est erroné, 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 « ménagent » parfois des éléments dont vous n’avez pas parlé. Protégez ce qui fonctionne :

Ajoute un filtre de dates au tableau des commandes. Ne change pas les colonnes du tableau, son style ni le bouton d’exportation.

Pour les règles qui s’appliquent partout (couleurs de marque, ton, « ne jamais supprimer de données sans confirmation »), placez-les dans un fichier de notes du projet ou un paramètre de connaissances que l’IA lit à chaque fois, au lieu de les répéter.

Étape 5 : Vérifiez plus que le changement

Après chaque consigne, testez :

• Le changement lui-même. Fait-il 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 parcours critique. Inscription, connexion, action principale, paiement. Un passage de trente secondes après chaque gros changement détecte la plupart des bris tôt.

Si quelque chose cloche, décrivez le problème avec précision. Consultez comment rédiger un bon rapport de bogue.

Étape 6 : Revenez en arrière plutôt que d’empiler

Lorsqu’un changement brise quelque chose et que la première correction ne fonctionne pas, arrêtez-vous. Chaque correction supplémentaire repose sur un état brisé, et les problèmes s’accumulent.

Plutôt :

1. Revenez à la dernière version qui fonctionnait (un point de contrôle ou un commit Git).
2. Déterminez ce qui manquait de clarté dans la consigne.
3. Essayez à nouveau avec une demande plus petite ou plus claire.

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

Étape 7 : Savoir quand reconstruire est la bonne solution

Reconstruire à partir de zéro jette 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 soutenir ce dont vous avez maintenant besoin, par exemple si elle a été construite comme un site statique et qu’il faut maintenant des comptes et une base de données.
• Le projet est encore presque vide.

Lorsque vous reconstruisez, listez ce qu’il faut conserver : nom, couleurs, textes, parties appréciées par les utilisateurs.

Exemples de consignes

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

Je veux ajouter des réservations récurrentes. Quelle est la plus petite version utile? Propose-la en trois changements distincts que nous pourrons faire un à la fois.

Examine les trois derniers changements pour voir si l’un d’eux a pu briser le parcours de paiement. Ne modifie rien encore.

Erreurs courantes

• Dix demandes dans une seule consigne. Certaines sont faites, d’autres à moitié, et vous ne savez pas lesquelles.
• Une rétroaction vague. « C’est brisé » ou « améliore ça » produit des suppositions.
• Ne jamais vérifier les voisins. Une modification d’un composant partagé brise trois autres pages.
• Corriger les corrections. Quatre consignes plus loin dans un bogue, revenez en arrière.
• Répéter le contexte à chaque fois au lieu de conserver les règles permanentes dans les notes du projet.
• Reconstruire quand on est bloqué. La plupart des moments « recommencer à zéro » sont en fait « revenir deux étapes en arrière ».

Liste de vérification

• Un seul objectif par consigne.
• Je décris ce que je vois et ce qui devrait se passer.
• Les gros changements font l’objet d’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 parcours critique.
• J’enregistre un point de contrôle ou un commit après chaque changement qui fonctionne.
• Lorsqu’une correction échoue, je reviens en arrière plutôt que d’empiler.
• Les règles permanentes sont dans les notes du projet que l’IA lit à chaque fois.

Itérer dans Mythex

Mythex est conçu autour de cette boucle :

• Modes Plan, Build et Ask. Plan discute de l’approche avant toute modification; Ask répond sans changer le code; Build effectue le changement. Consultez Clavardage.
• 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 utiliser Annuler et renvoyer pour essayer une autre consigne à partir de ce point. Consultez Itérer sans reconstruire.
• Connaissances. Paramètres du projet → Connaissances contient des notes permanentes que l’agent suit à chaque message.
• /test demande à l’agent de cliquer dans 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 consignes elles-mêmes, consultez comment rédiger des consignes pour les créateurs d’apps IA; et lorsque quelque chose se brise, comment déboguer une app créée par IA.

Questions