# Une grille tarifaire pour startup SaaS avec l’éditeur atomique d’Elementor > Construire des cartes de prix avec variantes et composants réutilisables sur la version alpha de l'éditeur atomique Elementor, sans paiement récurrent à intégrer. - Auteur : Clément Hadrot - Publié le : 2025-01-12 - Mis à jour le : 2025-01-12 - Catégorie : Elementor - URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/grille-tarifaire-saas-elementor-v4/ ## L’essentiel - L'éditeur atomique est encore en alpha au moment de ce test - Un composant de carte de prix évite de dupliquer trois fois la même structure - Les variantes de style se gèrent par classes plutôt que par duplication de widget Trois offres, trois mises en avant différentes, un seul design cohérent : c'est le brief classique d'une grille tarifaire pour un produit SaaS en phase de lancement. La jeune équipe produit qui a servi de terrain à ce test n'avait ni développeur front dédié ni budget pour un thème sur mesure, mais voulait un rendu qui ne ressemble pas à un modèle générique. Ce test a été mené sur la version alpha de l'éditeur atomique d'Elementor, disponible en activant l'expérience correspondante depuis les réglages du site. À ce stade, la fonctionnalité reste en évaluation active et certains comportements changent d'une mise à jour à l'autre ; ce tutoriel documente ce qui fonctionnait au moment du test, pas une promesse de stabilité définitive. ## Poser la structure du composant carte de prix L'éditeur atomique introduit la notion de composant réutilisable : un ensemble de widgets assemblés une fois, puis instancié à plusieurs endroits tout en gardant un lien vers la source. Pour une grille de trois offres, l'idée est de construire une seule carte de prix complète (titre de l'offre, prix, liste de fonctionnalités, bouton d'appel à l'action), puis de la dupliquer en tant qu'instances de composant plutôt qu'en copiant les widgets un par un. ### Étapes de création 1. Construire la carte de prix complète dans un container atomique isolé, avec les widgets de titre, de texte et de bouton disponibles dans l'éditeur atomique. 2. Sélectionner l'ensemble du container et choisir l'option de conversion en composant, ce qui l'enregistre comme source réutilisable au niveau du site. 3. Insérer deux instances supplémentaires du composant sur la page de tarification. 4. Modifier le contenu propre à chaque instance (nom de l'offre, prix, liste de fonctionnalités) sans casser le lien vers le composant source. 5. Appliquer une classe globale de mise en avant sur l'instance centrale, pour la différencier visuellement sans dupliquer la structure. ## Gérer les variantes sans dupliquer le composant > L'essentiel à retenir : L'éditeur atomique est encore en alpha au moment de ce test ; Un composant de carte de prix évite de dupliquer trois fois la même structure ; Les variantes de style se gèrent par classes plutôt que par duplication de widget La tentation classique face à une offre « recommandée » est de créer un second composant légèrement différent. C'est une mauvaise idée : dès qu'une modification de structure sera nécessaire plus tard (ajout d'un badge, changement de police), il faudra la répercuter sur les deux composants séparément. La bonne pratique consiste à garder un seul composant source et à jouer uniquement sur les classes globales appliquées à chaque instance. Dans ce test, une classe globale nommée pour la mise en avant applique une bordure de couleur et une légère élévation à l'instance centrale, pendant que les deux autres cartes conservent le style par défaut du composant. Le résultat visuel diffère nettement, alors que la structure reste strictement identique entre les trois cartes. ## Le prix comme donnée, pas comme texte figé Plutôt que de saisir le prix en dur dans chaque instance, ce test a utilisé une balise dynamique personnalisée pointant vers un champ de métadonnée associé à chaque offre, stockée comme un article d'un type de contenu dédié aux plans tarifaires. Cette approche facilite une éventuelle mise à jour groupée des prix depuis l'administration, sans repasser par l'éditeur visuel à chaque changement. ## Ce que ce test ne couvre pas Ce montage s'arrête à la présentation visuelle de la grille tarifaire. L'intégration d'un système de paiement récurrent, la gestion des essais gratuits ou la connexion à une plateforme de facturation sortent totalement du périmètre : ces briques relèvent d'une intégration applicative distincte, généralement côté backend du produit SaaS lui-même. ## Limites observées sur cette version alpha - Certains contrôles de style avancés (dégradés complexes, ombres multiples) restent moins riches que sur l'éditeur classique au moment du test. - La conversion d'un container existant en composant ne fonctionne pas toujours de façon prévisible si la structure contient déjà des widgets hérités non atomiques. - La documentation officielle de cette fonctionnalité évolue rapidement : mieux vaut vérifier les notes de version avant de reproduire ce montage sur un projet client. > Sur un test comme celui-ci, mieux vaut construire le composant source sur une page de brouillon isolée avant de le déployer sur la page publique : un composant mal structuré dès le départ se corrige plus difficilement une fois dupliqué en plusieurs instances. ## Pour aller plus loin Cette grille tarifaire montre l'intérêt concret des composants réutilisables pour un cas d'usage simple et répétitif. Une fois la fonctionnalité stabilisée en version définitive, ce type de montage devrait gagner en fiabilité, notamment sur la gestion fine des variantes de style et la synchronisation entre composant source et instances.