Démarrage
Choisir entre Elark, Shelly et Home Assistant
Trois produits, trois philosophies différentes. Ce guide vous aide à comprendre ce qu’Elark fait réellement — de la supervision, pas du pilotage — et où il se situe par rapport à Shelly et Home Assistant.
Lecture 7 min
1. Pourquoi ce comparatif ?
Shelly Smart Control et Home Assistant sont des outils de pilotage : ils envoient des commandes aux appareils (allumer, éteindre, régler une consigne). Elark est différent : c’est un outil de supervision pour intégrateur — il affiche l’état de tout un parc d’installations en temps réel, avec de la traçabilité et de l’alerting, mais il n’envoie aucune commande à l’installation cliente. Piloter reste le rôle de l’app Shelly, de l’API du fabricant, ou d’un Home Assistant vers lequel vous exportez le workspace.
Ce comparatif s’adresse principalement aux intégrateurs domotiques qui veulent un outil métier pour superviser plusieurs installations clientes à la fois, avec un journal d’audit RGPD, un mode multi-tenant propre et la possibilité d’exporter une installation vers Home Assistant pour le pilotage effectif si le client le souhaite.
Spoiler : aucun des trois n’est « meilleur » dans l’absolu, et Elark ne remplace ni Shelly ni Home Assistant pour piloter au quotidien. Lisez la fin de l’article — il y a une section honnête pour chaque concurrent.
2. Tableau comparatif détaillé
| Critère | Elark | Shelly Cloud | Home Assistant |
|---|---|---|---|
| Hébergement | France (OVH, Roubaix) | États-Unis (Amazon AWS) | Self-host (chez vous) |
| Devices supportés | ESPHome + Shelly gen2/3/4 + Zigbee2MQTT + Tasmota | Modules Shelly uniquement | Tous, via intégrations et plugins HACS |
| Pilotage (envoi de commandes) | Non — supervision uniquement, aucune commande envoyée à l’installation cliente | Oui, c’est sa fonction principale | Oui, c’est sa fonction principale |
| Mode local LAN sans cloud (firmware) | web_server ESPHome toujours actif sur l’ESP (hors app Elark, qui reste cloud-only) | Coupé si le cloud est désactivé | Dépend de l’installation et du réseau |
| Mode intégrateur multi-clients | Natif via workspaces + claim-token | Limité (Shelly Pro Tools, séparation manuelle) | Non prévu, hub mono-foyer |
| Audit log RGPD | Insert-only immuable (IntegratorAudit) | Journal basique côté constructeur | Aucun journal métier natif |
| Multi-tenant MQTT scopé | Oui — topics t/<ws>/d/<claim>/... isolés par workspace | Non — un broker partagé sans isolation cliente | N/A (broker local mono-foyer) |
| Tarif de départ | 0 € (plan Découverte, 3 devices) | 0 € jusqu’à 20 devices (limite Shelly Cloud) | 0 € self-host, ou 6,5 $/mois via Nabu Casa |
| Scripts éditables côté device | Non — firmwares ESPHome compilés (YAML) | Oui — scripts JS Espruino à l’exécution | Oui — automations YAML + scripts Python via plugins |
| Export vers Home Assistant | Oui, via MQTT discovery natif | Non, intégration HA externe nécessaire | N/A (c’est lui Home Assistant) |
3. Quand choisir Elark
Elark n’est pas une app de pilotage aujourd’hui — elle ne remplace ni l’app Shelly ni Home Assistant pour actionner vos appareils. Elle est conçue pour les usages où la supervision d’un parc multi-clients, l’hébergement français et la traçabilité sont des critères de premier ordre. C’est le bon choix dans les cas suivants :
- Vous êtes intégrateur domotique et vous voulez superviser le parc de plusieurs clients depuis un seul compte — état en temps réel, alertes, journal d’audit et workspaces séparés. C’est exactement la raison d’être du plan Intégrateur ; le pilotage effectif reste entre les mains du client ou de son installation Home Assistant.
- Vous avez déjà des modules Shelly et vous voulez superviser leur état aux côtés de vos modules ESPHome dans une même app. Elark consomme les topics MQTT Shelly gen2/3/4 nativement (voir notre guide Shelly gen2 / 3 / 4 (MQTT)) — en lecture seule.
- Vous voulez exporter vers Home Assistant pour le pilotage effectif. Elark publie un endpoint MQTT discovery (
/workspaces/<id>/ha-discovery-export) qui permet de récupérer toute votre installation dans HA en quelques minutes, sans reconfiguration. - Vous voulez du local-first côté firmware (
web_serverESPHome toujours actif sur le LAN, en dehors de l’app Elark) avec, en option, un cloud français hébergé en France chez OVH (RGPD, données qui ne quittent pas l’UE).
4. Quand choisir Shelly Smart Control
Shelly Smart Control est une excellente app constructeur, polie et bien intégrée à ses propres modules. C’est le bon choix dans ces cas :
- Vous n’avez que des modules Shelly et vous ne prévoyez pas d’élargir à de l’ESPHome ou du Zigbee. L’UI Shelly est plus aboutie pour piloter spécifiquement les fonctions avancées (Shelly Plus 2PM, Shelly Pro 3EM…) que les bridges génériques.
- Vous voulez des scripts JS éditables à l’exécution directement sur le device, sans recompiler un firmware. Espruino sur les Shelly gen2+ est unique dans cet écosystème — Elark et HA demandent tous deux un workflow de compilation ou de redémarrage.
- Vous ne voulez payer aucune mensualité, jamais. Le plan gratuit Shelly Cloud couvre jusqu’à 20 devices, ce qui est confortable pour une maison standard.
À noter : si vous voulez quand même garder Shelly Smart Control comme app principale tout en récupérant l’hébergement français + l’audit RGPD, vous pouvez bridger vos Shelly sur le broker Elark en parallèle. Ce n’est pas exclusif.
5. Quand choisir Home Assistant
Home Assistant reste la référence du hub domotique auto-hébergé. C’est le bon choix si :
- Vous êtes à l’aise avec l’auto-hébergement sur Raspberry Pi, NUC, serveur Proxmox ou Docker, et vous acceptez la maintenance que cela implique (mises à jour mensuelles, sauvegardes, réseau, certificats…).
- Vous voulez l’écosystème HACS le plus large : intégrations Tuya, Sonos, Tesla, Plex… il y a un plugin pour à peu près tout. Aucun autre projet ne s’en approche.
- Vous ne gérez que votre propre maison (un seul foyer, pas de séparation client/installateur, pas de besoin de facturation tierce).
Home Assistant et Elark ne s’excluent pas : beaucoup d’utilisateurs Elark continuent à utiliser HA en parallèle pour les automations avancées, en consommant le flux MQTT discovery d’Elark.
6. Migration entre les trois
Voici les chemins de migration les plus courants — ils sont tous techniquement possibles, mais leur niveau de finition varie.
De Shelly Cloud vers Elark
Roadmap : un workflow OAuth Shelly Cloud est en cours de spécification pour importer automatiquement votre liste de devices depuis Shelly Cloud vers un workspace Elark. En attendant, la méthode manuelle (passer chaque Shelly en MQTT pointé vers le broker Elark) est documentée dans le guide Shelly gen2 / 3 / 4 (MQTT). Comptez 2 à 5 minutes par module.
De Home Assistant vers Elark
Le bridge MQTT est la voie royale. Si vos devices HA publient déjà sur un broker MQTT, il suffit de pointer ce broker vers Elark (ou d’ajouter Elark comme broker secondaire). Pour les devices ESPHome, créez la fiche dans Elark pour obtenir un claim_code, collez-le dans votre propre secrets.yaml (configuration MQTT scopée par workspace), puis recompilez et reflashez vous-même — voir le guide Ajouter un appareil.
Vers Home Assistant (sortie d’Elark)
Le scénario « je teste Elark, je veux pouvoir partir » est explicitement supporté. Chaque workspace expose un endpoint d’export MQTT discovery : /workspaces/<id>/ha-discovery-export. L’output est directement consommé par HA et recrée la liste complète de vos devices avec leurs entités, sans configuration manuelle. Voir le guide Home Assistant (export) pour la procédure pas à pas.
Le principe que nous suivons chez Elark : votre installation domotique vous appartient. Si demain Elark ne vous convient plus, vous devez pouvoir partir avec vos devices et vos données. C’est aussi pour ça que les firmwares ESPHome qu’on génère ne sont pas verrouillés — ils restent compatibles avec Home Assistant, l’ESPHome dashboard officiel, et n’importe quel broker MQTT.