Comment créer un site web agrégateur : guide pratique

Notre position : nous sommes Geonode et nous vendons des proxys, qui constituent l’un des éléments d’un agrégateur et celui sur lequel la plupart des guides mettent trop l’accent. Il convient donc d’être clair dès le départ : les proxys sont la dernière chose que vous devriez acheter, pas la première. Une grande partie des données agrégables est disponible via des flux, des API et des plans de site qui sont gratuits, structurés, stables et explicitement proposés à cette fin. Développer un robot d’indexation pour du contenu publié sous forme de flux RSS est un travail inutile, et acheter de la bande passante avant de l’avoir découvert est un gaspillage d’argent. Les proxys ne deviennent pertinents qu’à un moment précis — lorsque vous effectuez un crawling à grande échelle, depuis plusieurs régions, sur des sites qui limitent le débit — et ce moment survient plus tard que la plupart des gens ne le pensent. Vous trouverez ci-dessous une section expliquant exactement où se situe cette limite.

Quel type d’agrégateur : quatre modèles

Ces modèles présentent des aspects économiques et des risques juridiques différents, et les confondre constitue la première erreur.

Les agrégateurs de liens collectent des titres et renvoient vers des liens externes. Faible besoin de stockage, faible risque juridique, faibles coûts de changement pour les utilisateurs. La valeur réside entièrement dans la sélection et la rapidité. C’est principalement dans cette catégorie que se situent les agrégateurs d’actualités et de contenus.

Les agrégateurs d’annonces collectent des fiches structurées — offres d’emploi, biens immobiliers, voitures, événements — et les présentent sous la forme d’une base de données consultable. Valeur ajoutée plus élevée, effort plus important, et modèle dans lequel la déduplication devient le principal défi technique.

Les agrégateurs de prix suivent l’évolution du prix d’un même article chez différents vendeurs. C’est le domaine le plus restreint et le plus difficile : faire correspondre des produits proposés par des détaillants qui les décrivent différemment est un véritable casse-tête, et les exigences en matière d’actualité sont impitoyables, car un prix obsolète est pire que l’absence de prix.

Les agrégateurs d’avis et de notes combinent des données d’opinion. Une couverture clairsemée, un travail de normalisation considérable, et ce sont eux qui sont les plus exposés aux accusations de déformation de la source.

Faites votre choix de manière réfléchie. L’architecture diffère, l’analyse juridique diffère, et c’est en voulant créer « un agrégateur pour tout » que les projets deviennent impossibles à mener à bien.

Commencez par obtenir les données de la manière la plus simple

Par ordre de préférence. Parcourez cette liste et arrêtez-vous dès qu’une solution fonctionne.

API officielles. Si la source en publie une, utilisez-la. Elle est stable, structurée, validée, et quelqu’un la corrigera en cas de dysfonctionnement. Lisez les conditions d’utilisation : la plupart limitent la redistribution, la durée de mise en cache et l’utilisation commerciale, et ces restrictions influencent la conception de votre produit.

Flux de partenaires ou d’affiliés. De nombreux secteurs publient des flux en masse spécialement destinés aux agrégateurs, car ceux-ci leur apportent du trafic. Les sites d’offres d’emploi, les portails immobiliers, les détaillants et les voyagistes disposent souvent d’un programme de partenariat qui vous fournit l’intégralité du jeu de données. C’est la source la plus sous-utilisée dans ce domaine, et la raison en est que les gens recherchent « comment extraire X » au lieu d’envoyer un e-mail à X pour demander s’ils disposent d’un flux. Demandez. Un nombre surprenant d’entre eux répondent par l’affirmative.

Flux RSS et Atom. Toujours largement diffusés, toujours idéaux pour l’agrégation de liens. Structurés, peu coûteux, conçus précisément à cet effet et proposés sans ambiguïté à la consommation.

Les plans de site. sitemap.xml vous fournit une liste complète d’URL ainsi que des horodatages lastmod, ce qui vous permet d’effectuer un crawl efficace plutôt que par force brute. Même lorsque vous devez effectuer un crawl, le plan de site vous indique ce qui a changé afin que vous ne récupériez que ces éléments.

