L'EAV (Entity-Attribute-Value) est un modèle de données qui permet de stocker des attributs dynamiques sans modifier le schéma de la base. Au lieu d'une colonne par caractéristique, chaque valeur est stockée comme un triplet : l'entité (un produit), l'attribut (sa couleur), la valeur (« bleu »). C'est le modèle de prédilection des PIM et des catalogues e-commerce hétérogènes.
Flexibilité du schéma
L'EAV permet d'ajouter un attribut sans migration de base. Chaque type de produit peut avoir ses propres caractéristiques : dimensions pour du mobilier, composition pour du textile, puissance pour de l'outillage. Magento, Akeneo et la plupart des PIM reposent sur ce principe.
Compromis et limites
La flexibilité a un coût : reconstituer un produit complet demande de nombreuses jointures ou requêtes, et filtrer sur plusieurs attributs devient lent. Les systèmes matures gardent l'EAV pour l'écriture et servent la lecture depuis des vues dénormalisées.
Quand l'EAV est le bon choix
L'EAV se justifie quand le schéma des données n'est pas connu à l'avance ou qu'il doit être défini par les utilisateurs eux-mêmes : un PIM où chaque client crée ses familles de produits, un catalogue multi-secteur, des fiches techniques dont les champs varient selon la catégorie. Dans ces cas, une table avec une colonne par attribut deviendrait ingérable, et une migration par nouvel attribut serait impossible à suivre.
À l'inverse, pour des données dont la structure est stable et connue — commandes, factures, utilisateurs —, un schéma relationnel classique est plus simple, plus rapide et plus sûr. L'EAV n'est pas un modèle par défaut : c'est une réponse à un besoin de flexibilité réel.
Comment je le mets en œuvre
Sur une plateforme SaaS PIM/DAM dont j'ai dirigé la technique, le cœur du PIM est un système d'attributs dynamiques en EAV : des schémas personnalisés par type de produit, des groupes d'attributs, des templates et une gestion multilingue. Les choix qui le rendent exploitable :
- Des attributs typés : texte, nombre, prix avec devise, unité de mesure, liste de valeurs, média. Un attribut typé se valide et se convertit ; une valeur texte libre ne se valide pas.
- Des valeurs localisables et scopables : un même attribut peut avoir une valeur par langue et une valeur par canal de vente, par exemple un titre optimisé pour Amazon et un autre pour la boutique.
- Une séparation stricte écriture et lecture : l'EAV reste la source de vérité pour l'édition, mais chaque produit est aussi projeté dans un document dénormalisé, indexé dans Elasticsearch pour la recherche full-text, le filtrage et l'affichage des listes.
- Un cache Redis invalidé par les événements Doctrine, pour que les lectures restent rapides sans servir de données périmées.
- Des accès par formule pour les exports : une valeur de sortie peut combiner plusieurs attributs, ce qui évite de stocker des données calculées.
L'EAV vu des plateformes e-commerce
On retrouve l'EAV dans les outils du marché, avec leurs propres compromis. Magento l'utilise pour ses produits, structurés par attribute sets — avec un piège bien connu : un attribut envoyé hors de l'attribute set du produit est ignoré sans erreur. WooCommerce s'appuie sur la table de métadonnées de WordPress, un EAV générique peu efficace pour les requêtes de catalogue complexes, ce qui explique en partie ses difficultés au-delà de quelques milliers de produits. Connaître ces modèles est indispensable pour écrire un connecteur qui transforme un EAV flexible en champs rigides.
Les pièges à éviter
- Lire directement dans l'EAV pour afficher des listes filtrées : les jointures se multiplient et les performances s'effondrent avec le volume.
- Des valeurs non typées stockées en texte : impossible de trier un prix ou de filtrer une dimension proprement.
- Mettre tout le modèle en EAV, y compris les données stables, par goût de la généricité.
- Négliger l'intégrité : sans contraintes applicatives fortes, un attribut obligatoire peut rester vide sans que la base le signale. La complétude doit être calculée et visible.
L'EAV est un outil puissant pour modéliser des données hétérogènes, mais il impose une architecture de lecture optimisée pour rester performant à grande échelle : flexibilité à l'écriture, dénormalisation à la lecture.
La conception de modèles de données de ce type relève de mes missions d'architecture et performance applicative. Pour la traduction de l'EAV vers les boutiques, voir Connecter un PIM à PrestaShop et Magento.