Pocket ID self-hosted : passkeys pour PME — tutoriel 2026

📍 Article principal du cluster : IAM open-source pour PME : Keycloak, Authelia, Authentik comparés (2026)
Cet article fait partie du cluster « IAM self-hosted ». Pour la vue d’ensemble des solutions, lisez d’abord le pilier avant de suivre ce tutoriel.

Introduction

Imaginez un collaborateur qui rejoint votre PME à Dakar, Abidjan ou Bamako : il reçoit un lien d’invitation, ouvre Chrome sur son téléphone Android, pose le pouce sur le capteur d’empreinte — et c’est tout. Pas de mot de passe à choisir, pas d’email de réinitialisation à gérer, pas de Post-it avec « Azerty123! » sous le clavier. C’est exactement ce que Pocket ID vous permet de déployer en self-hosted, en moins de vingt minutes, sur le VPS le plus modeste du marché.

Pocket ID est un fournisseur d’identité OIDC (OpenID Connect) minimaliste et passkeys-only. Son principe est radical : il supprime entièrement le mot de passe de son architecture. Il n’existe pas de formulaire login/password, pas de table de hachage de mots de passe en base, pas de politique de rotation à imposer à vos utilisateurs. L’unique facteur d’authentification est un passkey FIDO2/WebAuthn — biométrie du téléphone, YubiKey physique, ou Windows Hello. Le projet est open-source (licence MIT), maintenu activement sur GitHub à l’adresse github.com/pocket-id/pocket-id, et utilise SQLite comme base de données, ce qui simplifie radicalement la sauvegarde et la maintenance.

Pour une PME ouest-africaine qui gère Vaultwarden (coffre-fort de mots de passe), Forgejo (forge Git), Nextcloud ou tout autre service compatible OIDC, Pocket ID représente le maillon SSO le plus simple à opérer. Ce tutoriel vous guide de l’installation à la mise en production, avec les adaptations spécifiques au contexte local.

Prérequis

Un VPS Linux avec au moins 512 Mo de RAM — Ubuntu 22.04 LTS ou Debian 12 recommandés. Un Hetzner CX11 (2,49 €/mois) ou un VPS OVH Starter suffisent largement.
Docker Engine 24+ et Docker Compose v2 installés (docker compose version doit répondre).
Un sous-domaine dédié avec certificat TLS — par exemple auth.monentreprise.sn. WebAuthn est une API HTTPS-only : sans TLS valide, les passkeys sont inutilisables. Utilisez Caddy ou Nginx + Certbot.
Un téléphone Android 7+ ou iOS 16+, ou une YubiKey série 5 pour votre premier passkey administrateur.
Temps estimé : 15 à 25 minutes pour un premier déploiement fonctionnel.
Niveau attendu : intermédiaire — vous savez éditer un fichier docker-compose.yml et utiliser SSH.

Étape 1 — Pocket ID vs Keycloak : choisir le bon outil

Avant de déployer quoi que ce soit, il est utile de comprendre pourquoi Pocket ID existe à côté de solutions plus connues comme Keycloak, Authentik ou Authelia. Ce positionnement détermine si Pocket ID est le bon choix pour votre situation — ou si vous devriez consulter le pilier du cluster pour comparer les alternatives.

Keycloak est un mastodonte : il gère des milliers d’utilisateurs, des dizaines de realms, l’LDAP, le SAML, des flows d’authentification entièrement personnalisables, des politiques de mot de passe granulaires, du social login, de la MFA par TOTP… et nécessite une JVM, idéalement 2 Go de RAM, une base PostgreSQL dédiée, et un administrateur qui connaît son interface complexe. C’est l’outil de référence pour les entreprises de taille intermédiaire ou les équipes DevOps chevronnées.

Pocket ID, à l’inverse, a un périmètre délibérément réduit à l’essentiel : un fournisseur OIDC qui authentifie via passkey, avec une interface d’administration légère, une base SQLite, et zéro configuration de flows. Son avantage concurrentiel n’est pas la richesse fonctionnelle — c’est la simplicité opérationnelle. Pour une PME de 5 à 50 personnes qui veut un SSO fiable sans embaucher un ingénieur IAM, c’est le bon calibre.