Données structurées dans la page. Avant d’écrire des analyseurs HTML, vérifiez la présence de JSON-LD dans un bloc <script type="application/ld+json">. Le balisage Schema.org pour JobPosting, Product, Event et Recipe est très répandu car il alimente les fonctionnalités de recherche et vous fournit des données structurées propres à partir d’une page que vous alliez de toute façon récupérer. Il résiste également bien mieux aux refontes que les sélecteurs CSS.

L'analyse syntaxique du HTML. Dernier recours. Méthode fragile, exigeant beaucoup de maintenance, et qui transforme la gestion d’un agrégateur en un travail à plein temps.

L’ordre dans lequel ces éléments sont classés importe plus que n’importe quel élément pris individuellement. Les équipes qui commencent par le bas de cette liste développent d’abord un robot d’indexation, puis découvrent le flux six mois plus tard.

Quand il faut explorer un site : le fichier robots.txt est désormais une norme Le fichier

robots.txt a cessé d’être une simple convention en 2022. La RFC 9309 normalise le protocole d’exclusion des robots (Robots Exclusion Protocol) et, si vous développez un robot d’exploration, elle définit le comportement que vous devez mettre en œuvre.

Quatre exigences qu’il convient de connaître précisément :

La correspondance s’effectue par spécificité, et non par ordre. « La correspondance la plus spécifique trouvée DOIT être utilisée. La correspondance la plus spécifique est celle qui comporte le plus d’octets. » Ce n’est pas la première correspondance trouvée qui l’emporte, contrairement à ce que supposent de nombreux analyseurs syntaxiques développés manuellement.

La mise en cache ne doit pas dépasser 24 heures. « Les robots d’exploration NE DOIVENT PAS utiliser la version mise en cache pendant plus de 24 heures, sauf si le fichier robots.txt est inaccessible. » Le récupérer une seule fois au moment du déploiement n’est pas conforme.

Les erreurs serveur impliquent l’arrêt. « Si le fichier robots.txt est inaccessible en raison d’erreurs de serveur ou de réseau…… le robot d’indexation DOIT considérer que l’accès est totalement interdit.” Un code 5xx signifie qu’il faut renoncer complètement. Un code 404, en revanche, signifie qu’il n’y a pas de restrictions : le fichier n’existe pas, donc rien n’est interdit.

Analyser au moins 500 KiB. « La limite d’analyse DOIT être d’au moins 500 kibibytes. » Les grands sites ont des fichiers volumineux.

Utilisez une bibliothèque mise à jour plutôt que d’écrire ce code vous-même. La règle de correspondance des spécificités est à elle seule une source courante de bogues, et un robot d’indexation qui interprète mal un « robots.txt » est un robot qui génère des plaintes.

Au-delà du fichier lui-même, respectez les règles de courtoisie élémentaires : identifiez-vous avec un véritable agent utilisateur comprenant une URL de contact, respectez les balises Crawl-delay lorsqu’elles sont présentes, arrêtez net en cas de codes d’erreur 429 et 503, et mettez en cache pour ne jamais récupérer deux fois un contenu inchangé. Les requêtes conditionnelles avec If-Modified-Since ou If-None-Match ne coûtent rien à la source et ne vous coûtent rien non plus. La plupart des sites qui bloquent les agrégateurs le font en raison de leur comportement, et non de leur existence.

L’aspect juridique : droits d’auteur, clauses d’exclusion du TDM et droits sur les bases de données

Ceci ne constitue pas un avis juridique, et la juridiction applicable revêt une importance capitale. Il y a toutefois quatre points qu’il convient de comprendre avant de se lancer dans le développement.

Les faits ne sont généralement pas protégés par le droit d’auteur ; l’expression, en revanche, l’est. Un intitulé de poste, un salaire, un prix et une date sont des faits. La description rédigée pour promouvoir le poste relève de l’expression. L’agrégation des premiers repose sur des bases bien plus solides que la reproduction des seconds. Cette simple distinction détermine la conception la plus judicieuse d’un agrégateur : stocker les faits structurés, et renvoyer vers la source pour le texte.

