Cédrix
1 line
20 KiB
JSON
1 line
20 KiB
JSON
[{"uuid":"da1b3cec-980d-458c-9d2b-0c950d278f22","slug":"domotique-les-vrais-problemes-en-domotique-zigbee-home-assistant","title":"Domotique : les vrais problèmes en domotique Zigbee & Home Assistant","category":"domotique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2026-05-22 18:00:00","created_at":"2026-05-22 18:00:00","updated_at":"2025-05-01 06:11:58","tags":{"logiciels":["Home Assistant"]},"plain":"Je suis en train de préparer une vidéo un peu différente de celle que j’ai faite sur Zigbee, Zigbee2MQTT et Home Assistant. Cette fois, je veux parler des problèmes concrets que je rencontre au quotidien, dans une installation domotique qui fonctionne… mais pas toujours comme prévu.\r\n\r\nPar exemple, mon antenne Zigbee — une clé que j’utilise avec Zigbee2MQTT — se déconnecte régulièrement, toutes les 5 à 15 minutes. C’est intermittent, difficile à diagnostiquer, et surtout très frustrant. Parfois, elle réapparaît toute seule. D’autres fois, elle oblige à redémarrer le service ou la machine. Et évidemment, quand le Zigbee tombe, toute la chaîne domotique en dépend : capteurs inaccessibles, automatisations qui ne se déclenchent plus, etc.\r\n\r\nJe parlerai aussi des problèmes côté serveur, comme certaines mises à jour de Home Assistant ou d’addons qui ne se passent pas bien : dépendances cassées, redémarrages partiels, ou intégrations qui ne répondent plus comme avant. Ce sont des situations qu’on rencontre tôt ou tard quand on auto-héberge, surtout dans un système évolutif et modulaire comme Home Assistant.\r\n\r\nProblèmes coté objets connectés : \r\n pile HS\r\n valeurs incomplètes : il manque par exemple la puissance instantanée\r\n valeurs incorrectes : la valeur retournée n'est plus du tout correcte (il fait 9°C dehors et la capteur indique -1°), l'energie totale consommée passe de 1234 kW à 950 kW\r\n répondant de l'objet connecté : l'action n'est pas transmise ou avec avec beaucoup de retard à l'objet connecté quand l'objet de perd pas le réseau. Résolu avec la configuration de Zigbee2MQTT.\r\n perte de réseau : peut poser des problème lorsqu'on pilote des radiateurs\r\n\r\nOutils nécessaires :\r\n ssh\r\n multimètre\r\n\r\nL’objectif de cette vidéo, ce n’est pas de me plaindre ni de critiquer les outils que j’utilise. Au contraire. J’ai choisi cette approche justement parce qu’elle me laisse la main. Mais je veux montrer aussi la réalité terrain, au-delà des démonstrations propres et des installations idéales. Parce que ce sont dans ces moments-là — quand on cherche, qu’on teste, qu’on tâtonne — qu’on apprend vraiment comment tout fonctionne.\r\n\r\nEt si je partage ça, c’est aussi pour que d’autres qui rencontrent les mêmes soucis puissent comparer, proposer, ou tout simplement se rassurer**. Ce n’est pas parfait, mais ça tourne. Et parfois, savoir qu’on n’est pas seul à rencontrer un bug, c’est déjà beaucoup."},{"uuid":"ee7ae0b2-bf21-4710-81d7-d12e7af4807d","slug":"parametrage-raspi-config-pour-raspberrypi-3-plus","title":"raspi-config, le menu de configuration du Raspberry Pi 3+","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-02 14:18:28","created_at":"2023-02-02 14:18:28","updated_at":"2023-02-02 14:18:28","tags":[],"plain":"Il faut exécuter la commande avec les droits admin pour exécuter l'assistant de configuration. Ce programme propose :\nChange User Password - Changer le mot de passe de l'utilisateur \nNetwork Options - Paramétrer les options réseau\nBoot Options - Choisir de démarrer dans le terminal ou dans l’environnement graphique LXDE\nLocalisation Options - Configurer les options linguistiques\nInterfacing Options - Paramètre les connections aux périphériques\nOverclock - Paramétrer l'overclocking pour votre Pi\nAdvanced Options - Paramétrer les options avancées\nUpdate - Mettre à jour raspi-config avec la dernière mise à jour\nAbout raspi-config - Information concernant cet outil de configuration Je vous propose de suivre les que j'ai pu glaner sur différents supports."},{"uuid":"0abed1b9-feae-465d-bca5-047fce19b1fa","slug":"parametrage-raspi-config-pour-raspberrypi-2","title":"raspi-config, le menu de configuration du Raspberry Pi 2","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-02 14:11:50","created_at":"2023-02-02 14:11:50","updated_at":"2023-02-02 14:11:50","tags":[],"plain":"Il faut exécuter la commande avec les droits admin pour exécuter l'assistant de configuration. Ce programme propose :\nExpand Filesystem - Permettre d'étendre la partition de Rasbpian () au maximum de la possibilité de la carte SD\nChange User Password - Changer le mot de passe de l'utilisateur \nBoot Options - Choisir de démarrer dans le terminal ou dans l’environnement graphique LXDE\nWait for Network at Root - Choisir le temps d'attente pour se connecter au réseau au démarrage\nInternationalisation Options - Configurer les options linguistiques\nEnable Camera - Activer le Pi pour fonctionner avec la caméra Raspberry Pi\nAdd to Rastrack - Ajouter ce Pi à la carte en ligne des Raspberry Pi\nOverclock - Paramétrer l'overclocking pour votre Pi\nAdvanced Options - Paramétrer les options avancées\nAbout raspi-config - Information concernant cet outil de configuration Je vous propose de suivre les que j'ai pu glaner sur différents supports."},{"uuid":"093711bf-4e60-4ea8-ba73-928d2d67776c","slug":"certificats-let-s-encrypt-a-6-jours-faut-il-sauter-le-pas","title":"Certificats Let's Encrypt à 6 jours : faut-il sauter le pas ?","category":"actualité","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-07 22:46","created_at":"2026-05-12 08:47:27","updated_at":"2026-05-12 08:59:58","tags":[],"plain":"Guide DevOps / WebOps pour comprendre les certificats à durée de vie courte () et décider si vous devez migrer.\r\n--\r\n\r\nTL;DR\r\n\r\nLet's Encrypt propose désormais au grand public des certificats valides 6 jours (profil ), en plus du classique 90 jours. Pour les certificats sur adresse IP, c'est même obligatoire. La question n'est pas \"est-ce que c'est bien ?\" — techniquement oui — mais \"est-ce que mon infra est prête ?\". Si votre renouvellement automatique fonctionne sans accroc depuis 6 mois, foncez. Sinon, fiabilisez d'abord, migrez ensuite.\r\n--\r\n\r\n1. De quoi on parle\r\n\r\nDepuis janvier 2026, Let's Encrypt émet en disponibilité générale deux nouveautés couplées : les certificats pour adresses IP, et les certificats à durée de vie de 6 jours via un nouveau profil ACME nommé . Certbot 4.0 a introduit le flag pour les sélectionner, et Certbot 5.3 a ajouté pour demander un cert sur IP.\r\n\r\nConcrètement, un certificat a une validité de 6 jours au lieu de 90. Tout le reste — chaîne de confiance, algorithmes, format — est identique. Pour le navigateur, c'est un certificat Let's Encrypt standard.\r\n\r\nLes profils disponibles\r\nProfil | Durée | Usage |\r\n---|---|---|\r\n(défaut) | 90 jours | Tout le monde, par défaut |\r\n| 6 jours | Adopters précoces, certs sur IP (obligatoire) |\r\n| 90 jours | Variante optimisée serveur web (sans clientAuth) |\r\n--\r\n\r\n2. Pourquoi Let's Encrypt pousse vers le court\r\n\r\nQuatre raisons techniques, par ordre d'importance.\r\n\r\n2.1 La révocation TLS est cassée — autant l'éviter\r\n\r\nC'est le vrai sujet. Le mécanisme de révocation des certificats (CRL, OCSP) n'a jamais fonctionné correctement à grande échelle :\r\nOCSP soft-fail : si le serveur OCSP est injoignable, la plupart des navigateurs acceptent quand même le certificat. Un attaquant qui contrôle le réseau bloque l'OCSP et le cert révoqué passe.\r\nOCSP stapling mal configuré sur beaucoup de serveurs.\r\nCRLite, OneCRL : couvertures partielles, déploiement client incohérent.\r\nOCSP retiré : Let's Encrypt a arrêté OCSP en 2025, justement parce que ça ne servait quasiment à rien tout en posant des problèmes de vie privée.\r\n\r\nAvec un cert à 6 jours, la révocation devient cosmétique : on attend l'expiration. La fenêtre d'exploitation d'une clé compromise passe de plusieurs semaines (cert 90 jours, OCSP douteux) à quelques jours maximum.\r\n\r\n2.2 Réduire la fenêtre de compromission\r\n\r\nSi votre clé privée fuite (backup mal protégé, faille serveur, employé qui part avec une copie, vulnérabilité type Heartbleed), l'attaquant peut usurper votre site tant que le cert est valide. À 90 jours, c'est trois mois d'exposition dans le pire cas. À 6 jours, c'est une semaine.\r\n\r\nC'est encore plus critique pour les certs sur IP : une IP peut changer de propriétaire (cloud, VPS recyclé, réattribution FAI). Un cert long pour une IP qui ne vous appartient plus, c'est un risque que LE refuse de prendre — d'où l'obligation du profil court pour cet usage.\r\n\r\n2.3 Forcer une automatisation propre\r\n\r\nPersonne ne renouvelle un cert à la main tous les 6 jours. C'est mécaniquement infaisable. Le profil est donc un filtre qualité : si votre renouvellement n'est pas blindé, vous le saurez vite.\r\n\r\nL'effet de bord positif : ça élimine les pannes classiques type \"le cert a expiré parce que le cron était cassé depuis trois mois et personne ne s'en est rendu compte\". À 6 jours, un cron cassé devient visible immédiatement.\r\n\r\n2.4 Agilité cryptographique\r\n\r\nSi une vulnérabilité majeure impose de déprécier un algorithme en urgence (RSA, transition post-quantique, faille découverte sur SHA-256), un parc avec des certs à 6 jours bascule en une semaine. Un parc 90 jours met trois mois. C'est la raison qui motive aussi le CA/Browser Forum à pousser globalement vers des durées plus courtes (45 jours d'ici 2029 dans la baseline).\r\n--\r\n\r\n3. Pourquoi vous pourriez ne pas migrer\r\n\r\nSoyons honnêtes : pour la plupart des infras web classiques, le 90 jours suffit largement. Le 6 jours a des coûts réels.\r\n\r\n3.1 Pression sur le rate limiting\r\n\r\nLet's Encrypt limite à 300 nouveaux certificats par compte par 3 heures et 5 duplicatas de cert par semaine. Avec des certs 90 jours, vous renouvelez 4 fois par an. Avec des 6 jours, c'est 60 fois par an et par cert. Si vous avez 50 services derrière 50 certs distincts, vous explosez votre budget de requêtes ACME.\r\n\r\nMitigation : regrouper les domaines dans des certs SAN (un seul cert pour , , plutôt que trois certs).\r\n\r\n3.2 Dépendance critique au CA et au réseau\r\n\r\nÀ 90 jours, si Let's Encrypt est down 48h, vous ne le remarquez même pas. À 6 jours, une panne de 48h sur LE et votre fenêtre de renouvellement (typiquement à 1/3 de la durée restante, soit 2 jours), et votre cert expire. Vos services tombent.\r\n\r\nConséquences concrètes :\r\nIl faut un monitoring sérieux de l'expiration des certs (Prometheus blackbox exporter, , etc.).\r\nIl faut un fallback : second client ACME, second account, ou cert de secours d'une autre CA.\r\nIl faut absolument que la résolution DNS et le port 80/443 sortants depuis votre serveur soient fiables.\r\n\r\n3.3 Charge sur les systèmes de déploiement\r\n\r\nChaque renouvellement déclenche : appel ACME, validation HTTP-01 ou DNS-01, écriture des fichiers, rechargement du serveur web (Nginx, Apache, HAProxy, etc.). À 60 fois par an au lieu de 4, ça multiplie par 15 le nombre de reloads.\r\n\r\nSur un serveur web basique, un est gratuit. Sur des architectures plus complexes (load balancers stateful, terminations TLS distribuées, certs poussés vers un CDN, configs multi-nœuds avec Ansible/Salt), chaque renouvellement déclenche une cascade. À évaluer.\r\n\r\n3.4 Logs, audit, conformité\r\n\r\nCertains contextes réglementaires demandent une traçabilité des certificats (PCI-DSS, ISO 27001, HDS). Multiplier par 15 le volume d'événements de renouvellement à archiver et auditer, ça représente du stockage et du tooling à adapter.\r\n\r\n3.5 Le cas \"monitoring TLS externe\"\r\n\r\nSi vous avez des outils tiers (uptime monitors, scanners de conformité) qui vérifient l'expiration de vos certs, ils risquent de hurler en permanence : un cert qui montre toujours \"expire dans 6 jours\" déclenche les alertes \"cert expirant bientôt\" sur la plupart des outils mal configurés. Il faut soit ajuster les seuils, soit changer d'outil.\r\n--\r\n\r\n4. Décision : grille de lecture\r\nSituation | Recommandation |\r\n---|---|\r\nServeurs web classiques, renouvellement Certbot qui marche, < 20 certs | Restez en 90 jours. Le bénéfice marginal ne justifie pas le risque. |\r\nVous gérez des certs sur IP | Pas le choix : est obligatoire. |\r\nArchitecture critique avec rotation de clés agressive (banque, santé, infra publique) | Migrez. Le 6 jours est aligné avec vos exigences de sécurité. |\r\nInfra dev/staging interne | Excellent terrain de test. Migrez d'abord ici pour valider votre pipeline. |\r\nVous avez déjà eu une expiration cert non détectée en prod | Ne migrez pas tout de suite. Fiabilisez d'abord le monitoring et le renouvellement, puis migrez. Sinon vous transformez un incident annuel en incident hebdomadaire. |\r\nVous publiez via reverse proxy unique (un seul cert SAN pour plusieurs services) | Bon candidat. Un seul renouvellement à fiabiliser. |\r\nVous avez un parc hétérogène (Apache + Nginx + HAProxy + Traefik...) avec hooks custom | Auditez chaque hook avant de migrer. C'est là que ça casse. |\r\n--\r\n\r\n5. Comment migrer concrètement (Certbot)\r\n\r\n5.1 Pré-requis\r\n\r\nAvant tout :\r\n\r\n1. Certbot 4.0+ pour , 5.3+ pour , 5.4+ pour avec IP.\r\n2. Un renouvellement automatique opérationnel et vérifié (timer systemd ou cron actif, testé avec ).\r\n3. Un monitoring d'expiration des certs en place. Si vous n'en avez pas, installez-le avant de migrer.\r\n4. Un hook de reload du serveur web qui fonctionne ().\r\n\r\n5.2 Test sur le staging Let's Encrypt\r\n\r\n\r\n\r\nVérifier que le cert obtenu a bien une durée de 6 jours :\r\n\r\n\r\n\r\n5.3 Renouvellement plus fréquent\r\n\r\nPar défaut, Certbot renouvelle quand il reste 1/3 de la durée. Pour un cert 6 jours, ça veut dire renouveler à 2 jours restants. Ça laisse peu de marge en cas de panne. Vous pouvez forcer un renouvellement plus tôt :\r\n\r\n\r\n\r\nLe timer Certbot tourne deux fois par jour par défaut, ce qui est suffisant. Pas besoin de l'accélérer.\r\n\r\n5.4 Cas d'un certificat sur IP\r\n\r\n\r\n\r\nNote importante : Certbot ne sait pas encore installer automatiquement les certs IP dans Nginx ou Apache. Il faut éditer la config manuellement pour pointer vers et , et configurer un pour le reload.\r\n\r\n5.5 Plan de bascule recommandé\r\n\r\n1. Semaine 1-2 : un domaine non critique (un sous-domaine de test, un service interne) en . Surveillez les renouvellements.\r\n2. Semaine 3-4 : étendez à la moitié de votre dev/staging.\r\n3. Semaine 5-6 : migration progressive en prod, en commençant par les services les moins critiques.\r\n4. À tout moment : possibilité de retour arrière en supprimant du fichier de config Certbot dans .\r\n--\r\n\r\n6. Pièges à éviter\r\nNe migrez pas tout en même temps. Si votre hook de reload a un bug, vous le découvrez sur un seul service, pas sur 50.\r\nNe désactivez pas le monitoring d'expiration sous prétexte que c'est automatisé. L'automatisation peut casser silencieusement. Un check externe qui hurle à J-2 reste indispensable.\r\nAttention aux secrets stockés dans des configs autres que Certbot. Si vous avez des certs poussés manuellement vers un CDN, un load balancer cloud ou un firewall TLS-inspectant, le passage à 6 jours impose d'automatiser cette propagation aussi.\r\nPas de cert IP pour un service exposé publiquement à long terme. Si l'IP change, le cert devient inutilisable instantanément. Préférez le DNS quand c'est possible.\r\nVérifiez votre client ACME. Tous les clients ACME ne supportent pas encore les profils. acme.sh, Caddy, lego, Traefik : checkez la version. Certbot 4.0 minimum.\r\n--\r\n\r\n7. Verdict\r\n\r\nLe profil est techniquement supérieur au 90 jours sur le plan sécuritaire. Mais il déplace le coût : moins de risques liés aux clés compromises et à la révocation cassée, plus de risques liés à la chaîne de renouvellement.\r\n\r\nLa règle simple : si votre renouvellement automatique est fiable, migrez. Sinon, fiabilisez-le d'abord — la migration n'en sera que la conséquence naturelle.\r\n\r\nPour la majorité des infras web auto-hébergées (typiquement, un Proxmox + reverse proxy + une dizaine de services derrière), le 90 jours reste un excellent compromis. Le devient pertinent quand :\r\nVous avez besoin de certs sur IP (obligatoire).\r\nVous exploitez des services à forte exigence de sécurité (clés très sensibles).\r\nVous voulez tester votre résilience opérationnelle (le 6 jours est un excellent test de fiabilité de votre stack).\r\n\r\nLe reste du temps, gardez le 90 jours, dormez tranquille, et ressortez ce document quand le CA/Browser Forum imposera 45 jours par défaut (vers 2027-2028).\r\n--\r\n\r\nSources\r\nLet's Encrypt — Six-Day and IP Address Certificates Available in Certbot (mars 2026)\r\nLet's Encrypt — 6-day and IP address certs in general availability (janvier 2026)\r\nDocumentation Certbot — Hooks\r\nCA/Browser Forum Baseline Requirements"},{"uuid":"f8d53247-6fee-4953-864e-c283ef537120","slug":"stockage-pour-raspberry-pi","title":"Le stockage principal du Raspberry Pi","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-02 08:02:00","created_at":"2023-02-02 08:02:00","updated_at":"2023-02-02 08:02:00","tags":[],"plain":"En standard, les Raspberry Pi requièrent au minimum pour fonctionner un support de stockage mémoire carte SD ou micro SD selon le modèle.\nCartes SD pour Raspberry Pi\nLa taille minimale pour une installation de Raspbian Lite est de 4 Go. Pour les Raspberry Pi 3A+ et 3B+, la taille maximale de la carte SD de boot doit être de 256 Go. En règle générale, une carte de 32 Go suffit. L’usure des cartes SD est due uniquement à l'écriture des informations dans les cellules mémoire flash. Il faut entre 10 000 et 100 000 cycles d'écriture sur une cellule avant la mort de celle-ci, selon les technologies.\nCarte SD de 32 Go pour Raspbian Desktop Full La partition de la carte SD doit être FAT16 ou FAT32. Attention, car les cartes SD de taille supérieure à 32 Go sont formatée en exFAT. Il sera impératif de reformater en FAT32.\nBoot sur disque dur avec un Raspberry Pi\n> Modifier le fichier Jusqu'au Raspberry Pi 3, pour indiquer au Raspberry Pi de booter sur le disque dur branche sur un port USB, il faut à la fin du fichier écrire un paramètre. Celui-ci modifie le registre 17, bit 21 de l'OTP.\nPlus d'informations sur l'OTP : OTP register and bit definitions\n> Vérifier\nAprès avoir redémarré de nouveau, dans un terminal, il faut exécuter le programme vcgencmd avec le paramètre optdump. Cela affiche toutes les valeurs OTP (One-time Programmable). La valeur retournée doit être : Soit en binaire (32 bits) : J'éteins le Raspberry Pi et enlève la carte micro SD. Le Raspberry Pi peut maintenant démarrer sur un périphérique USB (clé ou disque). Si un carte micro SD est présente, elle reste prioritaire lors de la séquence de boot.\nRéduire le temps de démarrage\nOn peut raccourcir le délai de boot sur disque USB ou clé USB, en insérant une carte micro SD vierge.\nA voir aussi\nVidéo : Raspberry Pi 3B/3B+ USB SATA/SSD (2019)\nBoot simplifié sur USB avec les Raspberry Pi 1, 2 et 3\nhttps:jamesachambers.com/raspberry-pi-storage-benchmarks-2019-benchmarking-script/"}] |