Wat.erp, l’ERP métier édité par Somei pour les distributeurs d’eau et les opérateurs d’assainissement, centralise la gestion clientèle, la facturation et le suivi technique sur une même plateforme. L’accès à l’interface web pose régulièrement des difficultés liées au navigateur, aux identifiants ou à la configuration réseau. Nous détaillons ici les points de blocage les plus fréquents et les manipulations concrètes pour rétablir la connexion WATERP rapidement.
Certificat SSL et compatibilité navigateur sur Wat.erp
La majorité des échecs de connexion WATERP que nous rencontrons en exploitation proviennent d’un problème de certificat ou d’un navigateur obsolète. Wat.erp s’appuie sur une connexion HTTPS avec un certificat propre à l’infrastructure de l’opérateur.
A lire aussi : Entreprises : Liste des entreprises de qualité en un clin d'œil
Quand le navigateur affiche un avertissement de sécurité ou refuse d’ouvrir la page, le réflexe consiste à vérifier trois éléments avant toute autre manipulation.
- La date et l’heure du poste de travail : un décalage de quelques minutes suffit à invalider le certificat SSL et provoque une erreur de connexion silencieuse.
- La version du navigateur : les versions antérieures à Chrome 90 ou Firefox 78 ESR ne prennent pas en charge certains algorithmes de chiffrement récents. Mettre à jour le navigateur résout le problème dans la plupart des cas.
- Le cache SSL du système : sous Windows, la commande certutil -urlcache * delete purge le cache de certificats et force le navigateur à revalider la chaîne de confiance au prochain chargement.
Si l’avertissement persiste après ces vérifications, le certificat côté serveur a probablement expiré. Dans ce cas, seul l’administrateur de la plateforme (souvent le service SI de la régie ou du délégataire) peut le renouveler.
A voir aussi : Durée moyenne d'une réunion professionnelle : astuces pour gagner en efficacité
Erreur d’identifiants et verrouillage de compte sur la plateforme WATERP
Wat.erp applique une politique de verrouillage après plusieurs tentatives échouées. Le seuil exact dépend du paramétrage défini par l’exploitant, mais nous observons qu’il se situe généralement entre trois et cinq essais consécutifs.
Un compte verrouillé ne génère pas toujours un message explicite. L’interface peut simplement réafficher le formulaire de connexion sans indication d’erreur. Avant de multiplier les tentatives, vérifiez que le verrouillage n’est pas déjà actif en contactant votre administrateur applicatif.
Réinitialiser le mot de passe Wat.erp
La procédure dépend de l’architecture déployée. Sur les instances couplées à un annuaire LDAP ou Active Directory, la réinitialisation passe par l’outil de gestion de mots de passe de l’entreprise, pas par Wat.erp lui-même. Modifier le mot de passe directement dans l’ERP n’a aucun effet si l’authentification est déléguée à l’annuaire.
Sur les instances avec authentification locale, l’administrateur Wat.erp peut forcer la réinitialisation depuis le back-office. Nous recommandons de noter le type d’authentification configuré (locale ou LDAP) pour éviter de chercher au mauvais endroit lors d’un blocage.
Configuration réseau et accès distant à Wat.erp
Wat.erp fonctionne en mode client-serveur via le navigateur. L’accès distant (télétravail, agence déportée) suppose que le poste client atteigne le serveur applicatif à travers le réseau. Deux configurations coexistent selon les exploitants.
Accès via VPN
Le tunnel VPN doit être établi avant d’ouvrir la page de connexion. Une erreur fréquente consiste à lancer le navigateur puis à activer le VPN : le navigateur conserve alors la résolution DNS initiale et ne redirige pas vers le serveur interne. Fermer le navigateur, activer le VPN, puis rouvrir la session résout ce décalage.
Vérifiez aussi que le split tunneling est correctement paramétré. Si le flux vers le serveur Wat.erp passe par la passerelle Internet au lieu du tunnel, la connexion échoue sans message réseau clair.
Accès via portail web exposé
Certains opérateurs exposent Wat.erp sur un sous-domaine public protégé par un reverse proxy. Dans cette configuration, les règles de pare-feu et les listes blanches d’adresses IP peuvent bloquer l’accès depuis un réseau non référencé. Tester la connexion depuis un réseau mobile permet d’isoler un filtrage côté réseau local.
Problèmes de session et déconnexion intempestive dans Wat.erp
Les déconnexions en cours d’utilisation signalent le plus souvent un conflit de session ou un timeout serveur trop court. Wat.erp gère les sessions côté serveur avec un jeton transmis par cookie.
Si le navigateur bloque les cookies tiers ou applique une politique SameSite stricte, le jeton de session n’est pas renvoyé au serveur lors de la navigation entre modules. Le résultat : une redirection vers la page de connexion après chaque changement d’écran.
Paramètres cookies à vérifier
- Dans Chrome, accéder à chrome://settings/cookies et s’assurer que le domaine du serveur Wat.erp figure dans la liste des sites autorisés.
- Désactiver les extensions de type bloqueur de traceurs (uBlock Origin, Privacy Badger) sur le domaine Wat.erp : elles interceptent parfois les cookies de session applicatifs.
- Vider le cache et les cookies du navigateur pour le domaine concerné, puis se reconnecter. Une session corrompue stockée localement peut provoquer une boucle de déconnexion.
Côté serveur, le timeout de session peut être ajusté dans la configuration applicative. Un délai trop court (quelques minutes) pénalise les utilisateurs qui saisissent des données sur des formulaires longs, comme les devis travaux ou les interventions terrain.
Diagnostic rapide avant escalade au support Somei
Avant d’ouvrir un ticket auprès de Somei, nous recommandons de rassembler les éléments suivants pour accélérer le traitement.
Notez le message d’erreur exact (ou son absence), le navigateur et sa version, le type de réseau utilisé (LAN, VPN, accès distant), et l’heure précise du blocage. Un screenshot de la console développeur du navigateur (onglet Réseau) avec les requêtes en erreur permet au support d’identifier immédiatement si le problème est côté client ou serveur.
Testez aussi l’accès depuis un autre poste sur le même réseau. Si le problème est isolé sur un seul poste, la cause est locale (cache, certificat, extension). Si plusieurs postes sont touchés simultanément, le blocage est probablement côté infrastructure ou serveur applicatif.
La plupart des problèmes de connexion WATERP se résolvent en combinant mise à jour du navigateur, purge du cache et vérification du tunnel réseau. Les cas qui résistent à ces manipulations relèvent généralement d’un incident serveur ou d’une expiration de certificat, deux situations où seul l’administrateur de la plateforme peut intervenir.