La longueur des extraits a son importance. Reproduire un titre et une phrase accompagnés d’un lien n’est pas la même chose que reproduire un article. Plusieurs juridictions ont statué sur la limite à respecter, et les réponses divergent. Plus c’est court, plus c’est sûr, et créer un lien plutôt que de reproduire le contenu est la solution la plus sûre.

L’UE dispose d’une clause d’exemption relative à l’exploration de textes et de données, conçue pour être lisible par machine. L’article 4 de la directive (UE) 2019/790 autorise l’exploration de textes et de données par toute personne, à condition que les titulaires de droits n’aient pas expressément réservé leurs droits « de manière appropriée, par exemple en utilisant des moyens lisibles par machine ». Pour les contenus mis à disposition du public en ligne, la directive considère que la réserve lisible par machine — « y compris les métadonnées et les conditions générales d’un site web ou d’un service » — constitue la voie appropriée. L’exception exige également que l’accès au contenu ait été obtenu de manière licite.

Conséquence pratique pour un robot d’indexation : les réserves exprimées sous une forme lisible par machine doivent être respectées, et l’UE s’efforce de normaliser les protocoles permettant de les exprimer. Développer un robot d’indexation qui ignore les réserves lisibles par machine revient à intégrer un problème de conformité dès la conception.

L’UE dispose également d’un droit distinct sur les bases de données. Au-delà du droit d’auteur, la directive sur les bases de données a créé un droit sui generis protégeant les investissements substantiels réalisés pour obtenir, vérifier ou présenter le contenu d’une base de données — indépendamment du fait que ce contenu soit lui-même susceptible d’être protégé par le droit d’auteur. Cela concerne directement les agrégateurs, car l’extraction d’une partie substantielle de la base de données d’annonces d’un tiers peut faire jouer ce droit, même lorsque chaque annonce individuelle ne constitue qu’un simple fait.

Viennent ensuite les conditions d’utilisation, qui relèvent du contrat plutôt que de la loi, et que de nombreux sites utilisent pour interdire purement et simplement l’accès automatisé. La question de savoir si une clause vous lie alors que vous n’avez jamais cliqué sur quoi que ce soit est véritablement controversée et varie selon les juridictions. Lisez-les quand même : elles vous indiquent comment le site réagira, ce qui est souvent plus pertinent dans l’immédiat que ce qu’en dirait un tribunal.

En résumé, d’un point de vue pragmatique : privilégiez les sources autorisées, stockez des faits plutôt que des textes, créez des liens plutôt que de reproduire, respectez les restrictions lisibles par machine et demandez conseil pour toute question ayant une importance commerciale.

Architecture : quatre étapes, dont une difficile

Tous les agrégateurs suivent les quatre mêmes étapes, dont une seule est difficile.

Récupération. Récupérer le contenu brut. Points à prendre en compte : planification, limitation de débit, tentatives de réessai, mise en cache, requêtes conditionnelles. Toujours stocker la réponse brute : en cas de défaillance d’un analyseur, il vaut mieux réanalyser les données historiques plutôt que de les récupérer à nouveau.

Analyse. Transformer le contenu brut en enregistrements structurés. Points à surveiller : fragilité et détection des changements. Il faut être alerté lorsque le format de sortie d’un analyseur change plutôt que lorsqu’il génère une exception, car l’échec le plus coûteux est celui d’un analyseur qui commence silencieusement à renvoyer moins de champs.

Normalisation et déduplication. L’étape difficile. Détaillée ci-dessous.

Mise à disposition. Recherche, filtrage, affichage. Ingénierie web standard, et la partie dans laquelle la plupart des équipes investissent trop tôt, car c’est la partie visible.

C’est la déduplication qui fait la différence pour les agrégateurs. Une même offre d’emploi est publiée sur quatre sites avec des intitulés différents. Un même bien immobilier apparaît chez trois agents immobiliers à des prix différents. Un même produit porte un nom différent chez chaque détaillant. Les utilisateurs vous jugent presque exclusivement sur ce point : un site d’annonces affichant six fois la même chose est perçu comme défaillant, quelle que soit son exhaustivité.

L’approche qui fonctionne est par couches, en commençant par la moins coûteuse :

Identifiants exacts. ISBN, références, numéros d’immatriculation, identifiants source. Lorsqu’ils existent, utilisez-les et n’allez pas plus loin : ils résolvent complètement le problème.

