Tu prospectes des agences, des restaurants, des cabinets, des e-commerçants. Tu ouvres ton fichier de 300 lignes et tu envoies le même message à tout le monde : « Bonjour, je propose [service], on échange ? ». Sur 300 envois, tu décroches trois réponses, dont deux pour te dire d'arrêter. Le problème n'est pas ton offre. Le problème, c'est que tu n'as rien à dire de précis sur le prospect que tu contactes. Tu démarches au hasard, et ça se sent à la première ligne.
Maintenant imagine que tu ouvres ton message avec une observation concrète sur leur site : « J'ai chargé votre page d'accueil depuis mon mobile, elle met près de six secondes à afficher l'image principale — j'ai regardé pourquoi, voici ce que j'ai vu. » Tu n'es plus un démarcheur parmi cent. Tu es quelqu'un qui a pris le temps de regarder, et qui arrive avec un constat utilisable. La performance du site d'un prospect est l'un des rares signaux à la fois public, mesurable et directement parlant — surtout si tu vends du dev, de la refonte, du SEO ou de l'optimisation.
Score perf mobile d'un prospect type — le genre de chiffre qui ouvre une conversation
La feature d'audit de vitesse d'outsend.xyz, en alpha gratuite, passe une liste entière de sites par l'API Google PageSpeed Insights et te rend un score de performance et les Core Web Vitals par ligne. Tu transformes une colonne « site web » en colonne « niveau de qualification » — et tu repères en un coup d'œil les prospects à qui tu as vraiment quelque chose à dire.
Ce que mesure un audit de vitesse de site
Un audit de vitesse ne se résume pas à « le site est lent ou rapide ». Google a normalisé trois métriques d'expérience utilisateur, les Core Web Vitals, qui mesurent trois choses différentes : la vitesse d'affichage, la réactivité, et la stabilité visuelle. Les seuils ci-dessous sont ceux publiés par Google sur web.dev (web.dev, Core Web Vitals), mesurés au 75e percentile des chargements de page.
| Métrique | Ce qu'elle mesure | Seuil « bon » |
|---|---|---|
| LCP Largest Contentful Paint |
Le temps avant que le plus gros élément visible (souvent l'image ou le titre principal) s'affiche. La perception « ça charge vite ». | < 2,5 s |
| INP Interaction to Next Paint |
Le délai entre une action de l'utilisateur (clic, tap, frappe) et la réponse visuelle de la page. La perception « ça réagit ». | < 200 ms |
| CLS Cumulative Layout Shift |
L'ampleur des décalages de mise en page pendant le chargement — le bouton qui saute au moment où tu vas cliquer. La perception « c'est stable ». | < 0,1 |
Ces trois métriques se synthétisent en un score de performance sur 100, calculé par Lighthouse, le moteur d'audit de Google. C'est le chiffre que tu vois sur la jauge en haut de page. Un site à 90+ est rapide, un site sous 50 a un vrai problème ressenti par ses visiteurs — et donc potentiellement par les clients de ton prospect.
Comment outsend audite une liste entière de sites
Auditer un site à la main, c'est faisable : tu ouvres PageSpeed Insights, tu colles l'URL, tu lis le rapport. Le problème commence à la ligne 50 de ton fichier. Personne ne va coller 300 URLs une par une, attendre chaque rapport, recopier le score à la main. C'est exactement ce goulot que la feature d'audit de vitesse d'outsend fait sauter.
Tu fournis une liste de sites (un par ligne, ou directement la colonne « site web » d'un fichier que tu as déjà extrait). Pour chaque URL, outsend interroge l'API Google PageSpeed Insights v5 et récupère le score de performance Lighthouse ainsi que les Core Web Vitals (LCP, INP, CLS) en données labo. À la sortie, ta liste s'enrichit de plusieurs colonnes : score sur 100, LCP, CLS, INP, et un statut lisible (bon / à améliorer / mauvais). Le tout exportable en CSV, JSON ou XLSX.
Concrètement, tu pars d'un fichier brut et tu obtiens une liste triable par score. Si tu n'as pas encore tes prospects, tu peux extraire une liste d'entreprises locales depuis Google Maps avec leurs sites, puis enchaîner l'audit de vitesse dans la foulée — c'est l'intérêt d'avoir le scraping et la qualification dans le même outil plutôt que dans trois abonnements séparés. L'audit de vitesse se chaîne naturellement avec les autres signaux de qualification : la détection de tech stack te dit avec quoi le site est construit (un WordPress lourd bourré de plugins explique souvent un mauvais score), et le dead check des URLs mortes écarte d'abord les sites qui ne répondent même plus.
Tester outsend gratuitement
Tout-en-un, FR-natif. Accès alpha gratuit sur candidature.
Demander un accès alpha gratuitDu score à l'accroche : constat factuel, pas leçon de morale
Voici la partie délicate, et le seul endroit où un audit de vitesse peut se retourner contre toi. Arriver en disant « votre site est lent » ne te rend pas plus crédible — ça te rend agaçant. Personne n'aime se faire pointer un défaut par un inconnu qui veut lui vendre quelque chose. Le score n'est pas une arme, c'est une matière à conversation.
La différence tient dans la formulation. Compare ces deux ouvertures, fondées sur le même chiffre :
- À éviter — « Votre site est trop lent, ça vous fait perdre des clients. Je peux régler ça. » C'est un jugement suivi d'une vente frontale. Le prospect se braque.
- À privilégier — « J'ai mesuré le temps de chargement de votre page d'accueil sur mobile : l'image principale met environ 5 s à s'afficher, là où Google considère qu'en dessous de 2,5 s l'expérience est bonne. Souvent c'est une question de format d'image, je vous dis ce que j'ai vu si ça vous intéresse. » C'est un constat sourcé, une piste, et une porte que le prospect peut ouvrir ou non.
La seconde version marche parce qu'elle est vérifiable (le prospect peut tester lui-même), située (sa page, son chiffre, pas une généralité) et non agressive (tu offres une observation, tu ne dénonces pas une faute). Tu te positionnes en personne qui a regardé, pas en commercial qui récite un script. C'est aussi une excellente manière de qualifier : un prospect dont le site est déjà à 95 n'a pas besoin de toi sur ce sujet — tu gardes ton énergie pour ceux à qui tu apportes vraiment quelque chose.
Cette logique s'inscrit dans un workflow plus large : tu peux brancher l'audit de vitesse dans un pipeline de prospection no-code qui extrait, qualifie par score, puis prépare l'envoi — à condition d'avoir vérifié la délivrabilité de ton propre domaine en amont, parce qu'une accroche parfaite qui tombe en spam ne sert à rien.
Les limites : un score bas n'est pas un besoin garanti
Sois honnête avec toi-même sur ce que le score dit et ne dit pas. Un site lent n'est pas automatiquement un prospect chaud, et trois nuances comptent.
Le score mesure une page, pas un business. Une page d'accueil à 38/100 peut appartenir à une entreprise qui se moque totalement de son site parce que tout son chiffre d'affaires vient du bouche-à-oreille ou d'une marketplace. Le besoin technique existe ; la volonté d'y investir, pas forcément.
Les données labo ne sont pas les données terrain. L'audit via l'API renvoie une mesure labo (un chargement simulé dans des conditions standard). C'est parfait pour comparer des sites entre eux à grande échelle, mais le vécu réel des visiteurs peut différer selon leurs appareils et connexions. Pour un diagnostic approfondi sur un prospect précis, le rapport complet d'expérience utilisateur réelle reste plus fin.
Le contexte du prospect prime sur le chiffre. Une page un peu lente sur un site refait il y a six mois est une mauvaise piste ; la même lenteur sur un site visiblement à l'abandon depuis trois ans, sur un secteur où la concurrence locale a des sites soignés, est une bien meilleure accroche. Le score t'oriente, ton jugement décide.
Autrement dit : l'audit de vitesse est un signal de priorisation, pas un verdict. Il te dit où regarder en premier, pas qui va signer.
FAQ — Auditer la vitesse d'un site de prospect
Quels sont les bons seuils des Core Web Vitals ?
Selon Google (web.dev), au 75e percentile des chargements : LCP sous 2,5 s, INP sous 200 ms, CLS sous 0,1. Au-dessus de ces seuils, l'expérience est jugée « à améliorer » ou « mauvaise ». Ces trois métriques se résument en un score de performance sur 100 calculé par Lighthouse.
Quelle différence entre le score sur 100 et les Core Web Vitals ?
Le score sur 100 est une note synthétique calculée par Lighthouse à partir de plusieurs mesures labo. Les Core Web Vitals (LCP, INP, CLS) sont trois métriques précises qui décomposent l'expérience : vitesse d'affichage, réactivité, stabilité. Le score donne la vue d'ensemble pour trier une liste ; les Vitals expliquent pourquoi un site est bien ou mal noté.
Est-ce légal d'auditer le site d'un prospect sans son accord ?
Oui. Un audit de vitesse charge une page web publique et mesure son temps de réponse — exactement comme n'importe quel visiteur ou n'importe quel navigateur. Aucune donnée privée, aucun accès au serveur, aucun cookie utilisateur n'est requis. C'est de l'observation de ressources publiques, sans implication RGPD particulière sur la mesure elle-même.
Combien de sites peut-on auditer en alpha ?
Sans plafond strict en alpha. Le rythme des appels à l'API PageSpeed Insights est régulé pour rester dans les limites de service de Google, donc une grosse liste s'étale dans le temps plutôt que de partir d'un bloc. Le résultat reste exportable en CSV, JSON ou XLSX.
L'audit ralentit-il ou perturbe-t-il le site du prospect ?
Non. La mesure passe par l'API Google PageSpeed Insights, qui réalise un chargement standard de la page, comme un visiteur unique. Ce n'est pas un test de charge : aucune sollicitation massive n'est envoyée au serveur cible.
Le score de vitesse suffit-il à qualifier un prospect ?
Non, et il ne faut pas le présenter comme tel. Le score est un signal de priorisation parmi d'autres : il te dit quels sites méritent un regard, mais le besoin réel dépend du contexte du prospect (secteur, dépendance au site, budget). Combiné à d'autres signaux — tech stack, secteur, fraîcheur du site — il devient un vrai critère de tri ; seul, c'est un indice, pas une certitude.