Critère	Pocket ID	Keycloak	Authentik
RAM minimum	~64 Mo	~1,5 Go	~512 Mo
Base de données	SQLite (inclus)	PostgreSQL requis	PostgreSQL requis
Authentification	Passkeys uniquement	MDP + MFA + social	MDP + MFA + social
Temps de setup	~20 min	~2–4 h	~1–2 h
Courbe d’apprentissage	Faible	Très élevée	Modérée
OIDC / OAuth2	Oui (client OIDC)	Oui (complet)	Oui (complet)

Si vous avez besoin de mots de passe classiques en parallèle, d’une intégration LDAP/Active Directory, ou de SAML — Pocket ID n’est pas votre solution. Mais si l’objectif est de supprimer les mots de passe de votre stack d’outils internes, Pocket ID est imbattable sur la simplicité.

Étape 2 — Déployer Pocket ID via Docker Compose

Pocket ID se distribue sous forme d’une image Docker unique qui embarque à la fois le backend Go et le frontend. Il n’y a pas de service séparé à orchestrer : un seul conteneur suffit. La configuration passe entièrement par des variables d’environnement, ce qui rend le fichier Compose très lisible.

Connectez-vous à votre VPS en SSH et créez le répertoire de travail :

mkdir -p /opt/pocket-id && cd /opt/pocket-id

Créez ensuite le fichier docker-compose.yml suivant. Remplacez auth.monentreprise.sn par votre sous-domaine réel et choisissez un chemin local pour la persistance des données :

services:
  pocket-id:
    image: ghcr.io/pocket-id/pocket-id:latest
    container_name: pocket-id
    restart: unless-stopped
    ports:
      - "1411:1411"
    environment:
      # URL publique de votre instance — DOIT être en HTTPS
      PUBLIC_APP_URL: https://auth.monentreprise.sn
      # Clé secrète pour signer les tokens JWT — générez via: openssl rand -hex 32
      JWT_SECRET: REMPLACER_PAR_UNE_CLE_ALEATOIRE_64_CHARS
      # Fuseau horaire (important pour les logs et la validité des tokens)
      TZ: Africa/Dakar
      # Durée de vie de la session (en secondes) — 8h par défaut
      SESSION_DURATION: 28800
    volumes:
      # Persistance de la base SQLite et des fichiers de configuration
      - ./data:/app/data

Ce fichier Compose n’utilise pas le champ version: obsolète — Docker Compose v2 n’en a plus besoin et émet un avertissement si vous le laissez. La variable PUBLIC_APP_URL est critique : c’est l’origine WebAuthn que le navigateur va vérifier cryptographiquement lors de la création et de l’utilisation d’un passkey. Si cette URL ne correspond pas exactement au domaine du navigateur, l’authentification échoue avec une erreur InvalidStateError.

Avant de lancer, générez une clé JWT robuste et remplacez-la dans le fichier :

openssl rand -hex 32

Démarrez maintenant le conteneur en arrière-plan :

docker compose up -d
docker compose logs -f pocket-id

Les logs doivent afficher Server started on :1411. Pocket ID écoute sur le port 1411 — configurez votre reverse proxy (Caddy ou Nginx) pour faire terminer le TLS sur ce port et exposer https://auth.monentreprise.sn au monde. Avec Caddy, la configuration est minimaliste : un bloc auth.monentreprise.sn { reverse_proxy localhost:1411 } suffit, le certificat Let’s Encrypt étant obtenu automatiquement.

Étape 3 — Créer le compte admin et enregistrer le premier passkey

Au premier démarrage, Pocket ID génère automatiquement un lien d’inscription unique pour le compte administrateur. Ce lien est à usage unique et expire après 15 minutes. Vous devez le récupérer dans les logs immédiatement après le lancement :

docker compose logs pocket-id | grep "setup"

Vous verrez une ligne similaire à :
Admin setup URL: https://auth.monentreprise.sn/setup?token=abc123...

Ouvrez cette URL sur l’appareil avec lequel vous allez créer le passkey administrateur — téléphone ou ordinateur. Le navigateur vous demande de renseigner votre nom et email, puis déclenche immédiatement la création d’un passkey via l’API WebAuthn. Sur Android, Chrome affiche une invite « Enregistrer la clé de sécurité dans le Gestionnaire de mots de passe Google » ou propose la biométrie locale. Sur iOS, Safari propose Face ID ou Touch ID. Sur un PC avec une YubiKey branchée, Firefox ou Chrome proposent le flow FIDO2 matériel.

