Comment activer HTTPS en local pour le développement

La plupart des développeurs frontend pensent qu’ils ont besoin de HTTPS en local pour utiliser des API du navigateur comme les service workers ou la géolocalisation. C’est en réalité une idée reçue — les navigateurs traitent déjà localhost comme un contexte sécurisé, donc ces API fonctionnent parfaitement en HTTP simple. Mais il existe des situations réelles où vous avez véritablement besoin de HTTPS en local : tester des URL de callback OAuth, travailler avec des cookies dans un environnement similaire à la production, développer avec un nom d’hôte personnalisé, ou reproduire précisément le comportement de production. Cet article vous montre comment le configurer proprement.

Quand vous avez réellement besoin de HTTPS en local

Avant de vous lancer dans la création d’un certificat, demandez-vous si vous en avez vraiment besoin. http://localhost est traité comme une origine potentiellement digne de confiance par tous les navigateurs majeurs. Les service workers, l’accès à la caméra et la plupart des API nécessitant un contexte sécurisé fonctionnent sans aucune configuration HTTPS. Vous pouvez confirmer ce comportement dans les données de compatibilité des navigateurs sur webstatus.dev.

Vous pouvez néanmoins vouloir un vrai HTTPS local lorsque :

• Vous testez le comportement des cookies dans des conditions qui correspondent à la production, notamment avec des cookies Secure sur des noms d’hôte autres que localhost
• Vous testez des flux OAuth ou OIDC avec des URL de callback qui doivent correspondre à une origine HTTPS enregistrée
• Vous développez avec un nom d’hôte personnalisé comme app.localhost au lieu de localhost
• Vous devez tester sur un appareil mobile sur le même réseau
• Votre frontend et backend fonctionnent tous deux en local et doivent communiquer via HTTPS pour reproduire le comportement de production

Si aucun de ces cas ne s’applique, évitez cette configuration et gardez les choses simples.

Pourquoi les certificats auto-signés ne fonctionnent pas bien

Le premier réflexe évident est de générer un certificat auto-signé. Le problème : les navigateurs ne font pas confiance aux certificats à moins qu’ils ne soient signés par une autorité de certification connue. Un certificat auto-signé déclenche l’avertissement « Votre connexion n’est pas privée », et vous devrez cliquer pour passer outre à chaque fois — ou désactiver complètement la vérification des certificats, ce qui crée de mauvaises habitudes.

La bonne approche consiste à créer une autorité de certification locale à laquelle votre système et vos navigateurs font confiance, puis à émettre des certificats signés par cette CA. C’est exactement ce que fait mkcert.

Configuration de certificats locaux de confiance avec mkcert

mkcert est un outil sans configuration qui crée une CA locale, l’enregistre dans le magasin de confiance de votre système, et émet des certificats signés par celle-ci. Les navigateurs font confiance à ces certificats sans avertissements.

Étape 1 : Installer mkcert

Sur macOS :

brew install mkcert
brew install nss  # requis pour Firefox

Sur Linux, utilisez votre gestionnaire de paquets ou suivez le guide d’installation de mkcert. Sur Windows, utilisez Chocolatey ou Scoop.

Étape 2 : Enregistrer la CA locale

mkcert -install

Cela crée une CA racine et l’ajoute au magasin de confiance de votre système. Vous n’avez besoin de le faire qu’une seule fois par machine.

Étape 3 : Générer un certificat pour votre nom d’hôte

mkcert localhost
# ou pour un nom d'hôte personnalisé :
mkcert app.localhost

Cela produit deux fichiers : un certificat (.pem) et une clé privée (-key.pem). Gardez-les hors du contrôle de version — ajoutez-les à votre .gitignore.

Configuration de votre serveur de développement pour utiliser HTTPS

La façon dont vous transmettez le certificat à votre serveur de développement dépend de vos outils.

Vite — la méthode la plus simple, en utilisant vite-plugin-mkcert :

import mkcert from 'vite-plugin-mkcert'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [mkcert()]
})

Le plugin gère automatiquement la génération du certificat et la configuration du serveur.

Vite (manuel) :

import fs from 'fs'
import { defineConfig } from 'vite'

export default defineConfig({
  server: {
    https: {
      key: fs.readFileSync('./localhost-key.pem'),
      cert: fs.readFileSync('./localhost.pem'),
    }
  }
})

Next.js — utilisez le flag next dev --experimental-https disponible dans les versions récentes, ou configurez manuellement un serveur HTTPS Node.js personnalisé en utilisant les mêmes fichiers de certificat.

Node.js (n’importe quel framework) :

const https = require('https')
const fs = require('fs')

https.createServer({
  key: fs.readFileSync('localhost-key.pem'),
  cert: fs.readFileSync('localhost.pem'),
}, app).listen(3000)

Important : Ne partagez jamais et ne commitez jamais le fichier rootCA-key.pem que mkcert génère. Si quelqu’un obtient ce fichier, il peut émettre des certificats de confiance pour n’importe quel domaine sur votre machine. Exécutez mkcert -CAROOT pour trouver où il est stocké.

Une note de sécurité sur Node.js

Si votre backend local effectue des requêtes HTTPS vers d’autres services locaux, Node.js ne fera pas automatiquement confiance à votre CA mkcert — il utilise sa propre liste intégrée d’autorités de confiance plutôt que le magasin de confiance du système. Corrigez cela en définissant une variable d’environnement :

export NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem"

Ajoutez ceci à votre profil shell (.bashrc, .zshrc, etc.) pour qu’il persiste entre les sessions.

Conclusion

Activer HTTPS en local n’est pas quelque chose dont chaque projet a besoin — mais quand vous en avez besoin, un certificat auto-signé ne suffira pas. mkcert vous donne des certificats localhost correctement approuvés en quelques minutes, sans avertissements du navigateur ni solutions de contournement. Configurez-le une fois, pointez votre serveur de développement vers les fichiers générés, et votre environnement local se comportera exactement comme la production.

FAQ

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.