Ce site — Technologie simple, 100/100 Lighthouse, EcoIndex A-B
Scores de cette page :
EcoIndex A
SEO 100%
Accessibilité 100%
Performance 100%
Bonnes Pratiques 100%
Site professionnel développé en PHP/JS/CSS pur, sans CMS ni framework. 100/100 Lighthouse sur toutes les pages, EcoIndex A sur toutes les pages sauf Mes réalisations, en B à cause d'un contenu plus important.
Contexte
Ce site est le mien — le seul projet où j'applique mes principes sans compromis, sans un client pour imposer des visuels trop lourds ou un budget qui rogne sur la qualité. Sobriété numérique, accessibilité, transparence sur la qualité technique : ici, rien ne vient les limiter.
Une architecture PHP légère, sans framework ni base de données
Le site est codé en PHP pur, sans CMS ni framework : chaque page
est un fichier PHP autonome, qui inclut un en-tête et un pied de
page communs et se contente de définir son titre et sa description
avant de les inclure. Pas de base de données à interroger — les
réalisations, par exemple, sont lues depuis un simple fichier JSON
à chaque affichage, quelques dizaines de kilo-octets à peine.
Cette simplicité (aucun framework à charger, aucune requête SQL)
garde le temps de réponse serveur très bas malgré une exécution
PHP réelle à chaque visite. Une règle de réécriture Apache permet
des adresses propres, sans
.php visible dans l'URL :
elle cherche d'abord un fichier PHP correspondant à l'adresse
demandée et l'exécute directement ; ce n'est que si aucun fichier
PHP ne correspond qu'elle se rabat sur une éventuelle version
HTML statique — un filet de secours, pas le mode de
fonctionnement principal du site.
Des scores affichés en direct, pas juste annoncés
Plutôt que d'afficher une fois pour toutes "100/100 Lighthouse" en
argument marketing figé, chaque page du site porte un encart discret
(le "coin de page" replié en bas d'écran) indiquant ses propres
scores : EcoIndex, SEO, accessibilité, performance, bonnes pratiques.
Un choix de transparence contrôlable page par page plutôt qu'une
affirmation globale invérifiable.
Empreinte carbone mesurée sans dépendre d'un tiers
Le badge carbone affiché en pied de page n'appelle plus aucun service
externe depuis le navigateur du visiteur. À l'origine basé sur un script
tiers chargé directement dans la page, il a été réécrit pour être calculé
côté serveur : une tâche automatique interroge l'API Website Carbon une
fois par semaine et par page, enregistre le résultat dans un fichier, et
le pied de page affiche cette valeur déjà connue plutôt que d'aller la
chercher à chaque visite. Résultat pour le visiteur : aucune requête vers
un site tiers, aucune donnée déposée dans son navigateur, et une page qui
reste fonctionnelle même si l'API externe est temporairement indisponible
— la dernière valeur connue continue de s'afficher.
Optimisation SEO et référencement
Au-delà du design et du développement, ce site a fait l'objet d'un travail
spécifique de référencement technique, pour lever les ambiguïtés qui peuvent
freiner son indexation par les moteurs de recherche et leurs IA.
01
Données structurées (JSON-LD)
Le nom commercial du site (ECODE) diffère de la raison sociale de la structure
juridique (ANIMACLE24, SAS). Sans indication explicite, les moteurs de recherche
peuvent ne pas relier les deux — un balisage
schema.org/Organization
a donc été ajouté en page d'accueil, déclarant nom commercial, raison sociale,
SIRET, fondatrice et coordonnées, pour établir cette correspondance sans ambiguïté.
02
Identité visuelle et favicon
Le favicon a été retravaillé en version ronde multi-résolutions (16, 32 et 48 px),
avec une bordure de couleur
#46d9ff reprenant l'identité graphique du
site, pour un rendu net sur tous les supports (onglets navigateur, favoris,
résultats de recherche).
03
Cache et fraîcheur des assets
Un système de cache-busting automatique (basé sur la date de modification des
fichiers) garantit que les mises à jour de CSS, JS et images sont immédiatement
visibles pour les visiteurs récurrents, malgré une mise en cache navigateur d'un an.
04
Conformité légale et fiche Google Business
Les mentions légales ont été vérifiées pour conformité LCEN, et une fiche Google
Business Profile a été créée (catégorie "Concepteur de sites web"), avec une
description dédiée reprenant les mêmes informations que le site pour renforcer
la cohérence des signaux transmis aux moteurs de recherche.
05
Plan du site généré automatiquement
Le sitemap XML n'est pas une liste tenue à jour à la main : il est
généré directement depuis les mêmes données qui alimentent la page
des réalisations, pour rester systématiquement synchronisé avec le
contenu réel du site, sans étape de maintenance supplémentaire à
chaque nouvelle réalisation ajoutée.
Sécurité de base, sans surcouche inutile
En-têtes de sécurité standards (protection contre le détournement de
type MIME, contre l'affichage du site dans un cadre externe, contrôle
de la fuite d'URL au clic sur un lien sortant), et blocage de l'accès
direct aux fichiers de données JSON qui alimentent le site —
consultables par le code serveur, jamais directement depuis un
navigateur. Téléphone et email de contact également protégés :
absents du code source en clair (répartis en plusieurs attributs
distincts plutôt qu'écrits tels quels), ils ne s'assemblent et ne
s'affichent qu'après une action du visiteur (survol ou clic) — hors
de portée des robots collecteurs d'adresses qui scrutent le HTML brut
à la recherche de coordonnées à revendre.
Résilience et gestion des erreurs
Un site n'est pas testé par ses pages qui fonctionnent, mais par ce qui
se passe quand quelque chose échoue. Ce site a été durci sur ce point
précis, en conditions réelles plutôt que sur le papier : chaque
protection ci-dessous a été vérifiée par un test provoquant
délibérément la panne qu'elle est censée couvrir.
01
Formulaire de contact : validation stricte côté serveur
Chaque fichier joint est vérifié sur deux critères indépendants —
l'extension déclarée et le type réel du contenu (détecté par analyse
binaire, pas par ce qu'annonce le navigateur) — avant d'être accepté.
Le nom de fichier envoyé par le visiteur n'est lui-même jamais utilisé :
chaque fichier est renommé avec un identifiant aléatoire sur 128 bits
— un nombre de combinaisons si grand qu'il est impossible à deviner en
pratique. Cela empêche trois choses : écraser un fichier déjà présent,
accéder à un autre dossier du serveur en manipulant le nom du fichier
(une attaque appelée « traversée de chemin »), et faire exécuter du code
déposé sous un faux nom. Un jeton à usage unique (protection CSRF)
empêche qu'un envoi de formulaire soit rejoué automatiquement, un champ
invisible piège les robots, et tout ce qui est reçu est nettoyé pour
empêcher l'insertion de fausses instructions dans l'email envoyé (une
attaque appelée « injection d'en-têtes »). Si l'envoi échoue après
l'enregistrement d'un ou plusieurs fichiers, ceux-ci sont automatiquement
supprimés — aucun fichier orphelin ne reste sur le serveur.
02
Pièces jointes en liste blanche, sur deux couches indépendantes
Le dossier qui reçoit les pièces jointes du formulaire fonctionne en
liste blanche (on autorise seulement ce qui est explicitement permis,
tout le reste est refusé par défaut), avec deux règles distinctes et
redondantes — une au niveau du site, une au niveau du dossier lui-même —
qui n'autorisent que les fichiers dont le nom est un identifiant
aléatoire et l'extension l'une de celles réellement acceptées par le
formulaire. Tout le reste (scripts, pages HTML, fichiers de
configuration, listing du dossier) est refusé, même en cas de
défaillance de l'une des deux couches. Les liens envoyés par email
continuent de fonctionner normalement ; seule une adresse devinée ou
construite à la main est bloquée.
03
Fichiers internes jamais exposés par URL
Les gabarits communs à toutes les pages (en-tête, pied de page) et les
bibliothèques utilisées côté serveur (envoi d'email) ne répondent à
aucune requête directe : si quelqu'un tape leur adresse dans son
navigateur, il obtient une erreur, quelle que soit l'extension utilisée
dans la requête. Seul le code du site lui-même peut les charger, en
interne.
04
Pages d'erreur cohérentes avec le reste du site
Page introuvable, accès refusé, erreur technique : chacune de ces
situations affiche une page à la charte du site, avec une explication
en langage clair et un moyen de repartir, plutôt que la page générique
du serveur. La page d'erreur technique adopte volontairement un ton
différent des deux autres : elle précise explicitement que le problème
ne vient pas de la navigation du visiteur.
05
Filet de sécurité applicatif contre les pannes imprévues
Si une erreur technique imprévue survient pendant la construction
d'une page — un bug qui interromprait normalement tout l'affichage,
ce qu'on appelle une erreur fatale — un mécanisme dédié l'intercepte
avant qu'elle n'atteigne le visiteur : le contenu de la page n'est pas
envoyé au fur et à mesure qu'il est généré, mais retenu en mémoire
jusqu'à la fin ; si une erreur survient en cours de route, tout ce qui
a été généré jusque-là est écarté au profit d'une page d'erreur soignée
— plutôt qu'une page à moitié construite ou un message technique brut.
Cette protection est mise en place à deux endroits différents du code,
pour rester active même si l'un des deux venait à être retiré par
erreur. Les erreurs elles-mêmes continuent d'être consignées dans les
journaux du serveur pour diagnostic, sans jamais être affichées
publiquement.