Clés normalisées. Construisez une clé canonique à partir de champs en minuscules, sans espaces et sans ponctuation : employeur + intitulé du poste + lieu ; code postal + nombre de chambres + surface habitable. Cela permet de couvrir une grande partie des cas à moindre coût.

Correspondance approximative. Similitude basée sur des tokens pour les titres et les descriptions, avec un seuil que vous ajustez à partir d’un échantillon étiqueté manuellement. Indispensable mais coûteux ; limitez-la aux candidats qui partagent déjà une clé approximative, sinon cela devient une comparaison de toutes les paires que vous ne pouvez pas vous permettre.

Vérification manuelle pour les cas ambigus. Acceptez qu’une partie des cas nécessite une intervention humaine. Constituez la file d’attente dès le début plutôt qu’après les plaintes des utilisateurs.

Deux choix de conception qui vous épargneront des maux de tête par la suite : conservez chaque enregistrement source séparément et liez-les à une entité canonique, plutôt que de les fusionner de manière destructive — vous risqueriez de commettre des erreurs de fusion et de devoir les annuler. Et consignez la raison pour laquelle deux enregistrements ont été fusionnés, car « pourquoi cette annonce affiche-t-elle un prix erroné ? » est une question qui vous sera posée et à laquelle vous ne pourrez pas répondre à partir des seules données fusionnées.

Actualité, fréquence de mise à jour et coûts associés

Les exigences en matière d'actualité varient considérablement et déterminent l'ensemble de votre structure de coûts.

L’erreur qui ruine les budgets consiste à explorer tout le contenu à la fréquence requise par l’élément le plus volatile. La solution réside dans la hiérarchisation : explorez souvent ce qui change souvent ; explorez rarement ce qui change rarement ; et utilisez l’lastmod issue des plans de site et des requêtes conditionnelles pour ignorer complètement le contenu inchangé.

La détection des suppressions est le problème d’actualité que personne ne prévoit. Une offre d’emploi pourvue ou une maison vendue doit disparaître, et les sources l’annoncent rarement. Il faut soit un signal (la page renvoie une erreur 404, un champ d’état change), soit une règle (les enregistrements non détectés lors de trois explorations sont marqués comme inactifs). Si vous vous trompez sur ce point, votre agrégateur se remplit d’annonces obsolètes, ce qui constitue la deuxième raison la plus courante pour laquelle les utilisateurs cessent de faire confiance à un agrégateur, après les doublons.

Le coût est proportionnel au nombre de requêtes, et non au nombre d’annonces. Vérifier 10 000 annonces toutes les heures représente 240 000 requêtes par jour ; vérifier ces mêmes annonces une fois par jour en représente 10 000. Pour les mêmes données, cela représente une différence de 24 fois en termes de bande passante et de charge imposée aux sources. Chaque heure de désactualisation acceptable coûte de l’argent.

Quand utiliser des proxys et quand ne pas en utiliser

Notre partie du processus, décrite aussi précisément que possible.

Vous n’avez pas besoin de proxys lorsque : vous consommez des flux ou des API, votre volume est modeste, vous effectuez un crawling depuis un seul emplacement vers des sources qui n’imposent pas de limite de débit, ou vous êtes encore en phase de développement et de test. Cela couvre entièrement de nombreux agrégateurs en phase de démarrage.

Vous en avez besoin lorsque : votre activité de crawling est suffisamment importante pour qu’une seule adresse soit soumise à une limitation de débit ; le contenu varie selon les régions et vous devez consulter plusieurs régions ; vous utilisez des crawlers distribués et souhaitez qu’ils apparaissent comme des clients distincts plutôt que comme une seule machine avec plusieurs threads ; ou vous avez besoin d’une précision géographique pour la tarification et la disponibilité spécifiques à chaque région.

