Passer un WordPress de HTTP à HTTPS proprement, base de données comprise

Passer un site en connexion sécurisée paraît simple : l'hébergeur propose un certificat gratuit, on l'active, et le cadenas apparaît. Dans les faits, un site installé depuis plusieurs années a inscrit son adresse en clair à des centaines d'endroits : dans ses réglages, dans le contenu de ses articles, dans les liens vers ses images, dans les données enregistrées par ses extensions. Activer le certificat sans traiter ces occurrences produit un site à moitié sécurisé, avec un cadenas barré, des images qui ne s'affichent plus et parfois une boucle de redirection qui rend l'administration inaccessible. Nous décrivons ici la procédure complète, dans l'ordre où elle doit être exécutée, avec les points de contrôle à chaque étape.

Préparer la bascule

La préparation détermine la réussite de l'opération et elle occupe la moitié du temps total. Les bénéfices attendus de cette bascule, tant en sécurité qu'en confiance des visiteurs, sont exposés dans notre article sur les moyens de renforcer la sécurité d'un site en HTTPS.

Sauvegarder complètement

Une sauvegarde des fichiers et de la base de données constitue le préalable absolu, et elle doit être testée avant de commencer. Une restauration à blanc sur un environnement de test confirme que la sauvegarde est exploitable. Beaucoup d'incidents graves viennent d'une sauvegarde qui existait sans être valide. Cette vérification prend une demi heure et elle change la nature du risque encouru. Conserver la sauvegarde en dehors du serveur du site est également indispensable. Une copie locale et une copie distante constituent le minimum raisonnable.

Vérifier le certificat

Le certificat doit couvrir le domaine principal et ses sous domaines utilisés, en particulier la version avec et sans préfixe. Un certificat ne couvrant qu'une des deux formes produira une alerte de sécurité pour la moitié des visiteurs. Le renouvellement doit être automatisé, faute de quoi le site deviendra inaccessible à l'expiration. Les pièges de ce renouvellement sont détaillés dans notre article sur les certificats Let's Encrypt et leur renouvellement automatique. Tester l'accès à la version sécurisée avant toute modification confirme que le certificat fonctionne. Cette vérification se fait en saisissant directement l'adresse sécurisée dans le navigateur.

Inventorier les ressources externes

Les scripts, polices, images et lecteurs vidéo chargés depuis d'autres domaines doivent tous être accessibles en connexion sécurisée. Une ressource disponible uniquement en clair sera bloquée par le navigateur après la bascule. L'inventaire se fait en listant les domaines contactés dans l'onglet réseau, sur plusieurs types de pages. Les services actuels proposent tous une version sécurisée, mais un ancien widget ou un compteur de visites hérité peuvent poser problème. Repérer ces cas avant la bascule permet de prévoir leur remplacement. Les découvrir après produit des pages cassées en production.

Recenser les intégrations

Les outils de mesure d'audience, les consoles de moteurs de recherche, les passerelles de paiement et les services de notification connaissent l'adresse du site et devront être mis à jour. Établir cette liste à l'avance évite les oublis qui se manifestent des semaines plus tard par une perte de données. La console de recherche demande notamment l'ajout d'une nouvelle propriété, la version sécurisée étant considérée comme un site distinct. Les outils de mesure conservent l'historique si le suivi est correctement paramétré. Chaque intégration doit figurer dans une liste de contrôle avec la personne responsable. Cette liste sera reprise après la bascule.

Prévoir la fenêtre d'intervention

L'opération se déroule normalement en trente à soixante minutes sur un site de taille moyenne, incident non compris. La programmer en dehors des heures de forte affluence limite l'impact d'un éventuel problème. Prévenir les personnes concernées, notamment celles qui publient du contenu, évite les modifications concurrentes pendant l'intervention. Sur un site marchand, une fenêtre nocturne ou de début de semaine réduit le manque à gagner en cas de difficulté. Annoncer une durée plus longue que prévue laisse de la marge. Le stress est mauvais conseiller sur ce type de manipulation.

Travailler sur une copie d'abord

Sur un site important, la procédure complète doit être répétée sur une copie de préproduction avant d'être appliquée en production. Cette répétition révèle les particularités du site, les extensions récalcitrantes et les contenus qui résistent au remplacement. Elle permet également de chronométrer l'opération. Le temps investi dans cette copie se récupère largement lors de l'intervention réelle. Sur un site vitrine simple, cette étape peut être allégée sans être totalement supprimée. Le rapport entre l'enjeu et l'effort guide cette décision.

Remplacer les adresses en base de données

C'est l'étape technique centrale, et celle où les erreurs coûtent le plus cher.

Pourquoi un simple rechercher-remplacer ne suffit pas

Certaines données sont stockées sous une forme sérialisée, où la longueur de chaque chaîne est enregistrée à côté de son contenu. Remplacer une adresse en clair par sa version sécurisée allonge la chaîne d'un caractère et rend la longueur déclarée incorrecte. La donnée devient alors illisible et l'extension ou le thème concerné cesse de fonctionner, souvent silencieusement. Ce mécanisme explique les pannes mystérieuses qui suivent un remplacement effectué directement en base. Il concerne principalement les réglages de thèmes, les constructeurs de pages et les widgets. Un outil conscient de ce format est donc indispensable.