Ce passkey est lié cryptographiquement au domaine auth.monentreprise.sn — il ne peut être utilisé sur aucun autre site, ce qui rend le phishing structurellement impossible. Une fois le passkey créé, vous accédez à l’interface d’administration de Pocket ID, accessible à https://auth.monentreprise.sn/admin.

Pour ajouter d’autres administrateurs ou utilisateurs, naviguez dans Admin → Users → Create User. Pocket ID envoie un lien d’invitation par email — l’utilisateur clique, enregistre son passkey, et peut immédiatement s’authentifier sur tous les services OIDC configurés. Si vous ne disposez pas d’un serveur SMTP, vous pouvez copier le lien d’invitation manuellement depuis l’interface admin et l’envoyer par messagerie.

Étape 4 — Configurer un client OIDC pour Vaultwarden ou Forgejo

La valeur de Pocket ID réside dans sa capacité à servir de SSO pour vos outils internes. Voyons comment connecter deux services très courants dans les PME tech : Vaultwarden (coffre-fort de mots de passe Bitwarden compatible) et Forgejo (forge Git légère, alternative à Gitea). La procédure OIDC est identique pour les deux — seuls les noms de variables changent.

Dans l’interface admin de Pocket ID, allez dans OIDC Clients → Create Client. Renseignez :

Name : Vaultwarden (ou Forgejo)
Redirect URIs : l’URL de callback de votre service — pour Vaultwarden : https://vault.monentreprise.sn/identity/connect/oidc-signin ; pour Forgejo : https://git.monentreprise.sn/user/oauth2/pocket-id/callback
Public : laisser décoché (client confidentiel)

Pocket ID génère un Client ID et un Client Secret — copiez-les immédiatement, le secret ne sera plus affiché en clair. Les endpoints OIDC sont exposés sur le well-known standard : https://auth.monentreprise.sn/.well-known/openid-configuration. Ce fichier JSON liste automatiquement l’issuer, le jwks_uri, les scopes supportés — la plupart des services OIDC le consomment directement.

Pour Vaultwarden, ajoutez dans votre docker-compose.yml Vaultwarden les variables d’environnement suivantes :

  environment:
    SSO_ENABLED: "true"
    SSO_ONLY: "false"   # mettre true pour forcer le SSO exclusivement
    SSO_CLIENT_ID: "VOTRE_CLIENT_ID"
    SSO_CLIENT_SECRET: "VOTRE_CLIENT_SECRET"
    SSO_AUTHORITY: "https://auth.monentreprise.sn"

Pour Forgejo, allez dans Site Administration → Authentication Sources → Add Authentication Source, choisissez OAuth2, sélectionnez le provider OpenID Connect, et renseignez l’URL d’auto-découverte https://auth.monentreprise.sn/.well-known/openid-configuration avec votre Client ID et Secret. Forgejo récupère automatiquement tous les endpoints nécessaires.

Après redémarrage des services, le bouton « Se connecter avec Pocket ID » apparaît sur les pages de login. Vos utilisateurs cliquent, s’authentifient avec leur passkey, et sont redirigés dans l’application sans avoir jamais tapé un mot de passe.

Étape 5 — Contrôle d’accès par groupes d’utilisateurs

Toutes vos applications OIDC ne doivent pas être accessibles à tous vos collaborateurs. Un stagiaire ne devrait pas accéder à Vaultwarden de l’équipe de direction, ni un commercial à la forge Git des développeurs. Pocket ID gère ce cloisonnement via les groupes, une fonctionnalité introduite progressivement dans ses versions récentes.

Dans l’interface admin, naviguez vers User Groups → Create Group. Créez par exemple un groupe devs et un groupe direction. Ajoutez vos utilisateurs aux groupes correspondants via Users → Edit → Groups. Puis, dans la configuration de chaque client OIDC (OIDC Clients → Edit), activez l’option Allowed Groups et sélectionnez les groupes autorisés à accéder à ce client.

Lorsqu’un utilisateur non autorisé tente de s’authentifier sur un client dont il n’est pas dans le groupe autorisé, Pocket ID retourne une erreur OIDC access_denied avant même de déclencher la vérification du passkey. Le cloisonnement est donc traité côté SSO, indépendamment de la configuration de chaque application — ce qui évite de dupliquer les règles d’accès dans chaque service.

