CSS qui ne charge plus : l'attribut integrity bloque tout

Le fichier CSS est bien là, mais le navigateur refuse de l’afficher

Une feuille CSS qui ne charge plus après une modification, alors que le fichier existe et que le chemin est correct, vient presque toujours d’un attribut integrity sur la balise <link> : le navigateur recalcule le hash du fichier, le compare à celui déclaré, et bloque le chargement dès qu’ils diffèrent. C’est un comportement volontaire, pas un bug.

Rien n’est cassé côté serveur. Le fichier arrive, le code HTTP est 200, mais le navigateur refuse de l’appliquer parce qu’il ne fait plus confiance à son contenu. C’est réparable en quelques minutes une fois qu’on a identifié le bon message dans la console.

Le SRI (Subresource Integrity) est un mécanisme de sécurité qui vérifie, via un hash cryptographique placé dans l’attribut integrity, que le fichier chargé par le navigateur correspond exactement à celui attendu au moment où le code a été écrit source : MDN, 2026. Un hash cryptographique désigne une empreinte numérique unique calculée à partir du contenu d’un fichier, qui change dès qu’un seul octet est modifié.

Pourquoi ça arrive

L’attribut integrity casse toujours pour la même raison : le fichier a changé, mais la valeur déclarée dans le HTML n’a pas été mise à jour. Les cas concrets les plus fréquents :

• Une feuille CSS auto-hébergée a été modifiée (couleur, typographie, correction de bug) sans repasser sur les balises qui la référencent.
• Un fichier récupéré depuis un CDN a été téléchargé et hébergé en local, en conservant l’attribut integrity calculé sur le fichier d’origine, distant.
• Une mise à jour de version d’une librairie tierce (Bootstrap, une police, un plugin) change le contenu du fichier sans que le hash soit régénéré.
• Un processus de minification différent (build tool, plugin d’optimisation) génère un fichier byte à byte distinct de celui qui a servi à calculer le hash initial.
• Un template acheté (Webflow, ThemeForest, marketplace) embarque des hashs figés sur ses propres fichiers, invisibles jusqu’au jour où quelqu’un touche au CSS.

Ce dernier cas est le plus piégeux, parce qu’il ne prévient pas : tout fonctionne parfaitement jusqu’à la première modification.

1. Lire le message exact dans la console

Ouvre les outils de développement (F12), onglet Console, et recharge la page. Le message est standardisé et reproductible sur tous les navigateurs modernes, du type : “Failed to find a valid digest in the ‘integrity’ attribute for resource ‘…styles.css’ with computed SHA-384 integrity ’…’. The resource has been blocked.” source : GitHub, laravel/horizon #1435, 2024. Ce message confirme trois choses en une ligne : la ressource visée, l’algorithme utilisé (SHA-256, SHA-384 ou SHA-512), et le fait que le blocage vient bien du SRI, pas d’un chemin cassé ou d’un problème CORS.

Note le nom du fichier concerné. C’est la seule information qu’il faut avant de décider quoi faire.

2. Décider : fichier maison ou fichier verrouillé volontairement

Chez Peechy, on a rencontré ce cas sur un projet de miroir statique d’un template Webflow pour un client : 34 pages et 265 fichiers rapatriés en auto-hébergement. Une fois le CSS réécrit (la couleur d’accent du template remplacée par l’or du logo du client, le badge du template retiré), les feuilles de style ont cessé de charger d’un coup. Les balises <link> portaient un attribut integrity calculé sur le fichier CSS d’origine du template, avant toute modification. Chaque retouche invalidait le hash.

C’est la question à trancher immédiatement :

• Si le fichier est hébergé chez toi et modifié régulièrement (ton propre CSS, ton propre JS), le hash figé n’a plus de sens : c’est toi qui garantis l’intégrité du fichier, pas une source externe.
• Si le fichier vient d’un CDN ou d’une librairie tierce que tu n’héberges pas et dont tu veux justement garantir qu’il n’a pas été altéré en transit ou compromis côté CDN, le SRI fait exactement son travail : il faut recalculer le hash, pas le supprimer.

