HACS dans Home Assistant, le bon moment pour l'installer

HACS n’est pas un store officiel. C’est le premier point à garder.

HACS signifie Home Assistant Community Store. Le nom est parlant, mais un peu piégeux : “store” ne veut pas dire validation officielle par l’équipe Home Assistant. HACS facilite surtout la découverte, l’installation et le suivi de projets communautaires hébergés ailleurs, souvent sur GitHub. Sans HACS, installer une custom integration revient souvent à copier un dossier dans custom_components, vérifier la structure, redémarrer, suivre le dépôt source et recommencer quand une mise à jour arrive.

Avec HACS, vous gardez un point de gestion centralisé, plus lisible et moins bricolé.

Ça ne rend pas le code plus sûr par magie. HACS ne remplace pas votre jugement sur le dépôt, le rythme des releases, les issues ouvertes ou la compatibilité avec votre version Home Assistant. Il réduit la friction d’installation; il ne supprime pas la responsabilité d’exploitation.

Le bon signal, c’est le besoin précis, pas la curiosité. Vous voulez une intégration non officielle pour un équipement que Home Assistant ne gère pas encore correctement, ou une carte graphique plus propre que les cartes natives. Vous suivez un dépôt connu, actif, documenté, avec des releases lisibles. Là, HACS devient un vrai gain de temps, parce qu’il remplace une maintenance manuelle pénible par un flux centralisé et vous évite de traiter chaque mise à jour comme une opération de fichiers.

Le mauvais signal, c’est l’installation “parce que tout le monde l’a”. Une instance neuve, avec dix entités et trois automatisations, n’a pas forcément besoin de HACS. Elle a plutôt besoin de noms d’entités propres, de sauvegardes, d’un dashboard lisible et d’une logique d’automatisation que vous comprenez encore dans six mois.

Le meilleur HACS est souvent celui qui reste discret. Deux ou trois dépôts bien choisis valent mieux qu’une page entière de composants dont vous ne connaissez plus l’origine.

HACS 2.0 a rendu l’expérience plus propre. Le parcours est plus moderne, plus naturel dans Home Assistant, et la gestion des catégories paraît moins bricolée qu’avant.

Mais le point dur ne bouge pas : le contenu reste communautaire. Une custom integration peut être excellente, maintenue par quelqu’un de très compétent, puis ralentir parce que le mainteneur change de matériel, de job ou de priorité. Une carte Lovelace peut suivre Home Assistant pendant deux ans puis casser sur une refonte frontend. C’est le prix normal d’un écosystème ouvert.

Il faut donc lire HACS comme un gestionnaire de dépendances domestique. Chaque dépôt ajouté devient une petite dette technique : il faudra le mettre à jour, vérifier les breaking changes, comprendre pourquoi il disparaît ou le remplacer si le projet s’arrête.

Avant de toucher à HACS, faites une sauvegarde complète, pas une sauvegarde “je crois qu’elle existe”. Il faut une sauvegarde que vous savez retrouver, télécharger et restaurer. Sur Home Assistant OS ou Supervised, ce réflexe doit être banal. Sur une installation Container ou Core, il faut savoir où vivent vos fichiers de configuration, vos secrets et vos volumes, sinon le rollback reste théorique.

Vérifiez ensuite votre mode d’installation. HACS ne se vit pas pareil sur Home Assistant OS, Container ou Core. Les chemins, les redémarrages, la gestion des dépendances et la méthode de rollback diffèrent. Si vous ne savez pas quel type d’installation vous utilisez, commencez par ça. Le type d’installation conditionne la marche arrière.

Le compte GitHub n’est pas un détail non plus. HACS s’appuie sur GitHub pour accéder aux dépôts et gérer certains flux. Si vous ne voulez pas associer GitHub à votre instance, ou si votre accès réseau est verrouillé, anticipez l’autorisation GitHub avant de commencer.

