# Mots de passe : passer à la double vérification

> Quand un éditeur grand public impose la double vérification à ses utilisateurs, il signale que le mot de passe seul ne suffit plus. Voici comment une TPE ou une PME peut appliquer ce principe à sa messagerie, à ses outils métier et à son réseau, sans bloquer ses équipes.

Article de comm.it publié le 18 octobre 2026.


![Illustration en style plat et moderne : un écran de connexion professionnel avec un champ de mot de passe barré, relié à un smartphone affichant un code de vérification et à une clé d'accès stylisée.](https://commit.insit.net/media/comm.it_mots-de-passe-passer-a-la-double-verification-56f778.png)

## Le mot de passe seul ne suffit plus

L'éditeur **Notion** a récemment annoncé un changement de politique : les comptes qui se connectent par **mot de passe** devront ajouter une **seconde étape de vérification**. L'annonce, publiée sur le blog de l'éditeur sous le titre *« Making password login safer on Notion »* et signée par **Ankit Gupta** (équipe Trust Engineering), part d'un constat simple : **les gens réutilisent leurs mots de passe**. Quand un mot de passe fuite sur un autre site, quelqu'un peut l'essayer ailleurs. Selon l'éditeur, un mot de passe volé ne doit pas suffire à ouvrir un compte.

Ce constat dépasse largement un outil de prise de notes. Dans une TPE ou une PME, le même réflexe touche :

- la **messagerie professionnelle** ;
- le **CRM** et l'**ERP** ;
- les outils collaboratifs et le partage de fichiers ;
- les interfaces d'administration du **réseau**, du **Wi-Fi** et de la **vidéosurveillance** ;
- les comptes des prestataires et des fournisseurs.

Un seul mot de passe réutilisé peut donc donner accès à des données clients, à des factures ou à des caméras. Cet article reprend la démarche de **Notion** et montre comment comm.it l'adapte au système d'information d'une petite ou moyenne entreprise.

## Ce que la démarche de Notion montre

### Une sécurité qui sert aussi à récupérer son compte

L'éditeur souligne que la seconde étape de vérification ne sert pas qu'à se protéger. Elle peut aussi **aider à récupérer l'accès** à un compte quand un autre problème survient. La **MFA** (*authentification multifacteur*) est donc à la fois une protection et un moyen de **continuité d'accès**.

C'est un argument utile en entreprise. Une mesure de sécurité perçue comme une contrainte passe mal. Une mesure qui évite aussi de perdre l'accès à sa boîte mail un lundi matin passe beaucoup mieux.

### Un déploiement progressif, pas brutal

Le changement n'arrive pas d'un coup. D'après l'annonce, il se déploie **par étapes sur plusieurs mois**. Les situations sont traitées différemment :

- **mot de passe et double vérification déjà actifs** : rien à faire ;
- **aucun mot de passe** (connexion par passkey, code par e-mail, compte Google, Apple, Microsoft ou **SSO** de l'organisation) : aucun besoin d'en créer un ;
- **mot de passe ancien et inutilisé**, alors qu'une autre méthode fonctionne : l'éditeur prévoit de **désactiver ce mot de passe dormant** ;
- **mot de passe sans seconde étape** : l'utilisateur sera **prévenu**, aura du **temps** et recevra des **instructions** avant la désactivation de la connexion par mot de passe seul.

Cette segmentation est une bonne pratique. Elle sépare les usages déjà sûrs, les accès oubliés et les comptes vraiment exposés, et traite chaque cas à part.

### Plusieurs méthodes, et des codes de secours

L'éditeur propose une **application d'authentification** ou un **code par SMS**. Il précise que le SMS n'est pas disponible partout. Il insiste aussi sur les **codes de secours** remis à l'activation : il faut les conserver pour le jour où l'on perd son téléphone. Enfin, il prévoit un **parcours de récupération** : code envoyé par e-mail, autre méthode déjà liée, codes de secours, puis support.

Ce sont les mêmes étapes que dans tout projet d'**authentification forte** : choisir les méthodes, prévoir la perte d'un appareil et documenter la récupération.

## Le vrai sujet pour une PME : la gestion des identités

Sur une plateforme comme **Notion**, l'éditeur gère tout pour ses utilisateurs. Dans une PME, personne ne le fait à votre place. Les comptes sont souvent :

- **dispersés** entre des dizaines d'outils SaaS ;
- créés par chaque service, **sans inventaire central** ;
- **jamais supprimés** au départ d'un salarié ou d'un stagiaire ;
- **partagés** entre collègues (le fameux identifiant « accueil » ou « compta ») ;
- protégés par des mots de passe **réutilisés** d'un service à l'autre.

L'approche de comm.it ne consiste pas à activer une case « MFA » outil par outil. Il s'agit de construire une **gestion des identités et des accès** adaptée à la taille de l'entreprise.

## Étape 1 : faire l'inventaire des accès

On ne protège bien que ce que l'on connaît. La première étape est un **audit des accès** :

1. **Lister les applications** utilisées, y compris celles adoptées par les équipes sans validation.
2. **Recenser les comptes** de chaque application et vérifier qu'ils correspondent à des personnes encore présentes.
3. **Identifier les méthodes de connexion** : mot de passe seul, MFA, connexion via un fournisseur d'identité, SSO.
4. **Repérer les comptes à privilèges** : administrateurs de la messagerie, du pare-feu, des bornes Wi-Fi, de l'enregistreur vidéo, du CRM.
5. **Repérer les comptes partagés**, plus difficiles à sécuriser et à tracer.

Cet inventaire reprend la logique de segmentation de **Notion** : distinguer ce qui est déjà protégé, ce qui dort et ce qui est exposé. Les comptes dormants se suppriment. Les comptes exposés passent en priorité. Les comptes déjà sûrs restent en place.

## Étape 2 : centraliser l'authentification avec le SSO

L'annonce cite le **SSO de l'organisation** parmi les méthodes de connexion. Pour une PME, c'est souvent le levier le plus efficace. Avec l'**authentification unique**, chaque collaborateur utilise **une seule identité professionnelle**, protégée par une seconde étape, pour accéder à ses outils.

Les bénéfices sont concrets :

- **moins de mots de passe** à retenir, donc moins de réutilisation ;
- **une seule politique MFA** à appliquer, au lieu d'une par outil ;
- **arrivées et départs plus simples** : désactiver l'identité centrale coupe l'accès à toutes les applications reliées ;
- **meilleure traçabilité** des connexions.

comm.it vérifie quelles applications acceptent le SSO, les relie à l'identité centrale et définit les règles d'accès. Quand un outil ne le permet pas, une MFA locale est activée et documentée.

## Étape 3 : choisir les bonnes méthodes de vérification

Toutes les secondes étapes ne se valent pas, et toutes ne conviennent pas à chaque poste. L'éditeur propose l'application d'authentification et le SMS, et rappelle que le SMS n'est pas disponible dans toutes les régions. En entreprise, on étudie plusieurs options :

- **Application d'authentification** : codes temporaires générés sur le téléphone, adaptée à la plupart des usages.
- **Passkeys** (*clés d'accès*) : connexion sans mot de passe, liée à l'appareil et validée par biométrie ou code PIN. L'éditeur les cite parmi les méthodes acceptées.
- **Code par e-mail** : pratique en secours, mais il suppose que la messagerie soit elle-même bien protégée.
- **SMS** : facile à prendre en main, mais dépendant du réseau et de la région.

comm.it adapte la méthode au profil :

- les **administrateurs** reçoivent les méthodes les plus robustes ;
- les **équipes terrain** ont une méthode simple, compatible avec leur téléphone professionnel ;
- les **postes partagés** (accueil, atelier, entrepôt) font l'objet d'un traitement spécifique.

Une méthode trop contraignante finit toujours contournée. L'objectif est une sécurité que les équipes utilisent vraiment.

## Étape 4 : prévoir la perte d'un téléphone

L'annonce de **Notion** consacre une section entière à la question « et si je ne peux plus me connecter ? ». C'est le point le plus souvent oublié des projets MFA en PME. Un collaborateur perd son téléphone ou en change sans transférer son application, et se retrouve bloqué.

comm.it met en place une **procédure de récupération** claire :

- **codes de secours** générés à l'activation et stockés dans un endroit sûr et accessible ;
- **au moins deux méthodes** de vérification enregistrées par compte quand c'est possible ;
- **procédure de réinitialisation** par l'administrateur, avec **vérification d'identité** pour éviter l'usurpation ;
- **comptes d'administration de secours**, protégés et réservés aux urgences ;
- **documentation simple** remise aux équipes.

La procédure de récupération est elle-même un point d'attaque. Un attaquant qui obtient une réinitialisation par simple appel au support contourne toute la MFA. Elle doit donc être aussi rigoureuse que la connexion.

## Étape 5 : déployer progressivement et accompagner

L'éditeur échelonne son déploiement sur plusieurs mois, prévient les personnes concernées, fixe une échéance et fournit des instructions. comm.it applique la même méthode en entreprise :

1. **Pilote** sur un petit groupe volontaire pour tester les méthodes et la procédure de récupération.
2. **Comptes à privilèges en priorité** : administrateurs, direction, comptabilité.
3. **Communication claire** : pourquoi on le fait, ce qui change, la date d'échéance.
4. **Accompagnement à l'activation**, en présentiel ou à distance, avec un guide pas à pas.
5. **Généralisation**, puis **désactivation de la connexion par mot de passe seul** une fois l'échéance passée.

Cette approche réduit les appels au support et les blocages. Elle évite aussi l'effet « coup de force » qui braque les équipes.

## Automatiser le cycle de vie des comptes

La MFA protège les comptes existants. Encore faut-il que seuls les bons comptes existent. C'est là qu'intervient l'**automatisation des processus**, l'un des métiers de comm.it.

Un **workflow d'arrivée et de départ** automatisé permet :

- à l'**arrivée** d'un collaborateur, de créer son identité, de l'ajouter aux bons groupes et de lui ouvrir les applications de son poste, avec activation de la MFA dès la première connexion ;
- lors d'un **changement de poste**, d'ajuster les droits au lieu de les empiler ;
- au **départ**, de désactiver l'identité, de couper les sessions ouvertes et de transférer la messagerie selon la politique de l'entreprise.

Ce processus reprend l'idée de **Notion** de supprimer les mots de passe dormants, mais à l'échelle de toute l'entreprise et de façon systématique. Un compte qui n'existe plus ne peut plus être piraté.

## Intégrer l'authentification forte dans les logiciels métier

comm.it développe aussi des **logiciels cœur de métier**, comme des **CRM** et des **ERP** sur mesure. Ces outils concentrent souvent les données les plus sensibles : clients, devis, stocks, données financières.

Lors de leur conception, comm.it prévoit dès le départ :

- la **connexion via le SSO** de l'entreprise, pour éviter un compte et un mot de passe de plus ;
- une **MFA native** quand le SSO n'est pas disponible ;
- la **compatibilité avec les passkeys** si le contexte s'y prête ;
- une **gestion fine des rôles et des droits** ;
- une **journalisation des connexions** et des actions sensibles ;
- un **parcours de récupération** sécurisé.

Ajouter la sécurité dès la conception coûte moins cher que de la greffer après coup. Les utilisateurs profitent aussi d'une expérience cohérente avec le reste de leurs outils.

## Ne pas oublier le réseau et les équipements

Les problèmes de mots de passe ne concernent pas que les applications en ligne. Dans beaucoup de PME, les **équipements réseau** restent négligés :

- **routeurs** et **pare-feu** avec identifiants par défaut ou partagés ;
- **bornes Wi-Fi** administrées par un mot de passe connu de plusieurs personnes ;
- **enregistreurs de vidéosurveillance** accessibles depuis l'extérieur ;
- **clé Wi-Fi unique** jamais changée malgré les départs.

Dans ses missions **réseau**, **Wi-Fi** et **vidéosurveillance**, comm.it applique les mêmes principes :

- remplacer les identifiants par défaut ;
- **nominatifier** les accès d'administration ;
- protéger les interfaces sensibles par une seconde étape quand l'équipement le permet ;
- limiter l'exposition sur Internet ;
- relier le Wi-Fi professionnel à l'identité des collaborateurs plutôt qu'à une clé partagée, lorsque l'infrastructure s'y prête.

## Ce que l'IA change et ne change pas

comm.it intègre aussi des **solutions d'IA** dans les processus de ses clients. Ces outils se connectent souvent à la messagerie, aux documents et au CRM. Ils héritent donc des droits du compte qui les utilise. Un compte compromis peut alors exposer, via un assistant connecté, beaucoup plus de données qu'avant.

Avant de connecter un outil d'IA à vos données, comm.it vérifie :

- que les comptes concernés sont protégés par une **authentification forte** ;
- que les **droits accordés** sont limités au strict nécessaire ;
- que les **connecteurs** et **jetons d'accès** sont inventoriés et révocables.

L'IA ne remplace pas une bonne hygiène des identités. Elle en dépend.

## En résumé

L'annonce de l'éditeur, signée Ankit Gupta, rappelle trois idées :

- un **mot de passe volé** ne doit jamais suffire à ouvrir un compte ;
- la **seconde étape de vérification** protège et aide à récupérer l'accès ;
- un changement de ce type se **déploie progressivement**, avec préavis, instructions et solutions de secours.

Pour une TPE ou une PME, cela se traduit par un projet structuré :

1. inventaire des accès ;
2. centralisation avec le SSO ;
3. choix de méthodes de vérification adaptées ;
4. procédure de récupération rigoureuse ;
5. déploiement progressif ;
6. automatisation du cycle de vie des comptes ;
7. sécurité intégrée aux logiciels métier, au réseau et aux outils d'IA.

comm.it accompagne chacune de ces étapes, de l'audit initial au support des utilisateurs, en tenant compte des contraintes et des usages de chaque entreprise.

> Prêt à transformer ces enjeux en avantage concurrentiel ? Contactez comm.it pour en discuter.

---

*Source : [Making password login safer on Notion](https://www.notion.com/blog/making-password-login-safer-on-notion)*

---

- [Accueil](https://commit.insit.net/index.html.md)
- [Demander un devis gratuit](https://commit.insit.net/#devis)