Cédrix
1 line
47 KiB
JSON
1 line
47 KiB
JSON
[{"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":"104a8694-4268-4e0a-99c7-e7ecfd47af1e","slug":"auto-heberger-son-serveur-mail-en-2026","title":"Auto-héberger son serveur mail en 2026","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-12 08:35","created_at":"2026-05-12 08:38:14","updated_at":"2026-05-12 08:40:06","tags":[],"plain":"Survivre aux règles de Gmail, Outlook et consorts\r\nContexte — Cet article de Clubic (lien) rappelle une vérité technique : SMTP date de 1982, n'a aucune sécurité native, et toutes les \"rustines\" (SPF, DKIM, DMARC, MTA-STS, DANE) ont été conçues par Yahoo, Cisco, Microsoft, Google. Depuis février 2024 (Google) et mai 2025 (Microsoft), tout expéditeur dépassant 5000 mails/jour vers Gmail/Outlook doit configurer SPF + DKIM + DMARC, maintenir un taux de spam < 0,1 %, et fournir un lien de désinscription en un clic.\r\nMais même en dessous de 5000/jour, ces règles s'appliquent en pratique : sans elles, ton mail finit en spam ou est rejeté. Ce dossier décrit comment monter son propre serveur mail tout en passant à travers ces filtres.\r\n--\r\n\r\nSommaire\r\n\r\n1. Avant de commencer : est-ce vraiment une bonne idée ?\r\n2. Prérequis techniques\r\n3. Architecture cible\r\n4. Choix du fournisseur et de l'IP\r\n5. Configuration DNS complète\r\n6. Installation du stack mail\r\n7. SPF, DKIM, DMARC : les rustines obligatoires\r\n8. MTA-STS, TLS-RPT, DANE : aller plus loin\r\n9. PTR (reverse DNS) et HELO\r\n10. Warmup d'IP : la phase la plus délicate\r\n11. Postmaster Tools, SNDS, FBL\r\n12. Liste de désinscription en un clic (RFC 8058)\r\n13. Anti-spam entrant et hygiène\r\n14. Monitoring, logs, alertes\r\n15. Que faire quand Gmail rejette quand même ?\r\n16. Checklist finale avant mise en prod\r\n17. Annexes : commandes utiles\r\n--\r\n\r\n1. Avant de commencer : est-ce vraiment une bonne idée ?\r\n\r\nL'auto-hébergement mail est techniquement possible, mais c'est probablement le service le plus pénible à maintenir en 2026. Avant de te lancer, lis ça :\r\n\r\nCe qui marche bien en auto-hébergé :\r\nRecevoir du mail (presque tout le monde te livre).\r\nEnvoyer vers d'autres serveurs auto-hébergés ou pros bien configurés.\r\nGarder le contrôle sur tes données, tes alias, tes domaines.\r\n\r\nCe qui est dur :\r\nEnvoyer vers Gmail / Outlook / Yahoo / iCloud sans atterrir en spam.\r\nSortir d'une blacklist une fois dedans.\r\nMaintenir un score de réputation IP correct sur la durée.\r\nSurvivre à un changement unilatéral des règles côté gros acteurs (cf. février 2024 et mai 2025).\r\n\r\nStratégie réaliste recommandée :\r\nRéception entrante : auto-hébergée à 100 %. Aucun risque, full contrôle.\r\nEnvoi sortant : deux options, selon ton volume et ton tolérance au risque.\r\nOption A — Pure auto-hébergée : tu envoies directement depuis ton serveur. Faisable, mais demande un warmup, une IP propre, et un suivi continu.\r\nOption B — Smart host sortant : tu envoies via un relais réputé (un autre de tes serveurs avec une IP qui a déjà sa réputation, ou un service type Mailjet/Sendgrid/SMTP2GO en bas volume gratuit). Tes mails sortent depuis l'IP du relais, qui a déjà sa réputation faite. C'est un compromis : tu perds une partie de la souveraineté technique, mais tu gagnes énormément en délivrabilité.\r\n\r\nLe reste du dossier suit l'option A — tout en t'expliquant comment basculer en B si nécessaire.\r\n--\r\n\r\n2. Prérequis techniques\r\nÉlément | Détail |\r\n---|---|\r\nDomaine | À toi, registrar peu importe, mais avec DNSSEC activable (cf. §8 pour DANE). |\r\nServeur | VPS ou dédié, 2 vCPU / 4 Go RAM minimum, Debian 12+ ou Ubuntu 24.04 LTS. |\r\nIP fixe v4 | Indispensable. IP \"résidentielle\" ou IP de datacenter récemment recyclée = exclues. |\r\nIP fixe v6 | Recommandée, mais désactivable si l'IPv6 du fournisseur est blacklistée. |\r\nPTR / reverse DNS | Modifiable par toi. Si l'hébergeur ne te le permet pas, change d'hébergeur. |\r\nPorts | 25, 465, 587, 993, 4190 ouverts sortants ET entrants. Le port 25 sortant est bloqué chez beaucoup d'hébergeurs grand public (OVH résidentiel, Free, etc.) : vérifie avant. |\r\nTLS | Certificat valide (Let's Encrypt suffit). |\r\n\r\nCompétences attendues : Linux en ligne de commande, DNS (champs A/AAAA/MX/TXT/SRV/CAA/TLSA), notion de TLS, lecture de logs et .\r\n--\r\n\r\n3. Architecture cible\r\n\r\nUn stack standard, éprouvé, en logiciels libres :\r\n\r\n\r\n\r\nComposants :\r\nPostfix : MTA. Reçoit, route, envoie le SMTP.\r\nDovecot : serveur IMAP/POP3, livraison locale (LMTP), authentification SASL pour Postfix, gestion Sieve (filtres).\r\nRspamd : antispam moderne, fait aussi la vérification SPF/DKIM/DMARC entrante, le greylisting, et — option recommandée — la signature DKIM sortante (en remplacement d'OpenDKIM).\r\nLet's Encrypt (certbot) : TLS.\r\n(Optionnel) Roundcube ou SnappyMail : webmail.\r\n\r\nAlternative tout-en-un : Mailcow ou Mailu, basés sur Docker, qui empaquètent tout ça avec une interface admin. Si tu préfères ne pas tout configurer à la main, c'est légitime — la majorité des règles DNS et de délivrabilité de ce dossier restent identiques.\r\n--\r\n\r\n4. Choix du fournisseur et de l'IP\r\n\r\nLe choix de l'hébergeur conditionne la moitié de ta délivrabilité. Avant de prendre un VPS :\r\n\r\n1. Le port 25 sortant est-il ouvert ? Beaucoup d'hébergeurs le bloquent par défaut pour limiter le spam (Hetzner l'ouvre sur demande, OVH l'ouvre selon le produit, Scaleway l'ouvre selon le compte). Pose la question au support avant de payer.\r\n2. Le PTR est-il configurable ? Si non, change.\r\n3. L'IP a-t-elle été utilisée par un spammeur ? Avant d'acheter le VPS, demande l'IP qu'on te donnera. Vérifie sur :\r\nmxtoolbox.com/blacklists.aspx\r\nmultirbl.valli.org\r\ntalosintelligence.com (Cisco)\r\nsenderscore.org\r\n \r\n Si l'IP est listée sur Spamhaus, Barracuda, SORBS, SpamCop, demande à l'hébergeur de te l'échanger ou prends un autre VPS. Une fois listée, tu vas y passer des semaines.\r\n4. Réputation du subnet (). Même si ton IP est propre, si le est pourri (beaucoup de spammeurs voisins), Gmail va te traiter avec méfiance. Vérifie sur senderscore.org en saisissant ton IP — le score du subnet apparaît.\r\n\r\nHébergeurs réputés corrects pour le mail : Hetzner, OVH (gamme dédiée, pas SoYouStart), Scaleway, Infomaniak (en VPS), Netcup. À éviter pour de l'envoi : DigitalOcean (subnets souvent grillés), Linode/Akamai (idem), AWS EC2 (le port 25 est limité par défaut, et la rate-limit est costaude).\r\n--\r\n\r\n5. Configuration DNS complète\r\n\r\nPour un domaine avec un serveur mail sur à l'IP (et en v6) :\r\n\r\n\r\n\r\nDétails dans les sections dédiées plus bas.\r\n\r\nÀ ne pas oublier : l'enregistrement PTR (reverse DNS) se configure chez ton hébergeur, pas dans ta zone DNS. Il doit pointer . C'est traité au §9.\r\n--\r\n\r\n6. Installation du stack mail\r\n\r\nSur Debian 12. Ce qui suit est volontairement condensé — pour une configuration ligne par ligne, suis le tutoriel de référence de Workaround.org qui est l'étalon depuis 20 ans.\r\n\r\n\r\n\r\nPostfix : configuration minimale-mais-saine\r\n\r\n\r\n\r\nDovecot, Rspamd\r\n\r\nCes composants demandent leurs propres fichiers de configuration. Renvoi explicite vers les tutos qui font autorité :\r\nWorkaround.org / ISPmail : https://workaround.org/ispmail/ — référence francophone et anglophone, mise à jour à chaque version Debian.\r\nRspamd quickstart : https://www.rspamd.com/doc/tutorials/quickstart.html\r\nDovecot wiki : https://doc.dovecot.org/\r\n\r\nSi tu veux gagner du temps, Mailcow () est aujourd'hui la solution clé-en-main la plus fiable.\r\n--\r\n\r\n7. SPF, DKIM, DMARC : les rustines obligatoires\r\n\r\nSans ces trois enregistrements correctement configurés, Gmail et Outlook rejetteront ou marqueront en spam la majorité de tes messages — peu importe ton volume.\r\n\r\nSPF (Sender Policy Framework)\r\n\r\nDéclare qui a le droit d'envoyer du mail pour ton domaine.\r\n: autorise les serveurs listés dans le MX du domaine.\r\n: rejet strict de tout le reste. Indispensable pour la réputation. Ne jamais utiliser (softfail) en prod : Gmail aujourd'hui considère comme un signal faible.\r\n\r\nSi tu envoies aussi via un relais externe (smart host) : ajoute son , ex. .\r\n\r\nLimite : un enregistrement SPF doit tenir en 10 lookups DNS maximum. Au-delà, il est invalide. Vérifie avec https://www.kitterman.com/spf/validate.html.\r\n\r\nDKIM (DomainKeys Identified Mail)\r\n\r\nSigne chaque mail sortant avec une clé privée. Le destinataire vérifie la signature via la clé publique publiée en DNS.\r\n\r\nGénération de la clé (Rspamd, sélecteur , clé 2048 bits) :\r\n\r\n\r\n\r\nLe fichier contient l'enregistrement DNS à publier :\r\n\r\n\r\n\r\nConfiguration Rspamd () :\r\n\r\n\r\n\r\nRecharge : .\r\n\r\nVérification : envoie un mail à check-auth@verifier.port25.com, tu reçois un rapport complet SPF/DKIM/DMARC en retour. Ou utilise https://www.mail-tester.com/ (note sur 10).\r\n\r\nDMARC (Domain-based Message Authentication, Reporting and Conformance)\r\n\r\nDit aux serveurs distants quoi faire en cas d'échec SPF/DKIM, et te renvoie des rapports sur ce qui passe et ce qui rate.\r\n: surveillance seule, à utiliser pendant 2-4 semaines en démarrage pour collecter les rapports sans pénaliser.\r\n: mise en spam des mails non authentifiés. Cible normale.\r\n: rejet pur. À atteindre en cible finale, après avoir vérifié 4 semaines de rapports propres.\r\n: adresse pour les rapports agrégés (quotidiens).\r\n: rapports forensiques (par message). Optionnel.\r\n: alignement strict — le domaine de signature DKIM et le domaine SPF doivent exactement correspondre au domaine .\r\n\r\nLecture des rapports DMARC : ils arrivent en XML, illisibles. Utilise un parseur :\r\nPostmark DMARC Monitoring (gratuit, agrège les rapports dans une UI).\r\nparsedmarc (auto-hébergeable, envoie dans Elasticsearch/Splunk/Grafana).\r\n--\r\n\r\n8. MTA-STS, TLS-RPT, DANE : aller plus loin\r\n\r\nCes standards sécurisent le transport entre serveurs (chiffrement TLS forcé). Gmail les regarde, Microsoft aussi. Pas obligatoires, mais ils boostent ta réputation.\r\n\r\nMTA-STS\r\n\r\nForce les serveurs distants à utiliser TLS pour t'envoyer des mails. Trois éléments :\r\n\r\n1. Enregistrement DNS TXT :\r\n\r\n\r\n2. Sous-domaine servant un fichier en HTTPS à :\r\n\r\n\r\n est la cible. En démarrage, mets pendant 1-2 semaines.\r\n\r\n3. Certificat TLS valide sur ce sous-domaine (déjà fait via certbot au §6).\r\n\r\nTLS-RPT\r\n\r\nDemande aux serveurs distants de t'envoyer des rapports en cas d'échec TLS.\r\n\r\n\r\n\r\nDANE (DNS-based Authentication of Named Entities)\r\n\r\nEncore plus solide que MTA-STS, mais nécessite DNSSEC activé sur ton domaine. Si ton registrar ne supporte pas DNSSEC, oublie DANE.\r\n\r\nDANE publie un hash du certificat TLS dans un enregistrement TLSA :\r\n\r\n\r\n\r\nOu plus simplement avec https://www.huque.com/bin/gentlsa :\r\n\r\n\r\n\r\nVérification globale de tout ton setup TLS+DANE : https://internet.nl/mail/ (excellent, recommandé).\r\n--\r\n\r\n9. PTR (reverse DNS) et HELO\r\n\r\nLe PTR est probablement la cause la plus fréquente de rejet par Gmail/Outlook chez les nouveaux auto-hébergés.\r\n\r\nRègle absolue : , et tout doit être un FQDN cohérent.\r\n\r\nConfigure le PTR dans le panneau de ton hébergeur (chez OVH : \"IP\" → \"Reverse DNS\") :\r\n\r\n\r\nVérifie :\r\n\r\n\r\nDans Postfix, et c'est ce qui est annoncé en HELO. Cohérence garantie.\r\n--\r\n\r\n10. Warmup d'IP : la phase la plus délicate\r\n\r\nUne IP neuve = pas de réputation = défiance maximale des gros acteurs. Tu ne peux pas envoyer 1000 mails le jour 1 sans te griller.\r\n\r\nPlan de warmup sur 4 à 6 semaines\r\nSemaine | Volume max/jour vers Gmail+Outlook | Volume max/jour total | Contenu |\r\n---|---|---|---|\r\n1 | 20-50 | 100 | Mails à toi-même, comptes test sur Gmail/Outlook/Yahoo. Réponds-y, marque \"non spam\" si en spam. |\r\n2 | 100 | 300 | Cercle proche qui sait répondre / interagir. |\r\n3 | 300 | 1000 | Élargissement progressif. |\r\n4 | 800 | 3000 | Ouvre aux usages normaux. |\r\n5+ | 2000+ | volume cible | Stable. |\r\n\r\nRègles d'or pendant le warmup :\r\nPas de mailing list, pas de notifs automatiques en masse. Privilégie des mails 1-à-1 conversationnels.\r\nDemande aux destinataires de répondre — un mail avec réponse a 100x le poids d'un mail ouvert silencieusement.\r\nAucun lien raccourci, aucun pixel de tracking, aucune image lourde.\r\nStop net si ton score Senderscore baisse ou si Gmail Postmaster Tools (cf. §11) montre du rouge.\r\n\r\nSi tu as un volume immédiat à envoyer\r\n\r\nBascule en option B (smart host) le temps du warmup, puis rapatrie progressivement en interne en répliquant les volumes ci-dessus.\r\n--\r\n\r\n11. Postmaster Tools, SNDS, FBL\r\n\r\nLes gros acteurs te donnent des dashboards dédiés. Inscris-toi à tous, dès la création du domaine.\r\nService | Acteur | Usage |\r\n---|---|---|\r\nGoogle Postmaster Tools | Gmail | Réputation IP+domaine, taux de spam, authentification, encryption. Indispensable. |\r\nMicrosoft SNDS | Outlook/Hotmail | Smart Network Data Services, qualité de l'IP. |\r\nMicrosoft JMRP | Outlook | Junk Mail Reporting Program, FBL Microsoft. |\r\nYahoo CFL | Yahoo | Complaint Feedback Loop. |\r\nValidity Sender Score | Indépendant | Score sur 100, à surveiller. |\r\n\r\nConfigure les feedback loops (FBL) : quand un destinataire clique \"spam\", tu reçois une notification. Ça te permet de désinscrire l'utilisateur avant qu'il ne dégrade ta réputation.\r\n--\r\n\r\n12. Liste de désinscription en un clic (RFC 8058)\r\n\r\nExigence Google/Microsoft pour les expéditeurs en volume, mais à mettre en place dès le début même en bas volume.\r\n\r\nAjoute deux en-têtes à tous les mails non-strictement-personnels :\r\n\r\n\r\n\r\nL'URL HTTPS doit accepter une requête POST (pas seulement GET) avec dans le corps, et désinscrire immédiatement et silencieusement sans demander de confirmation.\r\n--\r\n\r\n13. Anti-spam entrant et hygiène\r\n\r\nUn serveur mail mal configuré côté entrée devient vite un relais de spam ou une cible. Configuration Rspamd minimale :\r\n\r\n\r\n\r\n\r\n\r\nActive aussi :\r\nVérification SPF/DKIM/DMARC entrante (par défaut activée dans Rspamd).\r\nRBL (Realtime Blackhole Lists) : Spamhaus ZEN, Barracuda. Attention à ne pas multiplier — 2 ou 3 RBL fiables suffisent.\r\nGreylisting : refuse temporairement les premiers contacts, ce qui élimine 80% du spam basique. Ne pas activer sur un domaine à fort volume transactionnel (gêne les notifs).\r\nBayes : laisse Rspamd apprendre via le dossier de Dovecot (signal / ).\r\n\r\nMises à jour : activé, redémarrage planifié, lecture des annonces sécu Postfix/Dovecot.\r\n--\r\n\r\n14. Monitoring, logs, alertes\r\n\r\nSans monitoring, tu découvres les problèmes par les utilisateurs. À mettre en place :\r\nLecture des logs : , , web UI de Rspamd sur .\r\nMétriques : exporter Postfix/Dovecot vers Prometheus + Grafana (, ).\r\nAlertes sur :\r\nFile d'attente Postfix > 50 messages ().\r\nScore Senderscore qui chute.\r\nApparition sur une RBL : surveillance automatisée par https://multirbl.valli.org/ ou via un script qui interroge plusieurs DNSBL en cron.\r\nÉchec TLS-RPT (rapport entrant signalant une connexion non chiffrée).\r\nRapports DMARC parsés régulièrement (cf. §7).\r\n--\r\n\r\n15. Que faire quand Gmail rejette quand même ?\r\n\r\nÇa arrive. Diagnostic dans l'ordre :\r\n\r\n1. Lis le code de rejet SMTP dans . Gmail renvoie des codes très explicites :\r\n→ contenu jugé spammy. Revois le contenu, ajoute du texte conversationnel, retire les liens douteux.\r\n→ tu as dépassé un seuil. Ralentis immédiatement, attends 24-48h, reprends doucement.\r\n→ ton DMARC ne passe pas. Revérifie SPF/DKIM/alignement.\r\n→ tu es sur une RBL. Va sur spamhaus.org/lookup/ pour vérifier et demander la sortie.\r\n2. Va dans Postmaster Tools (§11). Si \"IP reputation\" est rouge ou orange, regarde le contenu et le timing de tes envois récents.\r\n3. Test mail-tester : envoie à une adresse fournie par mail-tester.com, obtiens une note sur 10. Vise 10/10. Toute case manquante doit être corrigée.\r\n4. Sortie de blacklist : la plupart des RBL (Spamhaus, Barracuda) ont un formulaire de retrait. Spamhaus retire en quelques heures si tu corriges la cause. SORBS est plus lent. UCEPROTECT exige souvent de payer — ignore-la, peu de serveurs sérieux la consultent.\r\n5. Si rien ne marche, change d'IP. C'est parfois la seule issue. Demande à ton hébergeur une IP fraîche, refais un warmup.\r\n--\r\n\r\n16. Checklist finale avant mise en prod\r\n\r\nAvant d'envoyer le premier vrai mail :\r\n[ ] Domaine avec DNSSEC activé.\r\n[ ] IP testée sur 5+ blacklists, propre.\r\n[ ] Port 25 sortant ouvert et testé ().\r\n[ ] PTR configuré et cohérent avec le HELO.\r\n[ ] MX, A, AAAA, SPF, DKIM, DMARC publiés et validés via mxtoolbox.com.\r\n[ ] MTA-STS publié (mode au démarrage).\r\n[ ] TLS-RPT publié.\r\n[ ] DANE/TLSA publié (si DNSSEC OK).\r\n[ ] CAA publié.\r\n[ ] Test envoyé à : tout en .\r\n[ ] Test mail-tester.com : 10/10.\r\n[ ] Test internet.nl/mail/ : 100%.\r\n[ ] Inscription Postmaster Tools, SNDS, JMRP, Yahoo CFL.\r\n[ ] DMARC au démarrage, parser de rapports en place.\r\n[ ] List-Unsubscribe + List-Unsubscribe-Post implémentés.\r\n[ ] Plan de warmup affiché et respecté.\r\n[ ] Monitoring file d'attente + RBL en place.\r\n[ ] Backup chiffré des Maildir.\r\n\r\nAu bout de 4 semaines de rapports DMARC propres : passage à . Au bout de 8-12 semaines : .\r\n--\r\n\r\n17. Annexes : commandes utiles\r\n\r\n\r\n\r\nOutils web à mettre en favoris\r\nhttps://www.mail-tester.com/ — score sur 10\r\nhttps://internet.nl/mail/ — audit complet\r\nhttps://mxtoolbox.com/SuperTool.aspx — DNS, blacklists\r\nhttps://dmarcian.com/dmarc-inspector/ — vérif DMARC\r\nhttps://www.kitterman.com/spf/validate.html — vérif SPF\r\nhttps://postmaster.google.com/ — Google Postmaster\r\nhttps://senderscore.org/ — réputation IP\r\n\r\nDocumentation de référence\r\nISPmail / Workaround.org — https://workaround.org/ispmail/ — le tutoriel le plus complet et tenu à jour, par version Debian.\r\nMailcow docs — https://docs.mailcow.email/ — pour la version conteneurisée clé-en-main.\r\nPostfix officiel — https://www.postfix.org/documentation.html\r\nRspamd docs — https://www.rspamd.com/doc/\r\nRFCs essentielles** : 5321 (SMTP moderne), 7208 (SPF), 6376 (DKIM), 7489 (DMARC), 8461 (MTA-STS), 8460 (TLS-RPT), 7672 (DANE-SMTP), 8058 (One-Click Unsubscribe).\r\n--\r\n\r\nL'auto-hébergement mail en 2026 reste possible, mais c'est devenu un sport : les règles changent, les gros acteurs durcissent leurs critères, et l'écosystème pousse vers la centralisation. Si tu réussis le warmup et tiens 6 mois sans incident, tu as gagné — mais ne baisse pas la garde, un changement unilatéral de Google peut survenir à tout moment, comme en février 2024."},{"uuid":"293562a2-3319-4ef7-8fc6-6605c3795bf1","slug":"mails-frauduleux","title":"E-mails frauduleux","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-02 07:38:57","created_at":"2023-02-02 07:38:57","updated_at":"2023-02-02 07:38:57","tags":[],"plain":"Un e-mail frauduleux (ou \"spoofing\") est un e-mail qui semble provenir d'une source fiable, mais qui a en réalité été envoyé par une personne ou une entreprise différente dans le but de tromper les destinataires. Les e-mails frauduleux peuvent avoir un aspect très convaincant et peuvent demander aux destinataires de fournir des informations sensibles telles que des mots de passe, des numéros de carte de crédit ou des informations personnelles. Il est important de ne jamais fournir des informations sensibles à des sources inconnues et de signaler immédiatement tout e-mail suspect à la sécurité informatique ou aux autorités compétentes. Voici quelques exemples.\nTable des matières\nintroduction Les pages\n<nav stacked=\"true\" fade=\"true\"> </nav> Les sous-catégories\n<nav stacked=\"true\" fade=\"true\"> </nav>"},{"uuid":"3f750a3a-fad0-4089-98e5-79c8b4287ea2","slug":"esp8266ex-restore-commandes-at","title":"Réinitialisation d'un ESP-01 : restauration du firmware AT","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-12-13 14:35","created_at":"2020-12-13 14:35:26","updated_at":"2026-05-13 18:15:11","tags":[],"plain":"Introduction\r\n\r\nL'ESP-01 est un petit module Wi-Fi très répandu, construit autour du microcontrôleur ESP8266EX fabriqué par Espressif. À sa sortie d'usine, il est livré avec un firmware (le programme interne du circuit) qui permet de le piloter à l'aide de commandes textuelles simples appelées commandes AT. Ce firmware peut être effacé ou corrompu, par exemple après avoir téléversé un programme Arduino ou MicroPython sur le module. Ce document explique comment remettre l'ESP-01 dans son état d'origine afin de retrouver l'usage des commandes AT.\r\n\r\nQuelques notions préalables\r\n\r\nAvant de commencer, il est utile de clarifier quelques termes.\r\n\r\nUn firmware est le logiciel embarqué dans un composant électronique. Contrairement à un programme installé sur un ordinateur, il s'écrit directement dans la mémoire flash du microcontrôleur et s'exécute au démarrage du circuit.\r\n\r\nUn fichier binaire (extension ) est le résultat de la compilation d'un code source écrit dans un langage évolué, généralement le C. Une fois compilé, le fichier ne contient plus que des instructions destinées au processeur, illisibles directement par un humain. Il n'est pas nécessaire de les modifier : ils se téléversent tels quels dans le microcontrôleur.\r\n\r\nLa mémoire flash de l'ESP8266EX est divisée en zones. Chaque binaire doit être écrit à une adresse mémoire précise, sans quoi le module ne saura pas où trouver le code à exécuter au démarrage. Sur l'ESP-01, la mémoire est généralement organisée en 512k + 512k, ce qui signifie que la flash totale de 8 Mbit (1 Mo) est partagée en deux zones de 512 ko : l'une pour le programme actif, l'autre réservée aux mises à jour à distance (OTA).\r\n\r\nÉtape 1 — Télécharger le firmware AT officiel\r\n\r\nLe firmware est mis à disposition par Espressif sur son site officiel :\r\n\r\nhttps://www.espressif.com/en/products/socs/esp8266ex/resources\r\n\r\n\r\n\r\nDans la section , choisir la version ou plus récente. L'archive ZIP téléchargée contient plusieurs binaires destinés à l'ESP8266EX.\r\n\r\nQuatre fichiers sont particulièrement importants :\r\nbootv1.7.bin — le chargeur de démarrage (bootloader), premier programme exécuté à la mise sous tension ;\r\nuser1.1024.new.2.bin — le programme AT proprement dit, qui interprète les commandes envoyées par la liaison série ;\r\nespinitdatadefaultv08.bin — les données d'initialisation (paramètres radio, calibration) ;\r\nblank.bin — un fichier rempli de zéros, utilisé pour réinitialiser certaines zones de la flash.\r\n\r\nUne copie de ces binaires pour la configuration ESP8266EX 512k+512k est disponible ici :\r\n\r\nhttps://gitlab.com/cedricAbonnel/esp/-/tree/master/esp01/esp8266exatbin\r\n\r\nÉtape 2 — Identifier le port série de l'ESP-01\r\n\r\nL'ESP-01 ne se connecte pas directement à un port USB : il faut passer par un adaptateur USB-série (souvent un module FTDI ou CH340). Une fois branché, l'ordinateur expose ce périphérique sous la forme d'un fichier dans .\r\n\r\nPour repérer ce fichier, exécuter dans un terminal :\r\n\r\n\r\n\r\nParmi les entrées affichées, celle qui nous intéresse est généralement /dev/ttyUSB0 (parfois si plusieurs adaptateurs sont branchés, ou selon le modèle).\r\n\r\nUne astuce utile : exécuter la commande une première fois sans l'adaptateur, puis une seconde fois après l'avoir branché. La nouvelle entrée qui apparaît est celle du module.\r\n\r\nÉtape 3 — Préparer le téléversement avec esptool.py\r\n\r\nesptool.py est l'outil officiel d'Espressif, écrit en Python, qui permet de communiquer avec la mémoire flash de l'ESP8266EX. S'il n'est pas déjà installé, on peut l'obtenir via :\r\n\r\n\r\n\r\nAvant le téléversement, l'ESP-01 doit être placé en mode programmation : la broche GPIO0 doit être reliée à la masse (GND) au moment de la mise sous tension. Sans cette manipulation, le module démarre normalement et refuse l'écriture en flash.\r\n\r\nÉtape 4 — Téléverser les binaires\r\n\r\nLa commande suivante écrit les quatre binaires aux bonnes adresses mémoire :\r\n\r\n\r\n\r\nDécortiquons les options :\r\nindique le port série identifié à l'étape précédente ;\r\nest la sous-commande d'écriture en mémoire flash ;\r\nprécise le mode d'accès à la flash (Quad I/O, le plus rapide, supporté par l'ESP-01).\r\n\r\nChaque valeur hexadécimale (, , etc.) qui précède un nom de fichier indique l'adresse mémoire à laquelle l'écriture doit commencer. La table de correspondance officielle pour une flash de 8 Mbit organisée en 512k+512k est la suivante :\r\n\r\n\r\n\r\nL'adresse correspond aux paramètres système, et à la zone RF système : les remplir de zéros () garantit un démarrage propre.\r\n\r\nSi tout se passe bien, esptool affiche la progression du téléversement et confirme la réussite de l'opération. C'est le moment d'apprécier le travail accompli :\r\n\r\n\r\n\r\nÉtape 5 — Vérifier le bon fonctionnement\r\n\r\nAprès le téléversement, retirer la connexion entre GPIO0 et la masse, puis redémarrer le module. Ouvrir une console série (par exemple avec , ou la console série de l'IDE Arduino) à la vitesse 115200 bauds :\r\n\r\n\r\n\r\nTaper la commande suivie d'un retour à la ligne. Le module doit répondre . La commande retourne la version du firmware installé, ce qui permet de confirmer la réussite de la réinitialisation.\r\n\r\n\r\n\r\nEn cas de problème\r\n\r\nQuelques pistes si la procédure échoue :\r\nAucune réponse d'esptool : vérifier que GPIO0 est bien reliée à GND au moment de l'alimentation, et que l'adaptateur USB-série fournit assez de courant (l'ESP-01 demande des pics jusqu'à 300 mA).\r\nRéponses illisibles dans la console série : la vitesse par défaut a pu changer selon la version du firmware. Essayer 9600, 74880 ou 115200 bauds.\r\nErreur de checksum ou de mode flash** : essayer à la place de , certains clones d'ESP-01 ne supportent pas le mode Quad I/O.\r\n\r\nConclusion\r\n\r\nCette procédure restaure un ESP-01 dans son état d'origine, prêt à recevoir des commandes AT depuis n'importe quel système capable de dialoguer en série : ordinateur, Arduino, Raspberry Pi, etc. Elle constitue également un bon exercice d'introduction aux notions de firmware, de mémoire flash et de programmation bas-niveau des microcontrôleurs."},{"uuid":"6f2639a5-58ed-4102-a6a2-0acbecf01de5","slug":"esp8266-commandes-at","title":"ESP8266 : prise en main des commandes AT","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-12-13 08:51","created_at":"2020-12-13 08:51:55","updated_at":"2026-05-13 18:23:54","tags":[],"plain":"Présentation\r\n\r\nL'ESP8266 est un microcontrôleur Wi-Fi développé par Espressif. Lorsqu'il sort d'usine, ou lorsqu'il est flashé avec le firmware AT officiel d'Espressif, il accepte un jeu d'instructions textuelles appelées commandes AT (ou commandes Hayes, du nom du fabricant de modems qui les a popularisées dans les années 1980).\r\n\r\nLe module ESP-01, le plus répandu pour découvrir l'ESP8266, est généralement livré avec ce firmware AT préchargé. Il est donc utilisable immédiatement, sans programmation, simplement en lui envoyant des commandes texte sur sa liaison série.\r\nPrérequis matériel : un ESP-01 connecté à un PC via un adaptateur USB-série, et un terminal série (moniteur série de l'IDE Arduino, , , PuTTY…) configuré à 115200 bauds avec fin de ligne CR+LF.\r\nNote sur les versions : la syntaxe et les codes retour des commandes AT varient selon la version du firmware. Les exemples ci-dessous correspondent à un firmware AT v1.x typique sur ESP-01. Pour les firmwares plus récents (AT v2.x sur ESP32), certaines commandes prennent des paramètres supplémentaires.\r\n\r\nTravaux pratiques\r\n\r\nL'enchaînement ci-dessous permet de mettre l'ESP-01 sur un réseau Wi-Fi, puis de le transformer en serveur HTTP minimaliste. Chaque commande est envoyée depuis le terminal série ; les lignes préfixées par représentent la réponse du module.\r\n\r\n1. Vérifier le mode Wi-Fi courant\r\n\r\n\r\n\r\nLe module répond avec un chiffre indiquant son mode courant (voir glossaire plus bas).\r\n\r\n2. Passer en mode dual (client + point d'accès)\r\n\r\n\r\n\r\nLe mode 3 active simultanément le mode station (le module se connecte à un Wi-Fi existant) et le mode AP (le module expose son propre point d'accès). C'est le mode le plus polyvalent pour expérimenter.\r\n\r\n3. Se connecter à un réseau Wi-Fi\r\n\r\n\r\n\r\nTrois événements sont remontés successivement :\r\nWIFI CONNECTED : association réussie au point d'accès ;\r\nWIFI GOT IP : adresse IP obtenue via DHCP ;\r\nOK : la commande est terminée avec succès.\r\n\r\n4. Lister les adresses IP et MAC du module\r\n\r\n\r\n\r\nEn mode dual, le module possède deux interfaces réseau :\r\nAP (point d'accès) : adresse fixe par défaut, sur laquelle se connectent les clients du Wi-Fi exposé par l'ESP ;\r\nSTA (station/client) : adresse attribuée par le routeur du réseau auquel l'ESP s'est connecté.\r\n\r\n5. Activer les connexions multiples\r\n\r\n\r\n\r\nPar défaut, l'ESP n'accepte qu'une seule connexion TCP simultanée. Le mode multi-connexion est obligatoire pour faire fonctionner le module en serveur (étape suivante).\r\n\r\n6. Démarrer un serveur TCP sur le port 80\r\n\r\n\r\n\r\nLe module écoute désormais sur le port 80 de son adresse STA. Un simple navigateur pointé sur (l'adresse retournée par ) déclenche une connexion HTTP.\r\n\r\n7. Observer une requête entrante\r\n\r\nLorsqu'un client se connecte, l'ESP recopie sur la liaison série l'événement de connexion, puis la requête HTTP brute, et enfin la fermeture de la connexion :\r\n\r\n\r\n\r\nLecture :\r\n: un client vient de s'associer ; est l'identifiant de connexion (link ID), utile en mode multi-connexion ;\r\n: l'ESP a reçu 341 octets sur la connexion ; ces octets suivent immédiatement (ici, l'en-tête HTTP envoyé par Firefox) ;\r\n: le client a fermé la connexion (ou un timeout est intervenu).\r\n\r\nÀ ce stade, l'ESP ne répond rien au client : il faut explicitement envoyer une réponse avec (voir glossaire). Le navigateur affichera donc une page vide ou un message d'erreur.\r\n\r\nPour aller plus loin : répondre au client\r\n\r\nPour renvoyer une page HTML minimale au client :\r\n\r\n\r\n\r\nLe module affiche et attend exactement le nombre d'octets annoncé, puis envoie le tout sur la connexion . Il faut ensuite fermer la connexion avec :\r\n--\r\n\r\nGlossaire des commandes AT\r\n\r\nConventions\r\n\r\nTrois formes coexistent pour la plupart des commandes :\r\nForme | Syntaxe | Rôle |\r\n---|---|---|\r\nInterrogation | | Lire la valeur courante |\r\nTest | | Lister les valeurs autorisées |\r\nAffectation | | Modifier la valeur |\r\n\r\nLes chaînes de caractères (SSID, mot de passe…) sont toujours encadrées par des guillemets droits.\r\n\r\nCommandes Wi-Fi\r\n\r\n— Mode de fonctionnement Wi-Fi\r\n\r\n\r\n\r\nValeurs de :\r\nValeur | Mode | Description |\r\n---|---|---|\r\n1 | STA | Station/client : le module se connecte à un Wi-Fi existant |\r\n2 | AP | Point d'accès : le module expose son propre Wi-Fi |\r\n3 | STA+AP | Mode dual : les deux à la fois |\r\n\r\nExemple :\r\n\r\n\r\n\r\n— Lister les points d'accès visibles\r\n\r\n\r\n\r\nRetourne une ligne par réseau détecté, sous la forme :\r\nChamp | Signification |\r\n---|---|\r\n| Chiffrement : ouvert, WEP, WPA-PSK, WPA2-PSK, WPA/WPA2-PSK |\r\n| Nom du réseau |\r\n| Puissance du signal en dBm (plus la valeur est proche de 0, plus le signal est fort) |\r\n| Adresse MAC du point d'accès (BSSID) |\r\n| Canal Wi-Fi (1 à 13 en Europe sur 2,4 GHz) |\r\n\r\nExemple :\r\n\r\n\r\n\r\nPrérequis : doit inclure le mode station (1 ou 3).\r\n\r\n— Se connecter à un point d'accès\r\n\r\n\r\n\r\nCodes d'erreur retournés en cas d'échec via :\r\nCode | Signification |\r\n---|---|\r\n1 | Délai de connexion dépassé |\r\n2 | Mot de passe incorrect |\r\n3 | SSID introuvable |\r\n4 | Échec de connexion (autre) |\r\n\r\nExemple d'échec :\r\n\r\n\r\n\r\nExemple de réussite :\r\n\r\n\r\n\r\n— Se déconnecter du point d'accès\r\n\r\n\r\n\r\nÀ ne pas confondre avec une commande de sauvegarde : signifie Quit AP, c'est-à-dire déconnexion. Les paramètres de connexion (SSID, mot de passe) sont en revanche automatiquement mémorisés en flash par les commandes et dans les versions classiques du firmware AT — le module se reconnectera donc au démarrage suivant.\r\n\r\n— Adresses IP et MAC locales\r\n\r\n\r\n\r\nRenvoie les adresses IP et MAC du module pour chaque interface active :\r\n/ : interface point d'accès (toujours par défaut) ;\r\n/ : interface station (attribuée par le DHCP du réseau rejoint).\r\n\r\nEn mode , seule la partie STA est retournée ; en mode 2, seule la partie AP.\r\n\r\nCommandes TCP/IP\r\n\r\n— Activer les connexions multiples\r\n: connexion unique (mode par défaut) ;\r\n: jusqu'à 5 connexions simultanées, chacune identifiée par un link ID de 0 à 4.\r\n\r\nPrérequis pour passer en mode 1 : aucune connexion ne doit être active, et le module ne doit pas déjà être en mode serveur.\r\n\r\n— Démarrer un serveur TCP\r\n: pour démarrer, pour arrêter ;\r\n: port d'écoute, optionnel (par défaut 333).\r\n\r\nPrérequis : doit avoir été exécuté au préalable.\r\n\r\nAprès un arrêt (), un redémarrage du module est nécessaire () pour libérer complètement le port.\r\n\r\n— Envoyer des données sur une connexion\r\n\r\n\r\n\r\nLe module affiche un prompt et attend exactement octets, puis transmet le bloc au client. Indispensable pour répondre à une requête HTTP entrante.\r\n\r\n— Fermer une connexion\r\n\r\n\r\n\r\nCommandes générales utiles\r\nCommande | Rôle |\r\n---|---|\r\n| Test de présence du module (doit répondre ) |\r\n| Redémarrer le module |\r\n| Afficher la version du firmware AT |\r\n| Changer le débit série (non persistant) |\r\n/ | Désactiver / activer l'écho des commandes |\r\n--\r\n\r\nRécapitulatif : déclarer un serveur HTTP minimal\r\n\r\nSéquence complète depuis un ESP-01 vierge :\r\n\r\n\r\n\r\nÀ partir de cet instant, toute connexion entrante sur est remontée sur le port série sous forme d'événements , à charge pour le programme côté PC (ou pour un firmware personnalisé) de les analyser et de répondre via .\r\n\r\nLimites du firmware AT\r\n\r\nLe firmware AT est pratique pour découvrir et tester l'ESP8266, mais il montre vite ses limites :\r\nlatence importante (chaque commande passe par le port série) ;\r\npas de TLS correct dans les anciennes versions ;\r\ncomplexité pour gérer plusieurs clients simultanés ;\r\ndépendance à un hôte qui pilote l'ESP en permanence.\r\n\r\nPour des projets plus aboutis, il est préférable de flasher l'ESP avec un firmware personnalisé (Arduino, ESP-IDF, MicroPython, Tasmota, ESPHome…) qui exécute directement la logique applicative sur le microcontrôleur, sans intermédiaire série.\r\n```"}] |