Quand l’intranet Inetum affiche une page blanche ou un délai d’attente dépassé, le premier réflexe est souvent d’appeler le support. La plupart des cas d’inaccessibilité se résolvent par des vérifications côté utilisateur, sans mobiliser l’équipe technique. Cet article passe en revue les points de contrôle à mener soi-même pour qualifier le problème et, si le ticket reste nécessaire, le formuler de façon exploitable.
Accès réseau et VPN : le premier filtre à vérifier sur un intranet Inetum
Un intranet d’entreprise comme celui d’Inetum est généralement accessible uniquement depuis le réseau interne ou via un tunnel VPN. Si vous travaillez à distance, la connexion VPN peut avoir expiré, être mal configurée ou simplement désactivée après une mise en veille prolongée.
Avant de conclure à une panne de la plateforme, testez un site externe (un moteur de recherche, par exemple). Si ce site s’affiche normalement, le problème ne vient pas de votre connexion Internet mais probablement du lien entre votre poste et le réseau d’entreprise.
| Symptôme observé | Cause probable | Vérification à mener |
|---|---|---|
| Page blanche, délai dépassé | VPN déconnecté ou expiré | Relancer le client VPN, vérifier le statut de connexion |
| Erreur « DNS introuvable » | Résolution DNS interne absente | Tester un ping vers l’adresse interne de l’intranet |
| Page accessible puis coupure | Session VPN instable | Contrôler la stabilité du réseau Wi-Fi ou filaire |
| Accès OK sur un autre poste | Configuration locale du poste | Comparer les paramètres proxy et réseau |
Ce tableau couvre la majorité des situations rencontrées en télétravail. Un VPN expiré est la première cause d’inaccessibilité intranet à distance. Si vous êtes sur site et branché au réseau local, passez directement à l’étape suivante.
Cache navigateur et paramètres proxy : les blocages invisibles
Un cache corrompu peut empêcher le navigateur de charger la version actuelle de l’intranet Inetum. Le symptôme typique : la page reste figée sur un état antérieur ou affiche une erreur alors que d’autres collègues y accèdent sans difficulté.
Videz le cache et les cookies du navigateur, puis relancez-le. Sur la plupart des navigateurs, le raccourci Ctrl+Maj+Suppr ouvre directement le panneau de nettoyage.
Proxy d’entreprise et extensions de navigateur
Les postes gérés par la DSI utilisent souvent un proxy pour filtrer le trafic. Une mauvaise configuration proxy (fréquente après une mise à jour système ou un changement de profil réseau) redirige les requêtes vers un serveur qui ne répond pas.
- Vérifiez les paramètres proxy dans les réglages réseau du système d’exploitation, pas uniquement dans le navigateur. Une incohérence entre les deux provoque des blocages silencieux.
- Désactivez temporairement les extensions de navigateur (bloqueurs de publicité, VPN intégrés, gestionnaires de mots de passe tiers) qui peuvent interférer avec l’authentification SSO de l’intranet.
- Testez l’accès dans une fenêtre de navigation privée : si l’intranet s’affiche en navigation privée, le problème vient du profil navigateur, pas de la plateforme.
Tester depuis un autre poste ou appareil pour isoler la panne
Une vérification que beaucoup d’utilisateurs sautent : essayer d’ouvrir l’intranet Inetum depuis un autre appareil connecté au même réseau. Un smartphone sur le Wi-Fi d’entreprise ou le poste d’un collègue suffit.
Si l’intranet fonctionne ailleurs, le problème est local. Si personne dans l’équipe n’y accède, l’incident est probablement côté serveur ou infrastructure, et le signalement au support devient pertinent.
Isoler le périmètre de la panne détermine la priorité du ticket. Un incident limité à un poste ne sera pas traité avec la même urgence qu’une indisponibilité touchant un service entier.
Classifier la gravité de l’incident avant de contacter le support Inetum
Ouvrir un ticket en indiquant simplement « l’intranet ne marche plus » ralentit le traitement. Les équipes support priorisent les incidents selon leur impact métier, pas selon le ressenti individuel. Qualifier la gravité en amont change la vitesse de prise en charge.
Trois niveaux de gravité permettent de structurer la demande :
- Critique : l’accès est impossible pour plusieurs équipes et bloque des processus clés (RH, finances, production). Ce niveau justifie une alerte immédiate.
- Majeur : un ralentissement ou une intermittence affecte un département ou une fonction, sans arrêt total de l’activité.
- Mineur : le problème est limité à un seul utilisateur ou à des fonctionnalités non critiques de l’intranet.
Un incident classé « mineur » après vos propres vérifications (VPN OK, cache vidé, problème reproduit uniquement sur votre poste) sera traité différemment d’un incident « critique » confirmé par plusieurs collaborateurs.
Rédiger un ticket exploitable pour le support informatique
La qualité du signalement conditionne la rapidité de résolution. Un ticket bien rédigé évite les allers-retours et permet au technicien de reproduire le problème sans vous recontacter.
Les éléments à inclure dans chaque signalement
Mentionnez le navigateur utilisé et sa version, le système d’exploitation, le type de connexion (réseau local, Wi-Fi, VPN) et l’heure exacte du premier dysfonctionnement. Joindre une capture d’écran du message d’erreur divise le temps de diagnostic.
Précisez aussi les vérifications déjà effectuées : cache vidé, test en navigation privée, essai depuis un autre poste. Cette information évite que le support vous demande de refaire exactement ces étapes.
Ce que le support ne peut pas deviner
Un détail souvent omis : avez-vous changé quelque chose récemment ? Mise à jour du système, nouveau logiciel installé, modification du mot de passe réseau. Un changement de mot de passe Active Directory non propagé au VPN bloque l’intranet sans message d’erreur explicite.
Signalez également si le problème est apparu après un redémarrage, une mise à jour Windows ou un déplacement géographique. Ces contextes orientent le diagnostic vers des pistes précises.
L’ensemble de ces vérifications prend une dizaine de minutes. Dans la majorité des cas, le problème se résout avant même la rédaction du ticket. Quand le signalement reste nécessaire, un ticket structuré avec le niveau de gravité, les tests déjà menés et une capture d’écran donne au support Inetum les éléments pour intervenir dès la première lecture.