1. Une sauvegarde récente et récupérable.
2. Un accès administrateur à Home Assistant.
3. Le type d’installation clairement identifié : OS, Supervised, Container ou Core.
4. Un compte GitHub prêt pour l’autorisation HACS.
5. Un créneau de test où une panne domotique temporaire n’est pas critique.

Suivez la documentation HACS, pas un vieux tutoriel : c’est le raccourci le plus sûr. Le déroulé exact dépend de votre version et du mode d’installation. Les méthodes ont changé avec le temps, et certains anciens articles mélangent encore téléchargement manuel, dépôt personnalisé, commandes shell et anciens écrans. Sur une instance que vous utilisez tous les jours, ce décalage suffit à créer une panne évitable, surtout si vous ne savez plus quelle étape venait de quelle source.

La méthode propre tient en quatre temps. D’abord, sauvegarde et vérification des prérequis. Ensuite, installation de HACS selon la documentation officielle. Puis redémarrage et authentification GitHub. Enfin, test avec un seul dépôt utile, pas dix. Ce dernier point évite de confondre panne HACS, panne du dépôt et erreur de configuration.

Commencez par un composant peu critique. Une carte Lovelace est souvent moins risquée qu’une intégration qui pilote chauffage, alarme ou portail. Si vous cassez un dashboard secondaire, vous respirez. Si vous cassez une intégration centrale un dimanche soir, vous allez détester votre propre curiosité.

Un dépôt sérieux laisse des traces. Tout doit se voir vite.

1. Documentation claire et exemples de configuration.
2. Releases récentes, datées, avec changements lisibles.
3. Issues traitées, pas seulement empilées.
4. Compatibilité annoncée avec les versions Home Assistant récentes.

Un dépôt abandonné depuis dix-huit mois peut encore fonctionner aujourd’hui, puis casser brutalement lors d’une mise à jour Home Assistant. Ce n’est pas une faute morale du mainteneur; c’est juste une dépendance communautaire qu’il faut traiter comme telle, avec un plan de retrait possible.

Regardez aussi le périmètre. Une carte Lovelace qui affiche mieux une statistique n’a pas le même impact qu’une custom integration qui remplace la communication avec une API cloud ou un équipement critique. Plus le composant touche une fonction centrale, plus vous devez être exigeant sur la maintenance.

Je garde une règle simple : si je ne peux pas expliquer en une phrase pourquoi ce dépôt est installé, je ne l’installe pas. Si je ne sais pas ce qu’il remplace, je ne l’installe pas. Si je ne peux pas le supprimer sans perdre une fonction importante, je documente le rollback avant de cliquer.

HACS ne doit pas remplacer les intégrations natives quand elles font déjà le travail. C’est une erreur classique : installer une custom integration parce qu’elle semble plus “complète”, alors que l’intégration officielle couvre le besoin réel avec moins de dépendances et une meilleure trajectoire de maintenance. Si l’intégration native expose les entités utiles, tient les mises à jour et reste compatible avec vos automatisations, gardez-la. La simplicité a une vraie valeur quand l’instance pilote des routines quotidiennes et que vous devrez encore la maintenir dans deux ans.

HACS ne doit pas non plus remplacer une architecture propre. Une instance avec des noms d’entités incohérents, des helpers inutilisés et des automatisations copiées sans logique ne devient pas meilleure parce qu’on lui ajoute une carte plus jolie. Dans ce cas, le vrai chantier est le nettoyage de configuration : renommer, documenter, simplifier, supprimer les doublons et vérifier les dépendances.

Dernier point : HACS ne remplace pas la lecture des logs. Quand une custom integration plante, commencez par les journaux Home Assistant, la page du dépôt, les issues récentes et la version installée. Ne désinstallez pas tout au hasard. Un diagnostic propre prend dix minutes; une reconstruction brouillonne peut prendre la soirée.

Si quelque chose casse après une installation HACS, isolez le changement.

