Les fiches produit vous vendent le design, la commande vocale et les notifications push. Mais la première question que vous devez vous poser, celle qui déterminera si vous restez planté derrière votre porte un soir de panne réseau, est bien plus prosaïque : quel est le temps de réponse réel et que se passe-t-il quand la box internet s’éteint ?
On a trop souvent vu des utilisateurs découvrir que leur serrure « intelligente » devenait une brique électronique dès que le Wi‑Fi vacillait. Ce guide pose les questions qu’un technicien pose avant d’installer quoi que ce soit sur sa porte d’entrée.
La latence avant le style
Une serrure connectée se juge d’abord à son temps d’ouverture. Une app qui met trois secondes à déverrouiller quand vous avez les bras chargés et votre enfant qui hurle derrière vous, c’est une serrure ratée. Sur ce point, les spécifications commerciales restent muettes.
Testez la réactivité en conditions réelles : déverrouillage immédiat depuis l’app, déverrouillage automatique à l’approche (Auto‑Unlock), commande par borne tactile ou empreinte digitale. Le délai ne dépend pas seulement du Bluetooth ou du Wi‑Fi, mais aussi de la chaîne logicielle qui va du capteur au moteur de la gâche. Une pile applicative lourde ajoute de la latence, un peu comme un site dont le LCP explose à cause d’un bundle JavaScript mal découpé.
La latence perçue se mesure en centaines de millisecondes. Si la porte ne s’ouvre pas dans la seconde qui suit une interaction intentionnelle, l’utilisateur va pianoter, relancer l’app, s’énerver. Ce seuil de tolérance est aussi documenté dans les travaux sur les Core Web Vitals : au‑delà de 100 ms de délai, l’utilisateur décroche. Pour votre porte, le coût est juste plus immédiat.
Le protocole radio détermine la résilience
Trois grandes familles coexistent : le Wi‑Fi pur, le Zigbee/Thread avec hub, et le Bluetooth sur courte portée. Chacune a des conséquences sur la réactivité et la survie en mode dégradé.
| Protocole | Réactivité typique | Dépendance réseau | Consommation |
|---|---|---|---|
| Thread / Matter | Très basse latence, mesh local | Aucune pour les commandes locales | Très faible |
| Zigbee | Basse latence via hub | Faible, le hub fait relais local | Faible |
| Wi‑Fi | Variable, selon qualité réseau | Totale si cloud obligatoire | Élevée |
| Bluetooth | Correcte, limité à la portée | Aucune | Très faible |
Une serrure Wi‑Fi qui dialogue avec un serveur distant peut afficher une latence dégradée dès que votre FAI tousse. À l’inverse, une serrure Thread ou Zigbee avec contrôleur local reste fonctionnelle même sans internet. C’est le même arbitrage que pour une application web : on préfère un rendu côté serveur bien conçu plutôt qu’une dépendance totale au CDN.
Si vous optez pour du Wi‑Fi, vérifiez que la serrure intègre un mode point‑à‑point local et ne passe pas systématiquement par le cloud pour une simple ouverture.
Votre porte doit-elle dépendre du cloud ?
Beaucoup de modèles nécessitent un compte constructeur et une liaison permanente à un serveur distant, y compris pour gérer les utilisateurs et les heures d’accès. Le jour où ce serveur tombe ou que l’API change, vos accès sont hors service.
On ne parle pas d’un gadget web : c’est l’accès à votre domicile. La question n’est pas « est‑ce que le cloud est fiable ? », mais « est‑ce que la serrure fonctionne entièrement sans cloud ? ». Les modèles avec hub local (Apple Home Hub, Home Assistant, hub Zigbee) continuent d’exécuter les scénarios même quand le lien WAN est coupé.
C’est d’ailleurs un parallèle pertinent avec le choix d’un IDE. Quand vous évaluez un environnement de développement, la capacité à fonctionner hors ligne et la qualité de l’intégration locale font la décision. Un utilisateur avancé qui configure Home Assistant avec une serrure Zigbee fait le même calcul qu’un dev qui arbitre entre Claude Code et Cursor : quel outil reste performant quand le réseau tombe ?
L’autonomie et la panne sèche
Toutes les serrures intelligentes fonctionnent sur piles ou batterie. La promesse d’un an d’autonomie ne vaut rien si la serrure refuse de s’ouvrir mécaniquement quand la pile est vide. Vérifiez que le barillet accepte toujours une clé physique, que les contacts de secours sont accessibles, et que l’alerte de batterie faible est visible (notification push, LED) avant le point de non‑retour.
L’ennemi numéro un, c’est le modèle dont le moteur refuse de tourner alors qu’il reste du jus, parce que le firmware a décidé de passer en sécurité. Les bons modèles séparent le circuit d’ouverture du circuit connecté. Une pile bouton peut alimenter la radio et l’horloge, tandis qu’un accu dédié alimente le moteur.
L’API et l’enfermement propriétaire
Une serrure qui ne s’intègre qu’avec l’app du fabricant est un silo. Le véritable verrouillage, c’est de ne pas pouvoir automatiser l’allumage du chauffage à l’arrivée ou la création d’un code temporaire depuis votre propre interface.
Les API ouvertes et documentées changent la donne. Avec un endpoint REST local ou des webhooks, vous pouvez orchestrer des scénarios depuis Home Assistant, Node‑RED ou un script Python. Mais cela demande que le constructeur accepte le contrôle local. Beaucoup préfèrent vous garder dans leur cloud parce que vos données d’usage sont monétisables.
Dans la gestion des droits d’accès et des scénarios, l’application mobile fait face à une complexité analogue à celle du state management dans une app front‑end. Un store local bien structuré permet de savoir qui a ouvert la porte, à quelle heure, sans vider la batterie. Si vous avez déjà bataillé avec une gestion d’état en React avec Zustand, vous savez que la simplicité apparente cache vite des dépendances croisées ingérables. C’est la même chose avec les règles d’accès conditionnelles : plus c’est simple et local, plus c’est fiable.
Sécurité : au‑delà du crochetage
La sécurité d’une serrure connectée ne se limite pas à la résistance mécanique. L’attaque relais Bluetooth, le spoofing RFID, l’absence de verrouillage après authentification échouée sont des vecteurs classiques.
Préférez une serrure qui chiffre les échanges de bout en bout et dont les mises à jour firmware sont signées. Même sans être un expert, un bon réflexe : vérifiez si le constructeur publie un historique de ses vulnérabilités corrigées. L’absence de CVE n’est pas un signe de qualité ; c’est un signe d’absence de transparence.
Questions fréquentes
Quelle est la différence entre une serrure connectée et une serrure intelligente ?
La distinction est floue. Une serrure connectée se contente d’un pilotage à distance via une app. Une serrure intelligente embarque une logique locale (détection de présence, scénarios horaires, auto‑verrouillage) sans dépendre d’une connexion externe permanente. C’est cette logique locale qui fait la robustesse.
Faut‑il obligatoirement un abonnement pour les fonctions avancées ?
Certains constructeurs réservent l’historique des accès, les codes temporaires ou les intégrations tierces à un abonnement mensuel. Lisez bien la matrice des fonctionnalités avant achat. Si l’API locale est ouverte, vous pouvez souvent retrouver ces fonctions via votre contrôleur domotique sans payer de surcoût.
Peut‑on installer une serrure intelligente sur une porte ancienne ?
Oui, dans la plupart des cas, si le cylindre existant est compatible avec un remplacement standard. Les modèles à montage sur cylindre existant évitent de changer la ferrure. Vérifiez l’épaisseur de la porte, le type de gâche et la distance entre les points de fixation. Si le pêne n’est pas parfaitement aligné, aucun moteur ne compensera le frottement.
