Ce guide vous explique comment configurer le SSO pour votre équipe dans lemlist, vérifier et gérer les domaines de votre entreprise, décider si le SSO doit être obligatoire et utiliser Microsoft Entra ID, Okta ou Google comme fournisseur d’identité pour votre organisation.
À noter : cette fonctionnalité est disponible uniquement avec le plan Enterprise.
Avec le SSO, votre équipe se connecte via le fournisseur d’identité de votre entreprise, sans avoir à gérer ses mots de passe directement dans lemlist. Les administrateurs peuvent aussi mieux contrôler les accès par domaine, décider si le SSO est obligatoire et gérer l’authentification sur les différentes applications de l’écosystème Lempire.
Pourquoi c’est important
Le SSO renforce la sécurité des accès et simplifie leur gestion : vos utilisateurs s’authentifient via le fournisseur d’identité déjà en place dans votre organisation. Il réduit aussi les problèmes liés aux mots de passe et vous permet de choisir les domaines autorisés à accéder à votre équipe. Vous pouvez l’utiliser pour vous connecter à lemlist, lemwarm et lemcal.
Avant de commencer
Vous devez déjà savoir où trouver les paramètres de votre équipe dans lemlist.
Vous devez être administrateur de l’équipe dans lemlist pour configurer le SSO.
Vous devez avoir les droits d’administration dans Microsoft Entra ID ou Okta si vous utilisez l’un de ces fournisseurs d’identité.
Vous devez avoir identifié les domaines email de votre entreprise à protéger avec le SSO.
Important : si vous n’êtes pas administrateur de l’équipe, l’option SSO est désactivée.
Fournisseurs d’identité compatibles
Microsoft Entra ID : utilise SAML 2.0. Vous renseignez l’URL des métadonnées de fédération d’application, puis lemlist en extrait automatiquement le certificat et l’URL de connexion.
Okta : utilise SAML 2.0. Vous renseignez le champ Okta metadata URL, puis suivez la même procédure SAML.
Google : utilise Google OAuth, et non SAML. La configuration est plus simple et ne nécessite pas d’URL de métadonnées.
Partie 1 : ouvrir l’assistant de configuration SSO
Ouvrez lemlist et accédez aux paramètres de votre équipe.
C’est là que les administrateurs de l’équipe peuvent gérer les paramètres de connexion de l’organisation.
Repérez l’option Log in with your organization (SSO), puis lancez la configuration.
L’assistant vous guide pour configurer votre fournisseur et vos domaines, puis décider si le SSO doit être obligatoire.
Choisissez votre fournisseur : Microsoft Entra, Okta ou Google.
Ce choix détermine le type de configuration à suivre : SAML ou Google OAuth.
Partie 2 : ajouter et vérifier vos domaines
Les domaines configurés déterminent quels utilisateurs peuvent se connecter avec leurs identifiants d’entreprise. lemlist permet de configurer plusieurs domaines par organisation.
Ajoutez le ou les domaines email qui doivent utiliser le SSO, par exemple
acme.com.Ces domaines permettent à lemlist d’identifier les utilisateurs de votre organisation pour le SSO.
Vérifiez la propriété de chaque domaine avant de l’activer.
Cette vérification empêche une autre équipe de revendiquer un domaine qui ne lui appartient pas.
Choisir une méthode de vérification
Deux méthodes sont disponibles pour vérifier chaque domaine :
Vérification d'email : entrez une adresse email rattachée à ce domaine, par exemple
[email protected], puis cliquez sur le lien de vérification envoyé à cette adresse. Ce lien expire au bout de 15 minutes.DNS TXT verification : ajoutez un enregistrement TXT nommé
_lemlist-challenge.yourdomain.comet utilisez comme valeur le jeton affiché pendant la configuration. Une fois la propagation DNS terminée, cliquez sur vérifier.
Bon à savoir : un domaine ne devient actif pour le SSO qu’après sa vérification.
Gérer les domaines vérifiés
Après la vérification, vous pouvez :
Consulter vos domaines vérifiés
Ajouter d’autres domaines
Retirer des domaines
Configurer SAML bypass pour chaque domaine
Utiliser SAML bypass si nécessaire
L’option SAML bypass s’active par domaine et autorise la connexion par mot de passe en plus du SSO. Elle peut servir aux comptes administrateur de secours ou aux comptes de service qui doivent parfois se connecter sans SSO.
Partie 3 : vérifier l’impact sur l’équipe avant l’activation
Avant l’activation du SSO, lemlist vérifie ce qui va changer pour les membres actuels de votre équipe.
Passez en revue les utilisateurs dont l’adresse email utilise l’un de vos domaines SSO.
Ces utilisateurs se connecteront par SSO une fois celui-ci activé.
Passez en revue les utilisateurs dont l’adresse email n’utilise aucun de vos domaines SSO.
Pendant la configuration, lemlist peut afficher ces utilisateurs pour vous permettre de les retirer de l’équipe avant l’activation.
Important : si l’adresse email d’un utilisateur n’utilise aucun des domaines SSO configurés, cet utilisateur peut être retiré de l’équipe pendant la configuration.
Partie 4 : choisir si le SSO est obligatoire
Vous pouvez rendre le SSO facultatif ou obligatoire pour les utilisateurs dont l’adresse email utilise l’un de vos domaines SSO.
Si l’option Force SSO est activée
Les utilisateurs dont l’adresse email utilise un domaine SSO doivent se connecter par SSO
Les connexions par mot de passe et par OAuth sont bloquées pour ces utilisateurs
Les domaines pour lesquels SAML bypass est activé autorisent toujours la connexion par mot de passe
La reprise d’une session existante reste possible
Si l’option Force SSO est désactivée
Les utilisateurs peuvent se connecter par SSO ou avec les méthodes habituelles, comme le mot de passe ou la connexion avec Google ou Microsoft
Bonne pratique : laissez Force SSO désactivé pendant vos tests. Une fois votre fournisseur, vos domaines et les affectations vérifiés, vous pouvez rendre le SSO obligatoire pour les utilisateurs concernés.
Partie 5 : terminer la configuration selon le fournisseur choisi
Configurer le SSO avec Microsoft Entra ID
Ouvrez le centre d’administration Microsoft Entra, puis accédez à Enterprise applications > All applications.
Créez une nouvelle application pour lemlist.
Vous disposez ainsi d’une application d’entreprise dédiée à la gestion des accès SSO.
Sélectionnez SAML comme méthode de connexion.
Dans la configuration SAML, copiez les valeurs de votre équipe depuis lemlist, puis collez-les dans Microsoft Entra.
Collez la valeur du champ Identifier (ID d’entité) de lemlist dans le champ Identifier (Entity ID) d’Entra
Collez l’URL de réponse de lemlist dans le champ Reply URL (Assertion Consumer Service URL) d’Entra
Copiez l’App Federation Metadata URL depuis Microsoft Entra, puis collez-la dans le champ correspondant de lemlist.
lemlist utilise cette URL pour extraire automatiquement le certificat et l’URL de connexion.
Affectez les utilisateurs ou les groupes concernés à l’application.
Cette étape détermine qui peut effectivement accéder à lemlist via Entra.
Configurer le SSO avec Okta
Connectez-vous au tableau de bord d’administration Okta, puis accédez à Applications > Applications.
Cliquez sur Create App Integration, puis choisissez SAML 2.0.
Créez l’intégration lemlist, puis suivez les étapes de configuration à l’écran.
Copiez les valeurs de votre équipe depuis lemlist et collez-les dans Okta.
Collez la valeur du champ Single sign-on URL de lemlist dans le champ Single sign-on URL d’Okta
Collez la valeur du champ Identifier (ID d’entité) de lemlist dans le champ Audience URI (SP Entity ID) d’Okta
Ajoutez les déclarations d’attributs suivantes dans Okta :
firstName →
user.firstNamelastName →
user.lastNameemail →
user.email
Terminez la configuration dans Okta, puis copiez l’App Federation Metadata URL depuis Okta et collez-la dans lemlist.
Affectez les utilisateurs ou les groupes concernés à l’application Okta.
Important : si un utilisateur n’est pas affecté à l’application Okta ou Microsoft Entra, il risque de ne pas pouvoir accéder à lemlist, même si le SSO est correctement configuré.
Configurer la connexion avec Google pour votre organisation
Sélectionnez Google comme fournisseur dans l’assistant de configuration.
Configurez l’authentification Google dans lemlist.
Contrairement à Entra et Okta, Google utilise OAuth, et non SAML : aucune URL de métadonnées n’est donc nécessaire.
Terminez l’étape de configuration propre à Google, puis enregistrez votre configuration.
Partie 6 : tester la connexion
Les tests vous permettent de vérifier que les utilisateurs concernés sont redirigés vers le bon fournisseur avant de déployer le SSO pour toute l’équipe.
Enregistrez votre configuration SSO dans lemlist.
Attribuez l’accès à un utilisateur de test dans votre fournisseur d’identité.
Demandez à cet utilisateur d’ouvrir la page de connexion SSO à l’adresse
/sso.Entrez l’adresse email professionnelle rattachée à un domaine vérifié.
Vérifiez que l’utilisateur est redirigé vers Microsoft Entra, Okta ou Google.
Terminez l’authentification et vérifiez que l’utilisateur est automatiquement connecté à lemlist.
Comment les utilisateurs invités se connectent-ils ?
Si le SSO est activé pour l’équipe, les utilisateurs invités reçoivent un email leur indiquant qu’ils doivent se connecter par SSO.
Lorsqu’ils cliquent sur le lien d’invitation, ils accèdent directement à la procédure de connexion SSO.
Une fois authentifiés avec leurs identifiants d’entreprise, ils sont connectés à lemlist.
Exemple concret
Voici un exemple de déploiement courant pour une équipe avec le plan Enterprise :
Ajoutez
acme.cometacme.co.ukcomme domaines SSO.Vérifiez un domaine par email et l’autre à l’aide d’un enregistrement DNS TXT.
Laissez Force SSO désactivé pendant les tests pour que les utilisateurs puissent encore se connecter avec leur méthode habituelle si nécessaire.
Activez SAML bypass sur un domaine utilisé par un compte administrateur de secours.
Attribuez l’accès à un groupe pilote dans Okta ou Microsoft Entra, puis testez la connexion via
/sso.Une fois les tests réussis, activez Force SSO pour rendre le SSO obligatoire.
Cette approche limite le risque de bloquer les utilisateurs tout en permettant à l’équipe de passer à une gestion centralisée des connexions.
Cas particuliers et points importants
Membres de l’équipe et activation du SSO
Si un utilisateur est déjà membre de l’équipe et que son adresse email utilise le domaine SSO, son ancienne méthode de connexion n’est plus disponible : il doit passer par le SSO. Sa session en cours n’est pas interrompue et aucun email ne lui est envoyé pour l’informer du changement.
Si un utilisateur n’est pas membre de l’équipe, mais que son adresse email utilise le domaine SSO, rien ne change pour lui. L’obligation de passer par le SSO ne concerne que les membres actuels de l’équipe.
Si l’adresse email d’un utilisateur n’utilise pas le domaine SSO, il peut être retiré de l’équipe pendant la configuration. Sa méthode de connexion aux autres équipes reste inchangée.
Si certains utilisateurs possèdent déjà un compte lemlist dont l’adresse email utilise le domaine SSO, leurs comptes sont fusionnés pour leur permettre de se connecter par SSO.
Invitations et ajout à une équipe
Si une équipe qui utilise le SSO invite un utilisateur dont l’adresse email n’utilise pas le domaine SSO, l’invitation est bloquée.
Si un utilisateur d’une équipe sans SSO est invité dans une équipe avec SSO, il ne peut plus utiliser ses autres méthodes de connexion et doit désormais passer par le SSO. Sa session n’est pas interrompue et aucun email ne lui est envoyé pour l’informer du changement.
Lorsqu’un nouvel utilisateur se connecte pour la première fois par SSO, il est automatiquement ajouté à l’équipe qui utilise le SSO. Aucune équipe distincte n’est créée et aucune vérification de l’adresse email n’est nécessaire.
Les utilisateurs dont le compte a été créé via SSO peuvent rejoindre d’autres équipes, sauf si Force SSO est activé et que ces autres équipes n’utilisent pas elles aussi le SSO avec le même domaine vérifié.
Mots de passe, liens magiques et changement d’adresse email de connexion
Si un utilisateur SSO tente de réinitialiser son mot de passe, la réinitialisation est bloquée et le message suivant s’affiche : « Your account is using Organization login (SSO), please contact your admin to reset your password. »
Si un utilisateur SSO clique sur Obtenir le lien magique, le même message d’erreur s’affiche. Les liens magiques sont désactivés pour les comptes SSO.
Un utilisateur ne peut pas remplacer son adresse email de connexion par une adresse qui n’utilise pas le domaine SSO : ce champ est désactivé dans les paramètres tant que le SSO est actif pour l’équipe.
Utilisateurs membres de plusieurs équipes
Si un utilisateur appartient à une équipe avec SSO et à une autre sans SSO, il doit se connecter par SSO. Cette connexion lui donne accès aux deux équipes.
Si un utilisateur est retiré de l’équipe SSO dans le fournisseur d’identité, mais reste membre d’une équipe sans SSO, il risque de ne plus pouvoir se connecter et peut avoir besoin de l’aide de l’équipe support pour retrouver l’accès.
Si un utilisateur quitte une équipe pour laquelle le SSO est activé, il perd la possibilité de se connecter par SSO, mais sa session n’est pas interrompue immédiatement. Il reçoit un email contenant un lien pour créer un mot de passe.
Administration informatique et sécurité
Si un administrateur informatique bloque l’accès d’un utilisateur à lemlist via les groupes du fournisseur d’identité, cet utilisateur ne peut ni se connecter par SSO ni rejoindre l’équipe de l’entreprise. Il peut toutefois utiliser une autre méthode de connexion pour créer un compte distinct, puis une nouvelle équipe.
Plusieurs équipes peuvent configurer le SSO avec le même domaine. Il n’y a aucun contrôle d’unicité entre les équipes. Au moment de la connexion, le système recherche tous les fournisseurs correspondants parmi les équipes de l’utilisateur.
La propriété du domaine doit être vérifiée avant l’activation du SSO, par email ou à l’aide d’un enregistrement DNS TXT.
Certains messages d’erreur liés au SSO ou à la réinitialisation du mot de passe peuvent révéler qu’une entreprise utilise lemlist. Ce risque est accepté pour le moment.
Problèmes courants et solutions
Problème : un utilisateur ne peut pas se connecter à lemlist par SSO
Cause : l’utilisateur n’est peut-être pas affecté à l’application dans Okta ou Microsoft Entra, ou le domaine de son adresse email ne correspond à aucun domaine vérifié.
Solution :
Vérifiez que l’utilisateur est bien affecté à l’application dans votre fournisseur d’identité
Vérifiez que son adresse email de connexion utilise l’un des domaines SSO vérifiés
Vérifiez que la bonne URL de métadonnées a été collée dans lemlist
Problème : la vérification du domaine échoue
Cause : le lien reçu par email a peut-être expiré, ou la propagation DNS de l’enregistrement TXT n’est peut-être pas encore terminée.
Solution :
Demandez un nouveau lien de vérification par email si le précédent a expiré au bout de 15 minutes
Vérifiez le nom de l’enregistrement TXT et la valeur du jeton
Attendez la fin de la propagation DNS, puis cliquez à nouveau sur vérifier
Problème : les utilisateurs ne peuvent plus se connecter après l’activation de Force SSO
Cause : le SSO a été rendu obligatoire avant les tests ou avant la mise en place d’un accès de secours.
Solution :
Laissez Force SSO désactivé jusqu’à la fin des tests
Utilisez SAML bypass sur un domaine de confiance utilisé par les administrateurs si un accès de secours par mot de passe est nécessaire
Vérifiez les affectations dans le fournisseur d’identité avant de déployer le SSO pour toute l’équipe
Problème : un utilisateur ne peut ni réinitialiser son mot de passe ni utiliser les liens magiques
Cause : la connexion à son compte passe désormais par son organisation.
Solution :
Demandez à l’utilisateur de se connecter via
/ssoavec son adresse email professionnelleSi l’accès reste impossible, demandez à l’administrateur de l’équipe de vérifier la configuration SSO
Problème : l’adresse email d’un membre de l’équipe n’utilise aucun domaine SSO
Cause : son adresse email de connexion n’utilise aucun des domaines vérifiés de l’organisation.
Solution :
Examinez le cas de cet utilisateur dans l’assistant de configuration
Retirez-le de l’équipe si nécessaire
Si vous devez le conserver dans l’équipe, vérifiez s’il faut ajouter un domaine supplémentaire à la configuration SSO
FAQ
Que se passe-t-il si je passe du plan Enterprise à un plan inférieur ?
Votre configuration SSO est conservée, mais devient inactive. Les utilisateurs devront se connecter avec un mot de passe ou via OAuth jusqu’à ce que l’équipe repasse au plan Enterprise.
Puis-je utiliser SAML et le SSO Google dans une même équipe ?
Non. Une équipe ne peut avoir qu’un seul fournisseur SSO configuré à la fois. Vous choisissez Microsoft Entra, Okta ou Google pendant la configuration.
Puis-je changer de fournisseur après la configuration ?
Oui. Vous pouvez reconfigurer le SSO en relançant l’assistant de configuration et en choisissant un autre fournisseur.
Puis-je tester le SSO avant de le rendre obligatoire ?
Oui. Une fois la configuration terminée, laissez Force SSO désactivé : les utilisateurs pourront se connecter par SSO ou avec leurs méthodes habituelles pendant vos tests.