Les configurations (plusieurs variantes dans un fichier) sont généralement supérieures pour de vraies variantes d'une même pièce, mais il existe des cas où des fichiers séparés se justifient — voici comment trancher. Les avantages des configurations (tout dans un fichier) : (1) un seul fichier à maintenir — une correction sur la géométrie de base se répercute sur toutes les variantes automatiquement (avec des fichiers séparés, il faudrait corriger chacun, avec le risque d'oublis et d'incohérences) ; (2) cohérence garantie — toutes les variantes partagent la même définition, elles ne peuvent pas « diverger » par erreur ; (3) gestion de catalogue — idéal pour des familles (les longueurs d'une vis, les tailles d'un produit) via les tables de familles ; (4) plans et nomenclatures — on peut générer un plan par configuration depuis la même source, et une variante référencée dans un assemblage se choisit par sa configuration. C'est la solution privilégiée pour des variantes qui sont vraiment la « même pièce déclinée » : mêmes fonctions de base, différences paramétriques (dimensions, présence/absence d'éléments). Les cas où des fichiers séparés sont préférables : (1) quand les « variantes » sont en réalité des pièces fondamentalement différentes (pas juste des paramètres qui changent, mais des conceptions distinctes) — les forcer en configurations d'un même fichier serait artificiel et lourd ; (2) quand chaque variante a son propre cycle de vie / référence article et doit être gérée indépendamment dans un système de gestion de données (PDM) ou un ERP — certaines organisations préfèrent un fichier = un article pour la traçabilité ; (3) quand un fichier à multiples configurations devient trop lourd ou trop complexe (des dizaines de configurations avec beaucoup de différences ralentissent et compliquent le fichier) ; (4) pour éviter qu'une modification de la géométrie de base ne casse involontairement toutes les variantes (avec des fichiers séparés, l'isolation est totale — mais c'est aussi ce qui fait perdre la cohérence automatique). Il existe aussi une voie intermédiaire : les configurations « dérivées » et les pièces « pilotées ». En pratique, la recommandation courante : utilisez les configurations pour les vraies familles paramétriques (variantes d'une même conception — c'est leur cas d'usage idéal et le plus fréquent), et réservez les fichiers séparés aux pièces réellement distinctes ou aux exigences de gestion de données qui l'imposent. Et sachez que votre système PDM (niveau 5), s'il y en a un, aura souvent une politique sur ce point (comment il gère les configurations vs les fichiers) — à connaître pour rester cohérent avec l'organisation. Le principe : une configuration pour « la même pièce autrement dimensionnée », un fichier pour « une autre pièce ».

La bascule se fait sur le critère du nombre et de la systématicité des variantes : quelques configurations distinctes → à la main ; une famille nombreuse et régulière pilotée par des paramètres → table de familles. Détaillons. Créer des configurations à la main (dans le ConfigurationManager) est parfait quand : vous avez un petit nombre de variantes (deux, trois, une poignée) ; les variantes diffèrent de façon hétérogène (l'une supprime un perçage, l'autre change une dimension, une troisième retire un composant — pas un motif régulier) ; c'est ponctuel (montrer un assemblage ouvert/fermé, une pièce avec/sans option). Dans ces cas, la table serait une lourdeur inutile : quelques clics suffisent. La table de familles devient avantageuse quand : (1) vous avez un grand nombre de variantes (dix, vingt, cinquante — une gamme, un catalogue) : les créer une par une à la main serait fastidieux et source d'erreurs, alors qu'une ligne de tableau par variante est rapide et lisible ; (2) les variantes suivent un motif systématique — les mêmes paramètres prennent des valeurs différentes (les longueurs normalisées d'une vis : 10, 12, 16, 20, 25… ; les sections d'un profilé) : le tableau capture cela naturellement, une colonne par paramètre, une ligne par combinaison ; (3) vous voulez une vue d'ensemble et une édition groupée : la table (dans un tableur) montre toutes les variantes et tous les paramètres d'un coup, on modifie plusieurs valeurs facilement, on ajoute une variante en ajoutant une ligne — bien plus maniable que de naviguer entre des dizaines de configurations manuelles ; (4) les données de variantes existent déjà sous forme de tableau (un catalogue, une liste de références) : on peut souvent les importer ou s'en inspirer directement. Avantages supplémentaires de la table : elle documente clairement la famille (le tableau EST la spécification des variantes), elle facilite la maintenance (ajouter/retirer/modifier des variantes centralement), et elle peut piloter aussi des propriétés (référence, désignation) pour alimenter nomenclatures et gestion. Ses exigences : il faut que les variantes soient réellement paramétriques (définissables par des valeurs de paramètres) — une table gère mal des différences trop qualitatives ou structurelles. Recommandation pratique : commencez à la main pour comprendre le mécanisme des configurations ; dès que vous vous retrouvez à créer manuellement plus de quelques variantes régulières, ou que vous anticipez une famille qui va grandir, passez à la table de familles — l'investissement initial (mettre en place le tableau) est vite rentabilisé. C'est typiquement l'outil des pièces normalisées, des composants de catalogue et des produits déclinés en tailles : là où la variation est nombreuse et réglée, la table de familles est la réponse industrielle.