Profilia

Le contexte

Profilia est un projet personnel que j’ai lancé pour éprouver une hypothèse simple à formuler, beaucoup plus difficile à exécuter : est-ce qu’en empilant dix tests de personnalité reconnus, deux langues, et plusieurs dizaines d’articles de fond par thème, on peut construire un actif SEO qui se capitalise tout seul, mois après mois ?

La réponse, pour l’instant, est positive et la courbe de trafic continue de monter. L’objectif maintenant est de prolonger cette dynamique sans sacrifier la qualité du contenu, ni l’expérience des tests.

Le défi

Plusieurs contraintes à tenir en même temps :

• Bilinguisme complet FR et EN sur les tests, les profils, le blog et l’interface, sans duplication de contenu ni pénalité de référencement (balises hreflang, adresses localisées).
• Volume de contenu maîtrisé : près de 200 articles entre les deux langues, rédigés avec un véritable angle éditorial, pas du texte automatisé à faible valeur.
• Parcours de quiz fluide : dix tests de 15 à 30 questions chacun, chargement rapide, reprise possible même sans création de compte.
• Profil ADN synthétique : croiser les résultats de plusieurs tests pour générer un méta-profil qui donne envie de finir les dix.
• Module d’analyses maison pour piloter : quel test convertit, quel article amène le trafic, à quelle étape les utilisateurs décrochent.

Ce que j’ai fait

Produit

• Conception des dix tests : DISC, RIASEC, Jung, Tempéraments, Chronotype, VARK, Langages de l’amour, Quatre Tendances, Styles de leadership, Animal totem.
• Système de profils par test (de 4 à 16 profils selon le test), chacun avec sa fiche dédiée, son image de partage générée dynamiquement et son maillage vers les articles pertinents.
• ADN personnalité : méta-profil qui se débloque à partir de trois tests complétés et s’enrichit à chaque nouveau test.
• Mode anonyme par défaut pour abaisser la barrière à l’entrée, compte optionnel avec authentification par lien envoyé par email quand l’utilisateur souhaite conserver ses résultats.

Tech

• Pile technique Laravel 13, Blade et Alpine.js, base PostgreSQL, rendu côté serveur natif Blade : chaque page de résultat ou d’article arrive indexable, sans hydration ni conteneur Node intermédiaire.
• Tailwind v4 avec @theme comme source de vérité pour les tokens de design, un seul bundle JS partagé entre toutes les pages publiques (~35 KB gzip).
• Pipeline de contenu bilingue : séparation stricte entre configurations PHP (métadonnées, profils, questions) et stores Alpine (interactions du quiz, partage, ADN), chargés à la demande.
• Intégration continue GitHub Actions : Pint, ESLint, Prettier, Pest (PHP) et Vitest (scoring) exécutés sur chaque pull request, plus une suite Playwright sur Chromium et mobile.
• Sentry côté serveur et côté navigateur pour détecter les régressions en production avant qu’elles ne remontent dans les métriques business.
• Dockerfile multi-étapes pour la production, une seule commande make deploy qui enchaîne récupération du code, sauvegarde de la base, construction des assets, redémarrage, vérification de santé et purge Cloudflare.

Growth & SEO

• Images de partage générées automatiquement pour les quelque 200 articles et les profils de quiz, produites par une seule commande make og-images.
• Maillage interne dense entre blog, tests et profils, pensé autour des intentions de recherche et non des catégories internes.
• Core Web Vitals au vert sur toutes les pages, grâce au rendu Blade direct, au HTML préchargé et à un sous-ensemble de polices réduit au strict nécessaire.
• Tableau de bord graphique (ApexCharts, lazy-loadé sur l’admin uniquement) pour suivre l’entonnoir : trafic organique, démarrage d’un test, complétion, puis création de compte.

Stack et choix techniques

J’ai hésité à partir sur Next.js, puis j’ai choisi Laravel pour itérer rapidement sur l’administration, les files d’attente et les migrations, sans réinventer une API.

La première version du front tournait sur Inertia.js et React 19, avec un conteneur Node dédié pour le rendu côté serveur. C’était confortable à écrire, mais pour un site dont 95 % du trafic atterrit sur des pages de contenu statique (blog, profils, landings de tests), c’était surdimensionné : ~190 KB de JavaScript gzip à charger pour afficher un article.

Je suis donc revenu à Blade et Alpine.js : le serveur rend directement, Alpine prend la main uniquement là où c’est nécessaire (le quiz player, le partage, l’ADN). Bundle divisé par trois à quatre selon les pages, plus de conteneur SSR Node en prod, un seul paradigme à maintenir. Recharts (React-only) a été remplacé par ApexCharts vanilla, lazy-loadé sur l’admin.

PostgreSQL plutôt que MySQL pour les requêtes analytiques de l’administration (regroupements sur les complétions, séries temporelles). Sentry en front et en back parce qu’un projet personnel sans supervision devient rapidement un projet personnel abandonné.

Résultats

Phase d’amorce assumée : les volumes bruts restent modestes, mais les signaux qualitatifs sont nets. Les personnes qui commencent un test le terminent (67 %, au-dessus du standard de l’industrie qui se situe entre 30 et 50 %), elles passent en moyenne plus de 5 minutes sur le site (engagement réel, pas de rebond instantané), et la dynamique mensuelle est franchement à la hausse. DISC porte le trafic avec 63 % de conversion sur les démarrages de test, la première source d’acquisition est Google en recherche organique, et le socle SEO est en place pour absorber le prochain palier de croissance.

Si la stratégie SEO à grande échelle vous intéresse et que vous voulez en discuter, écrivez-moi.