Un site statique peut être mis en ligne en quelques minutes. La question utile arrive juste après : que fait le lien une fois partagé ?
Est-ce que quelqu'un l'ouvre ? D'où viennent les visites ? La page d'accueil est-elle vraiment l'entrée principale ? Le site est-il surtout consulté sur mobile ? Une image lourde, un PDF ou une vidéo commence-t-il déjà à consommer beaucoup de bande passante ?
Pour répondre à ces questions, un projet n'a pas forcément besoin d'une pile d'analyse complète dès la première heure. Il lui faut d'abord des statistiques simples, lisibles, reliées au site publié.
Commencer par la question du site
Les statistiques deviennent vite confuses si toutes les valeurs semblent avoir la même importance.
Un site statique a souvent une mission précise : montrer un portfolio, envoyer un CV en ligne, valider une landing page, partager une prévisualisation client, publier une documentation, tester un export généré par IA ou mettre un projet étudiant à disposition.
La première lecture doit suivre cette mission.
| Type de site | Question à poser en premier | Indicateurs à regarder |
|---|---|---|
| Portfolio | Le lien a-t-il été ouvert par les bonnes personnes ? | Visiteurs, sources, pages principales, appareils |
| Landing page | Quel canal apporte du trafic ? | Sources, liens UTM, pays, pages principales |
| CV en ligne | Le recruteur peut-il lire la page correctement ? | Appareils, navigateurs, pages vues |
| Prévisualisation client | La bonne version a-t-elle été consultée ? | Visites récentes, pays, appareils, pages |
| Documentation | Les visiteurs arrivent-ils sur la bonne page ? | Pages principales, sources, chemins inattendus |
| Site avec images ou PDF | Le poids des fichiers devient-il visible ? | Bande passante, pages principales, taille des ressources |
Si vous ne savez pas ce que le site doit prouver, le tableau de bord ne décidera pas à votre place. Vous risquez seulement de regarder une courbe monter ou descendre sans savoir quelle action prendre.
Pages vues et visiteurs ne racontent pas la même chose
Les pages vues indiquent combien de fois une page a été chargée. Les visiteurs donnent une idée plus proche du nombre de personnes, navigateurs ou sessions distinctes qui ont atteint le site.
Les deux valeurs sont utiles, mais elles ne doivent pas être lues comme une seule métrique.
Au lancement, vous, votre équipe, un client ou un enseignant pouvez recharger plusieurs fois la même page. Les pages vues montent, sans que l'audience réelle augmente vraiment. À l'inverse, un site peut avoir peu de vues, mais plusieurs visiteurs venus de sources différentes. Pour un portfolio, un CV ou une page de test, ce signal peut déjà compter.
| Indicateur | Utile pour | Erreur fréquente |
|---|---|---|
| Pages vues | Activité globale et intérêt par URL | Confondre rechargements et nouvelle audience |
| Visiteurs | Taille approximative de l'audience | Le prendre comme un nombre exact de personnes |
| Pages principales | URL réellement consultées | Ne regarder que la page d'accueil |
| Bande passante | Poids des ressources et pression sur l'offre | Découvrir trop tard qu'une page est lourde |
Les outils n'utilisent pas tous les mêmes mots. Google Analytics 4 fonctionne autour d'événements, dont page_view pour une page chargée. Des outils plus légers comme Plausible ou Cloudflare Web Analytics mettent surtout en avant pages vues, visiteurs, référents, pays, appareils et navigateurs.
Le nom exact de l'indicateur compte moins que la lecture croisée. Une statistique isolée peut tromper. Pages vues, visiteurs, sources et pages principales racontent une histoire plus fiable lorsqu'elles sont regardées ensemble.
Dans DeployPages, les statistiques d'un projet affichent pages vues, visiteurs estimés, bande passante, pages principales, référents, pays, appareils, navigateurs, systèmes d'exploitation et visites récentes. Pour un site statique fraîchement publié, c'est généralement assez pour prendre les premières décisions.
Les sources de trafic montrent si la diffusion a fonctionné
Beaucoup de petits lancements ne souffrent pas d'un problème technique. Personne n'a simplement vu le lien, ou il a été partagé au mauvais endroit.
Les sources de trafic permettent de séparer ces cas.
| Observation | Ce que cela peut vouloir dire | Prochaine action |
|---|---|---|
| Beaucoup de direct | E-mail, messagerie, QR code, lien copié ou référent absent | Ajouter des paramètres UTM aux prochains liens |
| Un réseau social domine | La publication ou le partage secondaire fonctionne | Regarder les pages et appareils associés |
| La recherche apparaît | La page commence à être trouvée hors du partage initial | Vérifier title, description et nom de domaine |
| Domaine interne ou client | La revue est en cours | Ne pas le mélanger avec le trafic public |
| Référents étranges | Bruit, bots ou trafic sans intérêt | Ne pas réécrire la page pour ce signal |
Si la même page part dans une newsletter, un QR code, un post LinkedIn et un lien de bio, préparez les URL en amont. Le générateur UTM permet de nommer la source, le support et la campagne. Ce n'est pas une garantie d'attribution parfaite, mais cela évite beaucoup de suppositions après coup.
Les appareils et navigateurs indiquent où tester
Un site statique est souvent construit sur un écran large et jugé sur un téléphone.
Un portfolio peut être équilibré sur desktop et devenir un très long défilement sur mobile. Une landing page peut garder son bouton principal visible sur un grand écran, mais le pousser sous la ligne de flottaison sur un téléphone. Un CV en ligne peut sembler propre dans Chrome sur ordinateur et trop serré dans Safari mobile.
Les données d'appareil, de navigateur et de système ne remplacent pas un vrai test. Elles disent où faire ce test en premier.
Si la majorité des visites est mobile, ouvrez le lien public sur un vrai téléphone avant de refaire la mise en page. Si Safari iOS revient souvent, contrôlez les images, les vidéos, les zones tactiles et les polices dans cet environnement. Si une revue client arrive depuis un navigateur plus ancien, évitez de transformer la validation en discussion de compatibilité.
Cette information vaut mieux qu'un conseil générique. Elle parle du site qui vient d'être publié, pas d'une moyenne abstraite.
Les pages principales révèlent les fausses hypothèses
Vous pouvez prévoir une entrée principale et découvrir que les visiteurs arrivent ailleurs.
Un lien profond circule dans un message. Un QR code pointe vers un chemin de campagne. Un ancien document contient encore une URL. Un moteur de recherche trouve d'abord un article. Un site généré par IA garde un chemin de test dans sa navigation.
Les pages principales sont particulièrement utiles après :
- un nouveau téléversement ;
- le passage d'un lien de prévisualisation à un nom de domaine ;
- une migration depuis GitHub Pages, un ancien portfolio ou une documentation ;
- une campagne avec plusieurs liens ;
- un changement de navigation, de chemins de fichiers ou de
index.html; - la mise en ligne de PDF, images ou fichiers téléchargeables.
Une page secondaire en tête du classement n'est pas forcément un problème. Elle peut être la vraie page d'entrée. Le problème apparaît lorsque les URL visibles sont anciennes, cassées, trop lourdes ou pas prêtes à être montrées.
La bande passante mérite d'être surveillée tôt
La bande passante paraît moins parlante que les visiteurs. Pour un site statique, elle peut pourtant devenir le premier signal de coût ou de performance.
Les fichiers statiques se distribuent bien, mais les grandes images, les PDF, les arrière-plans vidéo, les polices lourdes et les exports non compressés peuvent peser vite. Tant que trois personnes regardent une prévisualisation, cela passe inaperçu. Dès que la page circule dans une campagne, un portfolio ou un QR code, le sujet revient.
Surveillez la bande passante si :
- le site contient beaucoup de photos, captures ou images produit ;
- des PDF, menus, decks ou fichiers médias sont publiés avec le site ;
- une campagne peut créer un pic court ;
- le projet approche les limites de l'offre ;
- l'audience consulte surtout depuis mobile.
La bande passante ne désigne pas automatiquement le fichier fautif. Elle sert d'alerte. Il faut ensuite regarder dimensions d'image, compression, lazy loading, polices, vidéos et emplacement des fichiers lourds.
Statistiques intégrées d'abord, analyse complète ensuite
Google Analytics, Matomo, Plausible, Fathom, Simple Analytics ou PostHog ont chacun leur place. La question est de savoir quand les ajouter.
Au début, les questions sont souvent simples :
- Le lien s'ouvre-t-il ?
- D'où viennent les visites ?
- Quelles URL sont consultées ?
- Le trafic est-il plutôt mobile ou desktop ?
- Les visites viennent-elles des pays attendus ?
- Le poids du site reste-t-il raisonnable ?
Des statistiques intégrées répondent bien à cette première couche, parce qu'elles sont liées au projet publié. Vous téléversez un dossier, obtenez un lien HTTPS, le partagez, puis lisez les premiers signaux sans modifier les fichiers statiques pour y ajouter un script tiers.
Un outil d'analyse complet devient utile quand les questions changent : clics sur des boutons, tunnels de conversion, tests A/B, suivi publicitaire, comportement de comptes connectés, événements e-commerce ou analyse produit. Là, un outil spécialisé est le bon endroit.
Il vaut mieux garder les deux niveaux séparés. Les statistiques de publication répondent : le site publié est-il vu ? L'analyse produit répond : que font les visiteurs une fois arrivés ?
RGPD, cookies et mesure d'audience : rester précis
En France, les statistiques de site web sont vite associées au RGPD, aux cookies, aux traceurs et aux recommandations de la CNIL. Il faut donc éviter les raccourcis.
Une statistique de lancement et une mesure marketing détaillée ne soulèvent pas toujours les mêmes questions.
| Niveau | Question principale | Exemples |
|---|---|---|
| Statistiques de lancement | Le lien public a-t-il été consulté ? | Pages vues, sources, appareils, pays, bande passante |
| Analyse marketing ou produit | Que fait l'utilisateur dans le détail ? | Événements, conversions, tests A/B, segments, publicité |
DeployPages fournit une première lecture liée au projet publié. Cela ne remplace pas une revue juridique. Si vous ajoutez Google Analytics, Matomo, Plausible, Fathom, un pixel publicitaire, une carte de chaleur ou un script externe, vérifiez les données collectées, les cookies ou traceurs utilisés, l'information donnée aux visiteurs et votre politique de confidentialité.
Le bon ton n'est pas de promettre une conformité automatique. Le bon ton est de savoir quelle couche vous utilisez, pourquoi, et ce que vous devez documenter.
Une routine simple pour la première semaine
Un site statique ne demande pas un suivi permanent. Quelques vérifications suffisent souvent.
| Moment | À regarder | Pourquoi |
|---|---|---|
| Première heure | Ouverture de la page, 404, chemins d'images ou de scripts | Corriger avant que le lien circule |
| Premier jour | Sources, appareils, pages principales | Vérifier distribution et expérience réelle |
| Première semaine | Tendance, pays, bande passante, pages qui restent actives | Décider d'améliorer, conserver ou remplacer |
| Après un nouveau téléversement | Pages principales et visites récentes | Vérifier que la nouvelle version n'a pas cassé une URL utile |
| Après connexion du domaine | Direct, recherche, anciennes URL | Voir si l'adresse officielle remplace le lien de test |
L'objectif n'est pas de transformer un petit site en tableau de reporting. L'objectif est de savoir où agir : corriger un chemin, alléger une image, changer un lien partagé, ajouter un domaine ou passer à un outil d'analyse plus poussé.
La place de DeployPages dans ce flux
DeployPages place les statistiques dans la continuité de la mise en ligne.
Vous pouvez publier un dossier statique, un ZIP, un build frontend, un export généré par IA, une page avec PDF ou un portfolio, puis consulter dans le projet les pages vues, visiteurs estimés, sources, pages principales, pays, appareils, navigateurs, systèmes, bande passante et visites récentes.
Le même projet peut ensuite évoluer vers un nom de domaine personnalisé, une protection par mot de passe, un retour à une version précédente, un déploiement CLI ou des statistiques consultées plus régulièrement.
Ce chemin convient bien aux sites statiques : publier vite, observer les premiers signaux, puis décider si le projet mérite une configuration plus durable.