Presque toutes les pages Carrières modernes intègrent des données structurées lisibles par les machines décrivant le poste. Comprendre ce format vous offre un moyen fiable de surveiller les offres d'emploi sans analyser du HTML brut, et explique pourquoi Google Jobs est plus rapide que LinkedIn.
Presque chaque offre d'emploi que vous avez consultée contenait une version cachée d'elle-même à côté du HTML visible - une description claire et lisible par les machines du poste avec des champs structurés pour le titre, la localisation, la date de publication, la fourchette salariale et l'employeur. Cela s'appelle JSON-LD JobPosting, c'est intégré sous forme de balise script dans la page, et c'est la raison pour laquelle Google Jobs vous affiche une fiche avec une fourchette salariale et un horodatage « il y a 5 heures » tandis que LinkedIn vous dit encore que le poste a été publié « il y a 2 jours ».
Comprendre ce format vous apporte deux choses utiles. Cela vous explique pourquoi certains canaux sont structurellement plus rapides que d'autres (Google Jobs utilise directement JSON-LD ; LinkedIn non). Et cela vous offre un moyen propre de surveiller les pages Carrières des entreprises sans essayer d'analyser du HTML qui n'a pas été conçu pour être analysé.
JSON-LD (« JSON for Linked Data ») est un moyen d'intégrer des données lisibles par les machines dans une page web. Le schéma JobPosting, défini sur schema.org/JobPosting, est l'un des dizaines de types que Google utilise pour ingérer des informations structurées du web.
Pourquoi chaque entreprise l'émet : Google l'exige. Si un poste ne dispose pas d'un bloc JSON-LD JobPosting valide, il n'apparaît pas dans Google Jobs - et Google Jobs est de plus en plus le point de départ des candidats. Ainsi, chaque ATS moderne (Workday, Greenhouse, Lever, Ashby, Phenom, iCIMS) émet ces données structurées sur ses pages de publication, que l'employeur le demande ou non.
Si vous affichez le code source d'une offre d'emploi typique hébergée sur Greenhouse et recherchez application/ld+json, vous verrez quelque chose de similaire à ceci :
{
"@context": "https://schema.org",
"@type": "JobPosting",
"title": "Senior Backend Engineer",
"description": "We're looking for...",
"datePosted": "2026-05-12",
"validThrough": "2026-08-12",
"employmentType": "FULL_TIME",
"hiringOrganization": {
"@type": "Organization",
"name": "Acme",
"sameAs": "https://acme.example"
},
"jobLocation": {
"@type": "Place",
"address": {
"@type": "PostalAddress",
"addressLocality": "London",
"addressCountry": "GB"
}
},
"baseSalary": {
"@type": "MonetaryAmount",
"currency": "GBP",
"value": {
"@type": "QuantitativeValue",
"minValue": 90000,
"maxValue": 130000,
"unitText": "YEAR"
}
}
}Les champs sont largement explicites. Les deux qui vous intéresseront le plus en tant que chercheur d'emploi sont datePosted (l'horodatage canonique « quand ce poste a-t-il été publié ») et baseSalary (lorsqu'il est présent ; les offres d'emploi au Royaume-Uni, avec les récentes mesures de transparence, et les lois californiennes sur la transparence des salaires exigent de plus en plus son inclusion).
Trois raisons pratiques.
Le champ datePosted est l'horodatage de référence. Lorsqu'un agrégateur indique qu'un poste a été « publié il y a 3 jours », il affiche la date à laquelle il l'a ingéré pour la première fois, pas la date à laquelle l'entreprise l'a effectivement publié. Le JSON-LD sur la propre page de l'entreprise vous donne le vrai chiffre. Notre mesure du délai ATS-LinkedIn repose sur cette comparaison.
Google Jobs ingère directement via JSON-LD. Dès que Googlebot explore une page Carrières (ce qui se produit en quelques heures pour la plupart des sites d'entreprises), le poste apparaît dans les résultats de recherche Google Jobs. LinkedIn et Indeed doivent effectuer leur propre exploration, analyse, déduplication et classification, ce qui explique leur retard de 1 à 5 jours. L'analyse du coût du retard des agrégateurs détaille ce point.
Si vous mettez en place une surveillance quelconque, JSON-LD est nettement préférable à l'analyse de HTML brut. Les données sont déjà structurées. Vous n'avez pas besoin de sélecteurs CSS qui cassent quand l'entreprise redesigne sa page Carrières. Il suffit de chercher les blocs <script type="application/ld+json"> et de les analyser comme du JSON.
Dans n'importe quel navigateur :
application/ld+json."@type": "JobPosting" correspond aux données du poste.Vous pouvez le valider avec l'outil Rich Results Test de Google, qui confirme à la fois que le JSON-LD est bien formé et vous indique si Google Jobs l'indexerait.
Notre référence complète des ATS couvre comment identifier quel système une entreprise utilise.
Pour les lecteurs techniques, voici la structure générale d'un script Python qui surveille une seule page Carrières pour détecter de nouvelles entrées JSON-LD JobPosting :
import json, re, requests, hashlib
from bs4 import BeautifulSoup
def fetch_postings(url):
html = requests.get(url, headers={"User-Agent": "Mozilla/5.0"}).text
soup = BeautifulSoup(html, "html.parser")
out = []
for tag in soup.find_all("script", type="application/ld+json"):
try:
data = json.loads(tag.string)
except (json.JSONDecodeError, TypeError):
continue
items = data if isinstance(data, list) else [data]
for item in items:
if item.get("@type") == "JobPosting":
out.append(item)
return out
# À exécuter selon un calendrier ; comparer avec l'exécution précédente ; envoyer les nouvelles entrées par e-mail.
La machinerie complète (gestion des pages rendues en JavaScript, respect des limites de requêtes, déduplication entre les exécutions, analyse des salaires dans un format interrogeable) est simple mais plus élaborée. Notre guide complet sur la surveillance des pages Carrières compare cette approche avec les alternatives.
Si vous recherchez principalement sur des agrégateurs, vous êtes inhéremment en aval des données structurées que l'entreprise a déjà publiées. Le même JSON-LD qui a alimenté Google Jobs le jour où le poste a été mis en ligne se trouve sur la page de l'entreprise en attente d'être lu, et c'est la copie réduite, classifiée et en retard d'un jour de l'agrégateur que vous consultez à la place.
L'implication pratique : Google Jobs est structurellement plus rapide que LinkedIn ou Indeed en raison du fonctionnement du pipeline. Pour les postes où la candidature le jour même compte, préférez Google Jobs à la recherche LinkedIn si vous n'utilisez pas la surveillance directe de l'ATS. Notre comparaison des trois approches détaille les compromis pratiques.
JSON-LD JobPosting est la brique silencieuse qui se trouve sous la majeure partie de l'infrastructure moderne de recherche d'emploi. Les mêmes données qui ont alimenté Google Jobs à l'instant où un poste a été mis en ligne se trouvent sur la page de l'entreprise en attente d'être lues. Les agrégateurs ajoutent leurs propres couches d'ingestion, d'analyse, de déduplication et de classification par-dessus - c'est pourquoi ils ont un ou deux jours de retard sur la source canonique.
Pour la plupart des candidats, l'implication pratique est plus simple que l'histoire technique : si vous choisissez entre différents canaux de recherche d'emploi, Google Jobs est structurellement plus frais que LinkedIn parce qu'il lit directement le JSON-LD. Si vous mettez en place votre propre surveillance, JSON-LD est ce qu'il faut lire - pas le HTML rendu, et certainement pas la copie indexée des agrégateurs.