Les informations de groupe sont transmises dans le token OIDC sous la claim groups (liste de chaînes). Si votre application supporte la lecture de claims personnalisées — Forgejo le fait pour les rôles — vous pouvez ainsi mapper automatiquement les groupes Pocket ID à des rôles applicatifs.

Étape 6 — Sauvegarder la base SQLite

L’ensemble de l’état de Pocket ID — utilisateurs, passkeys enregistrés, clients OIDC, groupes, tokens de session — réside dans un seul fichier SQLite localisé dans le volume que vous avez monté : /opt/pocket-id/data/pocket-id.db. C’est à la fois la grande force de Pocket ID (un seul fichier à sauvegarder) et son unique point de fragilité (perdre ce fichier signifie que tous les passkeys enregistrés sont perdus et que vos utilisateurs devront se réinscrire).

SQLite inclut un mécanisme de sauvegarde à chaud via la commande sqlite3 ... .backup qui garantit l’intégrité de la copie même si la base est active. Voici un script de sauvegarde simple à déposer dans /opt/pocket-id/backup.sh :

#!/bin/bash
DATE=$(date +%Y%m%d-%H%M)
BACKUP_DIR="/opt/pocket-id/backups"
mkdir -p "$BACKUP_DIR"

# Sauvegarde à chaud — intégrité garantie même si Pocket ID tourne
sqlite3 /opt/pocket-id/data/pocket-id.db ".backup $BACKUP_DIR/pocket-id-$DATE.db"

# Garder uniquement les 14 dernières sauvegardes (2 semaines)
ls -t $BACKUP_DIR/pocket-id-*.db | tail -n +15 | xargs rm -f

echo "Backup OK : $BACKUP_DIR/pocket-id-$DATE.db"

Rendez ce script exécutable (chmod +x /opt/pocket-id/backup.sh) et planifiez-le via cron deux fois par jour. Éditez la crontab avec crontab -e et ajoutez :

0 2,14 * * * /opt/pocket-id/backup.sh >> /var/log/pocket-id-backup.log 2>&1

Pour une protection maximale, synchronisez le dossier /opt/pocket-id/backups/ vers un stockage objet externe (Backblaze B2, Scaleway Object Storage, ou même un bucket S3 hébergé en Afrique) via rclone. En cas de crash disque complet du VPS, vous pouvez recréer une instance Pocket ID fonctionnelle en moins de cinq minutes en restaurant ce fichier.

Erreurs fréquentes

Erreur / Symptôme	Cause probable	Solution
`InvalidStateError` lors de la création du passkey	`PUBLIC_APP_URL` ne correspond pas au domaine du navigateur (HTTP vs HTTPS, port différent)	Vérifiez que l’URL dans la variable d’env est identique à l’URL affichée dans la barre d’adresse du navigateur, TLS inclus
Bouton « Se connecter » absent dans Vaultwarden	`SSO_ENABLED` pas défini ou Vaultwarden redémarré sans recharger les variables	`docker compose down && docker compose up -d` ; vérifier les logs Vaultwarden
Erreur OIDC `redirect_uri_mismatch`	L’URL de callback configurée dans Pocket ID ne correspond pas exactement à celle envoyée par le client	Copier l’URL exacte depuis les logs d’erreur et la coller telle quelle dans `Redirect URIs` du client OIDC Pocket ID
Lien d’invitation admin expiré	Le lien de setup a une durée de vie de 15 minutes	Supprimer le conteneur, supprimer le fichier `data/pocket-id.db`, et relancer — Pocket ID régénère un nouveau lien
Utilisateur reçoit `access_denied` sans raison apparente	L’utilisateur n’est pas dans le groupe autorisé pour ce client OIDC	Vérifier `Admin → OIDC Clients → Allowed Groups` et ajouter l’utilisateur au groupe requis
Le passkey ne fonctionne plus après changement de domaine	Les passkeys sont liés cryptographiquement au domaine d’origine (RP ID WebAuthn) — un changement de domaine invalide tous les passkeys existants	Planifier tout changement de domaine à l’avance ; notifier tous les utilisateurs de re-créer leur passkey après la migration
Erreur `database is locked` dans les logs	Deux processus accèdent simultanément au fichier SQLite (ex. sauvegarde `cp` brute pendant une écriture)	Utiliser exclusivement `sqlite3 .backup` pour les sauvegardes à chaud, jamais un `cp` direct

Adaptation au contexte ouest-africain

