Ce que fait cet outil
Une page HTTPS est censée garantir que tout ce que le navigateur charge est chiffré et vérifié en chemin. Le contenu mixte casse cette garantie : une image, un script ou une feuille de style chargé via une URL http:// simple sur une page par ailleurs sécurisée. Cet outil récupère la page indiquée, vérifie qu'elle est bien servie en HTTPS, puis scanne son HTML à la recherche de ces ressources non sécurisées.
Pourquoi ça arrive presque toujours par accident
Le contenu mixte n'est presque jamais un choix délibéré — c'est le résidu d'une migration HTTP vers HTTPS incomplète : du texte codé en dur dans un CMS avec une URL http:// datant d'avant la migration, un widget tiers dont le code d'intégration n'a jamais été mis à jour, ou une image hébergée sur un ancien sous-domaine qui n'a jamais reçu son propre certificat SSL. Le site fonctionne visuellement, ce qui fait qu'on ne le remarque souvent qu'en ouvrant la console développeur du navigateur — ou en utilisant un outil comme celui-ci.
Contenu actif contre contenu passif
Les navigateurs traitent différemment le contenu mixte selon ce qu'il peut faire. Un script ou une iframe en HTTP peut modifier activement le comportement de la page — les navigateurs les bloquent donc généralement sans même les charger, ce qui casse visiblement une fonctionnalité. Une image ou un fichier de style en HTTP ne peut pas exécuter de code, donc la plupart des navigateurs la chargent quand même, avec un simple indicateur discret dans la barre d'adresse — ce qui la rend beaucoup plus facile à manquer, malgré le même problème sous-jacent.
Le cas des ressources tierces
Les widgets et scripts tiers (chat en ligne, cartes interactives, polices web, outils d'analyse) sont une source fréquente de contenu mixte, parce que le code d'intégration copié-collé peut dater d'avant que ce service propose HTTPS. La bonne nouvelle : la quasi-totalité des services tiers actuels proposent HTTPS, et le correctif se limite souvent à changer http:// en https:// dans une seule balise <script> ou <link>, sans toucher au reste de l'intégration.
Ce que cet outil ne détecte pas
Il ne scanne que le HTML initial renvoyé par le serveur — pas les ressources ajoutées dynamiquement par du JavaScript après le chargement de la page, ni les requêtes AJAX/fetch effectuées en HTTP depuis un script par ailleurs chargé en HTTPS. Pour ces cas, la console développeur du navigateur (onglet Sécurité ou Console) reste l'outil de référence, puisqu'elle observe la page réellement exécutée plutôt que son HTML brut.