Combien de temps un système doit-il faire confiance à un utilisateur après son authentification ?

Lorsqu’un utilisateur se connecte à un système, son identité est vérifiée. Si ses identifiants et les autres mécanismes d’authentification sont valides, le système lui accorde l’accès et crée une session.

Mais l’authentification confirme une identité à un instant précis. L’utilisateur peut ensuite continuer à travailler pendant plusieurs heures sans avoir à s’authentifier de nouveau.

Cela soulève une question importante en matière de sécurité logicielle : combien de temps une session doit-elle rester considérée comme fiable après l’authentification d’un utilisateur ?

La connexion marque le début de l’accès, pas la fin du contrôle

Après une connexion réussie, le système crée généralement une session qui permet à l’utilisateur de poursuivre son activité sans avoir à saisir ses identifiants pour chaque action.

C’est essentiel pour garantir une utilisation fluide. Mais une session active représente également la continuité d’une décision prise auparavant : le système suppose que la personne qui utilise la session est toujours celle qui s’est authentifiée au départ.

Plus cette confiance se prolonge, plus sa gestion devient importante.

Le NIST intègre précisément cette question à la gestion des sessions et définit la réauthentification périodique comme un moyen de confirmer la présence continue de l’utilisateur au sein d’une session authentifiée.

Une session active ne signifie pas toujours que la situation est restée la même

Prenons un exemple simple.

Un utilisateur se connecte à 8 h depuis son appareil professionnel. Plusieurs heures plus tard, la session est toujours active. Techniquement, le système peut toujours considérer la session comme valide, mais le temps écoulé, une période d’inactivité ou le contexte d’accès peuvent modifier le niveau de risque.

C’est précisément pour cette raison qu’existent des mécanismes tels que l’expiration de session, le délai d’inactivité et la réauthentification.

Le NIST distingue deux limites principales : une durée maximale globale de session et une limite liée aux périodes d’inactivité. Lorsque ces limites sont atteintes, la session doit prendre fin ou l’utilisateur doit s’authentifier à nouveau, selon la politique définie par le système.

Tous les utilisateurs et toutes les actions ne présentent pas le même niveau de risque

L’un des enjeux de la gestion des sessions tient au fait qu’une règle unique n’est pas nécessairement adaptée à toutes les situations.

Consulter des informations générales et administrer des privilèges critiques ne présentent pas le même niveau de risque. De même, un utilisateur standard et un administrateur disposant de droits étendus n’ont pas nécessairement besoin de la même politique de session.

C’est pourquoi la gestion moderne des accès devient de plus en plus granulaire. Le 15 septembre 2026, Google Cloud a annoncé avoir finalisé le déploiement d’une durée de session par défaut de 16 heures pour les clients qui n’avaient pas défini leur propre durée, tandis que de nouveaux contrôles permettent d’appliquer des politiques plus précises selon les groupes et les applications. Google cite notamment l’exemple d’une session de deux heures pour les utilisateurs disposant de privilèges élevés, contre une session standard de 16 heures pour les développeurs classiques.

Sécurité et expérience utilisateur doivent fonctionner ensemble

Un système pourrait demander aux utilisateurs de s’authentifier en permanence, mais cela rendrait rapidement son utilisation contraignante. À l’inverse, une session qui reste active sans limite peut accroître l’exposition au risque si l’appareil ou la session tombe entre les mains d’une autre personne.

L’objectif n’est donc pas simplement de réduire au maximum la durée des sessions.

Il consiste à déterminer quand le système peut continuer à faire confiance à l’authentification existante et quand une nouvelle vérification doit être demandée.

Les standards modernes considèrent cette décision comme dépendante du contexte, notamment du type d’application, de l’appareil utilisé, de l’environnement dans lequel le système est utilisé et du niveau de sécurité requis.

La confiance numérique a aussi une dimension temporelle

La sécurité de l’identité est souvent abordée au moment de la connexion : mots de passe, MFA, passkeys ou autres méthodes d’authentification.

Mais un système doit également gérer ce qui se passe après l’authentification.

Combien de temps s’est écoulé ? La session est-elle restée inactive ? De quel niveau d’accès l’utilisateur dispose-t-il ? Tente-t-il d’effectuer une action nécessitant un niveau de sécurité plus élevé ?

Ces décisions font de la gestion des sessions une composante de l’architecture des accès, et non un simple minuteur qui déconnecte automatiquement l’utilisateur.

Chez Soft & Solution Group, la gestion des identités et des accès est considérée comme une composante de la sécurité d’un système tout au long du parcours utilisateur, depuis l’authentification initiale jusqu’au contrôle continu des accès.

Comme l’explique Ermal Beqiri, fondateur de Soft & Solution Group :

« La sécurité ne s’arrête pas lorsqu’un utilisateur se connecte. Un système doit également savoir quand il est nécessaire de vérifier à nouveau son identité. Cet équilibre entre accès et contrôle fait partie intégrante de la conception d’un système sécurisé. »

Une connexion réussie confirme que le système a accordé sa confiance à l’utilisateur à cet instant précis. La gestion des sessions détermine combien de temps cette confiance reste valable.