En coulisses

Un site vitrine est aussi une démonstration. Voici comment j’ai fabriqué celui-ci, et pourquoi.

Un site statique

Les pages sont écrites une fois, puis servies telles quelles. Il n’y a ni base de données, ni serveur applicatif, ni compte à créer. Moins de pièces, c’est moins de pannes et moins de failles.

Accessible : conçu selon le RGAA

Le site est conçu selon le référentiel général d’amélioration de l’accessibilité (RGAA) et les règles WCAG 2.2 de niveau AA. Vous pouvez agrandir ou réduire le texte, choisir un thème clair ou sombre, et tout faire au clavier. L’état réel des vérifications est détaillé dans la déclaration d’accessibilité.

Sobre : conçu selon le RGESN

Le référentiel général d’écoconception de services numériques (RGESN) guide les choix : une seule police de caractères, une page qui pèse moins de 150 Ko, police comprise, aucun service tiers qui se charge à votre insu, aucune vidéo. Un contrôle automatique vérifie, avant chaque mise en ligne, que la vue initiale reste sous 300 Ko.

Sans cookie

Le site ne dépose aucun cookie et n’a pas besoin de vous demander votre accord. Les réglages de taille et de thème restent dans votre navigateur. Les détails sont sur la page Confidentialité.

Déclaration d’écoconception

Cette déclaration porte sur ce site : la page d’accueil et les quatre pages annexes (mentions légales, confidentialité, en coulisses, accessibilité). Elle est datée du 16 octobre 2026. J’ai évalué le site moi-même avec le référentiel général d’écoconception de services numériques (RGESN, version de mai 2024, 78 critères). Aucun audit externe n’a été réalisé : je dis donc que le site est conçu selon le RGESN, pas qu’il le respecte entièrement.

Score d’avancement : 48 %

Sur les 78 critères, 50 s’appliquent à ce site et 28 ne s’appliquent pas. J’en ai validé 25, et 25 restent à améliorer. Le score suit la méthode du référentiel : chaque critère validé compte selon sa priorité (31,5 points sur 65). C’est un indicateur d’avancement, pas une mesure d’impact environnemental.

Les critères qui touchent à ce que votre navigateur télécharge et affiche sont presque tous validés (12 sur 14 pour l’interface et les contenus). Ceux qui restent à faire concernent surtout la stratégie, la documentation et l’hébergeur : 20 des 25 critères à améliorer.

Mesure EcoIndex : note A sur les cinq pages

Mesurée le 16 octobre 2026 sur le site construit, avant sa mise en ligne, avec la méthode d’ecoindex.fr : navigateur Chrome, écran de 1 920 × 1 080, trois secondes d’attente, défilement jusqu’en bas, puis trois secondes d’attente.

Accueil : EcoIndex 86 sur 100 (note A), 240 éléments, 4 requêtes, 143 Ko transférés.
Les quatre autres pages : EcoIndex de 87 à 91 sur 100 (note A), de 97 à 234 éléments, 3 requêtes, de 118 à 129 Ko transférés.

La police pèse 73 Ko sur chaque page. Le serveur de mesure ne compresse pas les fichiers texte : le poids réel sera plus bas avec la compression de l’hébergeur.

Critères validés (25)

1.3 Référent. Maxence Martin, éditeur du site, joignable par le contact de la page d’accueil.
1.6 Données collectées. Le site ne collecte aucune donnée : ni cookie, ni mesure d’audience, ni formulaire. Seul l’hébergeur garde des journaux techniques, expliqués dans la page Confidentialité.
1.7 Chiffrement. Il se limite au HTTPS fourni par l’hébergeur. Aucun autre mécanisme.
1.9 Standards. HTML, CSS et JavaScript standards, sans application native.
2.3 Bas débit. Page d’accueil testée à 512 kbit/s : premier affichage en 1,1 s, page complète en 2,1 s.
2.5 Écrans. Mise en page testée de 320 à 1 440 px de large et sur deux téléphones simulés, sans défilement horizontal.
2.6 Revues. Revue de conception avec budgets de poids avant la réalisation (10 octobre 2026), revue du code au regard du référentiel (16 octobre 2026).
3.1 Architecture. Un générateur de site statique (Eleventy), retenu pour sa sortie sans framework JavaScript et son petit arbre de dépendances. Astro a été écarté.
3.7 Environnements. Un seul environnement distant, la production. Développement et tests se font en local.
4.1 Lecture automatique. Aucune. Aucune animation non plus.
4.2 Défilement infini. Aucun : tout le contenu tient sur une page de moins de 150 Ko.
4.5 Composants natifs. Boutons, liens et menus HTML natifs, sans bibliothèque d’interface.
4.6 et 4.7 Médias. Ni vidéo, ni son, ni animation.
4.8 Polices. Une seule police, un seul fichier de 73 Ko.
4.9 Requêtes à la saisie. Aucune : le site n’a aucun champ de saisie.
4.12 Fonctionnalités lourdes. Aucune : pas de téléchargement, pas de média.
4.13 Notifications. Aucune.
4.14 Dark patterns. Aucun : pas de fenêtre surgissante, de case précochée ni de compte à rebours.
5.1 Formats d’image. La photo de l’accueil est servie en AVIF et en WebP. Seules les icônes d’onglet et l’image de partage sont en PNG ou ICO, formats exigés par les navigateurs et les réseaux sociaux.
5.2 Qualité des images. AVIF à la qualité 50, WebP à 65, en trois largeurs (480, 960 et 1 440 px).
6.2 Cache. Les fichiers à nom haché sont configurés pour rester un an dans le navigateur, les pages sont revalidées à chaque visite.
6.4 Images adaptées à l’écran. Trois définitions de la photo ; le navigateur choisit la plus proche de son écran.
6.5 Rien d’inutile. La photo n’est pas téléchargée sous 900 px de large (téléphones et tablettes en portrait).
9.1 Apprentissage automatique. Aucun dans ce site.