Les outils appropriés

Un script dédié, exécuté en ligne de commande, effectue le remplacement en gérant correctement les données sérialisées. L'interface en ligne de commande de la plateforme propose également une commande de remplacement avec cette gestion intégrée. Des extensions offrent la même fonction depuis l'administration, ce qui convient aux sites sans accès en ligne de commande. Toutes ces solutions proposent un mode simulation, qui affiche le nombre de remplacements sans les appliquer. Utiliser systématiquement ce mode avant l'exécution réelle permet de vérifier l'ampleur de l'opération. Un nombre de remplacements très éloigné de l'attendu signale une erreur de motif.

Le motif de recherche

Le remplacement doit porter sur l'adresse complète, préfixe compris, et non sur le seul nom de domaine. Remplacer le domaine seul modifierait aussi les occurrences déjà correctes et les adresses de courriel contenant ce domaine. Il faut également traiter la version avec barre oblique finale et sans, ainsi que les formes échappées présentes dans les données au format structuré. Lister les variantes à traiter avant de commencer évite les passages multiples. Un oubli se rattrape facilement, il suffit de relancer avec le motif manquant. Une erreur de motif trop large, en revanche, demande une restauration.

Les tables concernées

Les adresses se trouvent principalement dans la table des options, celle des contenus et celle des métadonnées d'articles. Les extensions ajoutent souvent leurs propres tables, qui doivent être incluses dans le traitement. Traiter l'ensemble des tables est plus simple et présente peu de risques avec un outil approprié. Il faut en revanche exclure les tables de journalisation volumineuses, dont le traitement serait long et inutile. Vérifier la liste des tables avant de lancer permet de repérer les tables inattendues. Cette lecture prend une minute et évite des surprises.

Les réglages principaux

Deux réglages définissent l'adresse du site et celle de l'installation, et ils doivent être modifiés en premier. Sur certaines configurations, ces valeurs sont figées dans le fichier de configuration et ne peuvent pas être modifiées depuis l'administration. Il faut alors les corriger directement dans ce fichier. Une erreur sur ces deux valeurs rend l'administration inaccessible, situation angoissante mais réversible par modification du fichier de configuration. Connaître cette porte de sortie avant de commencer évite la panique. C'est le point où la plupart des interventions se bloquent.

Les contenus dans les fichiers

Le remplacement en base ne touche pas les adresses inscrites dans les fichiers du thème, dans les feuilles de style ou dans les scripts. Une recherche dans les fichiers du thème enfant et des extensions personnalisées complète l'opération. Les adresses figurant dans les fichiers de la plateforme elle même ne doivent jamais être modifiées, une mise à jour les écrasant de toute façon. Cette recherche se fait avec un éditeur de code ou une commande de recherche récursive. Elle révèle souvent quelques occurrences oubliées dans un modèle de page personnalisé. Leur correction prend quelques minutes.

Rediriger et vérifier

Une fois les adresses corrigées, il reste à s'assurer que les anciennes adresses conduisent bien aux nouvelles, sans détour ni boucle.

La redirection permanente

Toute requête en clair doit être redirigée vers son équivalent sécurisé avec un code indiquant un déplacement définitif. Les enjeux et le fonctionnement de ce type de redirection sont détaillés dans notre article sur la redirection 301. Cette redirection se configure au niveau du serveur web, dans le fichier de configuration du répertoire ou dans la configuration principale. Une extension peut également l'assurer, avec une légère perte de performance. La configuration serveur reste préférable car elle intervient avant le chargement de la plateforme. Elle est également plus difficile à casser par une mise à jour.

Éviter la chaîne de redirections

Un site accessible avec et sans préfixe de sous domaine peut se retrouver avec deux redirections successives, ce qui ralentit le chargement et dilue le signal transmis aux moteurs. La configuration doit conduire à l'adresse finale en une seule étape, quelle que soit la forme d'entrée. Vérifier ce point avec un outil affichant la chaîne complète prend quelques secondes. Le cas des quatre combinaisons possibles doit être testé individuellement. Cette vérification est presque toujours omise et elle révèle fréquemment une redirection superflue. La corriger améliore mesurablement le temps de réponse.

La boucle de redirection

Un site placé derrière un service de diffusion ou un répartiteur de charge reçoit parfois les requêtes en clair même lorsque le visiteur utilise la connexion sécurisée. La règle de redirection se déclenche alors indéfiniment et le navigateur abandonne. La solution consiste à s'appuyer sur l'en-tête transmis par le service plutôt que sur le protocole apparent. Cette configuration est documentée par tous les services concernés. Connaître ce cas avant de le rencontrer évite une heure de recherche dans l'urgence. Il constitue l'incident le plus fréquent de toute la procédure.

Le contenu mixte

