Le ScrUB

On va être honnête deux minutes. Quand on m'a parlé du projet pour le journal Le ScrUB, mon premier réflexe c'était de vouloir tout construire from scratch. J'avais des envies de stack moderne, de Jamstack, de trucs légers codés en Rust ou de générateurs de sites statiques. C'est le piège classique on veut se faire plaisir techniquement. Sauf qu'à la fin de la journée, qui va gérer le site ? Des étudiants en journalisme, pas des ingénieurs système. Il fallait que je range mon ego de côté pour sortir un outil qui soit réellement utile, maintenable par des non-techs.

La réponse était évidente, même si elle fait parfois grincer des dents : WordPress. Mais attention, pas le WordPress installé en un clic via un module automatisé dégueulasse. Non, là on parle d'une instance montée à la main, sécurisée et optimisée.

Le choix de l'hébergement mutualisé s'est imposé pour des raisons budgétaires évidentes pour une asso, mais ça veut dire qu'on a moins de contrôle que sur un VPS. C'est là que le vrai travail commence. J'ai forcé la config serveur pour tourner sur les dernières versions de PHP 8.x, parce que la vitesse d'exécution est incomparable et que la sécurité est critique. J'ai nettoyé la base de données MySQL avant même d'y injecter le premier article, en m'assurant que l'encodage des caractères (UTF8mb4) allait supporter n'importe quel émoji ou caractère spécial sans transformer le texte en hiéroglyphes. C'est le genre de détail invisible qui sauve la mise trois mois plus tard.

L'étape qui a probablement consommé le plus de caféine, c'est la gestion du domaine et des DNS. Acheter lescrub.fr, c'est la partie facile. Faire en sorte que tout communique correctement, c'est autre chose. J'ai passé un temps fou dans la zone DNS pour mapper proprement les champs A (pour l'IPv4) et AAAA (pour l'IPv6, parce qu'on est en 2025 quand même). Mais le vrai boss final, c'était la délivrabilité des emails. L'asso avait besoin d'adresses pros, et on sait tous que Google et Outlook adorent jeter les mails des nouveaux domaines directement dans les spams. J'ai dû configurer manuellement les enregistrements SPF pour déclarer officiellement quels serveurs ont le droit d'envoyer des mails en notre nom, et mettre en place le DKIM pour signer cryptographiquement chaque message. C'est de la plomberie pure, c'est ingrat, personne ne le voit, mais c'est la différence entre un projet amateur et une infra qui tient la route.

Ensuite, il a fallu s'attaquer au visuel. Je refusais catégoriquement d'utiliser un constructeur de page lourd type Elementor ou Divi qui injecte des mégatonnes de JavaScript inutile. J'ai opté pour une approche hybride : le "semi-custom". J'ai pris un thème parent ultra-minimaliste, une coquille vide mais bien codée, et j'ai créé un thème enfant. C'est là que j'ai pu coder pour de vrai. J'ai viré toutes les requêtes vers Google Fonts pour héberger les typographies en local (RGPD et performance obligent), j'ai réécrit les feuilles de style pour avoir une grille CSS moderne qui s'adapte parfaitement aux mobiles, et j'ai hacké le fichier functions.php pour retirer les fonctionnalités natives de WordPress dont on ne se servait pas. Le résultat, c'est un site qui a l'apparence d'un truc sur-mesure, mais qui garde la facilité de mise à jour du core WordPress.

Côté sécurité et maintenance, je suis devenu un peu paranoïaque, comme tout bon admin sys qui se respecte. J'ai déplacé l'URL de connexion pour éviter les bots qui scannent le web à la recherche de /wp-admin, j'ai blindé les permissions des fichiers sur le FTP (le bon vieux chmod, un classique qui peut tout casser si on se rate), et j'ai mis en place un certificat SSL Let's Encrypt strict. Il y a aussi toute une couche de cache que j'ai configurée pour générer des pages HTML statiques à partir du PHP dynamique. Concrètement, quand un utilisateur visite le site, le serveur ne recalcule pas tout : il sert une page déjà prête, ce qui rend la navigation instantanée, même sur une connexion 4G un peu bancale dans le tram.