Apprenez le modèle « do not change » pour effectuer une petite mise à jour tout en gelant les flux UI clés, les règles métier et le comportement critique afin que rien d’autre ne dérive.
Un « petit » changement reste rarement petit. Vous demandez de modifier le libellé d’un bouton, et soudain une mise en page bouge, un formulaire cesse de valider, ou une étape de checkout se comporte différemment. Les applications sont des systèmes connectés. UI, logique, données et intégrations s’appuient les uns sur les autres.
Une cause fréquente est le manque de limites claires. Si une demande dit « simplifier l’inscription », la personne (humaine ou IA) doit deviner ce que « simplifier » signifie. Deviner entraîne des modifications supplémentaires : suppression de champs, changement d’étapes, ajustement de copies ou réécriture de validations. Une autre cause est la dépendance cachée. Un petit changement d’interface peut réutiliser un composant présent sur cinq autres écrans.
Une itération sûre signifie obtenir l’amélioration prévue tandis que tout le reste reste effectivement identique. Pour une équipe non technique, cela veut dire que le flux reste le même pour les utilisateurs, que les scripts d’assistance correspondent toujours au produit et que les rapports restent cohérents. Pour une équipe technique, cela signifie aucune modification inattendue des routes, des formats de données, des contrats d’API ou des comportements en cas de bord.
Pour rendre cela possible, vous devez geler ce qui ne doit pas bouger. En pratique, cela inclut généralement les flux critiques (les étapes exactes suivies par les utilisateurs), les détails UI/UX (mise en page, espacements, comportements d’interaction), les règles métier (tarification, permissions, validations), le comportement des données (ce qui est stocké et quand) et les intégrations (événements analytics, emails, paiements, API externes).
Ce pattern « do not change » réduit les risques en supprimant les conjectures et en limitant la portée du changement. Ce n’est pas une garantie. Vous pouvez toujours avoir de la dérive si le comportement initial est mal défini, si le changement touche des composants partagés, ou si vous ne vérifiez pas le résultat. L’objectif est moins de surprises et des validations plus rapides.
Le pattern do not change est une façon simple de demander une mise à jour précise tout en verrouillant clairement tout le reste. Vous nommez le changement voulu, puis vous rédigez une courte liste de gel des parties qui doivent rester identiques après la modification.
C’est important parce que les modèles cherchent souvent à être utiles en refactorisant, renommant, réorganisant des fichiers ou « nettoyant » la logique lorsqu’ils touchent le code. Même si le résultat fonctionne toujours, ces changements additionnels peuvent introduire des bugs, modifier le comportement ou compliquer les revues.
Comparez ces deux demandes :
« Améliorez la page des paramètres. » Cela invite des changements de design, de nouvelles copies, des déplacements de mise en page et des ajustements de logique.
« Changez seulement le texte du libellé de ‘Phone’ en ‘Mobile phone’. Ne changez pas la mise en page, la validation ou le comportement de sauvegarde. » Ceci est étroit, testable et plus sûr.
Une bonne liste de gel couvre généralement trois domaines :
Quand vous utilisez ce pattern dans un outil de build basé sur le chat comme Koder.ai, les itérations sont souvent plus rapides parce que le modèle se concentre sur l’édition unique au lieu de faire de larges « améliorations » non sollicitées.
Ce pattern fonctionne mieux quand votre demande ressemble à un petit contrat : un objectif clair, une liste gelée de ce qui doit rester identique, et quelques vérifications pour confirmer le résultat.
Copiez ce modèle et remplissez les crochets. Restez court, mais précis.
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -> checkout -> receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
Un exemple concret : si vous voulez changer la couleur du bouton de checkout, votre objectif est « Mettre à jour la couleur du bouton principal de checkout en #1A73E8. » Vos éléments DO NOT CHANGE doivent geler le flux complet de checkout, le texte du bouton et le calcul des prix.
Si vous utilisez Koder.ai, ce format accélère aussi les revues parce que vous pouvez comparer les checks d’acceptation avec l’aperçu et le résumé des changements avant d’approuver quoi que ce soit.
Quand vous demandez une petite modification, ne dites pas simplement « ne cassez rien ». Nommez les parcours utilisateurs exacts qui doivent se comporter de la même façon, du premier clic au résultat final. Vous ne geler pas toute l’appli, vous geler les parties où une régression fait mal.
Commencez par lister les flux critiques en langage clair : login (y compris reset de mot de passe), onboarding, checkout, paramètres. Pour chaque flux, indiquez ce que « terminé » signifie. Exemple : « L’utilisateur peut se connecter avec email + mot de passe, arrive sur le Dashboard, et reste connecté après un refresh. »
Ensuite verrouillez les cas limites souvent oubliés. Le comportement du bouton Retour est une source classique de dérive : « Retour depuis Checkout retourne au Panier (pas à l’Accueil), et les articles du panier restent. » Indiquez les états d’erreur (« mauvais mot de passe affiche le même message »), les états vides (« pas de projets affiche le même texte d’écran vide ») et les états de chargement (« un spinner apparaît sous 200ms, sans saut de mise en page").
Si les attentes de performance et de sécurité comptent, figez-les aussi. Si vous ne les mentionnez pas, le modèle peut « améliorer » en ajoutant des requêtes, des logs ou en changeant les vérifications d’auth.
Une façon concise de le préciser sans écrire un roman :
Soyez spécifique sur le flux de données en une phrase par item. Exemple : « L’adresse est enregistrée uniquement après appui sur Save, stockée dans le record du profil utilisateur, et doit persister après logout/login. » Ce niveau de détail évite les autosave accidentels, les nouveaux champs, ou les changements de timing qui cassent les vrais utilisateurs.
La dérive UI survient souvent parce que le modèle « nettoie » les styles, les espacements ou la structure des composants. La solution est la même que pour la logique métier : nommez ce qui doit rester identique, et nommez la seule chose qui peut changer.
Fixez la structure visible. Indiquez la mise en page (colonnes/lignes, en-tête et pied de page), les règles d’espacement (padding, gaps, alignement), et le comportement des composants (hover, état désactivé, spinners, messages d’erreur). Si un composant a une sensation précise, dites-le clairement : « Taille du bouton, radius et couleur doivent rester exactement les mêmes. »
Le comportement responsive nécessite des règles explicites. Si vous ne mentionnez pas le mobile, les outils peuvent « améliorer » ça. Indiquez les breakpoints qui vous importent et ce qui doit se passer à chacun : ordre d’empilement, éléments masqués, barres fixes, tailles de cibles tactiles.
Gelez aussi les mots. Dites au modèle que toutes les copies, libellés, placeholders et textes d’aide doivent rester inchangés, sauf la seule chaîne que vous modifiez. Cela évite les réécritures silencieuses qui changent le sens.
Un prompt compact à coller dans une demande de changement :
Si possible, demandez des captures avant/après. Si ce n’est pas disponible, demandez un court « UI diff » (ce qui s’est déplacé, redimensionné, changé de couleur) pour approuver en confiance.
Les règles métier sont l’un des endroits les plus faciles pour qu’un petit changement UI crée une régression silencieuse. Une mise à jour d’étiquette peut accidentellement changer un calcul, une transition d’état, ou qui peut voir un enregistrement. Traitez les règles et le comportement des données comme des contrats gelés.
Commencez par nommer les quelques règles qui feraient le plus mal si elles changeaient. Écrivez-les comme des tests : entrées, sorties et qui peut faire quoi.
Au lieu de « garder la tarification la même », précisez :
Ajoutez un exemple numérique pour éviter l’interprétation. Par exemple : « Sous-total commande 120 $, remise 10 % (applique avant taxe), taxe 8,25 % sur le montant remisé. Total attendu = (120 - 12) * 1.0825 = 116,91 $. Arrondir à 2 décimales uniquement sur le total final. »
Précisez la visibilité basée sur les rôles, pas seulement les actions. Exemple : « Les agents support peuvent voir le statut de commande et l’email client, mais ne doivent pas voir les détails complets de la carte. Seuls les admins peuvent effectuer des remboursements. »
Si les validations comptent, figez-les explicitement. Mentionnez le déclencheur exact et le message visible : « Si la date de début est postérieure à la date de fin, bloquer la sauvegarde et afficher : ‘End date must be after start date.’ Ne changez pas ce libellé. »
N’oubliez pas les effets secondaires hors de l’app. Si vous envoyez des emails, webhooks ou appelez des API tierces, figez ce qui doit rester identique : noms d’événements, champs du payload, timing (immédiat vs différé) et comportement d’idempotence (pas d’envois dupliqués au retry).
Traitez une petite mise à jour comme un mini-contrat. Le pattern fonctionne mieux quand le changement est restreint et que tout le reste est explicitement gelé.
Rédigez le changement en une phrase testable. « Sur la page des paramètres, ajouter un toggle pour activer le mode sombre » est testable. « Améliorer l’UI des paramètres » ne l’est pas. Si vous ne pouvez pas le tester en 30s, c’est encore trop large.
Rédigez une liste de gel pour les parties qui feraient mal en dérivant : flux utilisateurs, éléments UI clés, règles métier, comportement des données, et les APIs ou tables qui doivent rester identiques.
Ajoutez des checks d’acceptation et un court plan de test. C’est là que vous évitez le « ça marche chez moi » surprise. Incluez des checks tels que : le nouveau toggle apparaît, les paramètres existants continuent de se sauvegarder, et rien d’autre sur la page ne bouge.
Avant toute modification, demandez à l’assistant de répéter vos contraintes. Faites-le confirmer ce qui va changer et ce qui doit rester identique. Si le résumé est incorrect, corrigez la demande avant d’autoriser le changement.
Demandez l’implémentation la plus petite possible : pas de refactorings, pas de renommages, pas de réorganisations, pas de mise en forme au-delà des lignes touchées. Vous achetez un changement, pas une refonte.
Une courte checklist de revue :
Ceci fonctionne particulièrement bien dans Koder.ai : collez la liste de gel en Planning Mode, faites-la écho des contraintes, puis générez le patch le plus petit.
La plupart des « petites » modifications échouent pour la même raison : la demande protège l’objectif, mais pas le comportement. Un modèle peut atteindre votre but d’une nouvelle manière qui change silencieusement des écrans, de la logique ou des données.
Un piège courant est de geler l’issue (« rendre l’onboarding plus fluide ») au lieu des étapes exactes. Un autre est d’écrire « garder tout pareil » en supposant que le système sait ce que cela signifie.
Erreurs qui causent le plus souvent la dérive :
Un petit exemple : vous demandez de « rendre le bouton plus visible » et vous geler la couleur, mais oubliez l’état désactivé. La mise à jour peut activer le bouton en permanence, modifiant le comportement d’une manière que vous ne remarquez qu’après coup.
Ce qui aide, c’est d’être précis sur ce qui ne doit pas bouger. Avant d’accepter la mise à jour, faites un rapide passage de régression :
Si l’un d’eux diffère, la demande manquait d’un détail gelé, ce n’est pas du “mauvais code”.
Une itération sûre courante est une petite retouche UI où le workflow ne doit pas changer.
Scénario : un fondateur a un écran d’inscription simple avec un formulaire court (Nom, Email, Taille de l’entreprise) et un bouton principal qui soumet le formulaire puis redirige l’utilisateur vers le dashboard.
Demande de changement exacte (une phrase) : « Renommer le bouton principal de 'Create account' en 'Continue' et transformer le champ 'Company size' d’un input libre en un dropdown. »
Appliquez le pattern en gelant ce qui doit rester identique :
Checks d’acceptation rapides :
Une bonne réponse de l’assistant doit redire les items gelés, confirmer toute ambiguïté (par exemple : quelles options du dropdown et quelle valeur est stockée), puis produire uniquement le changement UI/code minimal nécessaire. Il doit aussi indiquer ce qu’il n’a pas touché (routing, logique de validation, forme du payload).
Avant d’accepter une « petite modification », faites un passage rapide pour repérer la dérive silencieuse. L’objectif n’est pas une QA complète. C’est de confirmer que l’app se comporte toujours là où vous avez dit « ne pas changer », sauf pour la modification voulue.
Exécutez ces vérifications dans le même ordre à chaque fois. Cela calme les revues et rend les régressions plus faciles à repérer.
Revenez en arrière si un item gelé a changé, même si l’app « fonctionne toujours ». Un libellé modifié, un nouveau champ ou une règle légèrement différente est le signe que le modèle a pris des libertés.
Réémettez la demande avec des contraintes plus strictes : reformulez le changement en une phrase, listez les flux et écrans gelés par nom, et ajoutez « pas de changements de schéma, pas de changements d’endpoints, pas de comportement extérieur à X ». Dans Koder.ai, prendre un snapshot avant le test rend le rollback instantané quand quelque chose dérive.
Si vous travaillez dans Koder.ai, le pattern do not change devient une habitude : un petit changement, tout le reste verrouillé, et un moyen clair de revenir en arrière si quelque chose dérive.
Avant de demander le changement, passez en Planning Mode et demandez à l’assistant de reformuler votre périmètre en termes simples. Demandez-lui de répéter deux choses : (1) le changement exact, et (2) une liste claire des éléments à geler (flux, détails UI et règles métier).
Un prompt de planification efficace : « Reformule ma demande. Puis liste ce qui ne doit pas changer. Si quelque chose est ambigu, pose des questions avant d’éditer. »
Traitez chaque demande de changement comme un checkpoint. Créez un snapshot avant d’appliquer la mise à jour, puis un autre après vérification. Si quelque chose casse, le rollback est plus rapide que de corriger un mauvais changement.
Par exemple, vous ajustez un libellé de bouton dans un écran React. Le changement semble minime, mais peut déplacer l’espacement, déclencher un rerender ou casser un test automatisé. Un snapshot permet de comparer le comportement et revenir en arrière rapidement.
Un workflow simple :
Koder.ai peut générer du web (React), backend (Go + PostgreSQL) et mobile (Flutter). Le pattern reste le même même si le code diffère. Geler les parties qui définissent le comportement, pas seulement les fichiers.
Si vous changez un endpoint backend, gelez la forme request/response, les règles de validation et les écritures en base. Si vous changez un écran mobile, gelez l’ordre de navigation, les valeurs par défaut des champs et les messages d’erreur. Si vous touchez la logique de base de données, gelez la signification des lignes existantes et assurez des migrations sûres.
Copiez votre template, faites une petite modification aujourd’hui, et vérifiez-la avec la checklist avant d’accepter. Conservez le texte du template et remplacez uniquement le prochain changement, un à la fois.
Utilisez-le chaque fois que vous voulez une modification précise et que vous tenez à ce que tout le reste reste identique. C’est particulièrement utile pour le checkout, l’authentification, la facturation ou tout flux où une dérive minime cause de vrais problèmes utilisateurs.
Parce que les parties d'une application partagent des composants, des données et des règles. Une petite modification d'interface peut toucher un composant réutilisé, déplacer des éléments ailleurs, modifier des validations ou changer des payloads d'API sans que vous vous en rendiez compte tout de suite.
Rédigez un objectif clair, puis listez ce qui doit rester identique après la modification. L’idée est de geler le comportement (flux, règles, données, intégrations) et les détails visibles de l’UI, pas seulement de dire « ne cassez rien ».
Soyez concis mais précis : flux critiques, détails UI/UX à ne pas déplacer, règles métiers, comportement des données et intégrations. Si vous ne pouvez pas nommer ce qui doit rester le même, le modèle devra deviner, et la devinette provoque une dérive.
Ciblez la plus petite zone qui vous protège. Par exemple, figez le flux de checkout et ses composants partagés, mais ne geler pas toute l'application si vous changez l'étiquette d'un écran.
Nommez les parcours étape par étape et décrivez ce que « terminé » signifie. Ajoutez les cas limites courants comme le comportement du bouton retour, les messages d’erreur, les écrans vides et le rafraîchissement pour que le flux reste identique là où les utilisateurs s’en rendent compte.
Gelez explicitement la structure visible, l’espacement, les états des composants (hover/désactivé/chargement) et tout le texte, sauf la chaîne unique que vous modifiez. Sinon, les modèles « nettoient » les styles ou réécrivent le texte, ce qui change le sens ou la mise en page.
Gelez les contrats : formes de requête/réponse, règles de validation, permissions, calculs, et ce qui est enregistré et quand. Ajoutez un exemple chiffré pour les règles sensibles comme la tarification afin d’éviter toute interprétation lors de l’implémentation.
Demandez des checks d’acceptation rapides à exécuter, plus un bref résumé en style diff de ce qui a changé et où. Ensuite, vérifiez le(s) flux gelé(s) de bout en bout, déclenchez au moins un état d’erreur, et confirmez que les données/intégrations n’ont pas changé.
Faites un snapshot avant la modification, exécutez une passe de planification qui répète la portée et la liste gelée, puis appliquez le plus petit patch. Après vérification, prenez un autre snapshot pour que le rollback soit simple si quelque chose dérive.