Certificat SSL et HTTPS : 2 tests qui peuvent ruiner votre crédibilité

Un certificat expiré déclenche un avertissement plein écran. Une redirection HTTPS manquante laisse fuir les données. Les tests #09 et #36 détectent les deux.

Il existe deux types de problèmes web : ceux que les visiteurs finissent par remarquer, et ceux qui leur sautent aux yeux immédiatement. Un certificat SSL expiré est du second type. Le navigateur affiche un avertissement plein écran — « Votre connexion n'est pas privée » — et la plupart des visiteurs repartent sans jamais voir le site.

Mais même quand le certificat est valide, des problèmes peuvent survenir. Si HTTP ne redirige pas vers HTTPS, les visiteurs peuvent atterrir sur une version non sécurisée du site. Si la page charge du contenu mixte (ressources HTTP sur une page HTTPS), le cadenas disparaît. La confiance s'érode silencieusement.

Orilyt exécute deux tests complémentaires. Le test #09 valide le certificat SSL lui-même — est-il valide, correspond-il au domaine, quand expire-t-il ? Le test #36 vérifie l'application du HTTPS — HTTP redirige-t-il vers HTTPS, y a-t-il du contenu mixte ? Ensemble, ils couvrent toute la surface de sécurité HTTPS.

Test #09 : Votre certificat SSL est-il valide ?

Le test #09 effectue une véritable poignée de main TLS avec le serveur et inspecte le certificat. Il vérifie :

1. Poignée de main TLS — le serveur peut-il établir une connexion sécurisée ? Si la poignée de main échoue, le score est 0. Le site est effectivement inaccessible en HTTPS
2. Expiration du certificat — combien de jours avant l'expiration ? Moins de 7 jours = score 55, moins de 14 jours = 65, moins de 30 jours = 75. Déjà expiré = score 20
3. Correspondance du domaine — le CN ou SAN du certificat correspond-il au domaine ? Un décalage déclenche un avertissement du navigateur. Le score chute à 20
4. Version du protocole TLS — le test indique quelle version TLS a été négociée (TLS 1.2, 1.3). Les anciens protocoles comme TLS 1.0/1.1 sont obsolètes et non sécurisés

Un certificat sain avec plus de 30 jours avant l'expiration et un domaine correspondant obtient 100. Si l'URL auditée utilise HTTP au lieu de HTTPS (même avec un certificat valide), le score plafonne à 80 — car le visiteur n'utilise pas réellement la connexion sécurisée.

Test #36 : Le HTTPS est-il vraiment appliqué ?

Avoir un certificat valide est nécessaire mais pas suffisant. Le test #36 vérifie deux choses :

1. Redirection HTTP vers HTTPS — si un visiteur tape http://votresite.com, le serveur le redirige-t-il vers https:// ? Sans ça, chaque visite directe ou ancien lien mène à la version non sécurisée. Score : 95 avec redirection, 60 sans
2. Contenu mixte — même sur une page HTTPS, si des images, scripts ou feuilles de style sont chargés via HTTP, le navigateur signale la page comme partiellement non sécurisée. Le cadenas disparaît. Score : 70 quand du contenu mixte est détecté

Si l'URL auditée utilise HTTP (pas HTTPS), le score tombe à 0. Cela signifie que le site n'a pas de HTTPS du tout — ou que l'URL a été mal saisie.

Le contenu mixte est particulièrement insidieux car il peut passer inaperçu. La page charge, tout semble normal — mais l'icône cadenas a disparu, et les visiteurs soucieux de sécurité (et Google) le remarquent.

Causes courantes et corrections rapides

La plupart des problèmes SSL/HTTPS se corrigent facilement une fois identifiés :

1. Certificat expiré — le renouvellement automatique a échoué (cron Let's Encrypt cassé, panel d'hébergement mal configuré). Correction : renouveler manuellement, puis réparer l'auto-renouvellement. 5 minutes
2. Pas de redirection HTTP→HTTPS — le .htaccess ou la config serveur ne redirige pas HTTP vers HTTPS. Correction : ajouter une RewriteRule. Deux lignes de code
3. Contenu mixte — d'anciens contenus ont des URL http:// en dur. Correction : rechercher-remplacer en base (plugin Better Search Replace) ou ajouter l'en-tête Content-Security-Policy: upgrade-insecure-requests
4. Mauvais domaine sur le certificat — le certificat a été émis pour www.example.com mais le site tourne sur example.com (ou inversement). Correction : réémettre avec un SAN couvrant les deux

Le schéma récurrent : ce sont tous des problèmes de configuration, pas de code. Ils se corrigent vite et ont un impact fort — exactement le type de constat qui justifie un audit.

SSL/HTTPS comme argument de vente

Pour les freelances et agences, les constats SSL/HTTPS sont parmi les plus puissants de tout audit. Ils sont visuels, urgents et compréhensibles par tous :

Dans le rapport Orilyt, les deux tests génèrent des recommandations FIA claires :

1. Fait : « Le certificat SSL expire dans 5 jours » ou « Aucune redirection HTTP vers HTTPS détectée »
2. Impact : « Le navigateur bloquera le site dans 5 jours » ou « Les visiteurs en HTTP ne voient aucun chiffrement — les données transitent en clair »
3. Action : « Renouveler le certificat immédiatement » ou « Ajouter une redirection 301 de HTTP vers HTTPS dans la configuration serveur »

Ces constats créent l'urgence. Un client qui voit « votre certificat expire dans 5 jours » agit immédiatement. Un client qui voit « pas de redirection HTTPS » comprend le risque sans explication technique. C'est le constat d'audit le plus facile à vendre.

La base de la confiance — vérifiée en 2 secondes

HTTPS n'est pas une fonctionnalité. C'est un pré-requis. Google l'exige pour le classement. Les navigateurs alertent sans. Les visiteurs partent au premier signe d'insécurité. Les tests #09 et #36 vérifient cette base en quelques secondes.

Si le certificat est valide, la redirection fonctionne et il n'y a pas de contenu mixte — tout va bien. Si l'un de ces éléments échoue, c'est la première chose à corriger avant toute autre optimisation.

Pour les audits clients, SSL/HTTPS est le démarreur de conversation. C'est visuel, c'est urgent, et la correction est rapide. Si vous trouvez un problème ici, vous avez déjà justifié l'audit.