Dans une collectivité, l’authentification multifacteur protège les comptes en demandant une preuve supplémentaire lors de la connexion. Cette étape peut prendre la forme d’un code, d’une clé de sécurité ou d’une demande de validation sur un téléphone. Elle réduit le risque qu’un mot de passe compromis suffise à accéder à une messagerie ou à un outil métier. Mais une notification inattendue peut aussi être approuvée par réflexe, notamment si elle se répète ou si l’agent pense qu’elle correspond à une opération en cours. La procédure doit donc préciser quoi faire lorsqu’une demande ne correspond pas à une connexion volontaire.
Une demande de validation inattendue doit être traitée comme un signal, pas comme une formalité. L’agent ne l’accepte pas et ne communique aucun code reçu par SMS ou par téléphone, même si l’interlocuteur se présente comme un technicien. Il vérifie ensuite s’il a lui-même lancé une connexion, par exemple depuis un nouvel appareil ou après une déconnexion. Si ce n’est pas le cas, il refuse la demande et signale l’événement au contact prévu par la collectivité. Cette consigne gagne à être accessible depuis un canal distinct du compte concerné, afin de rester consultable lorsque la messagerie est inaccessible ou suspecte.
La réponse dépend ensuite du contexte et du niveau de risque. Le service informatique peut vérifier les connexions récentes, les appareils enregistrés et les alertes disponibles dans l’outil d’authentification, sans conclure sur la seule base d’une notification. Si plusieurs demandes surviennent, si une connexion inconnue apparaît ou si l’agent a validé une demande par erreur, il faut appliquer la procédure interne : prévenir le support, révoquer les sessions si l’outil le permet et changer le mot de passe depuis un environnement de confiance. Les démarches ne sont pas identiques selon les services ; la collectivité doit donc indiquer qui contacter et quelles informations transmettre, sans demander l’envoi de mots de passe ou de codes temporaires.
La prévention repose aussi sur le paramétrage et l’organisation. Lorsque le service le permet, une validation qui affiche un nombre à comparer ou des informations de contexte peut aider l’utilisateur à distinguer sa propre connexion d’une demande qu’il n’a pas initiée. Ce mécanisme ne remplace pas les consignes ni la vigilance : il doit être testé avec les équipements réellement utilisés par les agents et expliqué dans des termes compréhensibles. La collectivité prévoit également une méthode de secours encadrée pour les personnes qui perdent leur téléphone, ainsi qu’un moyen de joindre le support sans dépendre exclusivement de l’application d’authentification. Les comptes à privilèges, qui donnent accès à des fonctions sensibles, nécessitent des règles adaptées et un suivi proportionné.
Une authentification multifacteur efficace associe donc un outil approprié à des gestes connus et à une assistance joignable. Les agents doivent savoir qu’une demande qu’ils n’ont pas déclenchée ne se valide pas, même si elle semble urgente ou répétitive. De leur côté, les équipes informatiques définissent un circuit de signalement, vérifient les événements disponibles et organisent la révocation des accès en cas de doute. Cette préparation limite les décisions prises sous pression et aide à protéger les données personnelles traitées par les services. Elle doit être réexaminée lorsque les outils, les usages ou les procédures de support évoluent.
