La question derrière la question
« Mais est-ce qu’on peut vraiment en vivre ? » La question revient sans arrêt sur les forums, parfois en clair, plus souvent déguisée. Quelqu’un raconte qu’il a Home Assistant chez lui depuis des années, que ses amis n’arrêtent pas de lui demander s’il ne pourrait pas le leur installer aussi — et puis tombe la phrase qui trahit l’hésitation véritable : « Mais peut-on bâtir un vrai business là-dessus ? C’est de l’open source, il n’y a personne derrière. »
Je trouve cette question honnête, et je la comprends. Qui fait reposer son revenu sur quelque chose veut savoir sur quoi il s’appuie. Avec un système fermé, son constructeur, sa hotline et son contrat, c’est plus net au premier coup d’œil. Avec Home Assistant, on dirait qu’il n’y a d’abord — personne.
Sauf que ce premier coup d’œil se trompe. Et la preuve a plus de quinze ans, tourne sur quelque quarante pour cent de tous les sites du web et s’appelle WordPress.
Trois peurs, un seul et même schéma
Quand je discute avec des gens qui caressent l’idée de s’occuper professionnellement d’installations HA, ce sont presque toujours les trois mêmes objections qui reviennent. Pas comme des excuses — comme de vraies inquiétudes, légitimes.
La première : il n’y a aucun constructeur derrière. Qui est responsable quand quelque chose casse ? Vers qui je pointe quand le client demande pourquoi sa serrure connectée ne répond plus depuis la mise à jour ? Chez Loxone ou Control4, il y a un éditeur, une certification, une chaîne d’escalade. Avec l’open source, il y a un ticket GitHub et, dans le doute, un haussement d’épaules.
La deuxième : je dois sans cesse être sur place. L’idée que chaque incident impose un déplacement, faute de pouvoir intervenir à distance, est ruineuse pour un modèle économique. Qui passe quarante minutes en voiture par incident ne peut pas suivre vingt clients. Cinq tout au plus, et encore, à condition qu’ils ne fassent pas tous des histoires en même temps.
La troisième : ce truc est instable. Les mises à jour font sauter des configurations, un plugin casse après une mise à jour HACS, une rupture de compatibilité dans le core tue une automatisation du jour au lendemain. Home Assistant passe encore, aux yeux de beaucoup, pour une plateforme de bricoleur — et sur du bricolage, on ne monte pas une activité.
Trois peurs, un dénominateur commun : le sentiment de s’appuyer sur quelque chose qui peut se dérober sous vos pieds à tout instant, sans que personne ne vous rattrape. Ce sentiment-là, on l’a déjà connu. Dans un autre écosystème, avec une histoire d’une ressemblance troublante.
WordPress avait exactement cette réputation
Rembobinez, disons, jusqu’en 2010. WordPress était open source, gratuit, porté par une communauté. Et il avait précisément la réputation qu’a Home Assistant aujourd’hui. « Les mises à jour cassent le site. » « Les plugins sont un cauchemar de sécurité. » « Pas de support officiel, vous êtes seul face à vous-même. » « Pour un vrai business, on prend du sérieux, pas un bidule récupéré sur le web. »
Qui proposait à l’époque à une PME de monter son site d’entreprise sur WordPress devait se justifier. Aujourd’hui, c’est l’inverse — qui ne le propose pas doit expliquer pourquoi.
Que s’est-il passé ? Pas que WordPress soit devenu stable du jour au lendemain ni qu’un grand groupe ait endossé la responsabilité. Ce qui s’est passé est autre chose : il est né toute une branche de gens qui exploitent WordPress de façon professionnelle. Des agences, des freelances, des structures à une personne qui ne montent pas un site pour ensuite tirer leur révérence, mais qui l’entretiennent dans la durée. Appliquer les mises à jour, mener les sauvegardes, réagir en cas d’incident — contre rémunération, chaque mois, de manière prévisible. Les fameux plans de maintenance et de care qui forment aujourd’hui l’épine dorsale d’innombrables agences. Du chiffre d’affaires récurrent tiré d’un logiciel pour lequel personne ne paie de licence.
C’est le point sur lequel j’aime bien coincer les futurs intégrateurs HA. Le constructeur manquant n’est pas un trou. C’est le fondement même de l’activité. Justement parce qu’aucune hotline n’existe, le client a besoin de quelqu’un pour tenir ce rôle — et ce quelqu’un, c’est vous. « Aucun éditeur derrière », du point de vue du client, veut dire : « J’ai besoin d’un humain en qui j’ai confiance. » Ce n’est pas un manque. C’est de la demande.
La partie que la plupart oublient : l’outil
Mais — et j’y tiens, parce qu’ici on lâche souvent trop vite un « eh bien lance-toi, alors » — la branche WordPress n’est pas née de la seule bonne volonté. Elle est devenue possible le jour où les outils ont fini par exister pour dompter la folie.
Imaginez un prestataire avec quatre-vingts sites WordPress de clients. Quatre-vingts identifiants. Quatre-vingts listes de plugins. Quatre-vingts routines de sauvegarde, quatre-vingts états de mise à jour. Qui se connecte chaque matin un par un sur chaque site pour vérifier si la nuit a cassé quelque chose abandonne au bout de deux semaines. Ça ne passe pas à l’échelle. C’est la peur du déplacement du monde WordPress, simplement transposée au numérique.
Le problème a été résolu par une catégorie de logiciels qu’on appelle les tableaux de bord de gestion. L’exemple libre le plus connu est MainWP — auto-hébergé, open source, conçu pour exactement cette douleur. Vous installez une petite extension sur chaque site client, et à partir de là vous voyez tout depuis un seul tableau de bord : quel site a besoin d’une mise à jour, où un plugin est obsolète, lequel est hors ligne en ce moment, quand la dernière sauvegarde a tourné. Les mises à jour du core, des plugins et des thèmes sur tous les sites d’un coup. Du monitoring d’uptime. Des contrôles de sécurité. Des rapports que vous envoyez au client pour qu’il voie ce qu’il paie.
Au lieu de se connecter sur quatre-vingts sites, le prestataire jette un œil une seule fois sur un tableau et voit où il faut agir. Ce qui demande un accès distant, il le règle à distance. Le déplacement — le grand épouvantail — se réduit aux rares cas où il faut vraiment poser la main sur le matériel.
C’est précisément cet outil qui a longtemps manqué pour Home Assistant. Et tant qu’il manque, la peur du déplacement reste légitime.
HA Fleet Manager, c’est le moment MainWP de Home Assistant
Voici qu’entre en scène le produit derrière ce blog — et je dis sciemment ce qu’il est et ce qu’il n’est pas, parce que le discours pub sur ce sujet me tape sur les nerfs à moi aussi.
HA Fleet Manager est à Home Assistant ce que MainWP est à WordPress. Un tableau de bord central pour de nombreuses instances. Vous installez une intégration custom sur chaque installation client, et ensuite vous voyez l’état de tout le portefeuille d’un coup d’œil : quelle instance est en ligne, quelles intégrations tournent, quels plugins HACS sont installés et dans quelle version, si des erreurs critiques figurent dans les logs. Un accès distant à l’interface HA quand vous devez intervenir — mais seulement après que le client l’a autorisé, et pour une fenêtre limitée dans le temps. Un historique de maintenance qui ne se résume pas à votre mémoire.
Le parallèle tient jusque dans le détail. La peur du déplacement se dissipe dans le monde HA pour la même raison qu’à l’époque dans le monde WordPress : parce que vous n’avez plus à vous rendre sur chaque installation ni à vous connecter une par une pour savoir comment elle se porte. Vous le voyez. Et s’il y a quelque chose, vous intervenez à distance. À quoi ça ressemble au quotidien, je l’ai déroulé ailleurs sous forme de petite histoire — la cascade Z2M un jeudi après-midi, trois clients, quarante minutes, aucun déplacement.
Ce que HA Fleet Manager n’est pas : un produit fini, durci par des décennies, doté de l’étendue fonctionnelle des suites RMM établies. Il est jeune. Il est en train de naître. Mais MainWP aussi était jeune en 2013, et WordPress en 2010 encore plus. Les écosystèmes mûrissent quand quelqu’un commence à construire les outils dont les pros ont besoin.
Reste la troisième peur : la stabilité
Du constructeur manquant et du souci du déplacement, nous avons parlé. La troisième — « le système flanche parce que les mises à jour cassent des choses » — mérite sa propre réponse, honnête. Car contrairement aux deux autres, elle ne s’évacue pas d’un « WordPress y est bien arrivé, lui aussi ».
D’abord : oui, les mises à jour cassent parfois des choses. C’est vrai et ça le restera. Mais c’est justement là le levier professionnel, pas un motif d’exclusion. La différence entre un hobbyiste et un prestataire, ce n’est pas que chez le prestataire rien ne casse jamais. C’est que le prestataire s’en aperçoit le premier — avant que le client n’appelle. Qui déploie une mise à jour de façon contrôlée sur une installation pilote, observe, et ne la passe à la flotte qu’ensuite, a transformé « quelque chose a cassé » en opération planifiée. C’est exactement à ça que sert un tableau de bord de flotte : non pas à empêcher les pannes, mais à les voir tôt et regroupées.
Ensuite : la réputation de « bidouille » est en retard sur la réalité. Home Assistant est sorti du fond de la cave depuis longtemps. Il y a une fondation, un cycle de releases fixe, le programme « Works with Home Assistant », du matériel officiel. Ce n’est plus un script du week-end, mais une plateforme aux millions d’installations. Qui dit encore « bidule de bricoleur » décrit l’état des choses d’il y a cinq ans.
Et enfin, le point qui me tient le plus à cœur : avec l’open source, la stabilité n’est pas une propriété que le constructeur livre. C’est une prestation que le prestataire fournit. Ça sonne comme plus de responsabilité — ça l’est. Mais c’est exactement la responsabilité pour laquelle le client paie. Un contrat de maintenance ne vend pas « le logiciel ne casse jamais ». Il vend « s’il y a quelque chose, quelqu’un s’en occupe, et le plus souvent avant que vous ne le remarquiez ». Ça, un éditeur avec son système fermé sait souvent moins bien le livrer qu’un humain qui connaît justement ces vingt installations.
Ce que ça veut dire pour vous, si vous vous lancez
Je ne veux rien enjoliver. Bâtir un business HA, c’est du travail, et ce n’est pas un succès garanti qui roule tout seul. Mais l’excuse « impossible, c’est juste de l’open source » est historiquement réfutée. Elle l’a déjà été dans un marché structurellement très proche, à fond, et par des gens qui en vivent aujourd’hui confortablement.
Ce qu’il faut, c’est la même chose qu’à l’époque : la disposition à tenir soi-même le rôle du constructeur manquant — comme personne de confiance, pas comme bricoleur. Un modèle économique à revenu récurrent, pour ne pas vivre d’urgence en urgence. Et un outil qui ne vous force pas à vous connecter chaque matin une par une sur vingt installations. À quoi ressemble ce métier concrètement, de la journée type aux taux horaires, je l’ai décrit plus en détail dans le portrait du métier d’intégrateur HA. Et si vous hésitez encore sur l’outil adapté à votre échelle, le comparatif des six façons de gérer plusieurs instances HA vous aidera peut-être.
Les gens de WordPress n’avaient ni MainWP ni la certitude, en 2010, que leur branche allait naître. Ils se sont simplement lancés. Aujourd’hui, vous vous lancez, et l’outil existe déjà.
C’est, à vrai dire, un assez bon moment.
Divulgation : HA Fleet Manager est le produit derrière ce blog. Le parallèle avec WordPress n’en est pas pour autant un argument de vente — c’est la raison pour laquelle je crois que ce marché fonctionne.