L'IA pour le support de récupération de compte est sûre quand chaque action qu'elle peut effectuer aide toujours le véritable propriétaire, même si la personne qui demande ment. Envoyer votre e-mail de réinitialisation habituel à l'adresse déjà présente sur le compte passe ce test : un attaquant peut le demander toute la journée et le lien arrive quand même dans la boîte du propriétaire. Changer l'e-mail, réinitialiser le 2FA ou "simplement le désactiver" ne le passe pas. Laissez donc l'IA résoudre les mots de passe oubliés et les blocages, trier et rédiger les cas de 2FA et de changement d'e-mail, et envoyer directement à une personne tout ce qui ressemble à un piratage.
Cette répartition compte parce que les services de support sont une porte d'entrée connue. L'avis sur Scattered Spider de l'agence américaine de cybersécurité CISA décrit des attaquants qui appellent les services d'assistance pour réinitialiser des mots de passe et déplacer le MFA vers leurs propres appareils. Une IA que l'on peut convaincre de faire la même chose est une version plus rapide de cette faille.
eesel fonctionne ainsi dans Zendesk, Freshdesk, HubSpot et d'autres helpdesks : il n'appelle que le point de réinitialisation que vous autorisez, retient les actions risquées pour approbation et ne voit jamais vos clés d'API. XAP, qui exploite des portails étudiants pour des États et des universités américaines, laisse son agent eesel traiter les réinitialisations de mot de passe du portail dans Freshdesk tandis que les suppressions de compte restent à l'équipe, et une personne envoie chaque réponse.
Pourquoi les tickets de récupération de compte sont-ils si difficiles à automatiser ?
Parce que c'est le seul type de ticket où être serviable et être sûr tirent dans des directions opposées. Le client est bloqué, souvent stressé, et veut récupérer son compte tout de suite. L'attaquant écrit exactement le même message.
Ils représentent aussi beaucoup de volume. Bron Gondwana, du fournisseur d'e-mail Fastmail, a donné un chiffre sur Hacker News :
"In 2016 before we had automated account recovery, lost password was in the top 3 categories of ticket every single week! Every member of the support team dealt with multiple account-loss tickets per day, both forgotten password or stolen account."
Ce couple, mot de passe oublié et compte volé dans la même file, est tout le problème. Je travaille la file de support d'eesel tous les jours, et "je n'arrive pas à me connecter" est l'un de ces messages où la réponse qui semble la plus gentille est parfois celle qu'il ne faut pas envoyer. Une personne ressent l'hésitation. Un chatbot conçu pour résoudre des tickets bouclera volontiers l'affaire pour qui que ce soit à l'autre bout.
L'autre aspect, c'est à quel point les clients se lassent des mauvais parcours de récupération. Un utilisateur de Hacker News a résumé la frustration liée aux sauvegardes MFA et aux services de support d'un seul coup :
"Plus a ton of vendors allow customer support to trivially turn off MFA via social-engineering, so what is the point?"
La mission n'est donc pas "d'automatiser la récupération de compte". C'est d'automatiser les parties où une mauvaise supposition ne coûte rien et de ralentir celles où une mauvaise supposition livre le compte à quelqu'un. La bonne nouvelle, c'est que l'essentiel du volume se trouve dans le premier groupe. Si vous ne traitez que des réinitialisations de mot de passe, mon article sur l'IA pour les demandes de réinitialisation de mot de passe couvre ce type de ticket plus en détail. Ce guide couvre toute la file de récupération.
Quel est le test unique qu'une action de récupération de l'IA doit passer ?
Demandez-vous : si la personne dans ce chat est un attaquant, cette action n'aide-t-elle toujours que le véritable propriétaire ? Si oui, l'IA peut l'exécuter. Sinon, une personne décide.
Ce test paraît simple et trie presque toutes les actions de récupération proprement :
| Action demandée par le client | Aide-t-elle toujours seulement le véritable propriétaire ? | Qui l'exécute |
|---|---|---|
| Envoyer le lien de réinitialisation standard | Oui, il va à l'adresse enregistrée | L'IA, seule |
| Expliquer pourquoi le compte est bloqué et quand il se débloque | Oui, c'est de l'information, pas de l'accès | L'IA, seule |
| Guider l'utilisation d'un code de récupération enregistré | Oui, seul le propriétaire a le code | L'IA, seule |
| Renvoyer un code vers une adresse de récupération déjà enregistrée | Oui | L'IA, seule |
| Changer l'e-mail ou le numéro de téléphone du compte | Non, la nouvelle adresse pourrait être celle de n'importe qui | Une personne, après vérifications |
| Réinitialiser ou retirer le 2FA | Non, cela enlève le second verrou | Une personne, après vérifications |
| Dire au client si un e-mail a un compte | Non, cela révèle qui sont vos clients | Personne, jamais |
| Coller un lien de réinitialisation ou un code dans le chat | Non, le chat est le canal non fiable | Personne, jamais |
Les deux dernières lignes viennent directement de l'OWASP Forgot Password Cheat Sheet, la référence de la communauté de la sécurité pour les parcours de réinitialisation. Il y est dit de renvoyer un message cohérent pour les comptes existants comme inexistants, donc une réponse comme "si cet e-mail a un compte, un lien de réinitialisation est en route" est la bonne même quand l'IA peut voir que le compte existe.
Le tableau indique aussi ce qu'il faut connecter. Un agent IA qui n'a qu'un bouton "envoyer l'e-mail de réinitialisation" ne peut pas être convaincu d'exécuter les lignes dangereuses, car il n'a pas de bouton pour elles. C'est une garantie bien plus forte qu'une consigne lui demandant d'être prudent. Les consignes se discutent. Une permission absente, non. J'y reviens dans la section de configuration.
Quelles demandes de récupération de compte l'IA peut-elle traiter ?
Classez-les selon ce qui se passe mal si l'IA est trompée. Je commencerais n'importe quelle équipe avec trois voies :
Voie 1 : l'IA résout. Mots de passe oubliés, blocages après des échecs et clients qui ont encore un code de récupération ou un second appareil. La solution passe par quelque chose que le propriétaire contrôle déjà. L'IA déclenche la réinitialisation, explique le blocage ou guide l'utilisation du code, puis ferme le ticket. C'est là que se trouve l'essentiel de votre volume et que l'IA vous rend le plus d'heures. C'est aussi la voie à faire tourner 24h/24 et 7j/7, car personne de bloqué un samedi ne veut attendre le lundi.
Voie 2 : l'IA prépare, une personne décide. Un téléphone 2FA perdu sans codes de récupération, pas d'accès à l'e-mail enregistré ou un nouveau numéro de téléphone. Il ne reste aucun canal qui prouve la propriété, donc quelqu'un doit vérifier. L'IA fait quand même l'essentiel du travail : elle lit le compte, liste les options de récupération existantes, ouvre le dossier, rédige la demande de pièce d'identité et écrit une note interne pour que l'agent qui reprend commence avec les faits. C'est la même forme qu'un transfert à une personne pour les remboursements, avec simplement une règle plus stricte sur qui appuie sur le bouton.
Voie 3 : équipe de sécurité uniquement. "Quelqu'un a changé mon mot de passe", une demande de retrait du 2FA ou toute demande sur une connexion administrateur ou propriétaire du compte. Le rôle de l'IA ici est la rapidité et le silence : l'étiqueter urgent, l'acheminer, dire au client ce qui va se passer et n'envoyer rien à une adresse modifiée récemment.
Un cas client montre pourquoi la voie 1 a besoin de contexte, pas seulement d'un mot-clé. MentorShow, une entreprise française de formation en ligne, fait lire à eesel chaque ticket HubSpot avec la fiche du membre, y compris le statut de l'abonnement et la date de renouvellement. Leurs consignes contiennent une ligne que je copierais dans n'importe quelle configuration : un problème de connexion venant de quelqu'un sans abonnement actif n'est pas un problème de connexion. Ce ticket demande une réponse de facturation, et un lien de réinitialisation ne ferait que faire tourner le membre en rond.
Que disent les normes de sécurité sur la récupération de compte ?
Les deux références vers lesquelles se tournent la plupart des équipes de sécurité sur cette question sont la NIST SP 800-63B-4, les lignes directrices d'identité numérique du gouvernement américain, et l'OWASP. Elles ont été écrites pour des ingénieurs qui construisent des systèmes de connexion, mais la plupart des règles se traduisent directement en ce qu'un agent de support, humain ou IA, doit et ne doit pas faire.
| Ce que dit la norme | Ce que cela signifie dans un ticket de support |
|---|---|
| Le NIST liste quatre méthodes de récupération : codes de récupération enregistrés, codes émis envoyés à une adresse de récupération, contacts de récupération et répétition de la vérification d'identité | Votre agent doit vérifier lesquelles le compte possède avant de promettre quoi que ce soit |
| Récupérer un compte avec 2FA exige deux codes de récupération de méthodes différentes, un code plus un autre facteur fonctionnel, ou une vérification d'identité répétée (NIST) | "Donnez-moi votre date de naissance" n'est pas une des options. Un cas de téléphone perdu sans rien d'enregistré va à une personne |
Un code de récupération émis dure au plus 10 minutes par SMS ou appel vocal et 24 heures par e-mail (NIST) | Dites aux clients combien de temps le lien est valable, et d'en demander un nouveau plutôt que de répondre à un ancien e-mail |
| Une nouvelle adresse de récupération doit être confirmée par un code avant d'être utilisée (NIST) | Ne traitez jamais comme celui du client un e-mail saisi dans le chat |
| Chaque récupération de compte envoie une notification aux adresses enregistrées, avec un moyen de dire "ce n'était pas moi" (NIST) | L'ancienne adresse est informée de chaque récupération, donc le véritable propriétaire peut arrêter une fausse |
Les échecs sur un authentificateur sont plafonnés à 100 avant sa désactivation (NIST) | Les blocages sont voulus. Expliquez-les ; ne cherchez pas de contournement |
| Renvoyer le même message que le compte existe ou non (OWASP) | L'IA ne confirme jamais "oui, cet e-mail est celui d'un client" |
| Ne pas connecter automatiquement l'utilisateur après une réinitialisation et proposer de fermer les autres sessions (OWASP) | Après un piratage, un nouveau mot de passe seul peut ne pas exclure l'attaquant |
| Les questions de sécurité ne doivent pas être l'unique contrôle de réinitialisation (OWASP) | Des réponses comme un anniversaire ou le nom d'un animal se trouvent souvent en ligne |
Cette règle de notification est celle que les équipes de support oublient le plus, et c'est la protection la moins chère dont vous disposez. Le NIST dit que les notifications de récupération vont à toutes les adresses de notification du compte, et que l'avis doit inclure des instructions claires et des coordonnées au cas où le destinataire ne l'aurait pas demandé. Si votre IA déclenche une récupération, assurez-vous que votre système envoie cet avis aussi à l'ancienne adresse. Si quelqu'un détourne le compte, le propriétaire l'apprend en quelques minutes, pas à sa prochaine tentative de connexion.
L'OWASP souligne aussi un point qui change la façon de traiter les tickets "je crois avoir été piraté". Il dit qu'une réinitialisation de mot de passe seule peut ne pas rétablir le contrôle d'un compte compromis, car l'attaquant peut encore avoir une session active ou avoir modifié les informations de récupération. C'est pourquoi les cas de piratage sont dans la voie 3, où quelqu'un peut fermer toutes les sessions et vérifier ce qui a changé, plutôt que dans la voie 1 avec un joyeux lien de réinitialisation.
Pourquoi l'IA ne devrait-elle pas changer des e-mails ni réinitialiser le 2FA seule ?
Parce que ce sont exactement les demandes que les attaquants apportent aux services de support, et un modèle qui lit un seul chat ne peut pas les distinguer d'un vrai client.
L'avis de la CISA sur Scattered Spider, un groupe derrière plusieurs grandes intrusions, énumère les manœuvres. Le groupe se faisait passer pour des employés "to convince IT and/or helpdesk staff to provide sensitive information, reset the employee's password, and transfer the employee's MFA to a device they control". L'avis ajoute que ces appels se font souvent en plusieurs conversations : ils apprennent d'abord ce que demande le service d'assistance, puis reviennent avec les réponses. Leur préparation vient des réseaux sociaux, des fuites de données et des sources ouvertes, ce qui est précisément pourquoi "confirmez votre adresse et votre date de naissance" est une vérification faible.
Okta a vu le même schéma. Dans son rapport de sécurité de 2023, Okta a indiqué que plusieurs clients américains avaient signalé des appelants tentant de convaincre le personnel du service d'assistance de réinitialiser tous les facteurs MFA de leurs comptes administrateurs les plus puissants. Les conseils d'Okta incluent des vérifications d'identité plus strictes au service d'assistance, la limitation des rôles du service d'assistance pour qu'ils ne puissent pas toucher aux comptes administrateurs, et des alertes chaque fois que tous les facteurs MFA d'un utilisateur sont réinitialisés.
Imaginez maintenant la même attaque contre un agent IA. Il ne se fatigue pas, répond instantanément, et un attaquant peut essayer cinquante formulations en une heure. Si l'agent a une action "retirer le MFA" activée, l'une de ces formulations pourrait marcher. S'il n'a pas du tout cette action, aucune ne marchera. C'est la règle que j'écrirais dans la configuration de n'importe quel agent : l'IA peut démarrer une récupération, elle ne peut pas en terminer une risquée.
Les changements d'e-mail méritent leur propre avertissement. Un commentateur de Hacker News qui a exploité un site à fort trafic a listé ce que l'on évite en interdisant totalement les changements d'e-mail :
"Email change is one of the most abused recovery vectors in account takeover (ATO)."
Vous ne pouvez probablement pas interdire les changements d'e-mail, mais vous pouvez vous assurer qu'une IA n'en effectue jamais à partir d'une demande de chat. Si vos inquiétudes sur les hallucinations de l'IA portent sur les mauvaises réponses, voici la plus grande : une action qui sonne juste effectuée pour la mauvaise personne.
Comment l'IA doit-elle dialoguer avec votre système de connexion ?
Par un seul point d'accès étroit, sûr par conception, et non par un accès administrateur à votre base d'utilisateurs.
La plupart des fournisseurs d'identité ont déjà l'appel dont vous avez besoin, et c'est le plus banal : envoyer l'e-mail de réinitialisation standard à l'adresse enregistrée. J'ai consulté la documentation de quatre systèmes courants :
| Système de connexion | L'appel sûr à donner à une IA | L'appel risqué à garder hors de sa portée |
|---|---|---|
| Amazon Cognito | AdminResetUserPassword, qui envoie un code de réinitialisation comme le "mot de passe oublié" de l'utilisateur lui-même | AdminSetUserPassword, qui définit directement un mot de passe |
| Firebase Authentication | Générer un lien de réinitialisation de mot de passe et l'envoyer à l'adresse existante de l'utilisateur | Définir l'e-mail ou le mot de passe depuis le SDK admin sur demande |
| Auth0 | Déclencher l'e-mail standard de changement de mot de passe | Supprimer l'inscription MFA d'un utilisateur via la Management API, qu'Auth0 décrit comme équivalent à retirer son enregistrement MFA |
| Okta | Récupération en libre-service initiée par l'utilisateur | Réinitialiser tous les facteurs, la demande exacte du rapport d'incident d'Okta de 2023 |
Un détail utile sur Cognito : sa documentation dit que les messages de récupération ne vont qu'aux utilisateurs ayant un e-mail ou un téléphone vérifié. Si aucun n'est confirmé, un administrateur doit intervenir. C'est un cas naturel de la voie 2, et votre IA doit le dire clairement plutôt que de réessayer.
Si votre propre application a un bouton "mot de passe oublié", l'option la plus propre est souvent d'exposer la même chose comme un petit point d'accès interne : il prend un e-mail, envoie l'e-mail de réinitialisation normal si le compte existe et renvoie toujours la même réponse. Votre IA appelle celui-ci. Elle ne peut rien faire que votre page de connexion publique ne permette déjà à n'importe qui.
Comment configurer l'IA pour la récupération de compte dans votre helpdesk
Voici l'ordre dans lequel je le ferais. Les étapes 1 à 3 valent la peine même si vous ne laissez jamais l'IA effectuer d'action.
Étape 1 : comptez ce que vous recevez vraiment
Avant d'écrire une règle, étiquetez un mois de tickets par type de récupération : mot de passe oublié, bloqué, 2FA perdu, e-mail perdu, nouveau téléphone, soupçon de piratage et "pas vraiment un problème de connexion". L'étiquetage de tickets par IA peut le faire rétroactivement sur les tickets passés. La répartition décide de tout le reste. Une file composée à 90 % de mots de passe oubliés a besoin d'un point d'accès et d'une bonne réponse. Une file pleine de 2FA perdus a d'abord besoin d'un meilleur processus de vérification d'identité.
Étape 2 : écrivez les voies dans les consignes
Mettez les trois voies dans les consignes de l'agent en mots simples, avec des exemples de ce que les clients écrivent vraiment : "je n'arrive pas à entrer", "nouveau téléphone, authentificateur perdu", "je n'utilise plus cet e-mail", "quelqu'un a changé mon mot de passe". Ajoutez aussi les règles strictes : ne jamais confirmer si un compte existe, ne jamais coller un lien ou un code dans le chat, ne jamais modifier les coordonnées sur demande. Dans eesel, les consignes sont du texte brut que vous modifiez, et l'agent peut les resserrer quand vous le corrigez dans le chat, comme l'expliquent les documents sur les consignes.
Étape 3 : donnez-lui le contexte du compte
Connectez tout ce qui dit à l'IA qui est cette personne : votre système d'abonnement ou de facturation, votre CRM, la fiche client de votre helpdesk. C'est la leçon de MentorShow. La moitié des tickets "je n'arrive pas à me connecter" sont des offres expirées, le mauvais produit ou un portail que vous n'exploitez même pas. XAP a constaté la même chose : certains étudiants qui n'arrivent pas à se connecter sont sur le portail propre d'une université, que XAP n'exploite pas, donc la bonne réponse est une réorientation, pas une réinitialisation.
Étape 4 : connectez un point d'accès sûr
Donnez à l'agent l'unique appel de réinitialisation de la section ci-dessus, et rien d'autre qui touche à la connexion. Dans eesel, c'est Network Access : vous autorisez un domaine, ajoutez l'en-tête d'authentification dans les paramètres et l'agent peut l'appeler. Les requêtes vers tout autre domaine sont refusées.
Ce qui compte pour la récupération, c'est la ligne en haut de cet écran : les identifiants sont stockés comme en-têtes et ne sont pas montrés à l'IA. La clé capable de déclencher des réinitialisations ne se trouve jamais dans un prompt, donc on ne peut pas la soutirer à l'agent par la conversation. Vos développeurs peuvent aussi le configurer depuis un terminal. La CLI d'eesel exécute le même agent et le même espace de travail que le tableau de bord, donc un ingénieur, un script ou un agent de code comme Claude Code ou Cursor peut brancher le point d'accès, modifier les consignes de récupération et tester l'agent sans ouvrir le navigateur.
Étape 5 : exigez une approbation pour toute action du helpdesk qui touche à l'identité
Chaque action qu'un agent eesel peut effectuer est réglée, par agent, pour s'exécuter seule, demander d'abord ou rester désactivée. Les documents sur les actions et approbations recommandent de démarrer en supervisé, avec les réponses et tout ce qui est irréversible sous approbation.
Pour la récupération, je laisserais l'étiquetage et les notes internes tourner seuls dès le premier jour, et je mettrais les réponses publiques sous approbation pendant la première ou la deuxième semaine. Vous pouvez aussi retenir un type de cas même quand les réponses sont activées : une consigne comme "demande avant de répondre à tout ce qui concerne le 2FA ou un changement d'e-mail" fait s'arrêter l'agent pour ces seuls cas.
Étape 6 : acheminez les voies 2 et 3 vers des personnes nommées
La voie 2 va à celui qui peut mener votre vérification d'identité, généralement un agent senior ou le niveau 2. La voie 3 va à la sécurité, nommément, avec une étiquette urgent et un SLA court. Une IA peut acheminer par étiquette instantanément ; elle ne peut pas corriger une règle d'acheminement qui pointe vers une boîte partagée que personne ne surveille le week-end. Si votre équipe de niveau 2 est petite, faites écrire la note interne par l'IA pour qu'elle démarre avec les faits du compte.
Étape 7 : testez-le sur vos anciens tickets de connexion
Faites tourner l'agent sur les tickets de récupération que vous avez déjà traités avant qu'il ne touche à un ticket réel. A-t-il envoyé des liens de réinitialisation uniquement dans la voie 1 ? A-t-il jamais confirmé qu'un e-mail avait un compte ? A-t-il repéré le piratage caché dans une plainte de facturation furieuse ? Une simulation sur des tickets passés y répond en un après-midi, et c'est l'étape que je ne sauterais jamais pour ce type de ticket.
Dans quelle voie ce ticket va-t-il ?
Choisissez un type de demande pour voir qui la traite, ce que fait l'IA et la règle qui la sous-tend.
Comment mesurer si cela fonctionne ?
Suivez la rapidité et la sécurité côte à côte. Une configuration de récupération rapide mais qui livre parfois un compte est pire que pas d'IA du tout.
- Part des tickets de récupération fermés par l'IA. Elle devrait correspondre à peu près à votre part de la voie 1 de l'étape 1. Si elle est bien plus élevée, l'IA ferme des tickets qu'elle ne devrait pas.
- Délai de première réponse dans la voie 1. Les clients bloqués ressentent chaque minute. C'est le chiffre qui devrait le plus baisser.
- Délai de réponse de la voie 3. Un piratage resté six heures dans une file est l'échec qui finit en gros titre. Surveillez-le dans vos rapports de SLA.
- Réponses "ce n'était pas moi" aux notifications de récupération. Chacune est une récupération que quelqu'un n'a pas demandée. Lisez-les toutes.
- Contacts répétés sous 7 jours. Si le même client revient, le lien de réinitialisation ne lui est pas parvenu ou la réponse a manqué le vrai problème.
Le guide sur le reporting du support par IA montre comment les construire à partir de tickets étiquetés.
Erreurs courantes avec l'IA et la récupération de compte
Voici celles que je surveillerais durant le premier mois :
- Laisser l'IA confirmer que le compte existe. "J'ai trouvé votre compte, j'envoie un lien" semble utile et dit à un attaquant quels e-mails sont des clients. Utilisez la même réponse dans les deux cas.
- Traiter les détails du chat comme une preuve. Nom, adresse, quatre derniers chiffres, date de naissance : tout est dans la fuite de données de quelqu'un. La CISA note que les attaquants rassemblent exactement cela avant d'appeler.
- Coller un lien ou un code dans la conversation. Le chat est le seul canal auquel vous ne pouvez pas faire confiance dans un cas de récupération. Les codes vont à l'adresse enregistrée.
- Donner à l'IA des clés d'API administrateur "au cas où plus tard". Si la clé peut retirer le MFA, partez du principe qu'un jour quelqu'un convaincra l'agent d'essayer. Donnez-lui l'unique appel dont il a besoin.
- Sauter la notification. Chaque récupération doit prévenir l'ancienne adresse. C'est l'alarme de piratage la moins chère que vous mettrez en place.
- Oublier l'autre connexion. La file de XAP l'a montré : parfois, le portail auquel l'étudiant n'accède pas n'est pas le vôtre. Une réorientation vaut mieux qu'un lien de réinitialisation.
Si vous voulez une vue d'ensemble de la façon dont un déploiement comme celui-ci passe du supervisé à l'autonome, l'article sur le calendrier de mise en œuvre détaille le curseur.
Essayez eesel pour les tickets de récupération de compte
eesel rejoint votre helpdesk comme coéquipier IA pour le support. Sur les tickets de connexion, il lit chacun avec le contexte de compte du client, ne déclenche que l'appel de réinitialisation que vous autorisez, répond de la même façon que le compte existe ou non, et retient pour votre équipe les changements de 2FA, les échanges d'e-mail et tout ce qui ressemble à un piratage. Il fonctionne dans Zendesk, HubSpot et les autres grands helpdesks, et sur Freshdesk via l'intégration Freshdesk.
Les approbations arrivent là où votre équipe travaille déjà : le tableau de bord, un fil Slack ou un lien dans la note du helpdesk, et chaque approbation enregistre qui a décidé et quand. Vos clés d'API restent dans les paramètres, jamais à la vue de l'IA, et eesel n'utilise jamais vos données pour entraîner les modèles sous-jacents, selon son Trust Center. Une lacune honnête : l'audit SOC 2 Type II d'eesel est encore en cours, donc si votre équipe de sécurité a besoin du rapport en main aujourd'hui, demandez d'abord l'état actuel ; ma liste de contrôle de la sécurité des fournisseurs explique ce qu'il faut demander à la place.
XAP est un bon modèle pour commencer petit. Un filtre devant son agent eesel ne laisse passer que les cas de réorientation et les réinitialisations de mot de passe du portail, rien n'arrive à un étudiant sans qu'une personne l'envoie, et les suppressions de compte restent à l'équipe. Commencez là, mesurez pendant un mois, puis ouvrez la voie 1. Vous pouvez essayer eesel gratuitement pendant 7 jours avec 100 crédits.
Comment le support doit-il vérifier l'identité pour la récupération de compte ?