Une page servie de façon sécurisée qui charge une image ou un script en clair déclenche un avertissement et le blocage de la ressource. La console du navigateur signale précisément chaque occurrence, ce qui rend le diagnostic simple. Le contrôle doit porter sur plusieurs gabarits, les occurrences se cachant souvent dans un article ancien ou un widget. Une extension peut forcer la réécriture des adresses à l'affichage, solution acceptable en dépannage et non satisfaisante durablement. Corriger la source reste préférable. La liste des pages à contrôler doit inclure la page d'accueil, un article, une page et le tunnel de commande le cas échéant.

Les fichiers techniques

Le plan de site, le fichier d'instructions pour les robots et les balises canoniques contiennent des adresses qui doivent refléter la nouvelle forme. La régénération du plan de site se déclenche depuis l'extension de référencement. Les balises canoniques sont généralement calculées dynamiquement et se mettent à jour seules, ce qui mérite néanmoins une vérification. Le fichier d'instructions doit être relu et corrigé manuellement. Ces éléments passent souvent inaperçus et ils envoient des signaux contradictoires aux moteurs. Leur contrôle prend dix minutes.

Les vérifications après bascule

Un parcours complet du site, en observant la console du navigateur, constitue le contrôle final. Il faut tester la connexion à l'administration, la publication d'un contenu, l'envoi d'un formulaire et, sur un site marchand, un paiement de test. Consulter les journaux d'erreur du serveur pendant les heures suivantes révèle les problèmes non visibles. Une surveillance renforcée pendant deux jours permet de détecter les cas rares. Prévoir cette disponibilité fait partie de l'intervention. Le sentiment que tout fonctionne ne remplace pas ces contrôles.

Les suites de la bascule

L'opération ne s'arrête pas au moment où le cadenas apparaît, plusieurs actions restant à mener dans les jours qui suivent.

Déclarer la nouvelle propriété

La console de recherche considère la version sécurisée comme un site distinct et il faut donc l'ajouter, puis soumettre le nouveau plan de site. L'ancienne propriété doit être conservée quelque temps pour observer la disparition progressive des anciennes adresses. Une propriété de type domaine, couvrant toutes les variantes, simplifie durablement ce suivi. Les données historiques ne se transfèrent pas, ce qui impose de conserver les exports antérieurs. Anticiper cette perte en exportant les données importantes avant la bascule est une bonne précaution. Elle prend quelques minutes et évite des regrets.

Mettre à jour les liens externes que l'on maîtrise

Les profils de réseaux sociaux, les fiches d'établissement, les annuaires professionnels et les signatures de courriel contiennent l'ancienne adresse. La redirection les fait fonctionner, et un lien direct reste préférable en termes de performance et de signal. Établir la liste de ces emplacements et les corriger progressivement constitue un travail d'une heure ou deux. Les liens sur des sites tiers ne peuvent évidemment pas être modifiés, d'où l'importance de conserver la redirection indéfiniment. Cette redirection ne doit jamais être supprimée, même des années plus tard. C'est une règle absolue.

Surveiller le positionnement

Une bascule correctement menée n'entraîne pas de perte durable, et une fluctuation de quelques jours reste normale. Un décrochage persistant au delà de deux semaines signale un problème technique, généralement une redirection mal configurée ou un blocage dans le fichier d'instructions. Comparer les positions avant et après, sur un échantillon de requêtes, permet de trancher rapidement. Cette surveillance doit être planifiée plutôt que laissée à l'inquiétude. Un tableau simple, relevé chaque semaine pendant un mois, suffit. Il rassure autant qu'il informe.

Activer les protections complémentaires

Une fois la bascule stabilisée, l'en-tête demandant au navigateur de ne plus jamais revenir en clair renforce la protection. Il ne doit être activé qu'après plusieurs semaines de fonctionnement sans incident, sa durée le rendant difficile à annuler. Commencer par une durée courte, puis l'allonger progressivement, constitue la méthode prudente. Les cookies doivent également être marqués comme réservés aux connexions sécurisées. Ces réglages complètent utilement la bascule sans en faire partie. Les traiter séparément évite de mélanger les causes en cas de problème.

Nettoyer les solutions de dépannage

Les extensions installées en urgence pour forcer la réécriture des adresses doivent être retirées une fois les contenus corrigés. Elles consomment des ressources à chaque affichage et masquent les problèmes résiduels plutôt que de les résoudre. Leur retrait doit être suivi d'un nouveau contrôle du contenu mixte. Cette étape est régulièrement oubliée, l'extension restant en place des années. Inscrire cette tâche dans le suivi de l'intervention évite l'oubli. Le gain de performance est modeste et la propreté technique en vaut la peine.

Documenter l'intervention

Consigner la date, les motifs de remplacement utilisés, les extensions ayant posé problème et les particularités rencontrées constitue une ressource précieuse pour l'avenir. Ce document sert lors d'une migration ultérieure, d'un changement d'hébergeur ou d'une intervention par un autre prestataire. Il tient sur une page et il fait gagner plusieurs heures à chaque fois. Le déposer avec la documentation du site plutôt que dans une messagerie garantit sa disponibilité. Cette habitude, appliquée à toutes les interventions structurantes, constitue un actif réel. Elle distingue les sites bien tenus des autres.