Étude de cas : rapport de performance du site ATKDA - WordPress vs primeCRM

Date: Mai 2026
Préparé par: Libertas Software
Portée: 15 pages équivalentes, 3 exécutions par page, mesure du document HTML basée sur curl

---

Résumé exécutif

Nous avons comparé le site WordPress existant d'ATKDA au nouveau site propulsé par primeCRM, hébergé sur un domaine de test pré-production. Les deux sites ont été mesurés sur le réseau dans des conditions identiques : la même machine, la même connexion, trois exécutions chronométrées par page, puis une moyenne des résultats.

Les résultats sont sans ambiguïté. Le nouveau site est en moyenne 9,3× plus rapide sur l'ensemble des 15 pages équivalentes. Le temps de traitement côté serveur (TTFB), principal facteur de lenteur sur WordPress, est 10,6× plus rapide avec primeCRM.

---

Méthodologie

Ce qui a été mesuré

Chaque page a été récupérée avec curl en enregistrant les variables de temps suivantes :

• DNS — temps de résolution du nom d'hôte
• Connect — temps nécessaire pour établir la connexion TCP/TLS
• TTFB — Time To First Byte ; temps écoulé entre l'établissement de la connexion et la réception du premier octet de la réponse. Cette mesure reflète le temps pur de traitement côté serveur.
• Total — temps complet jusqu'au téléchargement du corps de la réponse

Chaque page a été récupérée trois fois avec une pause d'une seconde entre les exécutions. Les trois temps totaux ont ensuite été moyennés pour obtenir le score final.

Note: Ce test mesure uniquement la réponse du document HTML, pas le chargement complet de la page incluant polices, JavaScript, CSS et images.

Ce qui n'a pas été mesuré

• Le chargement complet de la page dans le navigateur (exécution JS, chargement des polices, chargement des images)
• Les Core Web Vitals (LCP, FCP, CLS)
• Les performances sur mobile
• Les performances sous charge / utilisateurs concurrents

---

Correspondance des URL

Le nouveau site réorganise plusieurs URL. Le tableau ci-dessous documente la correspondance complète utilisée dans cette comparaison.

Nouvelles pages sans équivalent WordPress

Le nouveau site ajoute les pages suivantes, inexistantes sur WordPress :

• /en/schools — hub / index des écoles
• /en/events — hub / index des événements
• /en/privacy-policy
• /en/cookie-policy
• /en/gender-equality-plan

---

Résultats

Comparaison page par page

Comparaison du temps de connexion

La surcharge réseau (DNS + négociation TCP/TLS) était comparable sur les deux sites, ce qui confirme que l'écart de temps de réponse total vient de l'application elle-même, et non de l'infrastructure ou du réseau.

---

Analyse

L'histoire du TTFB

Le TTFB est la mesure la plus importante de ce test. Il représente le temps passé par le serveur à traiter la requête avant d'envoyer le moindre octet au navigateur : exécution PHP, requêtes en base, résolution des plugins, rendu des templates. Il n'a rien à voir avec la vitesse du réseau ou les capacités du navigateur.

Sur WordPress, le TTFB représente 87 à 95 % du temps de réponse total de chaque page. Le serveur passe entre 1,15 et 1,60 seconde à simplement traiter chaque requête. C'est cohérent avec une installation WordPress fortement chargée en plugins, où chaque chargement de page déclenche un bootstrap PHP complet, plusieurs requêtes SQL et des chaînes d'exécution de plugins.

Sur primeCRM, le TTFB varie de 0,10 à 0,16 seconde, soit une amélioration de 10,6×. Cela reflète une architecture serveur fondamentalement différente : templates précompilés, surcharge d'exécution minimale, et absence de chaîne de plugins à résoudre.

Ce que cela signifie pour les utilisateurs

Les recherches montrent de manière constante que le temps de chargement influence directement le comportement des utilisateurs. Dans la plage de 1,5 seconde observée en moyenne sur WordPress, une part significative des visiteurs — en particulier sur mobile — percevra la page comme lente. À 160 ms, le document HTML est livré avant même que l'utilisateur ne ressente consciemment un délai.

L'image complète sera encore meilleure. Ce test ne capture que le document HTML. La réduction de la complexité globale du nouveau site — moins de plugins, un chargement des assets plus propre — produira des gains supplémentaires sur le temps de chargement complet dans le navigateur, qui seront mesurés dans le test Playwright de suivi.

Conclusion

Les chiffres de ce rapport couvrent uniquement la récupération du document HTML — la réponse du serveur avant même que le navigateur n'ait chargé un seul asset. Même à ce niveau uniquement, le nouveau site est 9,3× plus rapide que WordPress, avec un temps de traitement serveur réduit de plus de 90 % sur chaque page testée.

L'amélioration de l'expérience utilisateur est encore plus importante. Deux changements supplémentaires s'ajoutent significativement aux gains sur la partie HTML.

Conversion des images. Toutes les images du nouveau site ont été converties de JPEG et PNG vers WebP. Le format WebP offre systématiquement des fichiers bien plus légers à qualité visuelle équivalente ou supérieure, ce qui permet aux mêmes images d'arriver dans le navigateur avec une fraction de la bande passante. Pour un site qui publie des photos d'écoles et d'événements, cette réduction du poids des images a un impact direct et concret sur le temps de chargement, en particulier sur mobile.

Chargement des polices. L'ancien site WordPress chargeait plus de 40 fichiers de police par page, conséquence d'un thème et d'un écosystème de plugins qui embarquaient chacun leurs propres typographies. Le nouveau site ne charge qu'une seule police additionnelle en plus de la pile système. Les polices sont des ressources bloquantes pour le rendu : le navigateur ne peut pas afficher le texte tant qu'elles ne sont pas disponibles. Passer de plus de 40 requêtes à une seule représente donc une amélioration majeure de la vitesse perçue et des Core Web Vitals, en particulier du First Contentful Paint.

Ensemble, ces trois changements — réponse serveur plus rapide, images plus légères, et réduction drastique du chargement des polices — constituent une amélioration globale de la performance du site à tous les niveaux de la pile. Le test Playwright de suivi, exécuté sur le domaine de production après mise en ligne, mesurera l'effet combiné de ces trois facteurs sur le temps de chargement complet dans le navigateur et sur les métriques Core Web Vitals.

Il faut aussi noter que WordPress propose des fonctions de cache et d'optimisation qui peuvent réduire une partie de cet écart, mais comme beaucoup de capacités de la plateforme, elles demandent une configuration volontaire et ne sont pas activées par défaut. En pratique, beaucoup de sites WordPress n'en bénéficient jamais. Sur primeCRM, le cache et les optimisations de performance sont activés par défaut. Les résultats de ce rapport reflètent cette différence : les chiffres WordPress représentent la réalité vécue par les utilisateurs du site, et non un scénario volontairement défavorable.

Si vous évaluez si votre site actuel freine votre croissance au lieu de la soutenir, contactez-nous. Nous construisons des plateformes conçues pour améliorer simultanément les performances, la visibilité et le contrôle opérationnel.

---

Annexe : données brutes des exécutions