Le principal argument contre les passkeys en Afrique de l’Ouest est souvent formulé ainsi : « nos utilisateurs n’ont pas de smartphones récents ». Cette objection mérite d’être nuancée avec des données actuelles. Selon les études du GSMA sur l’Afrique subsaharienne, le taux de pénétration des smartphones Android dépasse 60 % dans les zones urbaines du Sénégal, de la Côte d’Ivoire et du Ghana en 2025. Android 7.0 (Nougat), sorti en 2016, est le seuil minimum pour WebAuthn natif via Chrome — et la quasi-totalité des téléphones vendus aujourd’hui, y compris les entrées de gamme Tecno ou Itel à 40 000 FCFA, tournent sur Android 12 ou 13. Chrome pour Android supporte WebAuthn depuis la version 70 (2018). En pratique, pour une PME en zone urbaine, la couverture passkeys sur téléphone Android est réaliste dès aujourd’hui.

Pour les rares cas où un collaborateur dispose d’un téléphone basique (feature phone) ou d’un navigateur trop ancien, Pocket ID peut être combiné avec une stratégie hybride : les utilisateurs sans passkey reçoivent des liens d’authentification magiques (magic links) par email. Ce n’est pas du même niveau de sécurité qu’un passkey FIDO2, mais c’est sans mot de passe et infiniment plus sûr qu’un « Azerty2025 » réutilisé partout. La configuration d’un serveur SMTP (Postfix local, ou un relay externe comme Brevo qui propose 300 emails/jour gratuits) reste plus accessible qu’un serveur LDAP.

L’argument économique est peut-être le plus convaincant pour un dirigeant de PME : chaque ticket de réinitialisation de mot de passe mobilise en moyenne 15 à 30 minutes du temps d’un administrateur système. Pour une équipe de 20 personnes avec une rotation de mots de passe mensuelle et des oublis fréquents, cela représente facilement 5 à 10 heures de travail perdu par mois. Pocket ID supprime structurellement cette charge : si un utilisateur perd son téléphone, il suffit de révoquer ses passkeys depuis l’interface admin et de lui envoyer un nouveau lien d’inscription — opération qui prend 90 secondes.

Sur la bande passante : Pocket ID est exceptionnellement léger. L’interface complète charge en moins de 200 Ko, sans aucune dépendance CDN externe. Sur une connexion ADSL partagée ou une 3G fluctuante de Dakar ou d’Abidjan, les temps de chargement restent acceptables. La base SQLite réduit également la latence des requêtes comparée à un PostgreSQL distant — tout est local sur le VPS.

Concernant les coupures de courant fréquentes dans certaines villes : Docker avec restart: unless-stopped redémarre automatiquement Pocket ID dès que le VPS reprend après une coupure. La durée de session configurable via SESSION_DURATION permet d’allonger la durée de validité des tokens pour les contextes où les reconnexions fréquentes seraient gênantes — 24 heures ou plus pour les outils internes de confiance.

Tutoriels frères

Authelia en self-hosted : 2FA et reverse proxy Nginx — tutoriel complet — pour les équipes qui veulent conserver les mots de passe avec un second facteur TOTP.
Authentik SSO : connecter Nextcloud et Vaultwarden en 2026 — alternative à fonctionnalités plus étendues si vous avez besoin de social login ou d’LDAP.
Vaultwarden self-hosted : déployer votre coffre-fort Bitwarden sur VPS — le service OIDC le plus souvent connecté à Pocket ID en PME.

Pour aller plus loin

Retour au pilier : IAM open-source pour PME : Keycloak, Authelia, Authentik comparés (2026)
Code source et documentation officielle : github.com/pocket-id/pocket-id — README complet, changelog, issues GitHub pour le support communautaire.
Standard WebAuthn/FIDO2 : fidoalliance.org/fido2 — spécification officielle, liste des appareils certifiés FIDO2, ressources pour développeurs.
W3C Web Authentication API : w3.org/TR/webauthn-2 — spécification de niveau 2, référence technique pour comprendre le protocole sous-jacent.
Étape suivante recommandée : après avoir déployé Pocket ID, connectez-y Vaultwarden pour centraliser tous vos secrets d’équipe sous une authentification sans mot de passe — voir le tutoriel frère ci-dessus.

FAQ

Q : Pocket ID peut-il coexister avec des mots de passe pour les applications qui ne supportent pas OIDC ?

