Introduction
Quand ProSilicones64 m'a contacté, leur site accumulait des correctifs depuis des années. Un WordPress avec 23 plugins actifs, quatre failles de sécurité (dont deux critiques), et un temps de chargement de 6,2 secondes qui faisait fermer l'onglet à tout acheteur technique avant même de voir le catalogue.
Le problème n'était pas le design. Le problème, c'est qu'ils avaient construit une maison sur une maison sur une autre maison, et plus personne ne savait ce qui allait casser quand on touchait à quelque chose.
Cette étude de cas explique comment j'ai tout jeté pour reconstruire de zéro un système conçu spécifiquement pour un catalogue industriel technique. Avec du code réel, des décisions justifiées et des résultats mesurables.
Le problème
Première chose : connexion SSH au serveur et activation du log de requêtes MySQL. J'ai ouvert une fiche produit au hasard — un profilé silicone pour étanchéité ferroviaire — et j'ai compté les requêtes.
45 requêtes. Pour afficher une page avec un titre, une description, trois images et un tableau de caractéristiques techniques.
Pourquoi autant ? Parce que chaque plugin faisait son truc sans coordination avec les autres. Le plugin SEO interrogeait la base. Le plugin de cache interrogeait pour vérifier s'il y avait du cache. Le plugin de traduction interrogeait trois fois par champ. Le thème interrogeait les options globales à chaque chargement. Et ainsi de suite, jusqu'à 45.
Le TTFB (Time To First Byte) était à 890 ms. Ça veut dire que le serveur mettait presque une seconde rien que pour commencer à envoyer des données, avant même que le navigateur puisse rendre quoi que ce soit.
- 23 plugins actifs sans contrôle des dépendances
- Temps de chargement : 6,2 secondes
- TTFB : 890 ms (presque une seconde juste pour démarrer)
- 45 requêtes MySQL par fiche produit
- 4 vulnérabilités actives, dont 2 critiques
- Catalogue statique impossible à faire évoluer
- Aucun balisage Schema.org
Pour une entreprise industrielle où l'acheteur technique a 15 onglets ouverts pour comparer les fournisseurs, c'est un suicide commercial.
La décision : tout jeter et reconstruire de zéro
Deux options. Première : optimiser l'existant — désactiver des plugins, installer un cache agressif, prier pour que rien ne casse. Deuxième : migrer vers un système sur mesure conçu spécifiquement pour les besoins réels de ProSilicones64.
J'ai choisi la deuxième. ProSilicones64 n'est pas une boutique en ligne ni un blog d'entreprise. C'est un fabricant industriel avec un catalogue technique complexe : 30 produits, 19 séries de compounds silicone aux propriétés différentes, 10 secteurs industriels, 127 normes et certifications. Chaque produit peut être fabriqué dans plusieurs séries, chaque série a des plages de température et de dureté spécifiques, chaque secteur exige des certifications particulières.
WordPress n'est pas conçu pour ça. On peut le forcer avec des plugins de custom fields et des taxonomies personnalisées, mais on finit avec un monstre que personne ne comprend et qui casse à chaque mise à jour.
L'architecture : PHP natif, MySQL relationnel, zéro dépendance inutile
Je n'ai pas utilisé Laravel ni Symfony. Pas parce qu'ils sont mauvais — ce sont d'excellents frameworks — mais parce que pour ce projet ils ajoutaient de la complexité sans bénéfice réel. ProSilicones64 n'a pas besoin d'un ORM qui abstrait la base de données ; il a besoin de requêtes SQL optimisées qui retournent exactement ce que chaque page doit afficher.
Chaque contrôleur fait exactement une chose. Le contrôleur de fiche produit appelle le service produit, qui appelle le repository, qui exécute une seule requête SQL avec les JOINs nécessaires. Une requête, une query, une réponse.
Structure des répertoires
- /app/controllers → Reçoivent la requête, appellent le service, retournent la vue
- /app/services → Logique métier : quelles séries s'appliquent à quels secteurs
- /app/repositories → Requêtes SQL pures, une fonction par besoin de données
- /app/views → PHP simple avec HTML, sans moteur de templates
Base de données relationnelle conçue pour le métier
- produits → catégories : extrusion, moulage, caoutchoucs techniques, plaques
- series_silicone → 19 séries avec plage de température (-60°C à +300°C) et dureté (30-90 Shore A)
- secteurs → ferroviaire, médical, agroalimentaire, aéronautique...
- normes_certifications → 127 enregistrements : ISO, EN 45545-2, FDA, USP Class VI
- produit_serie_secteur → table pivot qui relie tout
Système de cache à trois niveaux
- Niveau 1 : OPcache PHP — bytecode compilé stocké en mémoire
- Niveau 2 : Cache de requêtes — résultats en JSON avec timestamp, invalidation par trigger
- Niveau 3 : Cache HTTP — en-têtes Cache-Control pour navigateur et CDN
SEO technique sérieux
- Balisage Schema.org Product sur toutes les fiches avec propriétés techniques
- URLs propres : de /produit/?id=847&cat=3 à /produits/profiles-silicone-ferroviaire/
- Redirections 301 pour préserver le jus de liens
- Sitemap XML dynamique généré depuis la base de données
Les résultats : des chiffres réels, pas des projections
Après trois mois avec le nouveau système en production, voici les données comparatives. Le dernier chiffre est celui qui compte : de 8 demandes de devis mensuelles à 31. Pas parce que le design est plus beau — il est quasiment identique — mais parce que le site charge vite, les produits se trouvent facilement, et le formulaire de contact fonctionne sans erreurs JavaScript.
Comparatif avant/après
| Métrique | WordPress (avant) | Système sur mesure (après) |
|---|---|---|
| Temps de chargement | 6,2s | 1,1s |
| TTFB | 890ms | 180ms |
| Requêtes SQL par page | 45 | 8 |
| Vulnérabilités actives | 4 | 0 |
| Plugins/dépendances | 23 | 0 |
| Pages valides dans Search Console | 68% | 94% |
| Demandes de devis/mois | 8 | 31 |
Conclusion
Ce projet a confirmé ce que je soupçonnais déjà : pour les entreprises industrielles avec des catalogues techniques, WordPress est le mauvais choix. Pas parce qu'il est mauvais, mais parce qu'il a été conçu pour un autre type de contenu.
Un blog personnel, un site vitrine de cinq pages, une boutique en ligne standard... WordPress gère ça très bien. Mais quand on a des relations complexes entre produits, séries, secteurs et normes réglementaires, on a besoin d'une base de données qui reflète cette complexité. Et quand on a besoin de vraie vitesse pour être compétitif face aux autres fabricants, on a besoin d'un contrôle total sur chaque requête qui s'exécute.
ProSilicones64 a maintenant un site qui peut évoluer sans se dégrader. Ajouter une nouvelle série de silicone, c'est insérer des lignes dans la base, pas installer un nouveau plugin. Ajouter un nouveau secteur, c'est créer des relations, pas bidouiller des shortcodes.
Et quand ils voudront refaire le front-end dans cinq ans, ils pourront le faire sans toucher à la logique métier. Parce qu'elles sont séparées. Parce que c'est comme ça qu'on construit des systèmes qui durent.
Si votre catalogue technique tourne sur WordPress et que vous avez remarqué qu'il ralentit, que les mises à jour cassent des choses, ou que les acheteurs techniques abandonnent avant d'atteindre le formulaire de contact... vous êtes probablement dans la même situation que ProSilicones64 il y a un an. Je peux réaliser un audit technique de votre site : mesurer les temps de chargement réels, compter les requêtes, identifier les goulots d'étranglement, évaluer les vulnérabilités. Sans engagement, sans blabla. Des données vérifiables pour prendre des décisions.
Demander un audit technique →
