Chaque root a un state et un apply. Tout ce qui est dans ce state peut, en théorie, être détruit dans le même run — erreur de refactor, mauvais workspace, prevent_destroy oublié. On découpe pour que le rayon d’impact d’une bêtise soit le plus petit qui reste operable.
Motif fréquent et défendable :
Les stacks du dessus lisent les dessous (remote state, data sources), ils ne les recréent pas.
Trop gros : un monorepo, un state « toute la prod », un plan de 400 lignes que personne ne relit. Trop fin : vingt states pour vingt lambdas, des cycles de remote state, des apply dans un ordre rituel que seule une personne connaît. L’intervieweur senior veut le critère, pas le nombre magique : même rythme de changement, mêmes personnes, même gravité si on détruit.
Le remote state est un contrat. Un output retiré casse les lecteurs. On versionne ces interfaces comme des modules.
Que vous parlez d’explosion, pas de « c’est plus clean ». Que vous refusez un apply applicatif qui pourrait toucher le VPC. Que vous savez dire où vous accepteriez encore un state unique (un lab, un produit minuscule).
« Et les workspaces pour découper ? »
Les workspaces découpent des copies d’une même config, pas des couches de gravité différente. Dev/prod oui (avec les réserves déjà dites). Réseau/app : non, ce n’est pas le bon outil.