IAM open-source pour PME : Keycloak, Authelia, Authentik comparés (2026)
Méta-description : Okta est hors budget, le RGPD et l’ARTCI imposent la souveraineté des données : comparez Keycloak, Authelia et Authentik pour choisir et déployer votre IAM open-source en PME en 2026.
Introduction : l’identité numérique, nerf de la guerre pour les PME
Imaginez la situation suivante : votre PME dakaroise utilise ERPNext pour la comptabilité, Nextcloud pour le stockage de fichiers, Mattermost pour la communication interne et Jitsi Meet pour les visioconférences. Chacun de ces outils possède sa propre base utilisateurs. Un employé crée son compte sur ERPNext, un autre compte sur Nextcloud, un troisième sur Mattermost. Lorsqu’un collaborateur quitte l’entreprise, l’administrateur système doit désactiver quatre comptes dans quatre interfaces différentes — et il arrivera inévitablement qu’un compte soit oublié, laissant une porte ouverte pendant des semaines ou des mois. Ce scénario n’est pas théorique : il est le quotidien de la quasi-totalité des PME africaines qui ont commencé à se digitaliser sans penser à la couche d’identité centralisée.
Un système IAM — Identity and Access Management, soit Gestion des Identités et des Accès — est précisément la brique qui résout ce problème. Il centralise l’authentification (qui est-ce que je suis ?), l’autorisation (qu’est-ce que j’ai le droit de faire ?) et la fédération d’identités (comment mon identité est-elle reconnue par plusieurs applications ?). Concrètement, avec un IAM en place, l’employé se connecte une seule fois — on parle de Single Sign-On, ou SSO — et accède à toutes ses applications sans ressaisir son mot de passe. Lorsqu’il quitte l’entreprise, un seul clic dans l’IAM révoque tous ses accès simultanément.
Le marché propose des solutions cloud clés en main comme Okta, Auth0 (racheté par Okta) ou Microsoft Azure Active Directory. Ces plateformes sont excellentes, mais leur modèle tarifaire est pensé pour les grandes entreprises nord-américaines : Okta facture à partir de 2 dollars par utilisateur et par mois pour les fonctionnalités de base, et bien davantage dès que l’on active la MFA avancée ou l’accès conditionnel. Pour une PME de 50 personnes en Afrique de l’Ouest, cela représente un poste budgétaire non négligeable en devise étrangère, avec une dépendance totale à un fournisseur étranger dont les serveurs sont physiquement hors du continent.
À cette contrainte budgétaire s’ajoute une contrainte réglementaire croissante. Le Règlement Général sur la Protection des Données (RGPD) européen s’impose à toute organisation qui traite des données de ressortissants européens, y compris depuis l’Afrique. Mais surtout, des régulateurs locaux se structurent : en Côte d’Ivoire, l’ARTCI (Autorité de Régulation des Télécommunications et de l’ICT) et la CDVP (Commission de la Donnée à Caractère Personnel) définissent un cadre de conformité qui exige de savoir où sont stockées les données des utilisateurs. Confier ces données à un fournisseur cloud américain sans mécanisme de contrôle local devient juridiquement risqué.
La réponse à ces contraintes — budgétaires, réglementaires et opérationnelles — existe sous forme open-source et auto-hébergée. Trois solutions dominent le marché en 2026 : Keycloak, la référence enterprise soutenue par Red Hat ; Authentik, le challenger Python moderne pensé pour la facilité d’administration ; et Authelia, la solution ultra-légère en Go taillée pour les reverse proxies. Ce guide pilier vous donne les éléments pour choisir et déployer la solution adaptée à votre contexte, avec une attention particulière aux réalités des PME d’Afrique de l’Ouest.
Pourquoi self-héberger son IAM ?
La décision de self-héberger un IAM ne se prend pas à la légère, mais elle devient de plus en plus rationnelle à mesure que les infrastructures cloud locales se développent et que les équipes techniques africaines montent en compétence. Voici les quatre raisons principales qui font pencher la balance.
La souveraineté des données d’abord. Un IAM gère les identités numériques de vos employés, de vos clients, parfois de vos partenaires. Ces données sont par nature sensibles : noms, adresses e-mail, numéros de téléphone, rôles dans l’organisation, historiques de connexion. Les confier à un tiers hors du territoire national signifie perdre le contrôle physique sur ces informations. En self-hébergeant sur un VPS dont vous choisissez la localisation — Hetzner en Allemagne pour la conformité RGPD, ou un datacenter local comme ceux qui émergent à Dakar ou Abidjan — vous gardez la maîtrise complète de l’emplacement et du traitement de ces données.
Le coût total sur trois ans. Un VPS Hetzner CX22 (2 vCPU, 4 Go RAM, 40 Go SSD) coûte environ 6 à 8 euros par mois en 2025-2026, soit moins de 100 euros par an. Sur ce VPS, Authelia ou Authentik tournent confortablement pour une PME de 50 à 200 utilisateurs. Comparé à 2 dollars par utilisateur et par mois pour Okta, le retour sur investissement est visible dès la première année pour toute équipe de plus d’une dizaine de personnes. Keycloak demande davantage de ressources — on reviendra sur ce point — mais reste économiquement très compétitif.
La personnalisation sans limite. Les solutions cloud imposent leurs interfaces, leurs workflows d’authentification, leurs limites de personnalisation. En self-hébergeant, vous définissez exactement les protocoles supportés (OIDC, SAML 2.0, LDAP, Kerberos), les flux d’authentification (MFA obligatoire pour certains groupes, MFA optionnel pour d’autres), les pages de connexion aux couleurs de votre marque, les règles d’accès conditionnel. Cette granularité est impossible à obtenir à un tarif raisonnable avec les offres cloud standards.
L’indépendance aux fournisseurs. Le marché cloud a montré, ces dernières années, que les politiques tarifaires peuvent changer brutalement après des rachats ou des pivots stratégiques. Auth0 racheté par Okta, Microsoft modifiant sa politique Azure AD B2C, Heroku supprimant son plan gratuit : ces événements ont forcé des milliers de développeurs à des migrations urgentes et coûteuses. Une solution open-source que vous opérez vous-même ne peut pas être modifiée unilatéralement par un éditeur. Vous choisissez quand et si vous montez de version.
Le self-hosting n’est pas sans contreparties : il exige une compétence DevOps en interne (ou un prestataire de confiance), une stratégie de sauvegarde sérieuse, et un plan de reprise d’activité. Mais pour une PME qui a déjà un administrateur système ou un développeur backend, ces prérequis sont accessibles. Ce guide vous montre précisément comment les satisfaire avec chacune des trois solutions.
Les 3 solutions open-source en détail
Keycloak — la référence Java enterprise
Keycloak est né en 2014 au sein de JBoss, la division open-source de Red Hat. Depuis lors, il est devenu la solution IAM open-source la plus déployée au monde, utilisée par des banques, des administrations publiques et des multinationales. La version 24.x, stable en 2025, introduit un mode de démarrage en production simplifié et améliore significativement les performances du plan de contrôle. La documentation officielle est disponible sur keycloak.org/documentation.
Keycloak est écrit en Java et tourne sur le serveur d’applications Quarkus depuis la version 17 (l’ancienne version WildFly n’est plus maintenue). Ce choix technique a des conséquences directes sur la consommation mémoire : en développement, Keycloak démarre avec 512 Mo de RAM, mais en production avec plusieurs realms actifs, des flux d’authentification complexes et un trafic modéré, il faut compter 2 Go minimum et prévoir 4 Go pour être à l’aise. Pour du clustering haute disponibilité, on monte à 8 Go et plus.
Sur le plan fonctionnel, Keycloak est le plus complet des trois. Il implémente nativement OIDC (OpenID Connect), OAuth 2.0, SAML 2.0, et dispose d’une fédération LDAP/Active Directory poussée. Son système de « realms » permet de gérer plusieurs organisations ou espaces de noms d’identités dans une même instance — une PME peut avoir un realm pour ses employés et un autre pour ses clients, avec des politiques de sécurité différentes. Les « Authentication Flows » sont entièrement configurables via une interface graphique : on peut imposer la MFA TOTP aux administrateurs tout en la gardant optionnelle pour les utilisateurs standards, ou déclencher une vérification d’e-mail uniquement pour certains groupes.
L’administration se fait via une console web moderne, claire et bien documentée. Keycloak propose également une API REST complète pour automatiser la gestion des utilisateurs, des rôles et des clients (au sens OIDC du terme — c’est-à-dire les applications qui s’authentifient via Keycloak). Il dispose d’un système de thèmes (Freemarker) pour personnaliser toutes les pages exposées aux utilisateurs : login, enregistrement, oubli de mot de passe, vérification MFA. Enfin, le magasin d’extensions (Service Provider Interface) permet d’ajouter des connecteurs personnalisés, des protocoles supplémentaires ou des flux d’authentification sur mesure.
Les limites de Keycloak sont réelles. Sa consommation mémoire en fait une solution inadaptée aux VPS très modestes (moins de 2 Go RAM). La courbe d’apprentissage est raide : les concepts de realm, client, scope, protocol mapper, authentication flow et identity provider sont nombreux et leur interaction peut déconcerter au début. La configuration initiale prend plusieurs heures, voire une journée complète pour une PME avec plusieurs applications à intégrer. Ce n’est pas une solution à déployer en 20 minutes, mais c’est la plus puissante et la plus pérenne.
Authentik — la modernité Python
Authentik est né plus récemment (2019) avec un objectif explicite : offrir la puissance fonctionnelle de Keycloak dans une interface plus accessible et avec une expérience développeur modernisée. Il est écrit en Python avec Django pour le backend, et en TypeScript avec Lit pour le frontend. La documentation officielle est disponible sur goauthentik.io/docs. La version 2024.x, stable en 2025, consolide notamment la gestion des enterprise policies et améliore le support RADIUS.
Authentik occupe une position intermédiaire dans notre comparatif : plus lourd qu’Authelia (il nécessite au minimum 2 Go de RAM, car il embarque un worker Redis et un serveur WSGI), mais moins gourmand que Keycloak et nettement plus facile à administrer. Son installation via Docker Compose est documentée en détail et fonctionne en moins de 30 minutes pour un administrateur habitué aux conteneurs. L’interface d’administration est jugée uniformément plus intuitive que celle de Keycloak par les équipes qui ont testé les deux.
Sur le plan des protocoles, Authentik supporte OIDC, OAuth 2.0, SAML 2.0, LDAP (en mode proxy), RADIUS et SCIM 2.0 pour la synchronisation des répertoires. Son système de « Flows » est l’équivalent des Authentication Flows de Keycloak : on construit visuellement un pipeline d’authentification par glisser-déposer de stages (identification, mot de passe, TOTP, WebAuthn, e-mail de vérification, invitation). C’est plus visuel et plus accessible que les menus imbriqués de Keycloak.
Authentik brille particulièrement dans deux cas d’usage. Premier cas : l’intégration rapide d’applications modernes via OIDC. Les connecteurs pré-built pour des dizaines d’applications (GitLab, Nextcloud, Mattermost, Grafana, Proxmox, ERPNext) sont documentés et maintenus sur le site officiel — on parle de quelques minutes d’intégration pour chaque application. Second cas : la gestion des accès pour des équipes techniques, car Authentik propose un proxy d’authentification qui peut protéger n’importe quelle application web sans modifier son code source, simplement en la plaçant derrière le proxy.
La limitation principale d’Authentik est sa consommation mémoire incompressible de 2 Go et sa relative jeunesse par rapport à Keycloak. Pour des environnements ultra-critiques où la conformité à des normes précises (FIPS 140-2 par exemple) est obligatoire, Keycloak avec son écosystème Red Hat sera plus approprié. Mais pour la majorité des PME ouest-africaines, Authentik offre un excellent compromis entre richesse fonctionnelle et facilité d’administration.
Authelia — la légèreté Go
Authelia occupe une place à part dans ce comparatif, car son périmètre fonctionnel est fondamentalement différent des deux autres. Écrit en Go, Authelia n’est pas un Identity Provider (IdP) à proprement parler : il ne délivre pas de tokens OIDC en mode standalone, il n’héberge pas de realm, il ne fédère pas de répertoires LDAP nativement. Sa fonction première est d’être un portail d’authentification et d’autorisation pour les reverse proxies — Nginx, Traefik, Caddy, HAProxy. La documentation officielle est sur authelia.com/docs. La version 4.38.x, stable en 2025, ajoute notamment le support WebAuthn amélioré et une configuration YAML plus expressive.
Ce positionnement se traduit par une empreinte mémoire remarquablement légère : Authelia fonctionne avec 128 Mo de RAM en exploitation normale, 256 Mo avec une marge confortable. Un VPS à 2 Go peut donc faire tourner Authelia, Traefik, et trois ou quatre applications protégées sans broncher. C’est une caractéristique décisive pour les contextes à budget contraint.
Concrètement, Authelia intercepte les requêtes entrantes au niveau du reverse proxy, vérifie que l’utilisateur est authentifié (et avec le bon niveau d’authentification selon les règles définies), et renvoie soit un en-tête d’autorisation, soit une redirection vers sa page de connexion. Il gère le SSO via des cookies de session, la MFA via TOTP (RFC 6238) et WebAuthn (W3C), et peut interroger un backend LDAP ou un fichier YAML pour la gestion des utilisateurs. Il supporte également un sous-ensemble du protocole OIDC en mode OpenID Connect Provider depuis la version 4.35, ce qui lui permet d’être utilisé comme IdP pour des applications compatibles OIDC — mais avec moins de configurabilité que Keycloak ou Authentik.
Authelia excelle dans les scénarios suivants : une PME qui héberge plusieurs applications web derrière Traefik ou Nginx et veut ajouter de l’authentification unifiée sans refactorer ses applications, une équipe DevOps qui cherche à protéger rapidement des outils internes (Portainer, Grafana, Netdata, une interface d’administration), ou encore un contexte où les ressources serveur sont véritablement contraintes. Sa configuration par fichier YAML est claire, versionnable dans Git, et facilement automatisable par Ansible ou Terraform.
Les limites d’Authelia sont symétriques à ses forces. Pour une PME qui a besoin de SAML 2.0 pour se connecter à un fournisseur tiers, Authelia n’est pas la bonne réponse. Pour une organisation qui veut gérer plusieurs organisations distinctes avec des politiques différentes (le concept de realm de Keycloak), Authelia ne propose pas cet isolement. Et pour des applications mobiles qui ont besoin de tokens OAuth 2.0 complets avec refresh tokens à longue durée de vie, Keycloak ou Authentik seront plus adaptés.
Critères de choix
Choisir entre ces trois solutions nécessite de répondre honnêtement à six questions qui cartographient votre situation réelle.
Question 1 : Quels protocoles vos applications cibles exigent-elles ? Si vous intégrez des applications SaaS tierces qui exigent SAML 2.0 (beaucoup d’outils d’entreprise américains ou européens), Authelia est insuffisant et il faut choisir entre Keycloak et Authentik. Si votre stack est entièrement moderne et OIDC-native (Nextcloud, Mattermost, Gitea, ERPNext récent), les trois solutions conviennent.
Question 2 : Combien de RAM avez-vous disponible sur votre serveur ? Moins de 2 Go → Authelia uniquement. Entre 2 et 4 Go → Authelia ou Authentik. Plus de 4 Go → les trois solutions, avec une préférence pour Keycloak si vous avez besoin de sa richesse fonctionnelle. Cette question est souvent décisive dans le contexte africain où les budgets VPS sont contraints.
Question 3 : Avez-vous besoin de SCIM ou de provisioning automatique des utilisateurs ? Si vous voulez que la création d’un utilisateur dans votre HRMS se répercute automatiquement dans toutes vos applications (sans intervention manuelle), vous avez besoin de SCIM 2.0 — supporté par Authentik et Keycloak, non supporté nativement par Authelia.
Question 4 : Quelle est la taille et la structure de votre équipe IT ? Une petite équipe (un ou deux admins sys) qui découvre les IAM ira plus vite avec Authelia (simple, documenté, prévisible) ou Authentik (interface moderne). Keycloak demande un investissement d’apprentissage significatif — comptez une journée de formation avant d’être opérationnel. Pour une entreprise tech avec des développeurs Java/DevOps expérimentés, Keycloak est la solution la plus puissante et la plus standardisée sur le long terme.
Question 5 : Avez-vous besoin d’isoler plusieurs organisations ou espaces de noms d’identité ? Si votre PME héberge plusieurs clients ou divisions avec des politiques d’authentification séparées (realm isolation), Keycloak est la seule solution qui offre cette architecture nativement. Authentik propose des « tenants » depuis les versions récentes, mais avec moins de maturité. Authelia ne supporte pas ce cas d’usage.
Question 6 : Quelle est votre tolérance à la complexité opérationnelle ? Keycloak en clustering haute disponibilité est une opération sérieuse (Infinispan pour le cache distribué, load balancer devant plusieurs instances). Authentik en mode HA est plus simple (Compose avec réplication). Authelia est intrinsèquement stateless et se scale horizontalement sans friction. Si votre équipe n’a pas d’expérience en haute disponibilité de bases de données Java, partir sur Keycloak en production à fort enjeu sans accompagnement est risqué.
Tableau comparatif
| Critère | Keycloak 24.x | Authentik 2024.x | Authelia 4.38.x |
|---|---|---|---|
| Langage | Java (Quarkus) | Python (Django) + TypeScript | Go |
| RAM minimale (prod) | 2 Go (rec. 4 Go+) | 2 Go (rec. 2 Go+) | 128 Mo (rec. 256 Mo) |
| OIDC / OAuth 2.0 | ✅ Complet | ✅ Complet | ⚡ Partiel (IdP limité) |
| SAML 2.0 | ✅ Complet | ✅ Complet | ❌ Non supporté |
| LDAP / AD | ✅ Natif et poussé | ✅ LDAP source + proxy | ✅ LDAP backend |
| SCIM 2.0 | ✅ (v24+) | ✅ | ❌ |
| TOTP (RFC 6238) | ✅ | ✅ | ✅ |
| WebAuthn / FIDO2 | ✅ | ✅ | ✅ (v4.35+) |
| Realms / Multi-tenant | ✅ Natif (realms) | ⚡ Tenants (partiel) | ❌ |
| Interface admin | Fonctionnelle, complexe | Moderne, intuitive | Basique (YAML + UI légère) |
| Installation Docker Compose | ⚡ Modérée (30-60 min) | ✅ Rapide (20-30 min) | ✅ Très rapide (10-20 min) |
| Reverse proxy SSO | Via Gatekeeper/NGINX | ✅ Proxy intégré | ✅ Fonction principale |
| Conformité FIPS 140-2 | ✅ (distribution Red Hat) | ❌ | ⚡ Partiel |
| Support commercial | ✅ Red Hat (RHEL) | ✅ Authentik Enterprise | ❌ Communauté seulement |
| Licence | Apache 2.0 | MIT | Apache 2.0 |
| GitHub Stars (2025) | ~23 000 | ~14 000 | ~22 000 |
| Idéal pour | Enterprise, multi-org, SAML | PME moderne, OIDC, onboarding rapide | Reverse proxy, petits VPS, équipes DevOps |
Tutoriels du cluster
Ce pilier est le hub du cluster IAM Self-Hosted. Les tutoriels suivants approfondissent chacun un aspect pratique couvert ici en vue d’ensemble. Chaque satellite est un guide pas-à-pas opérationnel que vous pouvez suivre après avoir lu ce pilier pour choisir votre solution.
-
Satellite 1 — Déployer Authelia avec Traefik sur Docker Compose — Installation complète d’Authelia 4.38.x derrière Traefik v3 sur un VPS Hetzner 2 Go, avec MFA TOTP et protection de plusieurs applications en moins d’une heure.
-
Satellite 2 — Installer Authentik et connecter Nextcloud + Mattermost — Guide pas-à-pas pour déployer Authentik 2024.x via Docker Compose et configurer le SSO OIDC pour Nextcloud et Mattermost, avec MFA WebAuthn.
-
Satellite 3 — Keycloak : configurer un realm et connecter ERPNext en SSO — Configuration d’un realm Keycloak pour une PME, intégration OIDC avec ERPNext (Frappe Framework), gestion des rôles et groupes, MFA TOTP.
Si vous n’avez pas encore décidé quelle solution adopter, commencez par le satellite Authelia (le plus accessible) pour vous familiariser avec les concepts SSO et reverse proxy, puis lisez le satellite Authentik pour comprendre le mode IdP complet. Le satellite Keycloak est recommandé pour les équipes qui ont déjà une expérience avec des applications Java ou une infrastructure existante à intégrer via SAML.
Adaptation au contexte ouest-africain
Le déploiement d’un IAM en Afrique de l’Ouest présente des spécificités que les tutoriels européens ou américains ignorent généralement. Cette section les adresse directement, à partir de retours d’expérience concrets sur des infrastructures PME au Sénégal, en Côte d’Ivoire, au Mali et au Burkina Faso.
Le choix du VPS et de la localisation. Pour la majorité des PME ouest-africaines dont l’équipe est locale et qui n’ont pas de clients européens, la localisation du serveur en Afrique est idéale mais encore rare et souvent coûteuse. En pratique, le datacenter de Francfort (Hetzner) est le choix le plus courant : latence acceptable depuis Dakar ou Abidjan (50-80 ms en général), conformité RGPD par défaut (territoire UE), tarifs très compétitifs. Le VPS CX22 d’Hetzner (2 vCPU, 4 Go RAM, 40 Go SSD NVMe) à environ 6-7 euros par mois est le minimum recommandé pour Authentik ou Authelia. Pour Keycloak en production, il faut monter au CX32 ou CX42 (8 Go RAM minimum recommandé pour éviter les saturations mémoire lors des pics d’authentification).
L’architecture SSO pour le stack PME typique. Le stack numérique d’une PME ouest-africaine digitalisée tourne souvent autour de quatre outils : ERPNext pour la gestion (comptabilité, stocks, RH), Nextcloud pour le stockage et le partage de fichiers, Mattermost pour la communication interne, et Jitsi Meet pour les visioconférences. Ces quatre outils supportent tous OIDC nativement ou via des plugins — ce qui signifie que les trois solutions de ce guide peuvent les fédérer. La configuration concrète est couverte dans les satellites du cluster : le satellite Authentik détaille l’intégration Nextcloud et Mattermost, le satellite Keycloak couvre ERPNext. Pour Jitsi Meet, la configuration OIDC via le module jitsi-meet-jicofo est documentée sur GitHub et compatible avec les trois solutions.
La MFA adaptée au terrain. Les méthodes de MFA disponibles sont TOTP (application comme FreeOTP, Aegis ou Google Authenticator) et WebAuthn (clé physique FIDO2 comme YubiKey, ou passkey biométrique sur smartphone récent). En Afrique de l’Ouest, la MFA TOTP est la plus accessible : les applications TOTP sont gratuites, fonctionnent hors ligne, et sont compatibles avec tous les téléphones Android récents. La MFA WebAuthn par passkey nécessite un smartphone avec puce de sécurité (disponible sur la plupart des Android depuis 2022 et tous les iPhone récents). Les clés FIDO2 physiques (YubiKey, Nitrokey) restent rares et coûteuses localement, mais peuvent être commandées pour les administrateurs et les accès hautement sensibles.
La conformité ARTCI et les régulateurs locaux. En Côte d’Ivoire, la loi n°2013-450 relative à la protection des données à caractère personnel crée des obligations similaires au RGPD, avec la CDVP comme organe de contrôle. En auto-hébergeant votre IAM, vous pouvez démontrer à la CDVP que les données d’authentification de vos utilisateurs ivoiriens sont traitées dans un serveur dont vous contrôlez l’emplacement et l’accès. La tenue d’un journal d’audit des connexions (disponible nativement dans les trois solutions) répond à l’obligation de traçabilité. Au Sénégal, la Commission de Protection des Données Personnelles (CDP) dispose d’un cadre similaire. Self-héberger son IAM est un argument de conformité concret que vous pouvez documenter.
La gestion des coupures électriques et réseau. Un IAM self-hébergé est une infrastructure critique : si votre serveur IAM est inaccessible, vos collaborateurs ne peuvent plus se connecter à leurs outils. En contexte africain où les coupures électriques sont fréquentes, deux précautions sont essentielles. Première précaution : ne jamais héberger l’IAM sur un serveur physique local sans onduleur et sans redondance réseau — un VPS cloud dans un datacenter européen est paradoxalement plus fiable qu’un serveur local non protégé. Deuxième précaution : configurer des sessions longues (token lifetime de 24h à 72h selon le niveau de sensibilité) pour que les utilisateurs déjà authentifiés continuent à fonctionner même en cas de coupure réseau temporaire vers l’IAM.
La bande passante et le mode offline. Authelia et Authentik peuvent être configurés pour ne solliciter le serveur IAM qu’à l’authentification initiale et lors des renouvellements de token. Entre ces moments, les applications utilisent des tokens JWT locaux valides sans appel réseau. Pour Nextcloud, le mode WebDAV fonctionne hors ligne après authentification initiale. Pour ERPNext, la session HTTP est maintenue côté client. Cette architecture est naturellement résiliente aux connexions intermittentes, à condition de ne pas configurer des durées de token trop courtes (éviter les tokens d’accès de moins de 15 minutes dans ce contexte).
Erreurs fréquentes à éviter
| Erreur | Cause | Solution |
|---|---|---|
| Déployer Keycloak sur un VPS 2 Go RAM | Sous-estimation de la consommation mémoire Java/Quarkus en production réelle | Utiliser au minimum 4 Go RAM pour Keycloak en prod ; choisir Authelia ou Authentik sur VPS 2 Go |
| Exposer l’interface d’administration sur Internet | Configuration par défaut de Keycloak et Authentik expose le panel admin sur le même port que le service | Restreindre l’accès admin à un réseau privé ou via un VPN ; utiliser des règles iptables ou Traefik middlewares |
| Utiliser des tokens OIDC avec une durée de vie trop longue | Volonté de réduire les reconnexions, mais augmente la surface d’attaque en cas de vol de token | Access token : 5-15 min. Refresh token : 24h-7j. Configurer la rotation automatique des refresh tokens |
| Ne pas sauvegarder la base de données de l’IAM | L’IAM est perçu comme un service secondaire alors qu’il est critique — sa perte bloque tous les accès | Backup automatique quotidien de PostgreSQL (Keycloak/Authentik) ou SQLite (Authelia) vers un stockage distant (S3, Backblaze B2) |
| Configurer le client OIDC avec le secret en clair dans l’application | Le client_secret OIDC est traité comme une variable d’environnement banale | Stocker les secrets dans un gestionnaire de secrets (Vault, Docker Secrets, variables d’environnement chiffrées) — jamais en dur dans le code ou dans le docker-compose.yml versionné |
| Oublier de configurer le protocole de déconnexion (Backchannel Logout) | L’utilisateur déconnecté de l’IAM reste connecté aux applications qui ont mis le token en cache | Activer le Backchannel Logout sur chaque client OIDC et tester le scénario de déconnexion globale après chaque intégration |
| Ne pas tester la MFA avant le déploiement en production | La MFA TOTP ou WebAuthn est activée sans tester le parcours de récupération (perte d’appareil) | Toujours configurer une méthode de récupération (codes de secours, e-mail admin) et documenter la procédure de réinitialisation MFA |
| Utiliser Authelia comme IdP OIDC complet sans vérifier les limitations | Confusion entre le mode proxy et le mode IdP partiel d’Authelia | Vérifier que les applications cibles fonctionnent avec le subset OIDC d’Authelia ; pour des besoins OIDC avancés (device flow, PKCE, etc.), choisir Keycloak ou Authentik |
FAQ
Quelle est la différence entre SSO, IAM et IdP ?
Le SSO (Single Sign-On) est la fonctionnalité qui permet à un utilisateur de se connecter une seule fois pour accéder à plusieurs applications. L’IAM (Identity and Access Management) est l’ensemble du système qui gère les identités (qui vous êtes), l’authentification (prouver qui vous êtes) et l’autorisation (ce que vous avez le droit de faire). L’IdP (Identity Provider) est le composant technique qui émet les assertions d’identité — c’est le serveur à qui les applications font confiance pour confirmer qu’un utilisateur est bien qui il prétend être. Keycloak, Authentik et Authelia (en mode IdP) sont des IdP qui offrent aussi les fonctionnalités SSO et IAM.
Peut-on migrer de Authelia vers Authentik ou Keycloak sans tout reconfigurer ?
La migration des utilisateurs est possible (export CSV ou LDAP sync), mais les configurations de flux d’authentification et les intégrations applicatives doivent être reconfigurées dans le nouvel outil. Authelia utilise un fichier YAML, Authentik et Keycloak ont des bases de données relationnelles. Il n’existe pas d’outil de migration automatique entre ces trois plateformes. Planifiez une migration en parallèle : faites tourner les deux systèmes simultanément le temps de migrer les applications une à une, en testant chaque intégration avant de couper Authelia.
Est-ce qu’Authelia peut remplacer complètement Keycloak pour une PME de 50 personnes ?
Cela dépend de vos applications. Si toutes vos applications sont des applications web derrière un reverse proxy Traefik ou Nginx, qu’elles ne nécessitent pas SAML 2.0, et que vous n’avez pas besoin de provisioning automatique SCIM, alors Authelia peut tout à fait suffire pour 50 utilisateurs. En revanche, si vous intégrez des applications mobiles natives (qui ont besoin de flows OAuth device code), des partenaires externes via SAML, ou que vous gérez plusieurs départements avec des politiques d’authentification très différentes, Keycloak ou Authentik seront plus appropriés.
Keycloak est-il vraiment difficile à administrer pour un sysadmin junior ?
Keycloak a une courbe d’apprentissage significative, mais pas insurmontable. Les concepts clés (realm, client, scope, role, group, authentication flow, identity provider) sont bien documentés sur keycloak.org. Un sysadmin junior motivé peut être opérationnel en une à deux semaines avec les tutoriels officiels. La difficulté principale est de comprendre les interactions entre ces concepts — notamment entre les scopes OIDC et les rôles applicatifs — avant de les toucher en production. Il est fortement recommandé d’avoir un environnement de test identique à la production pour expérimenter sans risque.
Comment sauvegarder correctement son IAM self-hébergé ?
La base de données est l’élément critique. Keycloak et Authentik utilisent PostgreSQL — configurez un pg_dump quotidien avec compression et envoi vers un stockage S3 (Backblaze B2 à 0,006 dollar/Go est une option économique). Authelia utilise SQLite ou Redis — une copie quotidienne des fichiers suffit. Sauvegardez également les fichiers de configuration (docker-compose.yml, fichiers YAML, certificats TLS, secrets). Testez la restauration au moins une fois par trimestre : une sauvegarde non testée est une sauvegarde qui ne fonctionne pas.
La MFA TOTP fonctionne-t-elle sans connexion Internet pour l’utilisateur ?
Oui. Le TOTP (Time-based One-Time Password, RFC 6238) génère des codes à partir de l’heure locale et d’un secret partagé, sans appel réseau. L’application TOTP sur le téléphone (Aegis, FreeOTP, Google Authenticator) génère les codes hors ligne. La seule condition est que l’horloge du téléphone soit synchronisée (ce qui est le cas automatiquement via le réseau mobile). En revanche, l’utilisateur doit évidemment avoir accès au serveur IAM pour s’authentifier — c’est la connexion vers le serveur, pas la génération du code TOTP, qui nécessite le réseau.
Faut-il un nom de domaine propre pour déployer un IAM self-hébergé ?
Oui, dans la pratique, un nom de domaine est indispensable pour plusieurs raisons. D’abord, les certificats TLS (HTTPS obligatoire pour tout système d’authentification) nécessitent un nom de domaine pour être émis via Let’s Encrypt. Ensuite, les clients OIDC et SAML sont configurés avec des URLs de callback fixes — une adresse IP peut changer, un nom de domaine reste stable. Enfin, le SSO repose sur des cookies dont le domaine doit correspondre. Un sous-domaine dédié comme auth.votreentreprise.com est la configuration standard, et un domaine .sn ou .ci coûte moins de 10 000 FCFA par an.
Pour aller plus loin
Ce pilier vous a donné la vision d’ensemble. Pour passer à l’action, voici les étapes concrètes recommandées selon votre profil :
- Si vous débutez avec les IAM : commencez par le tutoriel satellite Déployer Authelia avec Traefik sur Docker Compose. Vous serez opérationnel en moins d’une heure et vous comprendrez les concepts de base avant de considérer des solutions plus complexes.
- Si vous gérez un stack ERPNext + Nextcloud + Mattermost : lisez le satellite Installer Authentik et connecter Nextcloud + Mattermost, qui couvre exactement ce scénario avec les configurations OIDC détaillées pour chaque application.
- Si vous avez une infrastructure mature et des besoins enterprise : consultez le satellite Keycloak : configurer un realm et connecter ERPNext en SSO, puis explorez la documentation officielle de Keycloak sur keycloak.org/documentation.
Documentation officielle des trois solutions :
- Keycloak Documentation officielle — keycloak.org
- Authentik Documentation officielle — goauthentik.io
- Authelia Documentation officielle — authelia.com
Standards et RFC de référence :
- OAuth 2.0 : RFC 6749
- OpenID Connect Core : openid.net/specs
- TOTP : RFC 6238
- WebAuthn : W3C WebAuthn Level 3
ITSkillsCenter propose également des accompagnements pour les PME qui souhaitent déployer leur infrastructure IAM avec un suivi professionnel. Contactez-nous via itskillscenter.io/contact pour un audit de votre infrastructure actuelle.