Rapide, visible, protégé : l'anatomie d'un site bien construit

Un site se juge sur ce qu'il fait quand personne ne regarde : le temps qu'il met à s'afficher sur un mobile en 4G, sa place dans les résultats de recherche, ce qu'il advient d'un formulaire rempli un dimanche soir, et sa résistance au trafic automatisé qui frappe toutes les adresses publiques. Le site que vous lisez s'applique ces principes à lui-même. Voici ce qu'il y a dedans, en quatre parties.

Le code

Une base Symfony qui vieillit bien

Un framework ne se juge pas à la mise en ligne mais trois ans plus tard, quand il faut ajouter une fonctionnalité sans rien casser. Le code métier est tenu à l'écart de l'infrastructure : les règles qui décrivent votre activité ne dépendent ni du framework ni de la base de données, si bien que l'un peut changer sans réécrire l'autre.

Ce cloisonnement a un effet concret : chaque parcours critique est couvert par des tests automatisés, que nous passons avant chaque livraison. Une régression se voit là, pas après, quand un visiteur la signale. C'est cette discipline que rend possible un développement Symfony sur mesure.

Des images qui ne pèsent presque plus rien

Les images représentent l'essentiel du poids d'une page, et c'est là que les gains sont les plus immédiats. Chaque visuel est servi dans un format moderne, en plusieurs tailles, et le navigateur retient celle qui correspond à l'écran : un téléphone ne télécharge jamais une image pensée pour un grand écran.

Le résultat se mesure. Des pages plusieurs fois plus légères qu'avec des fichiers bruts, une image principale qui s'affiche sans attente, et un cache d'un an sur les fichiers versionnés, si bien qu'une seconde visite ne retélécharge rien. Sur une connexion mobile moyenne, c'est la différence entre une page qui apparaît et une page qu'on abandonne.

Des formulaires qui ne perdent rien

Un formulaire de contact est le seul endroit où un visiteur vous confie quelque chose. Il mérite mieux qu'un envoi à l'aveugle. Chaque demande est validée côté serveur, enregistrée en base avant toute tentative d'envoi d'email, et accompagnée d'un consentement explicite à être recontacté.

La personne qui remplit le formulaire reçoit aussitôt un accusé de réception qui récapitule sa demande et annonce le délai de réponse. Elle sait que le message est parti. C'est une attention simple, et pourtant rare.

Le référencement et la mesure

Le référencement se joue à la conception

Optimiser un site après coup coûte toujours plus cher que le concevoir correctement. Titres et descriptions calibrés page par page, hiérarchie de titres cohérente, adresse canonique unique, plan de site tenu à jour, données structurées lisibles par les moteurs : rien de tout cela ne se voit à l'écran, et pourtant tout cela décide de ce que Google comprend. C'est le coeur de notre travail de référencement SEO.

Deux langues réellement indexées

Le site existe en français et en anglais, correctement déclarés l'un à l'autre, avec des adresses distinctes et des liens suivables entre les versions. C'est la différence entre un site traduit et un site réellement présent dans les deux langues. Un sélecteur de langue que les moteurs ne peuvent pas suivre suffit à faire disparaître toute une version des résultats.

Mesurer sans pister

Rien n'est mesuré tant que le visiteur n'a pas accepté. Le choix exprimé sur le bandeau de consentement est réellement appliqué, pas seulement affiché, et la mesure démarre à ce moment-là.

Ce qui est compté comme une demande reçue ne l'est qu'après confirmation du serveur, jamais au clic sur le bouton : une soumission qui échoue ne gonfle aucun chiffre. Nos propres visites sont exclues du comptage, pour que les statistiques décrivent vos visiteurs et pas notre travail sur le site.

La sécurité

Ce que le navigateur applique à chaque page

Le HTTPS ne protège que le transport. Le reste se joue dans des en-têtes que le navigateur applique à chaque page : forcer la connexion chiffrée, refuser que le site soit affiché dans un cadre sur un domaine tiers, empêcher l'exécution de scripts venus d'ailleurs, limiter ce qui est transmis aux sites externes lors d'un clic sortant.

Les réflexes qui ne se voient jamais

S'y ajoute le travail invisible : échapper systématiquement ce qui est affiché, passer par des requêtes préparées pour parler à la base, refuser les envois de formulaire forgés depuis un autre site, ne jamais faire confiance à une donnée reçue. Ces réflexes ne coûtent rien à intégrer dès la conception, et ils ferment les portes les plus couramment essayées contre un site vitrine.

L'infrastructure

Une production cloisonnée

Un site n'est jamais plus fiable que l'infrastructure qui l'héberge. La nôtre tourne en France, avec une séparation nette entre l'environnement de test et la production. La base de données n'est joignable depuis internet à aucun moment, elle vit sur un réseau privé, et l'accès administratif passe par un point d'entrée contrôlé, sans clé SSH à distribuer ni à révoquer.

Un pare-feu devant le site

Devant la production, un pare-feu applicatif écarte les attaques les plus courantes avant qu'elles n'atteignent le site : injections, exploits connus, adresses déjà signalées, et une limitation du débit par adresse contre les envois massifs. La disponibilité est contrôlée automatiquement, et les journaux d'accès, d'application et de filtrage sont conservés, en-têtes sensibles expurgés.

Déployer, et savoir revenir en arrière

Les mises en ligne passent par une chaîne automatisée : l'application est reconstruite à l'identique, et la mise en production reste une action délibérée. Chaque version est conservée, si bien que revenir à la précédente prend quelques minutes, sans rien reconstruire. C'est ce socle que couvre un contrat de support et de maintenance.

Regarder plutôt que croire

Tout ce qui précède se vérifie depuis votre propre navigateur, sans nous croire sur parole. C'est le principe que nous appliquons à chaque projet : ce qui est affirmé doit pouvoir être constaté.