Un produit large, pas une simple maquette
Landing, comptes, sessions, réservation, paiement simulé, administration, droits, arrivée publique, assets, direct et post-tournage ont été réunis dans un parcours cohérent.
01 · Le résultat
Ce qui a réellement été construit
La vitesse initiale n’est pas fictive. Elle a permis de passer rapidement d’une interface locale à un produit couvrant plusieurs parcours reliés entre eux.
Des fondations durables ont ensuite été ajoutées
Les domaines métier, la persistance, les contrats entre modules, les contrôles d’architecture et les tests automatisés constituent aujourd’hui une base beaucoup plus explicite.
Interprétation
Le sujet n’est donc pas « l’IA n’a rien su faire ». Elle a beaucoup produit. La difficulté est que la structure permettant de comprendre et de faire évoluer ce volume est arrivée après lui.
02 · Le point de départ
La dette était déjà concentrée très tôt
- 5 912lignes dans
app.jsau commit intitulé « first commit ». - 2 279lignes dans la feuille principale au même point de l’historique.
- 9 408lignes atteintes ensuite par le serveur central avant sa modularisation.
- 26fichiers qui font aujourd’hui référence à une caractérisation ou à son équivalent.
Une demande locale touchait déjà plusieurs systèmes
Rendu, état, événements, droits, données et appels serveur partageaient de grandes portées. Une petite modification pouvait donc avoir des effets que ni le nom du fichier ni la demande initiale ne rendaient visibles.
La taille ne prouve pas à elle seule un mauvais code. Elle prouve ici une surface de changement difficile à isoler.
03 · Le coût de reprise
Il a fallu construire le filet avant de continuer
Modifier directement aurait signifié déplacer des règles sans savoir précisément ce qui dépendait d’elles. Le projet a donc dû être repris par lots sécurisés.
Inventorier les comportements existants avant de les déplacer.
Écrire des tests qui figent le résultat actuel, même imparfait.
Déplacer une responsabilité métier complète, pas seulement des lignes.
Maintenir les anciennes routes et données pendant la transition.
Relancer architecture, tests ciblés et parcours complets.
Un lot d’établissement des domaines a touché 302 fichiers : 14 636 insertions et 6 414 suppressions.
La finalisation suivante a encore touché 104 fichiers : 6 119 insertions et 5 287 suppressions.
Résultat utile : le point d’entrée serveur est passé de 9 408 lignes à une délégation d’une ligne, des frontières sont contrôlées automatiquement et 338 fichiers de test sont présents. Limite persistante : la complexité n’a pas disparu ; le contrôleur client compte encore 8 151 lignes et la racine de composition 2 209.
04 · Le coût récurrent
Chaque modification ouvrait une boucle de recette plus large
La difficulté n’était pas seulement de faire la modification. Elle était de démontrer ensuite que rien d’autre n’avait bougé dans une base où les dépendances restaient difficiles à prévoir.
Modification IA
La demande ciblée est appliquée dans le code.
Tests ciblés
Le cas demandé fonctionne dans son chemin direct.
Recette élargie
Les parcours voisins, droits, données et écrans sont rejoués.
Problème indirect
Une régression ou une incohérence non prévue apparaît ailleurs.
Consolidation
Le problème est corrigé et ajouté au filet de tests, puis la boucle repart.
Un domaine, des contrats et des tests de sortie donnaient à l’IA un périmètre explicite. Le travail pouvait être long tout en restant compréhensible.
Le rayon réel n’était découvert qu’au recettage. Un détail pouvait toucher navigation, autorisation, persistance, calcul, affichage ou responsive sans que la demande le laisse prévoir.
Le surcoût venait de la répétition de cette boucle, pas d’un exemple particulier. La direction artistique n’en est qu’une manifestation secondaire parmi d’autres.
05 · Le filet de consolidation
Le recettage est devenu un chantier à part entière
À mesure que les problèmes indirects étaient découverts, il fallait transformer chacun d’eux en preuve reproductible. Le filet s’est donc élargi avec le produit et avec les défauts rencontrés pendant les modifications.
fichiers de test suivis dans le corpus actuel
fichiers faisant référence à la caractérisation
fichiers dans la suite navigateur E2E
scénarios E2E nommés dans cette suite
Comportement métierRéservation, prix, droits, transitions d’état et effets secondaires devaient rester identiques après déplacement.
DonnéesBases neuves, données historiques, migrations, compatibilités et répétition sans double effet ont nécessité leurs propres preuves.
Parcours completsUne réussite locale ne suffisait pas : les scénarios voisins et les erreurs de page ou de requête devaient aussi rester verts.
InterfaceClavier, responsive, feedback et cohérence visuelle font partie de la recette, mais ne constituent qu’une catégorie parmi les autres.
Interprétation
Ces volumes ne signifient pas que chaque test a été créé à cause d’une régression. Ils montrent que la confiance ne pouvait plus venir d’une vérification locale : elle devait être reconstruite par plusieurs niveaux de recette à chaque changement sensible.
06 · Faire la part des choses
Tout le travail de reprise n’était pas évitable
Évolution normale
- le produit s’est enrichi et les besoins se sont précisés ;
- les intégrations réelles demandent des adaptations ;
- les retours utilisateurs font évoluer les parcours ;
- certaines décisions ne pouvaient apparaître qu’en testant.
Détour évitable
- règles et effets secondaires concentrés dans les mêmes noyaux ;
- tests ajoutés après la croissance plutôt qu’avec elle ;
- dépendances indirectes découvertes seulement au recettage ;
- intentions transmises comme demandes ponctuelles ;
- volume produit plus vite que la capacité de revue.
07 · Ce qui aurait évité le détour
Les fondations manquantes, vues après coup
| Fondation absente | Conséquence | Travail compensatoire | À poser dès le départ |
|---|---|---|---|
| Frontières métier | Modification à grand rayon | Migration par domaines et compatibilités | Tranches verticales petites et propriétaires clairs |
| Tests avec la croissance | Comportement difficile à déplacer sûrement | Caractérisation avant chaque extraction | Parcours critique testé au moment de sa création |
| Carte des effets | Le rayon d’une modification reste inconnu | Recette élargie et analyse après chaque changement | Contrats explicites entre règles, données, écrans et effets |
| Références transversales | Le cas direct passe mais un parcours voisin casse | E2E, intégration, responsive et tests de droits | Baseline par parcours, état et responsabilité |
| Intention explicite | L’IA applique la lettre, pas la forme générale | Allers-retours et corrections successives | Décrire invariant, surfaces, états et exclusions |
08 · Pour les prochaines demandes
Cinq règles simples pour un petit changement avec l’IA
- 1
Dire la règle
Expliquer l’effet général recherché, pas seulement le bouton à changer.
- 2
Nommer les surfaces
Lister pages, composants voisins, états et tailles d’écran concernés.
- 3
Figer l’avant
Capturer le rendu et les comportements qui ne doivent pas bouger.
- 4
Changer peu
Faire une tranche courte, vérifiable et facile à annuler.
- 5
Regarder l’ensemble
Valider humainement la page, ses voisines, le mobile et les états limites.
Formulation utile
« Modifie cette action sans changer les droits, la navigation, les données ni les autres parcours. Identifie d’abord les consommateurs et effets indirects. Ajoute le test du cas demandé, puis rejoue les parcours voisins. Si un comportement non défini apparaît, arrête-toi au lieu d’inventer. »
Conclusion
La vitesse n’était pas le problème. L’implicite l’était.
KRT montre qu’une IA peut produire vite un ensemble impressionnant, puis aider à mener de gros travaux de restructuration. Elle montre surtout que le coût se répète lorsque chaque modification oblige à redécouvrir son rayon réel par une recette élargie.
Les tests de caractérisation et les lots de consolidation n’étaient pas du travail accessoire : ils ont compensé ce qui n’avait pas été posé au départ. La prochaine économie consiste à rendre les dépendances et comportements explicites assez tôt pour qu’une modification ne déclenche plus systématiquement une enquête sur tout le produit.
Méthode et limites
Chiffres recalculés sur l’état Git suivi au 28 août 2026 et sur les commits historiques cités par leur contenu. Les modifications locales non validées ont été exclues. Les volumes de lignes, fichiers et règles sont des indicateurs de surface de changement, pas des mesures de qualité ni des estimations d’heures. Aucun test applicatif, environnement distant ou entretien humain n’a été utilisé pour ce bilan.