Un module enfant est une interface : entrées, sorties, une promesse de comportement. On en crée un quand trois conditions tiennent ensemble : vous avez collé le même bloc plusieurs fois, les différences tiennent en quelques variables, et vous êtes prêts à versionner le contrat (tag de module, pas « le dossier d’à côté qui bouge tous les jours »).
On s’abstient quand on wrappe une aws_s3_bucket « pour faire propre », quand le module a trente variables dont vingt ont un défaut magique, ou quand chaque environnement a besoin d’une fourche du module. Là, l’abstraction coûte plus cher que la duplication honnête.
HashiCorp décrit les modules comme composition et réutilisation. L’entretien sanctionne le module théâtre : couches vides, module "vpc" qui n’est que le root d’hier déplacé d’un dossier.
Le critère rayon d’interface. Un bon module cache des détails stables (sous-réseaux, tags communs). Un mauvais module cache le plan : on ne sait plus quelle resource va être remplacée. Si vous dites « je module dès la première resource, c’est plus pro », vous avez souvent perdu.
Préférer d’abord un module racine clair (fichiers network.tf, data.tf) avant un registre interne. Extraire ensuite, avec moved pour ne pas recréer.
« Module public registry ou module interne ? »
Registry : gagner du temps sur un problème générique, épingler une version, lire les issues. Interne : vos conventions, vos comptes, votre réseau. Jamais main flottant d’un module d’équipe dans la prod. La version du module est un contrat, comme celle du provider.