Site web À qui appartient votre site web ? La question que personne ne pose
Domaine, contenu, code, accès : votre site est un assemblage de 4 actifs qui peuvent appartenir à des gens différents. Comment vérifier qui possède quoi.
Pourquoi la vitesse d'un site révèle le soin qu'on y a mis. Les seuils Google des Core Web Vitals (LCP, INP, CLS) et comment Inleven les tient vraiment.
La vitesse d’un site n’est pas un détail technique réservé aux développeurs : c’est le premier signe visible du soin qu’on a mis à le construire. Un site qui s’affiche d’un coup, sans à-coups, sans texte qui saute sous le doigt, dit à votre visiteur qu’il a affaire à quelqu’un de sérieux, avant même qu’il ait lu une seule ligne. Un site lent dit l’inverse. Google a fixé des seuils publics pour mesurer tout ça, les Core Web Vitals, et chez Inleven on les tient sur chaque livraison. Voici ce qu’ils mesurent, et surtout, ce que la lenteur raconte de vous.
Un site lent envoie un message que vous n’avez pas choisi : « ici, on a fait au plus vite, au moins cher, sans regarder le résultat ». Le visiteur ne formule pas ça consciemment. Il ressent juste un agacement diffus, une page qui tarde, un bouton qui se dérobe au moment du clic, une image qui pousse le texte vers le bas pendant qu’il lit. Et il s’en va, sans savoir pourquoi, en gardant l’impression vague que « ça ne le faisait pas ».
C’est d’autant plus vrai en 2026. Produire un site est devenu trivial : un outil génère une page en trente secondes, et ça se voit. Le web se remplit de sites corrects en apparence, lourds en réalité, bourrés de scripts inutiles, jamais relus. Du slop. Dans ce paysage, un site qui répond instantanément n’est plus seulement agréable, il est rare. Il signale une main humaine derrière, quelqu’un qui a mesuré, taillé, refusé le superflu. La vitesse est devenue une preuve de soin, parce que le soin est devenu l’exception.
Les Core Web Vitals sont trois mesures définies par Google pour quantifier la qualité d’expérience d’une page réelle, sur de vrais appareils. Trois seuils publics, à connaître :
Google utilise ces trois mesures comme signal de classement, et les remonte dans la Search Console à partir des visites réelles de vos utilisateurs. Ce ne sont pas des notes de laboratoire : c’est ce que vivent vraiment les gens sur votre site, agrégé sur vingt-huit jours.

