Passkeys au Maroc : sécuriser les applications métier sans mot de passe

Les passkeys au Maroc offrent une voie concrète pour sécuriser les applications métier sans imposer un mot de passe supplémentaire aux collaborateurs, clients ou partenaires. Fondées sur WebAuthn et la cryptographie à clé publique, elles réduisent l’exposition au phishing tout en simplifiant la connexion. Leur déploiement demande toutefois plus qu’un bouton « Se connecter » : il faut traiter l’enrôlement, la récupération de compte, les appareils partagés et la coexistence avec les méthodes actuelles.

Pourquoi les passkeys changent l’authentification métier

Un mot de passe est un secret partagé que l’utilisateur doit mémoriser, stocker ou réutiliser. Une passkey repose au contraire sur une paire de clés : la clé publique est enregistrée par le service et la clé privée reste protégée par l’appareil ou un authentificateur. Le serveur ne reçoit pas la clé privée. La preuve cryptographique est liée au domaine de l’application, ce qui rend une fausse page beaucoup moins capable de détourner l’authentification.

La recommandation WebAuthn Level 3 du W3C formalise les mécanismes utilisés par les navigateurs et les authentificateurs. Les ressources de la FIDO Alliance distinguent notamment les passkeys synchronisées entre appareils et celles liées à un appareil ou à une clé de sécurité. Ce choix doit suivre le contexte métier, pas une préférence technique abstraite.

Choisir le bon modèle pour les passkeys au Maroc

Applications destinées aux clients

Pour un portail client ou un service numérique grand public, une passkey synchronisée peut faciliter le retour sur un nouvel appareil. L’utilisateur s’authentifie avec le mécanisme local de son téléphone ou ordinateur, comme le code de l’appareil ou la biométrie, sans transmettre cette donnée au service. Il reste indispensable de prévoir un parcours de récupération compréhensible et de limiter les risques de prise de contrôle du compte.

Applications internes et comptes sensibles

Pour l’administration, la finance, les environnements de production ou les comptes à privilèges, une passkey liée à un appareil géré ou à une clé matérielle peut mieux correspondre aux exigences d’assurance. La politique doit préciser qui délivre l’authentificateur, comment il est remplacé, comment un accès est révoqué et quelles traces sont conservées. Les scénarios de perte, de départ d’un collaborateur et d’intervention d’urgence doivent être testés avant le déploiement.

Les décisions à prendre avant de développer

• Périmètre : identifier les parcours et rôles où le mot de passe crée le plus de risque ou de friction.
• Type de passkey : arbitrer entre synchronisation, liaison à l’appareil et clé de sécurité selon le niveau d’assurance recherché.
• Récupération : concevoir une procédure qui ne réintroduit pas un canal plus faible que l’authentification principale.
• Compatibilité : vérifier navigateurs, systèmes, terminaux gérés, postes partagés et contraintes d’accessibilité.
• Support : préparer les équipes aux problèmes d’enrôlement, de changement d’appareil et de suppression accidentelle.
• Mesure : suivre adoption, échecs d’enrôlement, abandons, recours au support et méthodes de secours.

Un parcours de migration progressif

La transition commence généralement par l’ajout d’une passkey à un compte existant déjà vérifié. Une phase pilote permet d’observer la compatibilité réelle et les cas de récupération. L’application peut ensuite proposer la passkey comme méthode privilégiée, tout en conservant temporairement une solution de secours contrôlée. La suppression du mot de passe ne doit intervenir qu’après validation des parcours critiques, de l’assistance et de la révocation.

Le travail concerne autant le produit que l’identité. L’interface doit expliquer ce qui est créé, où la passkey est enregistrée et comment l’utilisateur retrouvera son accès. Les libellés doivent rester cohérents entre le web, le mobile et le support. La documentation de déploiement en entreprise de FIDO insiste sur l’adaptation aux appareils, aux rôles et aux exigences d’assurance de chaque organisation.

Architecture technique et contrôles de sécurité

Le serveur doit vérifier l’origine, l’identifiant de la partie de confiance, le challenge, la signature et les propriétés attendues de la réponse WebAuthn. Les challenges doivent être uniques et temporaires. Les clés publiques, identifiants de credential et compteurs pertinents doivent être rattachés au bon compte. Une authentification réussie ne remplace pas l’autorisation : les rôles et permissions restent à contrôler côté serveur.

Les passkeys doivent également s’intégrer à la journalisation, à la détection d’anomalies et à la gestion des sessions. Une nouvelle méthode d’authentification ne justifie pas des sessions illimitées. Pour les opérations sensibles, une confirmation supplémentaire ou une réauthentification peut rester nécessaire. Kanteek peut relier ce chantier à une architecture Web & Mobile cohérente et à des pratiques Cloud & DevOps vérifiables.

Cas d’usage prioritaires pour une entreprise marocaine

Les premiers candidats sont souvent les espaces clients, les portails partenaires, les applications mobiles professionnelles et les consoles internes exposées à des tentatives de phishing. Un déploiement ciblé évite de transformer l’authentification de tout le système en une seule fois. Il permet aussi d’apprendre sur les appareils réellement utilisés au Maroc, les contraintes de mobilité et les besoins du support.

Pour un portail client B2B, les passkeys peuvent compléter une stratégie d’accès fondée sur des autorisations précises et une traçabilité utile. Pour une application héritée, une couche d’identité modernisée peut précéder la refonte complète. Dans les deux cas, le bénéfice vient d’un parcours plus résistant au phishing et plus simple à utiliser, pas d’une promesse de sécurité absolue.

Comment cadrer un projet de passkeys

Un cadrage utile réunit produit, sécurité, support, juridique et opérations. Il documente les populations, terminaux, niveaux d’assurance, méthodes de secours et critères d’acceptation. Un prototype doit tester l’enrôlement, la connexion, le changement d’appareil, la révocation et la récupération. Les résultats guident ensuite le déploiement progressif.

L’équipe Conseil & Stratégie de Kanteek peut aider à prioriser les parcours, puis les équipes techniques peuvent intégrer WebAuthn aux applications existantes. L’objectif n’est pas de supprimer un champ au plus vite, mais de construire une authentification exploitable, supportable et adaptée aux risques réels de l’organisation.