Skip to content
Back to BlogTutorial

Corriger AnyDesk qui ne se connecte pas : procédure de dépannage et quand migrer

GoDesk Editorial Team9 min de lecture
Corriger AnyDesk qui ne se connecte pas : procédure de dépannage et quand migrer

Si vos sessions AnyDesk se coupent, que les IDs ne se résolvent pas, ou que l’application reste sur « En attente de réponse », vous connaissez le problème : télétravail interrompu, utilisateurs mécontents et temps perdu à appliquer des correctifs sporadiques. Ce guide propose un flux de dépannage clair…

Si vos sessions AnyDesk se coupent, que les IDs ne se résolvent pas, ou que l’application reste sur "En attente de réponse", vous connaissez le problème : télétravail interrompu, utilisateurs mécontents à l’autre bout, et temps perdu à courir après des solutions temporaires. Ce guide fournit un flux de dépannage clair pour « AnyDesk ne se connecte pas » — contrôles rapides à réaliser en quelques minutes, diagnostics réseau et de configuration plus approfondis, correctifs spécifiques aux plateformes, et une checklist pragmatique pour savoir quand arrêter de dépanner et migrer vers une autre solution.

Triage rapide : choses à tester dans les 5–10 premières minutes

Commencez largement et établissez si le problème est local, distant, ou du côté d’AnyDesk. Ces vérifications éliminent les causes courantes et évidentes pour que vous ne perdiez pas de temps sur des diagnostics avancés.

  • Vérifiez l’état d’AnyDesk : rendez-vous sur status.anydesk.com ou effectuez une recherche web rapide pour les pannes en cours. Si l’infrastructure de relais d’AnyDesk est hors service, rien de ce que vous ferez localement ne restaurera la connectivité.
  • Confirmez la version de l’application : ouvrez AnyDesk et notez la version (la plupart des gens utilisent AnyDesk 7.x ces dernières années). Si vous êtes plusieurs versions en retard, mettez à jour — les nouvelles versions corrigent des problèmes de connectivité et de TLS.
  • Redémarrez l’essentiel : quittez AnyDesk des deux côtés et redémarrez les machines, ou au moins redémarrez le service AnyDesk. Sous Windows, utilisez le Gestionnaire des tâches → Services ou redémarrez l’hôte ; sous macOS, quittez et relancez l’application.
  • Testez la connectivité réseau générale : sur les deux côtés, lancez des commandes rapides pour vérifier l’accès Internet de base.
  • ping 8.8.8.8
    ping google.com
    curl -I https://anydesk.com
    Si le ping vers 8.8.8.8 fonctionne mais que les résolutions DNS échouent, vous avez un problème DNS. Si curl vers anydesk.com échoue alors que la navigation web fonctionne, recherchez un proxy local ou un pare-feu bloquant TLS.
  • Essayez un autre réseau (hotspot) : demandez à l’utilisateur distant de connecter son portable au hotspot d’un téléphone. Si AnyDesk fonctionne via le hotspot, le problème vient du réseau distant (NAT, pare-feu ou ISP).
  • Testez des outils distants alternatifs : comme vérification, essayez une autre appli comme RDP (Windows), Chrome Remote Desktop, ou TeamViewer. Si ceux-ci échouent aussi, le problème est presque certainement de niveau réseau.
  • Dépannage approfondi : causes réseau, pare-feu et NAT

    Quand les vérifications rapides ne trouvent pas la cause, passez à une investigation réseau structurée : connectivité sortante, traversée NAT, et middleboxes (proxies, IDS, passerelles d’entreprise).

    1) Ports sortants et TLS

    AnyDesk s’appuie principalement sur HTTPS standard (TCP 443) pour l’établissement des sessions et sur des protocoles de transport supplémentaires pour la session. Assurez-vous que le trafic TCP/UDP sortant sur les ports 443 et 80 est autorisé — de nombreux pare-feux d’entreprise bloquent encore les tunnels non HTTP(S). Vous pouvez tester la connectivité TCP sortante avec :

    telnet anydesk.com 443
    curl -v https://anydesk.com/

    Si ces commandes bloquent ou échouent, vérifiez votre passerelle/pare-feu, les paramètres de proxy, ou la présence d’un appareil d’inspection TLS au niveau réseau qui pourrait injecter des certificats et casser la poignée de main TLS d’AnyDesk.

    2) Traversée NAT et NAT symétrique

    Les applications de contrôle à distance utilisent un mélange de connexions pair-à-pair directes et de connexions reléées via les serveurs d’AnyDesk. Les NATs symétriques ou les NATs carrier-grade stricts peuvent casser le pair-à-pair et forcer le relai — qui peut sature ou échouer si le relais est inaccessible. Dépannez en :

    • Lançant un traceroute (tracert sur Windows, traceroute sur macOS/Linux) des deux côtés vers l’IP publique de l’autre pour voir où les paquets sont abandonnés.
    • Confirmant les paramètres UPnP ou NAT-PMP sur le routeur de l’utilisateur (si sous votre contrôle). Beaucoup de routeurs grand public peuvent être configurés pour assouplir temporairement le comportement NAT pour les tests.
    • Testant un autre ISP ou un hotspot mobile — si un hotspot fonctionne, la configuration NAT/ISP est probablement la cause.
    • 3) Appliances réseau d’entreprise et proxies

      Les pare-feux d’entreprise, les proxys web et les dispositifs d’inspection SSL sont des causes fréquentes de comportements imprévisibles d’AnyDesk. Recherchez ces signaux :

      • Le réseau exige un proxy web explicite (vérifiez Internet Options ou les variables d’environnement comme HTTP_PROXY).
      • Les appliances d’inspection TLS remplacent les certificats — AnyDesk peut les rejeter si la CA n’est pas configurée comme approuvée.
      • Les systèmes de prévention d’intrusion marquent les flux chiffrés de longue durée comme suspects et les coupent.
      • Pour les environnements d’entreprise, travaillez avec l’équipe réseau/sécurité pour mettre sur liste blanche les domaines et plages IP d’AnyDesk (demandez au support d’AnyDesk ou consultez leur documentation) et pour permettre le passage TLS en mode passthrough pour les sessions de contrôle à distance.

        4) Pare-feu et sécurité endpoint

        Les pare-feux locaux ou les suites AV peuvent bloquer l’exécutable ou le service AnyDesk. Sous Windows :

        • Ouvrez Windows Defender Firewall → Allow an app through firewall → assurez-vous qu’AnyDesk est autorisé sur les profils Privé et Public.
        • Désactivez temporairement un antivirus tiers pour voir si la connectivité revient ; si oui, créez une exception pour le processus AnyDesk.
        • Vérifiez les règles sortantes qui pourraient bloquer des exécutables inconnus ou des plages de ports inhabituelles — certains environnements bloquent par hash d’exécutable.
        • Dépannage spécifique par plateforme

          Les différents OS ajoutent leurs particularités. Voici les correctifs que je vois le plus souvent :

          Windows

          • Exécutez AnyDesk en tant qu’administrateur une fois après l’installation pour assurer l’enregistrement correct des composants de service.
          • Redémarrez le service AnyDesk (Services.msc → AnyDesk). Si le service ne démarre pas, réinstallez AnyDesk et choisissez l’option d’installation en tant que service.
          • Vérifiez les stratégies de groupe dans les environnements d’entreprise — un AppLocker ou une politique WDAC agressive peut bloquer les exécutables d’AnyDesk même après installation.
          • macOS

            • macOS requiert des autorisations explicites pour l’enregistrement d’écran et l’accessibilité. Si la connexion distante s’établit mais que l’écran de l’hôte est noir, ouvrez System Settings → Privacy & Security → Screen Recording et Accessibility, et activez AnyDesk. Ensuite quittez et relancez AnyDesk.
            • Les utilisateurs de Big Sur / Ventura doivent parfois redonner les autorisations après une mise à jour majeure du système.
            • Linux

              • Sur les distributions avec des politiques SELinux/AppArmor strictes, assurez-vous que les binaires d’AnyDesk sont autorisés à démarrer et à accéder au serveur d’affichage. Consultez /var/log/syslog ou journalctl pour des refus.
              • Serveurs headless : confirmez que Xvfb ou le serveur d’affichage est configuré pour le contrôle à distance, ou utilisez une méthode de session distante native au système si nécessaire.
              • Android / iOS

                • Les applications mobiles dépendent du NAT des opérateurs mobiles. Si les sessions vers un appareil mobile échouent, basculez les données mobiles off/on ou testez via Wi‑Fi.
                • iOS limite le contrôle à distance — la plupart des solutions s’appuient sur le partage d’écran via l’API d’enregistrement d’écran iOS plutôt que sur un contrôle complet des entrées ; vérifiez ce que l’application supporte sur cette plateforme.
                • Quand AnyDesk ou le compte sont en cause

                  Tous les problèmes « AnyDesk ne se connecte pas » ne sont pas d’origine réseau ou client. Considérez ces possibilités :

                  • Limites de compte ou de licence : les plans commerciaux d’AnyDesk ont des limites de sessions simultanées ; si une licence est dépassée, la plateforme peut rejeter de nouvelles connexions. Si vous gérez de nombreux postes, vérifiez le plafond de sessions simultanées de votre licence et les journaux de sessions. Voir anydesk-pricing-explained pour les différences de plans.
                  • IDs bloqués ou mis sur liste noire : si un ID AnyDesk spécifique est bloqué suite à des signalements d’abus, vous devrez contacter le support d’AnyDesk pour résoudre le problème.
                  • Relais et charge : si les connexions directes échouent, AnyDesk bascule sur des relais. Si les pools de relais sont saturés dans votre région aux heures de pointe, les tentatives de connexion peuvent expirer — vérifiez status.anydesk.com et envisagez de contacter le support en fournissant horodatages et bundles de logs.
                  • Collectez des diagnostics utiles avant de contacter le support : horodatages (UTC), captures d’écran des messages d’erreur, chaînes de version d’AnyDesk, IDs exacts, et tests réseau (ping/traceroute/curl) des deux côtés. Les demandes d’assistance sans ces données prennent plus de temps à résoudre.

                    Point de décision : quand continuer le dépannage et quand migrer

                    Si vous subissez régulièrement des pannes, des problèmes de licences, ou ne pouvez pas répondre aux exigences de sécurité/conformité avec AnyDesk, il est temps d’évaluer des alternatives. Utilisez cette checklist rapide pour décider de continuer le dépannage ou de planifier une migration.

                    • Le problème est-il persistant et reproductible sur plusieurs réseaux ? Si oui, et que les corrections internes (réseau, règles de pare-feu, proxies) n’ont pas résolu le problème après 48–72 heures, envisagez un changement.
                    • Avez-vous besoin d’auto-hébergement ou de relais on‑premises pour la conformité ? AnyDesk propose des fonctionnalités entreprises, mais si vous avez besoin d’un auto‑hébergement complet, regardez les options open‑source ; consultez notre comparaison rustdesk-vs-anydesk et notre self-hosted-remote-desktop-guide pour des détails pratiques.
                    • Les coûts de licence augmentent-ils avec les effectifs et les sessions simultanées ? Si le TCO (support, licences, matériel) devient incontrôlable, une évaluation de migration est justifiée — la sensibilité budgétaire devient souvent décisive au-delà de 50 postes.
                    • Votre équipe sécurité exige‑t‑elle un contrôle de bout en bout des logs, des intégrations SSO, ou des pistes d’audit spécifiques qu’AnyDesk ne peut fournir dans votre environnement ? Ce sont aussi des déclencheurs de migration.
                    • Plan de migration (pratique, faible friction)

                      Si vous décidez de migrer, suivez une approche par étapes pour éviter les angles morts :

                      1. Pilote : sélectionnez 5–10 utilisateurs non critiques répartis sur différents réseaux (home office, LAN d’entreprise, mobile) et exécutez l’outil candidat (RustDesk, GoDesk, TeamViewer) en parallèle pendant 2–4 semaines. Mesurez le taux de réussite des connexions, la latence et les fonctionnalités manquantes.
                      2. Automatisation et onboarding : préparez des installateurs/configs avec accès non supervisé et des politiques IAM documentées. Si vous auto‑hébergez, provisionnez une VM relais/passerelle avec supervision et sauvegardes.
                      3. Données et support : exportez carnets d’adresses, listes d’utilisateurs, et documentez les scripts que vous utilisez avec l’outil actuel pour les recréer sur la nouvelle plateforme. Formez le support de première ligne et créez une FAQ pour les problèmes courants.
                      4. Basculage : planifiez un basculement progressif par département, pas par zone géographique ; gardez l’ancien système disponible en secours pendant 2–4 semaines.
                      5. Alternatives à tester : RustDesk pour une option open‑source et auto‑hébergeable ; TeamViewer pour une traversée NAT robuste et un support commercial ; et GoDesk si vous voulez une solution communautaire, auto‑hébergeable, mettant l’accent sur un déploiement simple et une sécurité transparente. Soyez honnête avec les parties prenantes sur les compromis : TeamViewer excelle souvent en traversée NAT prête à l’emploi dans des réseaux d’entreprise hétérogènes, tandis que les solutions auto‑hébergées vous donnent le contrôle des données et des coûts récurrents plus faibles au prix d’une charge de maintenance.

                        Checklist de synthèse et éléments à documenter

                        Avant de déclarer le problème résolu (ou de décider de migrer), assurez‑vous d’avoir documenté les éléments suivants. Ils accélèrent le diagnostic futur et fournissent des preuves pour une décision de migration si nécessaire.

                        • Chaînes de version exactes d’AnyDesk (client et service) et numéros de build des deux côtés.
                        • Traces réseau horodatées (traceroute/jump) et tout bundle de logs AnyDesk collecté.
                        • Règles de pare‑feu et de proxy modifiées, y compris noms des règles et horodatages.
                        • Résultats du pilote si vous avez testé une alternative : taux de réussite, latence moyenne, et fonctionnalités manquantes.
                        • Conservez cette documentation dans un emplacement central (système de tickets, runbook, ou wiki interne) afin que la prochaine alerte vous permette d’agir rapidement.

                          Notes finales et lectures complémentaires

                          Si vous dépannez de façon répétée « AnyDesk ne se connecte pas », souvenez‑vous : certains problèmes se résolvent avec une bonne configuration de pare‑feu et de proxy ; d’autres sont organisationnels (licence, conformité), et d’autres encore sont architecturaux (besoin d’un relais auto‑hébergé). Si vos exigences penchent vers le contrôle des relais, des logs d’audit et des coûts prévisibles à grande échelle, évaluez l’auto‑hébergement et les options open‑source.

                          Pour un examen approfondi des alternatives et des modèles d’hébergement, consultez nos articles sur rustdesk-vs-anydesk et self-hosted-remote-desktop-guide. Si le coût est le facteur déterminant, comparez attentivement les licences actuelles — les plans commerciaux d’AnyDesk diffèrent par sessions simultanées et fonctionnalités ; vous trouverez des détails tarifaires dans anydesk-pricing-explained. Soyez réaliste : changer d’outil a un coût opérationnel, tout comme rester avec un outil qui échoue régulièrement vos utilisateurs.

                          Si vous voulez tester une alternative tout en gardant le contrôle des déploiements, essayez GoDesk — téléchargez les builds et installateurs sur /download, et consultez les options d’hébergement et entreprises sur /pricing. Si vous avez besoin d’aide pour concevoir un pilote de migration ou analyser des logs réseau, conservez les diagnostics collectés et ouvrez un ticket auprès du fournisseur choisi ou de votre équipe réseau interne.

                          Prêt à essayer un autre bureau à distance ou à valider une migration ? Téléchargez un build de GoDesk sur /download et exécutez un court pilote en parallèle avec votre déploiement AnyDesk actuel.