Updates in FR

content/fr/docs/certificates-for-localhost.md

@@ -15,7 +15,7 @@ La meilleure option : Générez votre propre certificat, soit auto-signé, soit
 
 # Pour les applications natives dialoguant avec les applications web
 
-Parfois, les développeurs souhaitent proposer une application native téléchargeable qui peut être utilisée simultanément avec un site web pour offrir des fonctionnalités supplémentaires. Par exemple, les applications de bureau Dropbox et Spotify recherchent des fichiers sur votre machine, ce qu'une application web ne serait pas autorisée à faire. Une approche courante consiste à ce que ces applications natives offrent un service web sur localhost, et que l'application web fasse des requêtes via XMLHTTPRequest (XHR) ou WebSockets. L'application web utilise presque toujours le HTTPS, ce qui signifie que les navigateurs lui interdisent d'effectuer des requêtes XHR ou WebSockets vers des URL non sécurisées. C'est ce qu'on appelle le "Mixed Content Blocking". Pour communiquer avec l'application web, l'application native doit fournir un service web sécurisé.
+Parfois, les développeurs souhaitent proposer une application native téléchargeable qui peut être utilisée simultanément avec un site web pour offrir des fonctionnalités supplémentaires. Par exemple, les applications de bureau Dropbox et Spotify recherchent des fichiers sur votre machine, ce qu'une application web ne serait pas autorisée à faire. Une approche courante consiste à ce que ces applications natives offrent un service web sur localhost, et que l'application web fasse des requêtes via XMLHttpRequest (XHR) ou WebSockets. L'application web utilise presque toujours le HTTPS, ce qui signifie que les navigateurs lui interdisent d'effectuer des requêtes XHR ou WebSockets vers des URL non sécurisées. C'est ce qu'on appelle le "Mixed Content Blocking". Pour communiquer avec l'application web, l'application native doit fournir un service web sécurisé.
 
 Heureusement, les navigateurs modernes [considèrent ][mcb-localhost] `http://127.0.0.1:8000/` comme une URL ["potentiellement fiable"][secure-contexts] car elle renvoie à une adresse de loopback. Le trafic envoyé a `127.0.0.1` est garanti de ne pas quitter votre machine, et est donc considéré comme automatiquement sécurisé contre l'interception par le réseau. Cela signifie que si votre application web est HTTPS, et que vous offrez un service web d'application native sur `127.0.0.1`, les deux peuvent heureusement communiquer via XHR. Malheureusement, [localhost ne reçoit pas encore le même traitement][let-localhost]. De plus, WebSockets n'obtiennent ce traitement pour aucun des deux noms.
 

content/fr/docs/expiration-emails.md

@@ -1,30 +1,10 @@
 ---
 title: expiration-emails
 slug: expiration-emails
-lastmod: 2025-03-02
+lastmod: 2025-06-25
 show_lastmod: 1
 ---
 
-# Attention : Fin de vie annoncée pour les courriels d'expiration
+# Fermeture du service de notification par e-mail en cas d'expiration
 
-Veuillez noter que Let's Encrypt mettra fin à son service d'expiration des courriels conformément à [ce billet de blog](/2025/01/22/ending-expiration-emails/).
-
-# S'abonner
-
-Si vous fournissez une adresse e-mail à Let's Encrypt lorsque vous créez votre compte, nous ferons de notre mieux pour vous envoyer automatiquement des avis d'expiration lorsque votre certificat doit être renouvelé. Nous essayons d'envoyer le premier avis 20 jours avant l'expiration de votre certificat, et le deuxième et dernier avis 7 jours avant son expiration. Nous vous recommandons de vous fier à votre client ACME pour renouveler automatiquement vos certificats, et d'utiliser ces avis d'expiration comme un rappel pour vérifier votre automatisation.
-
-# Quand vous recevez un courriel d'expiration
-
-Si votre certificat est déjà renouvelé, nous n'enverrons pas d'avis d'expiration. Nous considérons qu'un certificat est renouvelé s'il existe un certificat plus récent avec exactement le même ensemble de noms, quel que soit le compte qui l'a créé. Si vous avez émis un nouveau certificat qui ajoute ou supprime un nom par rapport à votre ancien certificat, vous recevrez un courriel d'expiration concernant votre ancien certificat. Si vous vérifiez le certificat en cours d'exécution sur votre site web et qu'il indique la date correcte, aucune autre action n'est nécessaire. Pour consulter l'historique des certificats émis pour votre domaine, vous pouvez rechercher votre domaine sur les moniteurs du journal de transparence des certificats tels que [crt.sh](https://crt.sh/).
-
-# Désabonnement
-
-Le corps du courriel comporte un lien permettant de se désabonner des futurs avis. Si vous cliquez sur ce lien, vous ne recevrez aucun avis d'expiration pour l'année suivante. La liste des "personnes désinscrites" est indépendante pour les avis de pré-production et les avis de production, vous pouvez donc vous désinscrire de pré-production sans affecter votre statut production.
-
-Notez que votre désabonnement n'est valable que pour un an, vous devrez donc le renouveler chaque année.
-
-Il n'y a pas encore de moyen pour nous de vous réabonner de manière efficace si vous vous désabonnez. Notre fournisseur de courrier électronique, Mandrill, [dispose d'un mécanisme manuel que nous devons encore automatiser](https://mandrill.zendesk.com/hc/en-us/articles/360039299913).
-
-Cependant, vous pouvez changer l'adresse électronique de votre compte, ce qui vous réabonne effectivement. De nombreux services de courrier électronique courants traitent `votre nom+1@example.com` de la même manière que `yourname@example.com`. Ainsi, si vous mettez à jour votre adresse électronique en `votre nom+1@example.com`, vous pouvez recommencer à recevoir le courrier d'expiration. Avec Certbot, utilisez :
-
-`certbot update_account --email yourname+1@example.com`
+Let's Encrypt a [mis fin à son service de notification par e-mail en cas d'expiration](/2025/01/22/ending-expiration-emails/).