R : Pocket ID est un fournisseur d’identité pour les applications compatibles OIDC — il ne remplace pas les mots de passe locaux dans les applications qui n’ont pas de support SSO. Pour les outils sans OIDC, vous continuez à gérer des comptes locaux, idéalement en stockant les mots de passe dans Vaultwarden (lui-même connecté à Pocket ID). L’objectif à terme est de migrer progressivement chaque outil vers OIDC.

Q : Que se passe-t-il si un utilisateur perd son téléphone avec le passkey ?

R : En tant qu’administrateur, vous allez dans Admin → Users → [nom de l'utilisateur] → Passkeys et vous révoquez le passkey perdu. Vous générez ensuite un nouveau lien d’invitation. L’utilisateur l’ouvre sur son nouveau téléphone, enregistre un nouveau passkey, et retrouve immédiatement accès à tous ses services. Toute l’opération prend moins de deux minutes côté admin. Il est recommandé d’encourager les utilisateurs à enregistrer plusieurs passkeys (téléphone principal + clé YubiKey de secours ou passkey sauvegardé dans un gestionnaire de mots de passe).

Q : Les passkeys sont-ils synchronisés entre appareils ?

R : Cela dépend du choix de l’utilisateur lors de la création. Sur Android avec Chrome et un compte Google, le passkey peut être synchronisé dans le Gestionnaire de mots de passe Google et devenir disponible sur tous les appareils Android liés au même compte. Sur iOS/macOS avec Safari, la synchronisation passe par iCloud Keychain. Sur des YubiKeys matérielles, le passkey est non-extractible et reste sur la clé physique — c’est plus sécurisé mais moins pratique. Pocket ID accepte les trois modèles indifféremment.

Q : Pocket ID supporte-t-il plusieurs domaines ou instances multi-tenant ?

R : Non — chaque instance Pocket ID est liée à un seul domaine (PUBLIC_APP_URL) et gère un seul répertoire d’utilisateurs. Pour des besoins multi-entités (par exemple : une agence qui gère plusieurs clients avec des répertoires séparés), il faut déployer plusieurs instances Pocket ID sur des sous-domaines distincts. Compte tenu de la légèreté de Pocket ID (~64 Mo RAM par instance), c’est tout à fait envisageable sur un VPS standard.

Q : Est-il possible de migrer de Pocket ID vers Keycloak si les besoins évoluent ?

R : Les passkeys FIDO2 ne sont pas exportables — ils sont liés cryptographiquement au domaine d’origine et ne peuvent pas être transférés vers un autre fournisseur d’identité. En revanche, les données utilisateurs (noms, emails) peuvent être exportées depuis la base SQLite et importées dans Keycloak. La migration implique de demander à tous les utilisateurs de recréer leurs passkeys sur le nouveau système. C’est une opération possible mais qui nécessite une communication préalable et une période de transition. Planifiez cette migration dès le début si vous anticipez une croissance vers les 100+ utilisateurs.

Q : Pocket ID génère-t-il des logs d’audit des connexions ?

R : Oui — Pocket ID journalise chaque tentative d’authentification (succès et échec) avec l’identifiant de l’utilisateur, le timestamp, l’adresse IP et le client OIDC concerné. Ces logs sont accessibles dans l’interface admin sous Audit Log et sont également écrits sur stdout du conteneur Docker, récupérables via docker compose logs pocket-id. Pour une conservation longue durée, redirigez les logs Docker vers un agrégateur comme Loki (stack Grafana) ou un simple fichier rotatif via le driver json-file avec des options de rotation.

Q : Peut-on utiliser Pocket ID sans avoir un nom de domaine personnalisé ?

R : Techniquement non — WebAuthn exige HTTPS avec un certificat valide, et les certificats Let’s Encrypt ne sont pas délivrés pour des adresses IP brutes. Vous avez besoin d’au minimum un sous-domaine. Des services comme DuckDNS (gratuit) ou No-IP permettent d’obtenir un sous-domaine sans acheter un domaine premium — utile pour les tests ou les petites structures avec un budget très contraint. Pour une PME en production, un domaine .sn ou .ci revient à moins de 10 000 FCFA par an chez les registrars locaux.

ملخص بالعربية: جيب بوكت آيدي على خادمك الخاص في عشرين دقيقة واستخدم مفاتيح المرور (Passkeys) بدلاً من كلمات السر لتأمين مؤسستك الصغيرة أو المتوسطة — دليل عملي كامل لعام 2026.