Choisir entre Elark, Shelly et Home Assistant

1. Pourquoi ce comparatif ?

Elark, Shelly Smart Control et Home Assistant répondent tous les trois au même besoin de base — piloter des objets connectés chez soi — mais avec des promesses très différentes. Avant de vous engager dans un écosystème, autant savoir ce que vous y gagnez et ce que vous y perdez.

Ce comparatif s’adresse à deux profils :

• Les particuliers qui hésitent entre la simplicité d’une app constructeur (Shelly), la puissance d’un hub auto-hébergé (Home Assistant) et l’équilibre cloud français + local-first proposé par Elark.
• Les intégrateurs domotiques qui veulent un outil métier pour gérer plusieurs clients, avec un journal d’audit RGPD, un mode multi-tenant propre et la possibilité d’exporter une installation vers Home Assistant si le client le souhaite à terme.

Spoiler : aucun des trois n’est « meilleur » dans l’absolu. Ils sont juste optimisés pour des usages différents. Lisez la fin de l’article — il y a une section honnête pour chaque concurrent.

2. Tableau comparatif détaillé

3. Quand choisir Elark

Elark est conçu pour les usages où l’hébergement français, la séparation client/intégrateur et le local-first sont des critères de premier ordre. C’est le bon choix dans les cas suivants :

• Vous êtes intégrateur domotique et vous voulez un outil métier pour gérer plusieurs clients depuis un seul compte, avec facturation au client, journal d’audit et workspaces séparés. C’est exactement la raison d’être du plan Intégrateur.
• Vous avez déjà des modules Shelly et vous voulez les bridger avec de nouveaux 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)).
• Vous voulez l’option Home Assistant pour plus tard, sans vous y engager aujourd’hui. 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 garanti (web_server ESPHome toujours actif sur le LAN) mais avec, en option, un cloud français hébergé en France chez OVH (RGPD, données qui ne quittent pas l’UE).
• Vous tenez à la signature OTA : l’OTA Elark exige une signature Ed25519 sur le firmware côté ESP, ce qui empêche un attaquant d’injecter un firmware malveillant via le réseau.

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, le plus propre est de les re-flasher depuis un template du marketplace Elark, qui inclut déjà la configuration MQTT scopée par workspace et la signature OTA Ed25519.

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.