Le projet en bref
Le Château Barthélemy, à Paray-Douaville dans les Yvelines, accueille des mariages, des événements professionnels, des tournages et des hébergements sur un domaine de 12 hectares. Plusieurs bâtiments y fonctionnent en même temps : le château, la Verrière, l'Orangerie, le pavillon de gardes et son dortoir, le pavillon de chasse et les hébergements.
Ouest-Digit y a installé, avec la participation de Julien Diet, de Tconnecté, un socle domotique unique : un serveur Home Assistant hébergé sur le domaine, sous Proxmox, et six réseaux Zigbee distincts, un par bâtiment, tous réunis dans la même interface. Ce socle est livré et en service, avec de premiers usages déjà actifs : supervision de l'alarme Ajax, détection de fumée, éclairage des façades, poêle à pellets. Les suivants — alertes à l'équipe, éclairage, volets, scénarisation du parc, énergie et production solaire, suivi du bruit, météo, traçabilité des réceptions, sécurité, extérieurs — viennent s'y greffer par phases.
Le projet est en cours de déploiement. Pour la suite, le domaine a fait un choix : développer lui-même les intégrations, avec ses équipes, afin de gagner en autonomie. Ouest-Digit reste à ses côtés en conseil et en accompagnement technique.
Cette étude décrit l'architecture retenue, les raisons de chaque choix, et la feuille de route. Elle distingue ce qui fonctionne aujourd'hui de ce qui est planifié.
Un rendez-vous de chasse de 1764, devenu lieu de réception
Le château est édifié en 1764 comme rendez-vous de chasse. Passé sous le contrôle de l'État après la Révolution, puis propriété d'un médecin de Napoléon, il est acquis en 1829 par François, marquis de Barthélemy — ambassadeur, pair de France, et l'un des cinq Directeurs du Directoire de 1795 à 1799. Le domaine lui doit son nom. Ses héritiers y ajoutent deux ailes à la fin du XIXe siècle.
Le château rouvre en juin 2016, après une année de travaux conçus et pilotés par Camille de Compiègne, propriétaire du domaine : 22 corps de métiers, la restauration des chambres, la création du Pavillon de la Marquise, la recréation de l'étang. Deux objectifs sont affichés : préserver le patrimoine et assurer la pérennité du domaine.
Le point de départ : des systèmes épars, une application par équipement
Avant le projet, chaque équipement du domaine avait sa propre application. Rien ne communiquait. Pour connaître l'état d'un bâtiment, il fallait ouvrir plusieurs outils, ou s'y rendre.
Sur un lieu de réception, cette dispersion a un coût précis. L'équipe prépare une salle pendant qu'une autre est occupée, les prestataires entrent et sortent, des hébergements se libèrent. Une information qui n'arrive pas au bon moment devient un incident pendant un événement.
L'objectif fixé était donc moins d'ajouter des équipements que de les réunir : une seule interface, un seul historique, et un socle capable d'accueillir la suite sans être refait.
Pourquoi connecter un château comme celui-ci
Une maison connectée apporte du confort. Un domaine de réception y trouve autre chose : les deux objectifs que son propriétaire s'est fixés, préserver le bâti et faire durer l'activité, dépendent tous deux d'une information qui arrive à temps.
- →Un bâti de 1764 qu'on ne perce pas. Des murs épais, aucune gaine technique, et une restauration récente qu'il serait absurde d'entailler pour passer des câbles. Des capteurs sans fil, alimentés par pile, se posent sans toucher aux murs ni aux boiseries.
- →Des bâtiments vides entre deux événements. Une fuite, une chaudière en défaut ou un coup de gel dans une salle fermée pendant plusieurs jours ne se découvre, sans supervision, qu'à la réouverture — la veille d'une réception. C'est le premier risque pour le patrimoine, et il se mesure en dégâts des eaux.
- →Six bâtiments, une équipe. Personne ne peut être à la fois au château, à la Verrière, à l'Orangerie et dans les hébergements. Aujourd'hui, l'équipe fait le tour pour savoir ; demain, l'information vient à elle, dans la messagerie qu'elle utilise déjà.
- →Un lieu qui change de fonction plusieurs fois par semaine. Mariage le samedi, séminaire le mardi, tournage le jeudi, hébergement entre-temps : à chaque fois un autre éclairage, un autre chauffage, d'autres accès. Ce sont des réglages répétés, donc des scénarios.
- →Chauffer ce qui sert, quand cela sert. Maintenir toutes les salles à température en permanence n'a pas de sens sur un lieu occupé par intermittence. Le pilotage par bâtiment et selon le calendrier des événements est le levier d'économie le plus direct ; les consommations seront mesurées pour le vérifier, et non promises à l'avance.
- →Douze hectares d'extérieurs. Un étang recréé, une piscine, un arrosage, un portail : autant d'équipements éloignés du château, que l'on ne surveille pas en passant devant.
Aucun de ces points ne demande une technologie spectaculaire. Ils demandent un socle fiable, local, qui réunit ce qui était dispersé — c'est ce qui a été livré en premier.
Pourquoi six réseaux Zigbee plutôt qu'un seul
Le Zigbee est le protocole radio basse consommation qu'utilisent la plupart des capteurs et des actionneurs sans fil. Un réseau Zigbee est maillé : chaque équipement alimenté relaie le signal de ses voisins. Dans une maison, un seul réseau suffit.
Sur un domaine de 12 hectares, ce modèle ne tient pas. Les bâtiments sont éloignés les uns des autres, les murs anciens atténuent fortement la radio, et un maillage qui devrait franchir le parc reposerait sur quelques relais dont la panne isolerait un bâtiment entier.
Le choix retenu est inverse : chaque bâtiment a son propre réseau Zigbee, porté par sa propre antenne — un coordinateur SLZB-06, raccordé au réseau informatique du domaine et alimenté par le même câble (PoE). Trois conséquences :
- →Chaque réseau reste petit. Un maillage qui ne couvre qu'un bâtiment est plus stable et plus simple à diagnostiquer qu'un maillage étiré sur tout un domaine.
- →Une panne reste locale. Si une antenne tombe, un seul bâtiment est concerné ; les cinq autres continuent de fonctionner.
- →La radio ne traverse plus le parc. La liaison entre bâtiments passe par le câble, pas par les ondes.
Ce choix n'a été possible que parce que le domaine disposait déjà d'un réseau Ethernet et fibre entre ses bâtiments. Les antennes s'y sont raccordées, sans tranchée ni pont radio.
L'architecture, couche par couche
| Couche | Ce qui a été installé | Pourquoi |
|---|---|---|
| Serveur | Un mini-PC Intel basse consommation sous Proxmox, hébergé sur le domaine. | Proxmox est un hyperviseur : une seule machine héberge plusieurs environnements isolés. Home Assistant tourne dans le sien, et une mise à jour peut être précédée d'un instantané, puis annulée si elle pose problème. |
| Supervision | Home Assistant OS, en machine virtuelle | Logiciel open source, exécuté sur place : aucun éditeur ne peut l'arrêter, et les automatismes ne dépendent pas d'un service en ligne. |
| Radio | Six coordinateurs Zigbee SLZB-06, Ethernet et PoE, un par bâtiment | Une antenne par bâtiment, posée là où la couverture est la meilleure, et non là où se trouve le serveur. |
| Passerelle | Zigbee2MQTT, une instance par bâtiment | Chaque réseau a sa propre instance ; toutes remontent dans le même Home Assistant. Un bâtiment se redémarre ou se met à jour sans toucher aux autres. |
| Liaison | Le réseau Ethernet et fibre déjà présent sur le domaine | Réemploi de l'existant : aucune infrastructure ajoutée entre les bâtiments. |
| Sauvegarde | Sauvegardes de Home Assistant, avec une copie conservée hors du site | Un serveur unique impose de pouvoir le reconstruire rapidement. |
Les six bâtiments ou zones couverts : le château, la Verrière, l'Orangerie, le pavillon de gardes et son dortoir, le pavillon de chasse et les hébergements. Le socle a été posé en plusieurs interventions étalées, pour ne pas croiser les événements du domaine.
Ce qui fonctionne aujourd'hui
Le socle est en service : le serveur, les six réseaux, l'interface unique. Plus de cinquante équipements déjà appairés remontent leur état dans Home Assistant, bâtiment par bâtiment. Cinq usages fonctionnent déjà dessus.
- →Supervision de l'alarme Ajax. L'alarme reste un système autonome, certifié, qui fonctionne sans Home Assistant. Home Assistant en lit l'état : l'équipe voit dans la même interface si le domaine est armé, et ce qui s'y passe.
- →Détection de fumée. Les détecteurs remontent dans la même interface que le reste, et rejoindront les mêmes alertes. Sur un bâti de 1764 aux intérieurs restaurés, c'est le risque qui ne se rattrape pas.
- →Éclairage des façades du château. Les mises en lumière du bâtiment principal sont pilotées depuis Home Assistant, à l'heure voulue ou à la demande pendant un événement.
- →Poêle à pellets. Intégré à Home Assistant : son état et sa marche se suivent sans se déplacer.
- →Alerte de pile faible. Un capteur sans fil dont la pile s'épuise cesse de remonter ses informations sans prévenir ; sur un domaine de cette taille, personne ne s'en apercevrait. Home Assistant le signale avant, avec le nom de l'équipement et du bâtiment.
Les alertes arriveront dans la messagerie de groupe de l'équipe. Le canal retenu est volontairement celui qu'elle utilise déjà : une alerte qui arrive dans un outil de plus n'est pas lue.
La feuille de route : ce qui sera déployé sur ce socle
Le déploiement se poursuit, et il change de mains. Le domaine prévoit de développer lui-même, avec ses équipes, les intégrations qui suivent, pour gagner en autonomie ; Ouest-Digit reste en conseil et en accompagnement technique. C'est la suite logique d'un socle ouvert — serveur sur place, logiciel open source, configuration remise — et ce qu'un système fermé n'aurait pas permis.
Les usages prévus sont les suivants. Aucun ne demande de refaire l'infrastructure : chacun s'ajoute au serveur et aux réseaux déjà en place.
- →Alertes en temps réel à l'équipe. Incidents techniques — fuite d'eau, température anormale, coupure électrique —, accès resté ouvert après le départ des prestataires, détection dans une zone fermée hors événement, et rappels d'exploitation comme le chauffage d'une salle avant une réception.
- →Éclairage et scénarios événementiels. Mises en lumière des salles et du parc, ambiances adaptées à un mariage, un séminaire ou un tournage.
- →Ouverture et fermeture des volets. Selon l'heure, l'occupation et la météo : ouvrir une salle avant l'arrivée des invités, protéger les intérieurs du soleil, tout fermer le soir ou par grand vent sans faire le tour des bâtiments.
- →Gestion des énergies et monitoring d'ensemble. Chauffage piloté par bâtiment et selon l'occupation, mesure des consommations poste par poste, et un tableau de bord unique pour l'état de tout le domaine.
- →Production photovoltaïque. Suivi de la production et pilotage des usages pour consommer sur place ce qui est produit, plutôt que de le réinjecter.
- →Bruit ambiant pendant les événements. Mesure continue du niveau sonore dans les salles et en limite de propriété : l'équipe est prévenue avant qu'une soirée ne dépasse le niveau fixé, pour le voisinage comme pour les limites applicables aux sons amplifiés.
- →Prévisions météo. Le vent, la pluie ou le gel annoncés déclenchent les bons réflexes avant l'événement : mise en chauffe anticipée, arrosage suspendu, alerte pour une réception prévue en extérieur.
- →Traçabilité des événements clients. Un journal horodaté par réception — températures, ouvertures, niveaux sonores, incidents et leur traitement. Il porte sur le lieu et ses équipements, pas sur les personnes, et il sert de référence si une question se pose après coup avec un client ou un prestataire.
- →Sécurité étendue et gestion des accès.
- →Scénarisation du parc. Les éclairages et les équipements extérieurs coordonnés en scènes, selon l'heure et le type d'événement : l'arrivée des invités, le dîner, la fin de soirée.
- →Extérieurs. Piscine, arrosage, lac, portail.
- →Maintenance prédictive. Analyse des historiques par un modèle d'IA pour repérer une dérive — un équipement qui consomme plus, une température qui s'écarte — avant qu'elle ne devienne une panne.
Cet ordre n'est pas figé. Il dépend du calendrier des événements du domaine : on n'intervient pas dans une salle la semaine d'un mariage. La liste ne l'est pas non plus : d'autres usages viendront à l'usage, et le socle a été dimensionné pour les accueillir sans être refait.
Les bénéfices attendus, pour chacun de ceux qui font vivre le domaine
Le socle est en service depuis peu : rien n'est encore mesuré, et cette page ne prétend pas le contraire. Voici ce que le domaine en attend, pour chacun de ceux qui y vivent ou y travaillent, en distinguant ce qui fonctionne déjà de ce qui reste à déployer.
Pour le propriétaire : protéger le bâti, maîtriser les charges
Un départ de feu dans un bâtiment fermé plusieurs jours est le sinistre qui menace le plus un bâti de 1764 tout juste restauré : il est signalé au moment où il survient, pas à la réouverture. Une fuite ou un coup de gel le seront de la même façon. Le chauffage suivra le calendrier des événements au lieu de tourner en continu, et les consommations seront mesurées poste par poste : les charges se pilotent alors sur des relevés, pas sur des impressions. Enfin le système appartient au domaine — serveur sur place, logiciel open source, configuration remise — et ne dépend ni d'un éditeur ni d'un prestataire : ce sont ses équipes qui développent la suite.
Déjà en service : détection de fumée, supervision de l'alarme, poêle à pellets. À venir : fuite et gel, chauffage selon l'occupation, mesure des consommations.
Pour l'équipe : savoir sans faire le tour
Six bâtiments sur douze hectares, et une seule interface au lieu d'une application par équipement. L'information viendra à l'équipe, dans la messagerie qu'elle utilise déjà, au lieu que l'équipe aille la chercher. En fin de soirée, vérifier que tout est éteint, fermé et armé se fera depuis un téléphone, et non en parcourant le domaine de nuit.
Déjà en service : interface unique, état de l'alarme, alertes de pile faible. À venir : alertes techniques et d'accès, contrôle de fin de soirée.
Pour les clients du domaine : une réception sans accroc
Des mariés ou une entreprise ne verront jamais le système ; ils verront ce qu'il évite. Une salle à température à leur arrivée, parce que la chauffe aura été anticipée selon la météo. Des façades et un parc mis en lumière à l'heure dite. Un incident technique traité en coulisse avant d'atteindre la salle. Et un niveau sonore suivi en continu, qui donne à l'équipe le moyen d'ajuster avant qu'une soirée ne pose problème.
Déjà en service : éclairage des façades du château. À venir : chauffe anticipée, scénarios de salle et de parc, suivi du bruit.
Pour les prestataires : intervenir sans attendre quelqu'un
Traiteurs, techniciens, équipes de tournage : chacun intervient à des heures différentes, souvent en l'absence du propriétaire. Le domaine saura qui intervient, où et quand, sans qu'un membre de l'équipe attende sur place. Et le journal tenu pour chaque réception donnera une référence commune si une question se pose après coup.
À venir : gestion des accès, journal par réception.
Ce qui permettra de le vérifier : les relevés de consommation, le nombre d'alertes reçues et traitées, les incidents détectés avant qu'ils ne gênent un événement. Cette étude sera complétée lorsque ces relevés existeront.
Ce que ce projet illustre
Le socle avant les usages
Le serveur et les réseaux ont été dimensionnés pour la feuille de route complète, pas pour le premier besoin. Chaque phase suivante est un ajout, pas un chantier.
L'existant d'abord
Le réseau du domaine était là : il porte les antennes. Rien n'a été tiré entre les bâtiments.
Un client qui devient autonome
Serveur sur place, logiciel open source, configuration remise : le domaine développe désormais ses propres intégrations avec ses équipes, et Ouest-Digit l'accompagne en conseil. Un autre intégrateur pourrait aussi reprendre l'installation.
Le Château Barthélemy se trouve en Île-de-France, hors de notre zone habituelle d'Ille-et-Vilaine et des Côtes-d'Armor. Ouest-Digit intervient ponctuellement au-delà de la Bretagne sur des projets de cette nature ; le socle étant supervisable à distance, la suite s'y prête.
Remerciements. Merci à Camille de Compiègne, propriétaire du Château Barthélemy, pour sa confiance. Merci également à Julien Diet, de Tconnecté, qui a participé à ce chantier.