Passer juste sous la barre, c’est éviter la pénalité. Ce n’est pas la même chose qu’offrir une bonne expérience. Un LCP à 2,4 secondes est « vert » au sens de Google, mais 2,4 secondes d’attente, sur mobile, en 4G, ça se sent encore.
L’écart entre « conforme » et « instantané » est exactement là où se joue la perception de qualité. Et c’est là que la plupart des sites lâchent : ils visent le minimum réglementaire, parce que descendre plus bas demande un travail que les outils automatiques ne font pas à votre place. C’est précisément ce travail qui distingue un site dessiné d’un site assemblé.
Pas par magie, ni en cochant une case « optimiser » dans un constructeur. Par des choix d’architecture pris dès le premier jour, et tenus jusqu’à la livraison. Voici le détail, parce qu’un professionnel exigeant a le droit de savoir comment.
Un budget de performance fixé avant d’écrire la première ligne. On décide à l’avance du poids maximum d’une page, du nombre de scripts tolérés, de la taille des images. Ce budget devient une contrainte de conception, pas une vérification de dernière minute. Si une fonctionnalité fait exploser le budget, on cherche une autre façon de la faire, ou on y renonce.
Du statique, par défaut. Nos sites sont compilés en pages HTML servies telles quelles, sans base de données à interroger ni serveur à réveiller à chaque visite. Le navigateur reçoit du contenu prêt à afficher. C’est la base la plus rapide qui existe, et celle qui tombe le moins souvent en panne.
Des îlots interactifs, pas des pages interactives. Quand une partie de la page a besoin de JavaScript (une animation, un formulaire), on n’hydrate que ce morceau-là, et seulement quand il devient visible à l’écran. Le reste de la page reste du HTML pur. Résultat : le navigateur n’exécute presque rien au chargement, ce qui maintient le temps de blocage à zéro.
Des images traitées par Sharp. Chaque image est redimensionnée, recompressée et servie au bon format selon l’appareil. Une photo qui pèserait deux mégaoctets en sortie d’appareil descend à quelques dizaines de kilooctets, sans perte visible. C’est l’un des leviers les plus rentables sur le LCP.
Zéro décalage sur le titre. Le H1 et le sous-titre du haut de page sont du vrai texte HTML, rendu immédiatement, jamais masqué puis révélé par une animation. Les dimensions des images et des blocs sont réservées avant le chargement, pour que rien ne pousse rien. C’est ce qui nous donne un CLS de 0, et pas « proche de 0 ».
Les chiffres que ça produit, sur nos livraisons réelles : un LCP entre 2,0 et 2,4 secondes sur mobile, un CLS à 0, un temps de blocage (TBT) à 0 milliseconde, un score de performance Lighthouse entre 96 et 99, et une accessibilité à 100 sur 100. Ce dernier point compte autant que les autres : un site rapide mais illisible au lecteur d’écran n’est pas un site soigné.
À l’ère où n’importe qui peut produire un site en quelques minutes, ce qui vous distingue n’est plus d’avoir un site, mais d’en avoir un qui tient debout sous le poids du détail. La vitesse est la partie de ce détail qu’une machine sait mesurer. Elle ne ment pas. On ne peut pas la simuler avec un beau visuel ni la rattraper avec un slogan.
C’est pour ça qu’on la traite comme un livrable à part entière, au même titre que le design. L’IA nous aide à aller vite dans la fabrication, mais c’est un humain qui décide de ce qu’on garde et de ce qu’on jette, et c’est cette décision qui fait la différence entre un site qui respire et un site qui rame. Vous pouvez voir le détail de notre façon de travailler sur la page Méthode, et ce qu’on construit exactement dans nos services. Et parce qu’un site soigné est aussi un site qui vous appartient, tout ce qu’on livre (domaine, contenu, code) reste à vous dès le premier jour : c’est expliqué sur la page Garanties. Et si vous voulez en parler, on en discute volontiers via la page Contact.
Oui, mais indirectement. Les Core Web Vitals sont un signal de classement officiel : à contenu équivalent, Google favorise la page la plus rapide et la plus stable. Surtout, un site rapide retient ses visiteurs et en convertit davantage, et ce comportement réel pèse sur votre position au fil du temps. La vitesse n'est pas un raccourci magique vers la première place, c'est un fondement sur lequel le reste du référencement tient.
Deux outils gratuits de Google suffisent. PageSpeed Insights vous donne un diagnostic page par page, en laboratoire et sur données réelles. La Search Console, dans sa section « Signaux web essentiels », vous montre l'état de tout votre site selon les visites réelles de vos utilisateurs sur les vingt-huit derniers jours. Visez le vert sur les trois métriques, sur mobile en priorité, puisque c'est là que la majorité des gens vous consultent.
Les constructeurs grand public chargent le même socle technique lourd pour tous les sites, qu'on en ait besoin ou non : des scripts pour des fonctions que vous n'utilisez pas, des polices et des bibliothèques entières au cas où. Ce surpoids est le prix de la simplicité de l'éditeur. On peut l'atténuer, rarement l'effacer, parce qu'il est dans la fondation. Un site construit sur mesure part de zéro et ne porte que ce dont il a besoin.
Non, c'est même l'inverse pour qui sait faire. Les animations et les effets coûtent cher quand ils sont mal posés, presque rien quand ils s'appuient sur les bonnes propriétés et ne se déclenchent qu'au bon moment. Un site lent n'est pas un site « trop beau », c'est un site mal construit. La beauté et la vitesse se contredisent seulement quand on bricole. Si le sujet vous intéresse, parlons de votre projet : on en discute volontiers via la page Contact.
Un appel de 15 minutes suffit pour démarrer. Rien à signer.