1. Désactivez ou supprimez le dernier dépôt ajouté.
2. Redémarrez Home Assistant proprement.
3. Vérifiez les logs Home Assistant.
4. Si le problème touche Lovelace, testez cache navigateur et mode privé.

Les cartes frontend donnent parfois l’impression d’une panne Home Assistant alors que le backend fonctionne parfaitement. Ne mélangez pas diagnostic Lovelace, diagnostic intégration et diagnostic core.

Si le problème touche une intégration, regardez d’abord la version Home Assistant, la version du dépôt HACS et les breaking changes annoncés. Beaucoup de pannes viennent d’un décalage simple : une API modifiée, un manifeste mis à jour, une dépendance Python qui ne suit plus, ou une option YAML qui a changé de nom. La bonne réponse n’est pas toujours “revenir en arrière”; parfois, il faut corriger la configuration.

Gardez une note locale pour les composants sensibles : nom du dépôt, rôle, version installée, entités créées, automatisations dépendantes et méthode de retrait. Ce document paraît excessif quand tout marche. Il devient précieux le jour où une mise à jour coupe le chauffage ou rend un dashboard principal inutilisable.

Planifiez un nettoyage tous les trois ou quatre mois. C’est peu, mais ça suffit à éviter le cimetière de dépôts.

Ouvrez HACS, listez les dépôts installés, puis demandez-vous lesquels sont encore utilisés dans un dashboard, une automatisation ou une intégration active. Tout composant sans usage clair doit être retiré après vérification. La dette technique commence souvent par un composant “gardé au cas où”.

Sur une instance sérieuse, gardez aussi une mini-note de dépendance : composant, fonction couverte, dashboard concerné, automatisations liées, alternative native possible. Le jour où Home Assistant change une API ou où un mainteneur archive son projet, cette note donne un plan de remplacement au lieu d’une enquête dans l’urgence.

Ne mettez pas tout à jour en vrac : c’est le meilleur moyen de perdre le fil. Home Assistant core, add-ons, HACS, custom integrations, cartes frontend : si tout change en une session, le diagnostic devient pénible. Vous ne savez plus si la panne vient du core, d’un changement YAML, d’un dépôt HACS ou d’un cache navigateur. Une instance domotique se maintient par étapes, surtout quand elle contrôle des usages réels.

Mettez à jour par lots compréhensibles. Lisez les release notes des dépôts sensibles. Attendez quelques jours pour les composants critiques si la mise à jour n’apporte rien d’urgent. Et surtout, gardez une sauvegarde avant gros changement. Le temps perdu à faire une sauvegarde est ridicule face au temps perdu à reconstruire une instance.

Sur les cartes Lovelace, pensez aussi au cache frontend. Une carte qui semble cassée après mise à jour peut parfois demander un refresh dur, une purge cache ou un redémarrage navigateur. Ne partez pas tout de suite dans une réinstallation complète.

Mon verdict est simple : installez HACS pour un usage, jamais pour flâner. Installez HACS si vous avez déjà un besoin précis et que votre instance est propre. Exemple typique : une intégration communautaire connue manque à votre setup, ou une carte Lovelace améliore vraiment un dashboard utilisé tous les jours. Dans ce cas, HACS fait gagner du temps, clarifie les mises à jour et évite les copies manuelles hasardeuses, sans vous obliger à transformer Home Assistant en laboratoire permanent.

Évitez HACS si votre Home Assistant est récent, instable ou mal sauvegardé. Évitez aussi si vous êtes encore en train de comprendre les intégrations natives. Ajouter une couche communautaire trop tôt masque les vrais problèmes : entités mal nommées, automatisations trop fragiles, dashboards trop chargés ou matériel mal choisi.

Prenez HACS comme un outil d’exploitation. Un dépôt, une raison, un rollback. Si vous tenez cette discipline, HACS devient l’un des meilleurs accélérateurs de Home Assistant. Si vous l’utilisez comme un magasin de gadgets, il deviendra votre prochaine dette technique.