Points restant à travailler pour améliorer le score RGESN (25 critères)

Chaque point est un critère non validé. Ils sont regroupés par nature de travail, du plus rapide au plus lourd.

À faire dans le code, tout de suite

6.1 Plafond de requêtes. Le poids est plafonné (300 Ko), pas le nombre de requêtes (3 ou 4 aujourd’hui). Fixer un maximum, l’ajouter au contrôle automatique et le publier ici.
6.3 Compression et minification. Le script n’est pas réduit à son minimum et la compression des fichiers texte n’est pas configurée. Réduire le script à la construction du site, activer la compression chez l’hébergeur et la vérifier en ligne.

Une fois le site en ligne

3.3 Protocoles. Vérifier qu’IPv6, TLS 1.3 et HTTPS fonctionnent partout, puis publier les protocoles utilisés.
6.7 HTTP/2. Vérifier que le site est servi en HTTP/2 ou HTTP/3. Toutes les ressources viennent déjà d’une seule origine.

Décisions et textes à écrire

1.8 Open source. Le code du site n’est pas publié. Le publier sous licence libre, ou justifier publiquement de ne pas le faire.
2.7 Maintenance et fin de vie. Écrire la stratégie : un seul environnement (la production), une date de rappel, le sort des fichiers et du domaine si le site s’arrête.
1.4 Revues régulières. C’est la première évaluation. Refaire celle-ci après un changement important, publier la mise à jour et sa périodicité, faire un test de charge ou justifier de ne pas en faire.
4.15 Information et mode sobre. Afficher l’empreinte de l’usage de la page selon une norme reconnue, proposer un mode sobre et en documenter les gains.
2.8 Fournisseurs. Documenter le choix de l’hébergeur au regard d’exigences environnementales (guide des achats numériques responsables, ISO 20400).
1.1 Utilité et impacts. Rédiger l’étude : le numérique est-il nécessaire, existe-t-il une alternative, à quels objectifs de développement durable le site répond-il ? Y ajouter l’arbre des conséquences de la méthode Empreinte Projet de l’Ademe.
1.2 Cibles utilisatrices. Publier le profil des cibles et la recherche menée : retours des trois recommandeurs et notes d’entretien.
4.3 Parcours. Mettre en place une mesure d’audience respectueuse de la vie privée, optimiser le parcours de réservation d’après les usages et publier les indicateurs.
1.5 Objectifs de réduction. Évaluer l’empreinte du site avec une méthode reconnue, idéalement une analyse de cycle de vie multicritère (énergie, gaz à effet de serre, eau, ressources), puis fixer des objectifs de réduction, les suivre et les publier.

Essais sur d’anciens appareils

2.2 Anciens terminaux. Aucun essai sur un ordinateur de plus de dix ans. Essayer le site sur un portable de 2016 ou antérieur et noter ses caractéristiques.
2.4 Anciens navigateurs. Tester Chrome 130, Firefox 131 et Safari 18.0 (versions d’octobre 2024) et publier les versions minimales.
2.1 Profil matériel minimal. Une fois ces essais faits, publier le profil de matériel minimal.

Hébergement : à obtenir de l’hébergeur pour mon offre, puis à publier

3.2 Ressources serveur. Comment l’offre adapte ses ressources à la demande (elle est aujourd’hui mutualisée).
8.1 Hébergeur engagé. Des engagements publiés sur les gaz à effet de serre, l’énergie, l’eau et les ressources, appuyés sur le code de conduite européen des centres de données ou sur ISO 14001.
8.2 Durée de vie du matériel. Un plan de gestion durable du parc (objectif : plus de huit ans).
8.3 Efficacité énergétique. Un PUE réel inférieur à 1,5 pour le centre de données de l’offre.
8.4 Eau. Un WUE publié, avec un objectif de 0,4 L/kWh ou moins.
8.5 Électricité. Le détail des contrats (accords d’achat à long terme, sinon garanties d’origine avec additionnalité) et les quantités.
8.6 Lieu des serveurs. Un centre de données dans un pays dont l’électricité émet moins de 100 gCO2e/kWh.
8.7 Chaleur. Une récupération de la chaleur documentée, ou un PUE réel inférieur à 1,3.
8.9 Disponibilité. Un niveau de garantie de service adapté, relevé dans le contrat de l’offre.

Critères sans objet (28)

Pas d’objet connecté, de terminal vendu ni de mise à jour à installer : 1.10, 3.4, 3.5, 3.6.
Pas de vidéo ni de son : 5.3, 5.4, 5.5, 5.6.
Pas de formulaire ni d’envoi de fichier : 4.10, 4.11.
Pas de service tiers ni de composant d’interface prêt à l’emploi : 2.9, 2.10, 4.4. Le lien de réservation mène à un autre site, mais ne charge rien chez lui tant que vous n’avez pas cliqué.
Site statique, sans base de données ni traitement côté serveur : 5.7, 5.8, 7.1, 7.2, 7.3, 8.8, 8.10.
Pas de capteur, pas de blockchain : 6.6, 7.4.
Pas d’intelligence artificielle dans le service : 9.2 à 9.7.