Quel type choisir : le centre de données pour la plupart des activités de crawling, car il est nettement moins cher et les pages d’annonces publiques ne nécessitent généralement rien de plus. Notre offre commence à 0,14 $/Go, facturée au trafic plutôt qu’à l’adresse IP. Optez pour la solution résidentielle — à partir de 0,79 $/Go — uniquement lorsque la solution de centre de données s’avère inefficace ou lorsque vous avez besoin d’une géolocalisation sur le réseau grand public. Les nouveaux comptes bénéficient gratuitement de 1 To de trafic résidentiel, ce qui est suffisant pour déterminer si vous en avez réellement besoin. Chiffres tirés de notre page de tarification, vérifiés en septembre 2026.

Le facteur de coût que personne ne prévoit : les navigateurs sans interface graphique. Si vos sources nécessitent un rendu JavaScript, un navigateur récupère chaque image, police et script, et la bande passante augmente d’un ordre de grandeur par rapport au HTTP brut. Bloquez les types de ressources dont vous n’avez pas besoin. Sur une bande passante facturée au volume, c’est le levier le plus important dont vous disposez, et nous avons abordé les aspects économiques plus généraux dans notre guide des tarifs des proxys.

Et soyons honnêtes : les proxys résolvent les problèmes de distribution. Ils ne résolvent pas les problèmes liés aux conditions d’utilisation, ni ceux liés aux droits d’accès aux bases de données, et ils ne font pas en sorte qu’un site souhaite votre présence. Si un site vous a demandé de ne pas l’explorer, multiplier les adresses n’est pas une solution ; c’est simplement un moyen de contourner cette interdiction plus efficacement.

Pourquoi la plupart des agrégateurs échouent

Ce n’est pas pour des raisons techniques.

Absence de valeur ajoutée unique. Agréger ce que tout le monde agrège donne une version moins bonne d’un site existant. La valeur ajoutée doit résider dans une couverture que personne d’autre n’offre, une organisation que personne d’autre ne propose, ou une niche trop petite pour les acteurs en place.

Les doublons. Ce point a déjà été abordé plus haut, mais il mérite d’être répété. C’est la principale raison pour laquelle les utilisateurs quittent le site.

Des données obsolètes. Les annonces inactives détruisent la confiance plus rapidement que les annonces manquantes, car une annonce manquante est invisible, tandis qu’une annonce inactive fait perdre du temps à l’utilisateur.

Une charge de maintenance supérieure à la valeur ajoutée. Vingt analyseurs HTML écrits à la main, c’est un travail à temps partiel à vie. Chaque source que vous ajoutez augmente les coûts fixes récurrents. Privilégiez les sources disposant de flux ; n’hésitez pas à abandonner celles dont la maintenance dépasse leur contribution.

L'œuf ou la poule. Les agrégateurs ont besoin de couverture pour attirer les utilisateurs, et des utilisateurs pour justifier cette couverture. La solution consiste à être exhaustif dans un domaine restreint plutôt que partiel dans un domaine vaste.

Problèmes juridiques qui surgissent tardivement. Une mise en demeure après avoir bâti votre activité sur une seule source coûte considérablement plus cher qu’une discussion avec un partenaire avant de vous lancer. Discutez dès le début avec vos principales sources ; certaines se réjouiront du trafic généré, et il vaut mieux repérer dès le premier jour celles qui ne l’apprécieront pas.

Questions fréquentes

Est-il légal de créer un site web agrégateur ?

Cela dépend de ce que vous agréguez, d’où proviennent ces informations et de la manière dont vous procédez. Les faits ne sont généralement pas protégés par le droit d’auteur, contrairement à l’expression ; c’est pourquoi il est plus sûr de stocker des données structurées et d’inclure des liens vers la source. Dans l’UE, l’exception relative à l’exploration de textes et de données, les réserves de droits lisibles par machine et le droit distinct sur les bases de données s’appliquent tous. Demandez conseil pour tout projet présentant un intérêt commercial.

D’où les agrégateurs tirent-ils leurs données ?

Par ordre de préférence : les API officielles, les flux des partenaires et des affiliés, les flux RSS et Atom, les plans de site, les données structurées intégrées aux pages, et enfin, l’analyse du code HTML. La source la plus négligée est le flux des partenaires : de nombreux secteurs publient des ensembles de données complets à l’intention des agrégateurs, car ceux-ci leur apportent du trafic. Renseignez-vous avant de créer un robot d’indexation.

Ai-je besoin de proxys pour créer un agrégateur ?

