Migrer de Tailscale Cloud à Headscale : tutoriel pas-à-pas 2026

📍 Article principal du cluster : Headscale 2026 : guide complet.

Vous payez 90 USD par mois pour 5 utilisateurs Tailscale Premium. Vous voulez basculer sur Headscale auto-hébergé sans casser la connectivité de votre équipe. Ce tutoriel détaille la procédure éprouvée chez plusieurs PME africaines : préparation, bascule par lots de 5 appareils, validation, et plan de rollback si quelque chose tourne mal.

Prérequis

• Headscale en production avec HTTPS (voir Déployer Headscale).
• Accès admin à votre compte Tailscale Cloud actuel.
• Liste des appareils actifs avec propriétaire et rôle.
• Niveau attendu : intermédiaire.
• Temps estimé : 1 jour pour préparation, 1 à 3 jours pour bascule progressive.

Étape 1 — Audit de l’existant Tailscale Cloud

Listez via la CLI Tailscale Cloud :

tailscale status --json | jq '.Peer | to_entries | map({name: .value.HostName, ip: .value.TailscaleIPs[0], user: .value.UserID, online: .value.Online})'

Notez :

• Nombre total d’appareils.
• Appareils critiques (serveurs production, qui ne peuvent pas être déconnectés).
• Subnet routers (annoncent des LAN).
• Exit nodes éventuels.
• ACL actuelles (export depuis Tailscale Admin Console).

Étape 2 — Reproduire les utilisateurs et ACL côté Headscale

Pour chaque utilisateur Tailscale Cloud, créer son équivalent Headscale :

headscale users create amadou
headscale users create fatou
headscale users create servers

Pour les ACL, exporter le HuJSON depuis Tailscale Admin Console (Settings → Access controls → Tailscale ACL) et copier-coller dans /etc/headscale/policy.hujson :

headscale policy set -f /etc/headscale/policy.hujson

Étape 3 — Test de bascule sur un appareil pilote

Choisir un appareil non-critique (votre laptop personnel). Procédure :

# Sur le pilote
tailscale logout
tailscale up --login-server=https://headscale.votre-entreprise.com --auth-key=PREAUTH_KEY

Vérifier sur Headscale :

headscale nodes list

Tester la connectivité vers les autres appareils encore sur Tailscale Cloud (impossible : les deux mesh sont distincts) puis vers les appareils sur Headscale (devrait marcher).

Étape 4 — Bascule par lots de 5 appareils

Stratégie : ne pas migrer en une fois pour limiter l’impact en cas de problème. Lot 1 : 3 développeurs + 1 serveur staging. Tester pendant 24h. Si tout va bien, lot 2 : 5 personnes du marketing + 1 serveur prod secondaire. Etc.

Pendant la bascule, les utilisateurs encore sur Tailscale Cloud ne voient plus les appareils déjà migrés. Communiquer clairement : « les serveurs production sont sur Headscale depuis 14h, reconfigurez votre client avant 18h ».

Étape 5 — Cas particulier : serveurs critiques en production

Pour un serveur Postgres production que vous ne pouvez pas déconnecter :

# Ne JAMAIS faire tailscale logout sur le serveur sans plan B
# Préparer la commande tailscale up Headscale avant
PREAUTH=$(headscale preauthkeys create -u servers --expiration 168h | tail -1)
echo "PREAUTH=$PREAUTH"

# Sur le serveur prod, dans une seule commande :
tailscale logout && \
  tailscale up --login-server=https://headscale.votre-entreprise.com --auth-key=$PREAUTH

L’opération prend 2 à 5 secondes. Si elle échoue, tailscale up sans argument se reconnecte à Tailscale Cloud (rollback automatique).

Étape 6 — Subnet routers et exit nodes

Pour les routeurs annonçant un LAN, mêmes flags qu’avec Tailscale Cloud :

tailscale up --login-server=https://headscale.votre-entreprise.com \
  --auth-key=PREAUTH \
  --advertise-routes=192.168.10.0/24 \
  --advertise-exit-node

Côté Headscale, valider les routes :

headscale routes list
headscale routes enable -r ROUTE_ID

Étape 7 — Décommissionnement Tailscale Cloud

Une fois tous les appareils migrés et stables pendant 7 jours :

1. Tailscale Admin Console → Settings → Manage subscription.
2. Choisir « Cancel subscription ».
3. L’abonnement est annulé en fin de période, vous gardez l’accès jusqu’à la date.
4. Au moment du cutoff, supprimer définitivement les appareils résiduels via Machines → Delete.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Trois précisions terrain. Bascule en heures décalées : effectuer les migrations entre 22h et 5h heure locale, quand l’usage est minimal. Pour une équipe couvrant Dakar/Lomé/Cotonou, choisir 23h GMT. Communication interne : en plus du mail, créer un canal Telegram ou WhatsApp Business « Migration Headscale » pour notifier en temps réel. Période de chevauchement : conserver l’abonnement Tailscale Cloud actif pendant 14 jours après bascule complète, comme rollback de sécurité. Coût : 90 USD que vous payez sur 14 jours, soit ~ 42 USD. Acceptable face au risque.

Tutoriels frères

• Déployer Headscale sur VPS
• ACL pour équipe distribuée

FAQ

Mes données Tailscale Cloud (logs, métadonnées) sont-elles supprimées après cancel ? Tailscale annonce une suppression dans 30 jours après cancellation. Si conformité importante, demander confirmation écrite via support.

Puis-je avoir Tailscale Cloud et Headscale en parallèle pendant la bascule ? Pas sur le même appareil simultanément, mais oui en parallèle : un appareil peut basculer entre les deux selon la commande tailscale up exécutée.

Comment garder l’historique des connexions Tailscale Cloud ? Exporter via Admin Console → Logs → Export (CSV). Conserver localement dans archive chiffrée pendant 1 an pour audit.

Faut-il modifier les ACL applicatives (firewalls applicatifs) ? Non, les IPs internes Tailscale (100.64.0.0/10) restent les mêmes — seul le serveur de coordination change.

Les apps Tailscale Inc. continuent-elles de fonctionner après bascule ? Oui, identique. Aucune perte de fonctionnalité côté client (sauf SAML SSO Tailscale, à remplacer par OIDC Headscale).

Pour aller plus loin

• 🔝 Retour au pilier : Guide complet Headscale 2026
• Documentation Tailscale Cancel : tailscale.com/kb/billing