Vous ouvrez le code source d'une page et vos données n'y sont pas, alors qu'elles s'affichent à l'écran. C'est le problème le plus courant d'une collecte, et la réponse n'est presque jamais celle qu'on vous vendra en premier.
Publié le
Presque tout le monde se trompe de test, et ce n’est pas une question de compétence : les deux outils du navigateur se ressemblent et ne montrent pas la même chose.
L’inspecteur d’éléments montre la page après l’exécution du code. Vos données y sont toujours, puisque c’est ce que vous avez sous les yeux. Il ne prouve donc rien.
Le code source affiche ce que le serveur a réellement envoyé, avant toute exécution. C’est le seul qui réponde à la question.
Ouvrez le code source, cherchez une valeur précise que vous voyez à l’écran, un prix ou une référence. Si elle y est, votre page n’est pas concernée par ce que décrit cette page, et une collecte simple suffira. Si elle n’y est pas, les données arrivent séparément. Les décisions commencent là.
Le test complémentaire
Désactivez JavaScript dans votre navigateur et rechargez. Ce que vous voyez alors est exactement ce que voit un collecteur simple. C’est souvent plus parlant qu’un code source de dix mille lignes.
Les articles sur le sujet présentent deux options, l’appel interne ou le navigateur automatisé. La réalité en compte cinq, et deux d’entre elles ne demandent aucun des deux.
| Ce que vous observez | Ce que ça veut dire | La voie |
|---|---|---|
| La valeur est dans le code source | Le serveur envoie tout | Lecture directe, aucun surcoût |
| Le code source contient un gros bloc de données structurées | Rendu côté serveur, page hydratée ensuite | Lecture directe du bloc, voir le piège plus bas |
| Un appel en arrière-plan renvoie du JSON lisible | Appel interne exploitable | Rétro-ingénierie de l’appel |
| L’appel existe mais exige un jeton ou une signature | Appel verrouillé | Reproduire la séquence, ou navigateur |
| Rien ne se charge sans interaction ou défilement | Contenu déclenché par l’usage | Navigateur automatisé |
Les trois premières lignes couvrent la majorité des cas rencontrés, et aucune ne justifie un navigateur. C’est la raison pour laquelle le diagnostic vaut le temps qu’il prend : il arbitre entre des solutions dont le coût varie d’un facteur cinquante.
Vous ne savez pas dans quelle ligne vous tombez ? C’est exactement la vérification que nous faisons avant de chiffrer, et elle n’est pas facturée.
Demander un devisC’est la deuxième ligne du tableau, et le cas le plus mal traité de tout le sujet.
Beaucoup de sites récents sont construits avec des cadriciels qui produisent la page côté serveur, puis la réactivent côté navigateur. Next.js et Nuxt fonctionnent ainsi. Vu de l’extérieur, le site paraît entièrement dynamique : il navigue sans recharger, l’interface réagit, tout crie « JavaScript ».
Sauf que le premier chargement, lui, contient déjà tout. Les données sont dans la page, souvent regroupées dans un unique bloc de données structurées destiné à réactiver l’affichage. Il suffit de le lire.
Le symptôme est facile à reconnaître : le code source ne ressemble à rien de lisible, mais il contient un long passage de données nommées et typées, très loin de la mise en page. C’est exactement ce qu’on cherche, et mieux encore qu’un appel interne : aucune requête supplémentaire n’est nécessaire.
Des projets entiers font tourner un navigateur complet pour des pages qu’une requête HTTP ordinaire aurait suffi à lire. Le diagnostic a pris trente secondes de trop.
Les ordres de grandeur, pour une même collecte, rapportés à la lecture directe.
| Voie | Vitesse relative | Mémoire par tâche | Sensibilité aux changements |
|---|---|---|---|
| Lecture directe du HTML | référence | quelques mégaoctets | forte, une refonte casse tout |
| Appel interne | 10 à 100 fois plus rapide | quelques mégaoctets | faible sur le visuel, nulle garantie de stabilité |
| Navigateur automatisé | 10 à 50 fois plus lent | plusieurs centaines de mégaoctets | faible, il voit ce que voit un humain |
Ce n’est pas seulement une question de facture. Un navigateur qui consomme cent fois plus de ressources par page impose aussi une charge cent fois plus lourde au site visité. Raison suffisante pour ne pas s’en servir par défaut, indépendamment du budget.
Dans l’ordre, et on s’arrête à la première réponse positive.
Un prestataire qui commence par l’étape 4 sans avoir fait les trois premières vous vend de l’infrastructure dont vous n’avez pas besoin. La question à lui poser est simple : par quelle étape avez-vous commencé.
Envoyez l'adresse d'une page et les champs voulus. Nous faisons le diagnostic et nous vous disons quelle voie s'applique, sans frais et avant tout devis.