TITLE: Erreur 401 : identifiants, cache ou .htaccess ? Comment trouver la vraie cause
HTML:
Un client valaisan m’a appelé un lundi matin, persuadé que son site venait de se faire pirater : son équipe ne pouvait plus accéder à l’interface d’administration, et le navigateur affichait un message sec, « 401 Unauthorized ». Il n’y avait ni piratage ni panne générale. Juste une erreur d’authentification, la plus mal comprise du web, et souvent la plus facile à régler une fois qu’on sait où regarder.
Ce que dit vraiment l’erreur 401
Le code 401 signifie que le serveur refuse de vous montrer une ressource parce qu’il n’a reçu aucune preuve d’identité valable, ou que celle transmise est incorrecte ou expirée. Ce n’est pas un refus de principe : c’est une demande. La réponse du serveur contient presque toujours un en-tête technique nommé WWW-Authenticate, qui précise le type d’authentification attendu : Basic, Digest, ou Bearer pour les jetons d’accès utilisés par la plupart des API modernes. Ce détail change tout pour un développeur, car il indique directement où chercher : un mot de passe simple, un jeton OAuth expiré, ou un en-tête Authorization mal formé côté client. Le protocole HTTP ne conserve d’ailleurs aucune mémoire entre deux requêtes : chaque appel doit reprouver son identité, ce qui explique pourquoi un accès qui fonctionnait la veille peut échouer du jour au lendemain sans qu’aucun changement n’ait été fait côté utilisateur.
Dans mon métier de conseil, j’observe régulièrement que les PME romandes traitent ce message comme une panne mystérieuse alors qu’il s’agit d’un dialogue technique très précis entre le navigateur et le serveur. Comprendre cette mécanique évite déjà la moitié des appels paniqués à un prestataire facturé à l’heure.
401, 403, 407 : trois erreurs qu’on confond à tort
La confusion entre ces trois codes coûte du temps à beaucoup d’équipes que j’accompagne, notamment lors de la mise en ligne de nouveaux outils internes. Voici la distinction concrète.
| Code | Signification | Ce qu’il faut vérifier |
|---|---|---|
| 401 | Authentification absente ou invalide | Identifiants, jeton, en-tête Authorization |
| 403 | Identité reconnue, mais accès refusé | Droits, permissions, restrictions IP |
| 407 | Authentification requise par un proxy intermédiaire | Configuration du proxy, Proxy-Authorization |
La nuance entre 401 et 403 est celle qui revient le plus souvent dans mes échanges avec des responsables informatiques de PME : un 401 dit « je ne sais pas qui vous êtes », un 403 dit « je sais qui vous êtes, et ce n’est pas suffisant ». Deux problèmes, deux corrections différentes. Le 407, plus rare, se rencontre surtout en environnement d’entreprise : un proxy interne réclame ses propres identifiants avant de laisser passer la requête vers le serveur final, un cas que je croise de temps en temps chez des clients dont le réseau a été reconfiguré sans que tous les postes ne soient mis à jour en même temps.
Les causes les plus fréquentes
Du côté de l’utilisateur
Un mot de passe changé récemment mais non mis à jour dans une application connectée, un cache de navigateur qui conserve d’anciens identifiants, ou des cookies de session périmés : ce sont, dans mon expérience, les trois quarts des cas rencontrés chez mes clients. Le réflexe de vider le cache et les cookies avant toute autre manipulation résout une majorité de situations. Sur Windows, vider le cache DNS se fait via la commande ipconfig /flushdns ; sur macOS, la commande équivalente est sudo killall -HUP mDNSResponder.
Du côté du serveur
C’est ici que les choses deviennent plus intéressantes, et souvent plus révélatrices. J’ai vu chez un client lausannois un fichier .htaccess devenu, au fil des années et des prestataires successifs, un véritable creuset où s’étaient accumulées des directives d’authentification, des règles de réécriture d’URL et des restrictions d’accès par IP posées par trois agences web différentes, sans qu’aucune ne documente le travail des précédentes. Résultat : une règle héritée d’un ancien intranet bloquait silencieusement l’accès à une nouvelle page, produisant un 401 incompréhensible sans lien apparent avec le changement récent. Ce type de configuration serveur, empilée sans nettoyage, mérite d’être auditée périodiquement plutôt que rafistolée à chaque incident.
Sur un CMS comme WordPress, un plugin de sécurité ou un pare-feu applicatif peut aussi déclencher ce blocage, en particulier après une mise à jour qui modifie ses règles par défaut.
Diagnostiquer avant de corriger
Avant toute intervention, je recommande systématiquement à mes clients de vérifier deux choses simples : l’URL exacte demandée, qui peut avoir changé sans que personne ne l’ait signalé, et le contenu de la réponse du serveur via l’onglet Réseau des outils de développement du navigateur. C’est là qu’apparaît l’en-tête WWW-Authenticate mentionné plus haut, qui indique le schéma d’authentification réellement attendu. J’ai accompagné une PME vaudoise dont l’équipe informatique combattait ce message depuis trois jours sur son intranet, en changeant des mots de passe sans succès. Il a suffi d’ouvrir l’onglet Réseau pour constater que le jeton Bearer transmis par l’application avait expiré depuis longtemps, un problème que dix minutes d’inspection auraient permis d’identifier dès le premier jour. Sauter cette étape, c’est corriger au hasard, et dans un cabinet de conseil, le hasard coûte cher en heures facturées pour rien.
Corriger selon le contexte
Sur WordPress, l’accès à wp-admin bloqué par un 401 impose souvent de désactiver temporairement les plugins de sécurité via un client FTP, en dehors de l’interface d’administration devenue inaccessible. Sur une API, la solution passe généralement par le renouvellement d’un jeton d’accès expiré plutôt que par une nouvelle tentative avec les mêmes identifiants. Sur Outlook et Microsoft 365, l’erreur survient parfois indépendamment de toute action de l’utilisateur, lors d’un incident connu côté fournisseur ; dans ce cas, le tableau de bord Microsoft Service Health permet de vérifier si le problème est général avant de chercher une cause locale.
Dans tous les cas, l’ordre logique reste le même : vérifier l’identité transmise, nettoyer ce qui est périmé côté client, puis seulement ensuite auditer la configuration côté serveur. C’est l’approche que j’applique avec mes clients romands, et elle évite l’écueil classique consistant à réinstaller un site entier pour un problème qui tenait à une seule ligne de configuration oubliée.