Pas au départ. Les flux et les API n’en nécessitent pas, et un crawling modéré à partir d’un seul emplacement n’en a généralement pas besoin non plus. Ils deviennent nécessaires lorsque le volume déclenche des limites de débit, lorsque vous devez consulter du contenu spécifique à une région, ou lorsque vous utilisez des robots d’indexation distribués. La bande passante d’un centre de données est le choix par défaut raisonnable ; n’optez pour une connexion résidentielle que lorsque cela s’avère manifestement nécessaire.

Comment les agrégateurs gèrent-ils les doublons ?

Correspondance par niveaux, en priorisant les résultats les moins chers : identifiants exacts lorsqu’ils existent, puis clés normalisées construites à partir de champs nettoyés, puis similarité approximative au sein de groupes de candidats généraux, puis vérification humaine pour les cas ambigus restants. Conservez les enregistrements sources séparés et liez-les à une entité canonique plutôt que de les fusionner de manière destructive.

Que m’impose le fichier robots.txt ?

Depuis la RFC 9309, il s’agit d’une norme plutôt que d’une convention. Effectuez la correspondance par spécificité plutôt que par ordre, actualisez le fichier au moins une fois par jour, traitez les erreurs de serveur comme une interdiction totale, considérez un code 404 comme l’absence de restriction, et analysez au moins 500 KiB. Utilisez une bibliothèque mise à jour régulièrement plutôt que d’écrire votre propre analyseur.

À quelle fréquence un agrégateur doit-il mettre à jour ses données ?

Aussi rarement que votre cas d’utilisation le permet, car le coût est proportionnel au nombre de requêtes. Les actualités nécessitent quelques minutes, les offres d’emploi quelques heures, les événements quelques jours. Classez vos sources par volatilité, utilisez l’lastmod du plan du site et des requêtes conditionnelles pour ignorer le contenu inchangé, et disposez d’une politique explicite pour détecter les annonces supprimées.

Puis-je agréger du contenu provenant de sites qui bloquent les robots de collecte ?

Techniquement, c’est possible ; mais la question est de savoir si vous devriez le faire. Un blocage est une déclaration d’intention, et le contourner ne change en rien les conditions, le droit d’accès à la base de données ni la relation. La meilleure solution consiste à demander un flux : de nombreux sites qui bloquent les robots d’indexation fournissent volontiers des données à leurs partenaires.

Quelle est la partie la plus difficile dans la création d’un agrégateur ?

La déduplication et l’actualité, et de loin. La récupération et l’analyse syntaxique sont des problèmes résolus grâce à des bibliothèques. Déterminer que deux annonces formulées différemment correspondent à la même chose, et remarquer quand l’une d’entre elles a discrètement cessé d’exister, voilà où résident à la fois l’effort d’ingénierie et la confiance des utilisateurs.

Conclusion

Tout l’art de créer un agrégateur réside dans la capacité à identifier les véritables problèmes. La récupération de contenu n’en fait pas partie : les flux, les API, les plans de site et les données structurées intégrées couvrent un champ bien plus vaste que ce que l’on pourrait croire, et les équipes qui se lancent directement dans l’écriture d’analyseurs HTML résolvent généralement un problème qui avait déjà été résolu pour elles.

Les véritables problèmes se situent en aval. La déduplication détermine si les utilisateurs font confiance à vos données. La détection des suppressions détermine s’ils leur font confiance une seconde fois. La charge de maintenance détermine si le projet résiste à l’interaction avec une vingtaine de sources modifiant leur balisage de manière indépendante. Et l’aspect juridique — droits d’auteur sur l’expression, réserves relatives au traitement des données textuelles (TDM) lisibles par machine, droit des bases de données de l’UE, conditions d’utilisation — détermine si l’ensemble constitue une activité commerciale ou un risque juridique.

Commencez par une approche ciblée et complète plutôt que vaste et partielle. Privilégiez les sources autorisées à chaque occasion, y compris en vous adressant directement aux sources, car un flux partenaire élimine d’un seul coup toute une catégorie de problèmes. Ajoutez de l’infrastructure — proxys compris — au moment où vous pouvez identifier la limite que vous avez atteinte, pas avant.