Chez un éditeur SaaS, le deepfake vocal ne sert presque jamais à obtenir de l'argent. Il sert à obtenir une réinitialisation de facteur d'authentification. C'est le contournement le plus efficace du dispositif de sécurité le plus solide : inutile d'attaquer une passkey liée à l'origine si le service d'assistance accepte, sur la foi d'un appel, d'en enrôler une nouvelle pour un attaquant.
Le paradoxe du parcours de récupération
Les éditeurs sont souvent les organisations les mieux équipées en authentification forte. Population technophile, parc maîtrisé, FIDO2/WebAuthn déployé sans grande résistance. Cette maturité déplace mécaniquement le point d'attaque vers le seul endroit qui reste faible : la procédure prévue quand le facteur ne fonctionne plus.
Un collaborateur perd sa clé, casse son téléphone, part en déplacement sans son matériel. Il faut bien une voie de secours. Cette voie est presque toujours humaine, presque toujours téléphonique, et elle repose sur une identification que le deepfake vocal rend caduque : reconnaître la voix, poser des questions dont les réponses sont publiques, ou faire confiance au numéro affiché — qui se falsifie sans difficulté.
Le principe à retenir est net : la sécurité d'un compte vaut celle de son parcours de récupération, jamais celle de son facteur nominal.
L'anatomie de l'appel au support
L'appel efficace ne ressemble pas à une tentative d'intrusion. Il ressemble à un incident ordinaire.
L'attaquant appelle en fin de journée ou pendant une période de forte charge — fin de trimestre, lancement, astreinte de nuit. Il connaît le nom de son responsable, l'outil de tickets utilisé, le vocabulaire interne, parfois le nom d'un projet en cours. Ces éléments proviennent de profils professionnels en ligne, d'offres d'emploi, de dépôts publics et de conférences techniques.
Il n'exige rien. Il exprime une gêne : « je sais que ce n'est pas la procédure, mais je suis bloqué avant une démonstration client ». La demande est modeste, la pression est sociale plutôt qu'autoritaire, et l'agent qui refuse a le sentiment de nuire à un collègue.
| Élément de l'appel | Effet recherché | Ce qui le neutralise |
|---|---|---|
| Voix reconnaissable du collaborateur | Lever le doute initial | Ne jamais traiter la voix comme un élément d'identification |
| Numéro d'appelant correspondant | Confirmer l'identité | Rappel systématique sur le numéro de l'annuaire interne |
| Connaissance du contexte projet | Crédibilité | Assumer que le contexte est public |
| Urgence commerciale invoquée | Faire sauter la procédure | Procédure identique quel que soit le motif |
| Excuse de non-conformité assumée | Créer de la complicité | Script d'agent qui ne laisse pas de latitude |
| Appel hors heures ouvrées | Réduire la supervision | Procédure de nuit renforcée, pas allégée |
Une procédure de récupération qui résiste
Trois principes rendent le parcours de secours robuste sans le rendre inutilisable.
Aucune identification par la voix, ni par des données connaissables. Nom, service, date d'entrée, nom du responsable, dernier ticket : ces éléments ne prouvent rien. Ils figurent tous dans des sources publiques ou dans un compte de messagerie compromis.
Une preuve hors du canal de la demande. Rappel sur le numéro de l'annuaire interne, validation par le responsable hiérarchique contacté indépendamment, ou vérification en visioconférence avec pièce d'identité — en sachant que cette dernière option est elle-même exposée aux deepfakes vidéo et demande donc un contrôle de vivacité sérieux.
Un enrôlement de secours anticipé. La meilleure procédure de récupération est celle qu'on n'a pas besoin d'improviser : deux facteurs enrôlés dès l'arrivée du collaborateur, dont un conservé hors du poste de travail. Cette mesure élimine une grande partie des appels au support, donc une grande partie de la surface d'attaque.
Le risque propre au modèle SaaS
Un éditeur ne porte pas seulement son propre risque. Un compte interne réinitialisé au profit d'un attaquant peut ouvrir une console d'administration, un outil de support avec capacité d'impersonation, ou une chaîne d'intégration continue. L'incident devient alors un incident chez les clients, avec des obligations contractuelles et réglementaires en cascade.
Cela justifie un traitement différencié : les comptes disposant d'un accès transverse aux tenants clients ne doivent pas partager le parcours de récupération du reste de l'organisation. Pour eux, la réinitialisation doit exiger une présence physique ou une double validation par deux responsables distincts.
Ce que le facteur cognitif apporte à la récupération
Le facteur cognitif repose sur une méthode de résolution personnelle, acquise lors d'un enrôlement hors ligne et jamais transmise. Elle n'est pas verbalisable : un utilisateur ne peut pas la dicter au téléphone, et un attaquant ne peut pas l'obtenir en se faisant passer pour lui, faute d'élément à extorquer.
Appliqué au parcours de récupération, ce mécanisme change la question posée à l'agent de support. Elle n'est plus « suis-je convaincu que c'est bien lui ? », jugement subjectif que le deepfake vocal attaque directement, mais « le demandeur a-t-il produit la preuve attendue ? », question binaire et traçable. Le déploiement en overlay d'un dispositif existant permet de commencer par ce parcours, sans toucher au reste de l'authentification.
FAQ
Peut-on détecter une voix synthétique en temps réel au support ?
Les outils existent, mais la course avec les générateurs est permanente et la qualité du canal téléphonique dégrade les indices. Un détecteur peut alimenter un score de risque ; il ne doit pas autoriser une réinitialisation.
Faut-il interdire toute réinitialisation par téléphone ?
Pour les comptes à privilèges et les accès transverses, oui. Pour le reste, une voie téléphonique peut subsister à condition qu'elle exige une preuve hors du canal de l'appel et qu'elle soit tracée.
Comment éviter que la procédure paralyse l'activité ?
En anticipant l'enrôlement de facteurs de secours dès l'intégration du collaborateur. La plupart des demandes urgentes disparaissent quand une alternative existe déjà.
Les passkeys règlent-elles le problème ?
Elles sécurisent la connexion grâce à la liaison à l'origine, mais elles déplacent le risque vers l'enrôlement et la récupération. Un dispositif fort assorti d'une procédure de secours faible vaut le niveau de cette procédure.
Aller plus loin : le 4ᵉ facteur cognitif · AiTM chez les éditeurs SaaS · récupération de compte et passkey · réinitialisation au helpdesk