3. Retirer l’attribut sur un fichier auto-hébergé

Pour un fichier que tu maintiens toi-même, la solution la plus simple est de retirer integrity et crossorigin de la balise. Le SRI n’apporte aucune protection sur un fichier que tu contrôles et modifies : il ne fait que casser le rendu à chaque mise à jour.

Avant :

<link rel="stylesheet" href="/css/styles.css" integrity="sha384-abcXYZ..." crossorigin="anonymous">

Après :

<link rel="stylesheet" href="/css/styles.css">

Sur le projet Webflow évoqué plus haut, c’est ce traitement qui a permis de retrouver un rendu fidèle sur les 34 pages : suppression de l’attribut sur les feuilles CSS et JS auto-hébergées, une fois confirmé qu’aucun de ces fichiers n’était plus servi par un CDN tiers.

4. Recalculer le hash sur un fichier volontairement verrouillé

Si le fichier reste externe (CDN, police tierce, librairie) et que tu veux garder la protection, il faut régénérer la valeur avec le nouveau contenu. La commande de référence avec openssl source : Transloadit, 2025 :

echo "sha384-$(cat styles.css | openssl dgst -sha384 -binary | openssl base64 -A)"

Colle le résultat complet dans l’attribut integrity de la balise. SHA-256 est le minimum accepté par la spécification, SHA-384 reste le compromis le plus courant et supporté partout, SHA-512 offre la robustesse théorique la plus haute source : Transloadit, 2025. L’attribut peut contenir plusieurs hashs séparés par un espace : le navigateur choisit alors automatiquement le plus robuste qu’il supporte source : MDN, référence integrity.

Si la ressource est sur un autre domaine, garde crossorigin="anonymous" : sans en-tête CORS renvoyé par le serveur distant, le navigateur ne peut pas vérifier le hash et bloquera quand même le fichier source : MDN, guide pratique SRI.

5. Vérifier et éviter la récidive

Recharge la page en vidant le cache (Ctrl+Maj+R) et repasse par la console : plus aucun message lié à integrity ne doit apparaître, et les styles doivent s’appliquer visuellement. Vérifie aussi l’onglet Réseau : la requête vers le fichier CSS doit passer au vert, pas en rouge avec un statut “blocked”.

Pour éviter que le problème revienne à chaque modification future, deux options selon le contexte : soit tu automatises le recalcul du hash dans ton processus de build si le fichier change souvent, soit tu documentes clairement, dans le code ou un fichier README, quels fichiers portent un integrity volontaire et pourquoi. Le W3C prépare par ailleurs un en-tête complémentaire, Integrity-Policy, qui permettra à terme d’imposer au niveau serveur que toute ressource externe porte des métadonnées d’intégrité, avec une variante Integrity-Policy-Report-Only pour auditer sans bloquer immédiatement source : MDN, Subresource Integrity, 2026.

Tableau récapitulatif

Ce type de piège CSS n’est pas isolé : d’autres cas classiques (le contenu mixte qui casse le cadenas HTTPS, ou le coût caché des deux systèmes CSS d’un template Webflow) viennent de la même logique : un navigateur de plus en plus strict sur ce qu’il accepte de charger sans vérification.

FAQ

Quand passer la main à un pro

Un seul fichier concerné et une cause identifiée en console, tu répares en cinq minutes avec les étapes ci-dessus. Si le blocage touche plusieurs dizaines de fichiers repris d’un template ou d’un ancien prestataire, sans documentation sur ce qui a été verrouillé et pourquoi, un audit complet du code source évite de retirer un hash qui protégeait légitimement une ressource sensible, ou d’en oublier un qui bloquera silencieusement une page entière en production.