Sur une tablette murale, un bouton dont seule l’icône réagit au toucher, c’est un bouton raté : la main tape à côté, deux fois sur trois. Voici comment j’ai reconstruit mes boutons Home Assistant avec Bubble Card pour que toute la surface de la carte réponde, sans erreur silencieuse au passage.
button_type / tap_action : switch pour un appel de service, icon pour une navigation. Sur mon dashboard j’ai dû corriger une douzaine de boutons qui n’avaient qu’une icône cliquable au lieu de toute la carte. Retiens la règle simple : jamais de button_type: switch avec un tap_action: navigate, Bubble Card ignore la navigation et tente de togguer l’entité à la place.
Le problème du bouton qui ne répond qu’à moitié
J’ai une tablette fixée au mur de l’entrée qui sert de télécommande maison : volets, scènes, alarme, chauffage. Le souci avec les cartes Lovelace standard, c’est qu’une bonne partie de la surface visuelle (le fond de la carte, le texte, les marges) reste inerte au toucher. Sur un écran tactile utilisé debout, souvent avec les mains pas totalement libres, ce genre de zone morte se traduit par des taps ratés en boucle. Ce n’est pas un détail : c’est la différence entre un dashboard qu’on utilise sans y penser et un dashboard qu’on évite parce que ça demande de viser.
Bubble Card résout ça nativement, à condition de comprendre comment la librairie interprète ses propres options. Et c’est là que ça devient intéressant du point de vue développeur : le comportement n’est pas documenté de façon évidente, il faut le déduire de l’expérience.
Le contexte : une tablette murale, pas un smartphone
Le contexte technique compte ici. Sur téléphone, l’app Home Assistant tolère une marge d’erreur : l’écran est proche du visage, on peut ajuster le geste. Sur une tablette murale en usage quotidien (lumières, volets, scènes à la volée en sortant d’une pièce), l’exigence est différente : chaque carte doit se comporter comme un vrai bouton physique, cliquable sur toute sa surface, avec un feedback visuel net.
Contrainte supplémentaire : pas de développement JS custom lourd, je voulais rester sur des cartes déclaratives YAML, modifiables rapidement sans recompiler quoi que ce soit (l’éditeur visuel aurait suffi pour un usage basique, mais je voulais aller plus loin sur le rendu tactile). Bubble Card coche cette case, mais impose ses propres règles internes qu’il faut respecter à la lettre sous peine de comportements silencieusement cassés.
L’implémentation : deux patterns, deux button_type
Cas 1 : un bouton qui déclenche une action (call-service)
Pour un bouton qui appelle un service (basculer une scène, activer une alarme, lancer un script), le pattern qui fonctionne :
type: custom:bubble-card
card_type: button
button_type: switch
entity: scene.soiree_salon
card_layout: large
show_state: false
tap_action:
action: call-service
service: scene.turn_on
target:
entity_id: scene.soiree_salon
styles: |
.bubble-switch { display: none !important; }
Le button_type: switch combiné à une entity valide rend toute la carte tappable, le tap_action: call-service est bien respecté, et la ligne CSS masque juste le petit toggle visuel qu’on ne veut pas afficher pour une scène (ce n’est pas un interrupteur, ça n’a pas de sens de le montrer).
Cas 2 : un bouton qui ouvre un popup (navigate)
Pour un bouton de navigation vers un popup (volets, chauffage, éclairage), le pattern change complètement :
type: custom:bubble-card
card_type: button
button_type: icon
entity: cover.volets_salon
card_layout: large
tap_action:
action: navigate
navigation_path: /dashboard-maison/0#volets
styles: |
.bubble-main-icon-container {
position: absolute !important;
inset: 0 !important;
width: auto !important;
height: auto !important;
border-radius: inherit !important;
margin: 0 !important;
}
Ici, button_type: icon respecte la navigation, et on étend le conteneur de l’icône à toute la carte via CSS pour retrouver le même confort tactile qu’avec switch.
Fais-toi un tableau mental à deux lignes avant d’ajouter le moindre bouton : call-service va avec switch + toggle masqué, navigate va avec icon + conteneur étendu. Ça évite de redécouvrir le bug à chaque nouvelle carte.
Les pièges rencontrés
Le vrai piège, je l’ai découvert en croisant les deux patterns par erreur : button_type: switch avec un tap_action: navigate. Résultat, Bubble Card ignore purement et simplement la navigation et tente à la place de togguer l’entité associée. Sur un bouton pointant vers une entité d’alarme, ça se traduit par une tentative d’appel à un service qui n’existe pas pour ce domaine (l’équivalent d’un turn_off sur une entité qui ne l’expose pas), et donc une erreur silencieuse dans les logs, pas de crash visible côté interface, juste un bouton qui ne fait rien de ce qu’on attend.
Le symptôme est sournois parce que visuellement tout semble correct : la carte a la bonne taille, le bon style, elle réagit au clic. C’est seulement en observant qu’aucun popup ne s’ouvre, ou en allant fouiller les logs, qu’on comprend que le button_type est en cause. Depuis, je fais systématiquement le test manuel sur chaque nouveau bouton avant de le considérer terminé : un clic doit produire exactement l’effet attendu, pas une variante approchante.
Deuxième piège plus insidieux : sur les cartes qui vivent dans une grille avec grid_options, la mise en page peut sembler correcte en prévisualisation mais casser une fois le dashboard réellement affiché en usage, si l’option n’est posée que sur la carte interne et pas sur l’élément englobant. Un simple copier coller de bouton d’une section à une autre peut donc suffire à réintroduire le bug sans qu’on s’en rende compte immédiatement.
Éditeur visuel ou YAML : ce qu’il faut savoir
Petite précision utile pour les lecteurs qui ne codent pas au quotidien : Bubble Card, comme la plupart des cartes Lovelace, se configure normalement via l’éditeur visuel intégré à Home Assistant, formulaires et menus déroulants inclus, sans écrire une ligne de YAML. Pour un dashboard simple, ajouter une carte, choisir son button_type et relier une entité se fait entièrement au clic. C’est le point de départ recommandé, surtout si le YAML n’est pas un outil du quotidien.
Le YAML redevient utile dès qu’on sort du cas standard : c’est exactement ce que montre cet article, avec le CSS custom sur .bubble-main-icon-container, les réglages fins de grid_options ou les patterns d’accordéon un peu plus complexes, que l’éditeur visuel ne couvre pas complètement. À noter aussi, même si ce n’est pas le sujet direct des dashboards : la mise à jour Home Assistant 2026.7 a surtout fait progresser les automatisations sans YAML, avec des triggers orientés intention devenus le comportement par défaut de l’éditeur. Elle confirme la tendance générale de l’interface à réduire le besoin de code pour les usages courants, même si les cartes Lovelace, elles, n’ont pas changé sur ce point.
Bilan et pour aller plus loin
Le résultat concret : tous les boutons d’action et de navigation de mon dashboard mural répondent maintenant sur toute leur surface, ce qui a clairement réduit les taps ratés à l’usage quotidien. Ce que je changerais si c’était à refaire : documenter la règle button_type dès le premier bouton créé plutôt que de la redécouvrir par erreur au fil des semaines, ça m’aurait évité de repasser sur une bonne dizaine de cartes après coup.
Ce qui reste à améliorer : uniformiser un thème de couleurs automatique par domaine d’entité (lumière, volet, alarme) pour que la couleur d’un bouton donne un indice immédiat sur sa nature sans avoir à lire le texte, et industrialiser les modifications en masse via un script de transformation plutôt que d’éditer chaque carte à la main quand une règle de style change globalement.
FAQ
Pourquoi ne pas utiliser les cartes Lovelace standard plutôt que Bubble Card ?
Les cartes standard n’offrent pas de zone tactile pleine largeur sans CSS custom lourd. Bubble Card intègre ce comportement nativement, à condition de bien choisir son button_type.
Le bug du bouton qui ne réagit pas à la navigation est-il documenté officiellement ?
Pas clairement. C’est un comportement observé à l’usage : button_type: switch prend le pas sur tap_action: navigate et tente un appel de service à la place.
Faut-il toujours masquer le toggle visuel avec display: none ?
Seulement si l’entité n’est pas un vrai interrupteur (scène, script, alarme). Pour un vrai switch ou une lumière, garder le toggle visible a du sens.
Ce pattern fonctionne-t-il aussi bien sur smartphone que sur tablette murale ?
Oui, mais le bénéfice est surtout perceptible sur grand écran tactile utilisé debout, où la marge d’erreur du geste est plus faible.
Stack utilisée
- Home Assistant (dashboard type
sections) - Bubble Card (carte custom
custom:bubble-card) - Tablette murale tactile dédiée au contrôle maison
- YAML pour la déclaration des cartes et des conditions de visibilité
- CSS inline (
styles) pour ajuster le rendu tactile des boutons
