Une invitation d’utilisateur ressemble à un e-mail contenant un lien, mais dans un SaaS B2B, elle relève d’un parcours d’identité et d’appartenance à une organisation. Si les conséquences de l’expiration, du renvoi ou de l’arrivée sur un compte existant ne sont pas définies, l’équipe doit traiter les exceptions manuellement et les utilisateurs obtiennent des résultats difficiles à comprendre.
La décision produit consiste à modéliser tout le cycle, pas seulement l’envoi. Il est utile de distinguer l’invitation — une demande en attente associée à une adresse e-mail et à une organisation — du compte utilisateur et des autorisations accordées lors de l’arrivée. Cette distinction contribue à créer un processus prévisible, auditable et sûr.
Modélisez l’invitation avec des statuts et des transitions explicites
Commencez par définir les statuts nécessaires au produit. Un modèle courant comprend en attente, acceptée, expirée et révoquée. Si l’échec de l’envoi d’un e-mail peut être constaté, consignez ce résultat séparément ou ajoutez un statut opérationnel, tel que « échec de l’envoi ». Ne transformez pas chaque problème de distribution en statut métier si l’utilisateur peut toujours accepter l’invitation.
Précisez les actions associées à chaque transition. Une invitation en attente peut être acceptée, révoquée ou expirer ; une invitation expirée peut être remplacée par une nouvelle ; une invitation acceptée ne doit plus pouvoir être acceptée une seconde fois. La révocation doit rendre le lien inutilisable, même si le message d’origine se trouve encore dans la boîte de réception.
- Identifiez l’objet : enregistrez l’organisation, l’adresse invitée, l’auteur de l’invitation et la date de création.
- Définissez le résultat : consignez l’acceptation et l’identité qui a terminé le processus.
- Évitez les statuts ambigus : « e-mail envoyé » ne signifie pas nécessairement « invitation acceptée » et ne garantit pas que le message a été lu.
Cette distinction permet aussi de rendre l’écran d’administration plus clair : qui est en attente, depuis quand et quelle action l’administrateur peut entreprendre ensuite.
Choisissez la durée d’expiration en fonction du risque et de l’expérience
L’expiration limite la durée d’utilisation d’un lien. Une invitation valable trop longtemps augmente la période pendant laquelle un lien transféré ou exposé reste utilisable ; une durée trop courte complique le parcours, notamment si la personne invitée ne consulte son e-mail que plusieurs jours plus tard. Il n’existe pas de durée universelle : le choix dépend du risque, du type d’organisation et du niveau de contrôle souhaité par l’administrateur.
Définissez de manière cohérente ce qui se passe à l’expiration. L’option la plus claire consiste généralement à indiquer que l’invitation n’est plus valide et à proposer un moyen d’en demander une nouvelle. Si l’utilisateur est connecté, vous pouvez l’orienter vers l’administrateur de l’organisation. Ne présentez pas une invitation expirée comme un compte bloqué : ce sont deux situations différentes.
Dans l’interface de la personne qui invite, affichez la date d’expiration ou le statut expiré et autorisez la création d’une nouvelle invitation si cette personne dispose des droits nécessaires. Déterminez également si la nouvelle invitation conserve le destinataire et le rôle prévus ou si le responsable doit les vérifier. L’expiration doit être une règle appliquée par le serveur, et non un simple compte à rebours visuel : le système doit la vérifier au moment de l’acceptation.
Gérez les renvois et les changements d’adresse sans réactiver d’anciens liens
Un renvoi peut désigner deux opérations différentes : renvoyer le même lien ou en créer un nouveau. Si le lien est conservé, sa date d’expiration et son jeton restent identiques. Si un nouveau lien est généré, précisez si l’ancien est invalidé. Pour éviter plusieurs parcours actifs menant à une même invitation, il est souvent plus simple de révoquer l’ancien jeton lors de la création du nouveau.
La personne qui invite doit recevoir la confirmation de la réussite de l’opération ainsi qu’un signal clair en cas d’échec de l’envoi. Évitez qu’un bouton de renvoi crée une nouvelle invitation distincte à chaque clic : appliquez une règle d’idempotence ou vérifiez qu’une invitation équivalente est déjà en attente. Il est également utile d’éviter les envois répétés par inadvertance sans empêcher une nouvelle tentative légitime.
Si l’adresse change, traitez cette modification comme une opération sensible. La solution la plus claire consiste généralement à révoquer l’invitation adressée à l’ancienne adresse et à en créer une autre pour la nouvelle. Ne modifiez pas silencieusement le destinataire tout en conservant un lien déjà envoyé : la personne qui contrôle l’ancienne boîte pourrait encore accéder au processus. Consignez la modification pour permettre à l’organisation de comprendre ce qui s’est passé.
Gérez les doublons et les comptes déjà existants
Avant de créer une invitation, définissez ce qui constitue un doublon. Une règle pratique consiste à considérer la combinaison de l’organisation et de l’adresse normalisée, en appliquant les mêmes conventions de normalisation dans tout le système. N’appliquez pas de transformations excessives aux adresses e-mail : certaines équivalences qui semblent évidentes ne sont pas universelles. Conservez l’adresse saisie par l’utilisateur pour l’affichage et l’envoi.
Si une invitation est déjà en attente pour cette organisation et cette adresse, proposez une action utile : afficher le statut, renvoyer l’invitation ou la révoquer pour la remplacer, selon les autorisations de la personne à l’origine de la demande. Ne créez pas une deuxième entrée qui empêcherait les administrateurs de savoir laquelle est valide.
Si l’adresse est associée à un compte existant, l’invitation peut permettre à cette identité de rejoindre une autre organisation, à condition que la personne s’authentifie avec le bon compte et accepte de rejoindre l’organisation. Un compte existant n’implique pas l’appartenance à toutes les organisations. Si plusieurs comptes peuvent être associés à la même adresse, ne les reliez pas automatiquement sans mécanisme de vérification ni règle d’identité clairement définie.
Protégez le lien et vérifiez l’identité de la personne qui l’accepte
Le lien doit fonctionner comme un justificatif temporaire. Utilisez un jeton difficile à deviner, associé à une invitation précise et dont l’expiration est vérifiée par le serveur. N’incluez pas d’informations sensibles dans l’URL et évitez d’exposer le jeton dans les journaux, les outils d’analyse ou les pages de tiers. Les recommandations de l’OWASP Cheat Sheet Series sur la gestion sécurisée des justificatifs et des sessions peuvent servir de référence pour examiner la conception.
À l’ouverture du lien, fournissez suffisamment de contexte pour que la personne comprenne quelle organisation elle rejoint et à quelle adresse l’invitation a été envoyée. Avant de finaliser l’acceptation, vérifiez qu’elle contrôle cette adresse. Si elle est déjà connectée avec une autre identité, expliquez le conflit et demandez-lui de changer de compte ou de terminer la vérification, au lieu de relier les identités par commodité.
L’acceptation doit être une opération atomique : vérifier que l’invitation est toujours en attente et valide, confirmer l’identité, créer l’appartenance et marquer l’invitation comme acceptée. Si deux requêtes tentent d’utiliser le même lien simultanément, une seule doit pouvoir aboutir. Une visite ultérieure peut indiquer que l’invitation a déjà été utilisée, sans accorder à nouveau l’accès.
Définissez les conséquences d’un changement d’autorisations ou d’une révocation
L’invitation peut inclure un rôle initial ou une référence aux autorisations qui s’appliqueront lors de son acceptation. Décidez si ces autorisations sont fixées au moment de l’envoi ou consultées au moment de l’acceptation. Les fixer rend l’offre initiale explicite ; les consulter au dernier moment permet de prendre en compte les changements récents, mais peut surprendre la personne qui a envoyé l’invitation. Dans les deux cas, signalez les changements importants et ne renforcez pas les autorisations sans décision délibérée.
Si l’invitation est révoquée avant son acceptation, le lien doit cesser de fonctionner et la personne invitée doit recevoir un message neutre expliquant qu’elle ne peut plus terminer ce processus. Ne révélez pas d’informations inutiles sur l’organisation. Si le rôle ou l’adresse change, consignez qui a effectué la modification et à quel moment, en particulier lorsque plusieurs personnes administrent l’organisation.
Testez les cas limites et observez le parcours
Les tests doivent couvrir le parcours normal, mais aussi les transitions qui génèrent souvent des demandes d’assistance. Ils doivent inclure au minimum l’acceptation avant et après l’expiration, le renvoi avec l’ancien lien, la révocation, le double clic, les invitations répétées, un compte existant, une session ouverte avec une autre adresse et un changement de rôle alors que l’invitation est en attente.
- Vérifiez qu’un jeton utilisé, expiré ou révoqué ne permet pas d’obtenir l’accès.
- Assurez-vous qu’un échec d’envoi ne modifie pas par erreur le statut d’acceptation.
- Confirmez que les nouvelles tentatives ne créent ni appartenance ni invitation en double.
- Vérifiez que les messages indiquent la prochaine étape sans révéler de données concernant des tiers.
En production, suivez le nombre d’invitations en attente, expirées, révoquées et acceptées, ainsi que les échecs d’envoi et le délai avant acceptation. Interprétez ces indicateurs ensemble : de nombreuses expirations peuvent signaler des délais mal adaptés ou des e-mails qui n’arrivent pas ; de nombreux renvois peuvent indiquer que le message manque de clarté ou que le parcours est bloqué. Un indicateur ne suffit pas à établir la cause : complétez-le par les retours du support et des tests d’expérience.
La règle de conception qui relie tout le parcours est simple : chaque invitation doit avoir un destinataire, un statut, une échéance et une conséquence sans ambiguïté. Lorsque ces décisions sont documentées, l’équipe peut gérer les exceptions sans confondre invitations, comptes, appartenances ou autorisations générales.