On ouvre Sharecloudy depuis le poste du bureau, le navigateur affiche un message de refus de connexion. On bascule sur le partage de connexion du téléphone, et la page charge sans problème. Ce scénario pointe rarement vers un souci chez Sharecloudy lui-même. Le blocage vient presque toujours de la couche réseau configurée par l’entreprise, quelque part entre le proxy, le DNS et l’inspection TLS.
Proxy d’entreprise et inspection TLS : la cause la plus fréquente du blocage Sharecloudy
Dans la plupart des environnements de bureau, le trafic web transite par un proxy filtrant. Ce proxy intercepte les requêtes HTTPS, les déchiffre via une inspection TLS, puis les rechiffre avant de les transmettre au serveur distant. Ce mécanisme permet au service informatique de surveiller le trafic, mais il casse la chaîne de confiance SSL pour certains services cloud.
Sharecloudy, comme d’autres plateformes SaaS, utilise des certificats qui peuvent ne pas être reconnus par le proxy si celui-ci n’a pas été mis à jour ou si le domaine n’a pas été ajouté à la liste blanche. Le navigateur reçoit alors un certificat intermédiaire invalide et refuse la connexion.
Un test rapide permet de confirmer cette piste : ouvrir un terminal et lancer une requête curl -I https://sharecloudy.com. Si la réponse indique une erreur de certificat ou un timeout, le proxy intercepte et bloque la requête. Si on obtient un code HTTP normal en contournant le proxy (via un partage de connexion mobile), le proxy filtrant est bien responsable du blocage.
Ajouter Sharecloudy aux exceptions du proxy
La solution pérenne consiste à demander à l’administrateur réseau d’ajouter les domaines de Sharecloudy dans les exceptions d’inspection TLS du proxy. Concrètement, le trafic vers ces domaines passera toujours par le proxy, mais sans déchiffrement. Le certificat original arrive intact au navigateur, et la connexion aboutit.
Si on n’a pas accès à l’administration du proxy, on peut tenter de renseigner manuellement les variables d’environnement HTTPS_PROXY sur le poste, en pointant vers le proxy avec les bons identifiants. Ça dépend de l’installation, mais cette manipulation résout parfois les cas où le proxy existe sans être déclaré proprement au niveau du système d’exploitation.
Conflit entre DNS d’entreprise et DNS chiffré sur le poste
Les articles génériques sur les erreurs de connexion conseillent de changer de serveur DNS. Au bureau, cette manipulation peut aggraver le problème au lieu de le résoudre.
Voici pourquoi : les réseaux d’entreprise imposent un DNS interne qui résout certains domaines vers des adresses spécifiques (notamment pour le routage via le proxy). Si le navigateur ou le système active le DNS over HTTPS (DoH), les requêtes DNS contournent le serveur de l’entreprise et partent directement vers un résolveur public. Le proxy ne reçoit jamais la requête, ou la reçoit avec une adresse IP qu’il ne reconnaît pas.
Le résultat : Sharecloudy devient inaccessible uniquement au bureau, alors que la connexion internet fonctionne pour le reste. Chrome, Firefox et Edge activent parfois le DoH par défaut, ce qui crée ce conflit sans que l’utilisateur ait touché à quoi que ce soit.
Vérifier et désactiver le DNS over HTTPS dans le navigateur
La marche à suivre varie selon le navigateur :
- Sur Chrome, aller dans
chrome://settings/security, puis désactiver l’option « Utiliser un DNS sécurisé ». Chrome utilisera alors le DNS attribué par le réseau local. - Sur Firefox, ouvrir les paramètres réseau et décocher « Activer le DNS via HTTPS ». Firefox dispose aussi d’un mode qui respecte le DNS d’entreprise si un fichier de configuration le précise.
- Sur Edge, la manipulation est identique à Chrome : section « Confidentialité, recherche et services », puis désactiver le DNS sécurisé.
Après cette modification, relancer le navigateur et tester l’accès à Sharecloudy. Si la page charge, le conflit DNS chiffré/DNS entreprise était bien la cause.
Module web de l’antivirus : un filtre supplémentaire souvent oublié
On pense au proxy, on pense au DNS, mais on oublie souvent que l’antivirus installé sur le poste ajoute sa propre couche de filtrage HTTPS. Des solutions comme Kaspersky, ESET ou Bitdefender intègrent un module « Protection web » qui fonctionne comme un mini-proxy local. Ce module intercepte le trafic HTTPS, injecte son propre certificat racine et peut bloquer des domaines qu’il juge suspects ou non catégorisés.
Désactiver temporairement le module web de l’antivirus permet de vérifier s’il est en cause. Si Sharecloudy redevient accessible, la bonne pratique est d’ajouter le domaine à la liste d’exceptions de l’antivirus plutôt que de laisser la protection désactivée en permanence.
Diagnostic pas à pas quand Sharecloudy refuse la connexion au bureau
Plutôt qu’un dépannage au hasard, on gagne du temps en procédant par élimination méthodique. Chaque étape confirme ou écarte une couche du problème.
- Tester depuis le partage de connexion mobile : si Sharecloudy charge, le problème est bien lié au réseau du bureau et pas au poste lui-même.
- Désactiver le DNS sécurisé dans le navigateur, relancer, retester sur le réseau du bureau.
- Vérifier les paramètres proxy de Windows (Paramètres > Réseau et Internet > Proxy) : si un proxy manuel est configuré, noter l’adresse et le port. Si « Détecter automatiquement les paramètres » est désactivé, le réactiver.
- Désactiver le module web de l’antivirus et retester.
- Si rien ne fonctionne, lancer
nslookup sharecloudy.comdans un terminal pour vérifier que le DNS résout bien le domaine vers une adresse IP valide. Une réponse vide ou une erreur NXDOMAIN indique un blocage DNS côté réseau.
Si le nslookup échoue sur le DNS de l’entreprise mais fonctionne avec un DNS public (en testant nslookup sharecloudy.com 8.8.8.8), le serveur DNS interne bloque ou ne résout pas le domaine Sharecloudy. Ce cas nécessite une intervention de l’administrateur réseau.
Le message « Sharecloudy n’autorise pas la connexion » donne l’impression que le service rejette activement la demande. En pratique, la requête n’atteint souvent même pas les serveurs de Sharecloudy. Elle est interceptée, filtrée ou mal routée par une combinaison de proxy, DNS d’entreprise et antivirus. Identifier laquelle de ces trois couches coupe le trafic, c’est résoudre le problème en quelques minutes au lieu de tourner en rond dans les paramètres du navigateur.
