Illustration générée par IA — visuel conceptuel.
Pourquoi une maison “smart” finit parfois par énerver
Une maison automatisée devient irritante quand l’occupant a l’impression de devoir négocier avec le bâtiment : stores qui bougent pendant qu’on nettoie une baie vitrée, éclairage qui s’éteint alors qu’on lit, climatisation qui “reprend” une consigne sans prévenir, etc.
Dans la majorité des cas, le problème ne vient pas de la technologie en elle-même (KNX, radio, hybride…), mais d’un manque de règles explicites :
- Qui a la priorité : l’automatique ou le bouton ?
- Combien de temps on respecte une action manuelle ?
- Quand et comment le système “revient” à l’automatique ?
Objectif de ce guide : proposer des patterns pratiques pour que l’occupant reprenne la main sans casser l’automatisation (et sans “désactiver la domotique”).
Le principe de base : raisonner en “couches” de commande (priorités)
Pour concevoir une automatisation acceptable au quotidien, il est utile de classer les commandes en couches, du plus prioritaire au moins prioritaire.
Une hiérarchie simple (à adapter au projet)
- Sécurité / protection : contraintes de sécurité (ex. alarme météo sur stores extérieurs, intrusion…).
- Forçage / maintenance : nettoyage, intervention technique, usage exceptionnel.
- Manuel local : bouton mural, commande de scène, action directe de l’occupant.
- Automatique : capteurs, horaires, présence/absence, stratégie solaire, etc.
Point de cadrage important : KNX fournit le bus et les échanges, mais il n’existe pas une hiérarchie “universelle” imposée valable pour tout matériel KNX. Les notions de verrouillage, d’alarme, de forçage et de priorité relèvent souvent de l’application ETS et du comportement des produits (actionneurs, contrôleurs, logiques). Par exemple, la documentation KNX Support sur les actionneurs de stores/volets décrit des alarmes (intrusion/incendie/vent/pluie/gel) qui peuvent rendre un canal non contrôlable par d’autres objets tant que l’alarme est active, avec une notion de priorité d’alarme paramétrable : voir KNX Support — Blinds/Shutter Actuator.
Le réflexe qui change tout : rendre la hiérarchie visible
Une maison “qui n’énerve pas” ne se contente pas d’avoir des priorités : elle les montre à l’utilisateur (sur app, écran, voyant, ou libellé simple).
Exemples de statuts utiles :
- Auto (stratégie active)
- Manuel (override occupant)
- Maintenance / nettoyage (forçage temporaire)
- Protection (commande bloquée par une condition de sécurité)
Pattern n°1 — L’override local : le bouton gagne… mais avec une règle de sortie
La règle UX la plus robuste (et la plus attendue) est simple :
- Quand l’occupant agit (bouton, scène, curseur…), la maison respecte sa décision.
- L’automatique n’a plus le droit de contredire immédiatement.
- Mais l’override n’est pas “pour toujours” : il se termine selon une règle explicite.
Définir l’override : “combien de temps” ou “jusqu’à quel événement”
Deux approches se combinent souvent :
- Override temporisé : l’action manuelle bloque l’automatique pendant une durée définie au projet (courte ou longue selon la fonction).
- Override jusqu’à événement : le retour en automatique se fait lors d’un événement clair (ex. passage en mode Absence, activation d’une autre scène, appui long “Auto”).
Conseil Domocasa (pratique) : évitez le “retour automatique” trop court sur des fonctions visibles (stores) ou à forte charge émotionnelle (température). C’est exactement ce qui donne l’impression que “la maison résiste”.
À écrire dans le cahier des charges
- “Un appui manuel met la zone en manuel (override).”
- “Pendant l’override, les automatismes de confort sont ignorés (ou mis en attente selon la stratégie retenue).”
- “L’override se termine : par durée et/ou par événement.”
Pour structurer les commandes “1 bouton” (et éviter la multiplication de règles invisibles), voir aussi : Scènes domotiques qui marchent vraiment.
Pattern n°2 — Le “retour en automatique” : choisir une politique, sinon vous créez des surprises
La fin d’un override est souvent le moment où l’utilisateur perd confiance : le système “fait quelque chose” sans comprendre pourquoi.
Pour éviter ça, définissez une politique claire (fonction par fonction) :
- Ne rien changer : l’équipement reste dans l’état manuel, l’automatique reprendra plus tard au prochain cycle logique.
- Revenir à l’état d’avant override : utile si l’override était vraiment une parenthèse (cas maintenance).
- Rejoindre la consigne automatique : utile pour certaines fonctions, mais potentiellement irritant si c’est visible (stores) ou si c’est trop brutal (CVC).
Recommandation (non universelle) par grand lot
- Éclairage : “ne rien changer” fonctionne bien (l’automatique reprend à la prochaine extinction/scène), ou retour à l’état précédent si le besoin est très routinier.
- Stores : éviter un rattrapage immédiat ; privilégier une reprise plus tard (cycle suivant), sauf si l’utilisateur a explicitement demandé “Auto”.
- CVC : favoriser une reprise progressive, cohérente avec les états Présence/Absence (et l’inertie du bâtiment).
Pattern n°3 — Capteurs de présence : empêcher le capteur de “se battre” contre le manuel
Une source majeure d’irritants : un capteur qui allume/éteint, pendant que l’occupant essaye de garder une ambiance.
Deux stratégies robustes
A) Bloquer la détection pendant l’override
Quand le matériel le permet, le capteur peut être explicitement activé/désactivé. C’est un exemple dépendant des produits et de leur application ETS : certains détecteurs exposent des objets distincts “Enable/Disable Movement Detection” et “Enable/Disable Presence Detection” (voir KNX Support — Movement/Presence Detector).
Avantage : on évite les “relances” intempestives.
Limite : on perd temporairement l’information capteur (si elle était utilisée par d’autres fonctions).
B) Conserver l’information capteur, mais neutraliser son effet sur l’actionneur
Autre approche : le capteur continue à envoyer l’état présence (utile pour des statistiques ou des scénarios), mais la logique (ou l’actionneur) ignore ces télégrammes pendant l’override.
Avantage : on conserve les données et le contexte.
Limite : demande une logique claire (et une recette plus rigoureuse).
Pour éviter les faux allumages et les extinctions trop agressives, voir : Détecteurs de présence : guide anti-faux allumage.
Pattern n°4 — Stores et volets : temporisations + “Stop” + priorités de sécurité
Les stores sont l’exemple n°1 de domotique irritante, parce que ça bouge physiquement et que ça surprend. La stratégie doit donc être conservatrice en mode Présence, et très explicite sur les priorités.
Trois commandes indispensables côté utilisateur
- Monter / descendre (évident)
- Stop (arrêter un mouvement en cours)
- Reprise en main (qui bascule clairement en override manuel)
Ce que l’automatique a le droit de faire (ou non) pendant l’occupation
- Éviter les mouvements “sans contexte” (ex. sans changement notable de lumière, sans scène, sans explication).
- Limiter les ajustements trop fréquents (un store qui “pompe” donne une sensation d’instabilité).
- Garder l’automatique plus active quand la maison est en Absence (optimisation solaire/thermique sans gêner).
Priorité sécurité : un point à formaliser (et à expliquer)
Sur certains actionneurs de stores/volets, des états d’alarme (ex. vent, pluie, gel, incendie selon projet) peuvent empêcher le contrôle par d’autres objets tant que l’alarme est active, avec une notion de priorité d’alarme paramétrable : voir KNX Support — Blinds/Shutter Actuator.
Traduction projet : si une commande est refusée ou annulée, l’utilisateur doit voir pourquoi (sinon il conclut “ça ne marche pas”).
Pour aller plus loin sur la cohérence stores / lumière naturelle / climatisation (sans rigidifier l’usage), lire : Stores, lumière naturelle et climatisation : comment les faire travailler ensemble ?.
Pattern n°5 — États globaux (Présence / Absence / Nuit) : réduire les automatismes quand quelqu’un subit leurs décisions
Un piège classique est de traiter chaque automatisme “dans son coin”. Un état global simple rend le système beaucoup plus lisible.
Pourquoi ces états évitent des conflits
- En Présence : manuel prioritaire, automatisme conservateur, pas de surprises.
- En Absence : automatisme plus actif (énergie, protections, scénarios), car personne ne subit les micro-décisions.
- En Nuit : automatisme orienté confort (balisage doux, limitation des mouvements de stores), et transitions plus lentes.
Ce pattern se combine naturellement avec des scènes bien choisies (Arrivée, Départ, Nuit…).
La méthode qui évite les litiges : documenter et recetter (tests) le “manuel vs auto”
Une automatisation “propre” n’est pas celle qui semble magique, c’est celle qui est testable et documentée.
Livrables recommandés (vraiment utiles)
- Matrice des priorités par lot (éclairage / stores / CVC) : qui prime sur qui.
- Règles d’override : déclencheur, durée/événement de fin, politique de retour en auto.
- Exceptions : ce que “Tout éteindre” ne coupe pas, ce que “Absence” autorise, etc.
- Recette : scénarios de test reproductibles.
Tableau de recette (exemples de tests réalisables)
| Situation à tester | Ce qu’on attend | Ce qu’on note (résultat) | Limite / point d’attention |
|---|---|---|---|
| Appui manuel sur un éclairage puis occupant immobile | La lumière reste dans l’état choisi (pas d’extinction agressive) | Conforme / à régler | Valider dans les zones “lecture/TV/bureau” |
| Override store (nettoyage) pendant que l’automatique “soleil” voudrait bouger | Le store ne rebouge pas tant que l’override est actif | Conforme / à régler | Vérifier aussi l’arrêt “Stop” |
| Déclenchement d’une protection (selon projet) puis commande manuelle | La protection prime, et l’interface indique clairement la cause | Conforme / à corriger | À recetter en conditions proches du réel |
| Fin d’override (par temps / par événement) sur stores | Retour en auto selon la politique choisie, sans mouvement surprenant | Conforme / à régler | Le “rattrapage” immédiat est souvent perçu comme un bug |
Pour cadrer la réception d’une installation et intégrer ces tests dans un protocole complet : Réception d’une installation domotique : que faut-il tester ?.
Et pour protéger la maintenabilité (projet ETS, sauvegardes, logique fonctionnelle) : DOE domotique : quels documents et sauvegardes recevoir ?.
Conclusion : une domotique durable, c’est une domotique “compréhensible”
Une maison qui n’énerve pas n’est pas celle qui automatise tout. C’est celle qui :
- respecte l’occupant (manuel prioritaire),
- encadre l’override (durée / événement),
- revient en automatique selon une règle écrite (et testée),
- documente et recete les comportements (pas seulement “ça s’allume”).
Si vous préparez un projet au Maroc (villa neuve ou rénovation), vous pouvez aussi relire : KNX : le standard ouvert de la domotique et Domotique filaire vs sans fil.
Besoin d’un cadrage projet (usages, priorités, recette) ? Découvrez notre approche Domotique / Smart Home (CTA discret).
