Construire une veille concurrentielle multi-source avec Trustpilot, LinkedIn et le web

Il y a des projets qu'on commence parce qu'on a un vrai problème à résoudre. Pas une idée abstraite. Un problème concret, qui revient chaque semaine.

Dans le cadre de Signar, je devais répondre à une question simple : comment aider une équipe commerciale à surveiller ses concurrents sans passer deux heures à chercher manuellement sur LinkedIn, Trustpilot et les sites web ?

La réponse évidente était "automatise ça". La réponse réelle était plus nuancée.

La difficulté n'est pas de trouver des données. La difficulté est de transformer du bruit public en contexte utile.

C'est ce que ce projet m'a appris, progressivement, à coups d'itérations et d'erreurs.

Le problème de départ

Les équipes commerciales font de la veille. Pas toujours bien, pas toujours souvent, mais elles le font. Elles regardent ce que fait la concurrence, elles lisent les avis clients, elles suivent les annonces LinkedIn.

Le problème : c'est manuel, discontinu, et difficile à tracer.

Quand un concurrent annonce un nouveau partenariat, change de discours, recrute massivement ou accumule des avis négatifs sur son support, ce signal existe publiquement. Mais il faut être au bon endroit, au bon moment, pour le capter. Et même quand on le capte, il faut encore décider si ça mérite une action.

J'ai cherché des outils existants. Il en existe beaucoup : alertes Google, outils de social listening, plateformes de market intelligence. Le problème avec la plupart :

Problème	Détail
Trop généraliste	Pas calibré pour un usage commercial B2B
Pas intégrable	Fermé, sans API propre
Coûteux à l'échelle	Prix qui explose dès qu'on surveille plus de 20 entreprises
Trop bruité	Beaucoup de volume, peu de signal
Non personnalisable	Impossible d'ajouter ses propres règles ou son propre contexte

Ce que je voulais, c'était un pipeline que je contrôle entièrement : les sources, les règles de filtrage, le format de sortie, et surtout la façon dont l'IA intervient dedans.

Architecture globale

Le pipeline repose sur trois sources publiques, une couche de nettoyage, une analyse IA, et un stockage structuré dans Supabase.

flowchart TD
    A[Liste concurrents\nSupabase] --> B[Normalisation\ndomaines / noms]
    B --> C{Boucle par entreprise}

    C --> D[Trustpilot\navis clients]
    C --> E[LinkedIn\nposts / recrutements]
    C --> F[Site web / blog\ncontenu public]

    D --> G[Parsing\npar source]
    E --> G
    F --> G

    G --> H[Nettoyage\nnormalisation]
    H --> I[Assemblage\ncontexte structuré]
    I --> J[Profil client\ncontexte Signar]
    J --> K[Analyse IA\nOpenRouter]
    K --> L[Parsing\nréponse JSON]
    L --> M[Filtrage\nsignaux pertinents]
    M --> N[Hash\nanti-doublon]
    N --> O[(Supabase\nsignaux)]
    O --> P[Priorisation\nurgence]

Point important avant d'aller plus loin : n8n orchestre, il ne traite pas. Comme dans mes autres projets, la logique métier est dans les nodes de transformation, les appels HTTP et le prompt — pas dans le workflow lui-même.

Les sources : ce qu'on peut raisonnablement attendre

Avant d'entrer dans le détail technique, il faut être honnête sur ce que chaque source apporte vraiment.

TrustpilotLinkedInSite web / blog

Ce que c'est : des avis clients réels, avec une note, un texte libre, une date, parfois une réponse de l'entreprise.

Ce que ça révèle : des frustrations concrètes. Pas le discours officiel — ce que les clients pensent vraiment du support, du produit, de l'onboarding, des prix.

Pourquoi c'est utile commercialement : si un concurrent accumule des plaintes sur son support depuis 3 mois, et que tu proposes exactement ce niveau de service, tu as un angle.

Ce que ça ne fait pas : représenter tous les clients. Les gens qui déposent des avis sont souvent aux extrêmes. Il faut filtrer, croiser, nuancer.

Ce que c'est : des posts d'entreprise, des annonces de recrutement, des prises de parole publiques.

Ce que ça révèle : les mouvements visibles. Nouveaux partenariats, recrutements massifs dans un département, lancement produit, changement de direction.

Pourquoi c'est utile : un concurrent qui recrute 5 développeurs backend en même temps qu'il annonce une refonte produit, c'est un signal de transformation interne.

Ce que ça ne fait pas : produire des signaux exploitables en masse. La majorité des posts sont du contenu marque employeur ou des félicitations génériques. Le ratio signal / bruit est le plus élevé des trois sources.

Ce que c'est : les pages publiques d'un concurrent — blog, pages produit, pages ressources, pages pricing.

Ce que ça révèle : le discours officiel et son évolution. Un repositionnement de pricing, une nouvelle offre enterprise, un changement de cible dans le discours commercial.

Pourquoi c'est utile : c'est la source la plus contrôlée côté concurrent. Ce qui est publié là est intentionnel. Quand le discours change, c'est souvent qu'il se passe quelque chose.

Ce que ça ne fait pas : être uniforme. Chaque site a sa structure. Certains n'ont pas de blog, d'autres publient sans date, d'autres encore ont tout en JavaScript.

Voilà le tableau honnête :

Source	Valeur commerciale	Difficulté technique	Niveau de bruit
Trustpilot	Très élevée — douleurs client directes	Moyen	Moyen
LinkedIn	Bonne — signaux de mouvement	Élevée	Très élevé
Site web	Bonne — discours et stratégie	Moyenne	Moyen

Stack utilisée

n8n — orchestration

n8n a été le choix naturel pour ce type de workflow : déclenchement planifié, boucles sur les entreprises, appels HTTP vers plusieurs sources, branches conditionnelles, nœuds de transformation.

Ce qui plaît dans n8n pour ce type de projet :

• on voit le workflow entier d'un coup d'œil ;
• les erreurs sont loggées par nœud ;
• on peut tester une branche sans relancer tout le pipeline ;
• l'itération est rapide.

Ce qui devient difficile quand le workflow grossit :

• les branches deviennent longues et difficiles à lire ;
• les nœuds d'expression JS commencent à ressembler à du code spaghetti ;
• déboguer une erreur au nœud 47 d'un workflow de 60 nœuds n'est pas agréable.

La leçon principale : modulariser tôt. Séparer chaque source dans un sous-workflow appelé depuis un workflow principal.

Supabase — stockage des signaux

J'utilise Supabase comme base de données principale pour les signaux. Avantages :

• schéma SQL clair et versionnable ;
• API REST automatique ;
• facile à interroger depuis n8n ou directement ;
• possible d'exposer les signaux côté app sans infrastructure supplémentaire.

La table principale des signaux ressemble à ça :

{
  "signal_id": "uuid",
  "company_id": "uuid",
  "source": "trustpilot",
  "type": "customer_pain",
  "topic": "support",
  "severity": 0.8,
  "confidence": 0.74,
  "raw_content": "...",
  "commercial_angle": "...",
  "recommended_action": "...",
  "hash": "sha256...",
  "first_seen_at": "2026-05-19",
  "last_seen_at": "2026-05-19",
  "status": "new"
}

OpenRouter / LLM — analyse contextuelle

Le modèle n'est pas là pour "faire la veille". Il est là pour classifier, résumer et contextualiser des données déjà nettoyées.

Ce point est crucial. Au début, j'ai eu tendance à vouloir donner trop de liberté au modèle. La réalité :

Le modèle est aussi bon que ce qu'on lui donne

Un prompt envoyé sur du HTML brut mal nettoyé produit une réponse confuse. Le même prompt envoyé sur un contexte structuré propre produit une sortie exploitable. Le travail de nettoyage en amont est la vraie variable d'ajustement.

J'utilise OpenRouter pour accéder à plusieurs modèles selon les besoins : Claude pour les analyses nécessitant du raisonnement, GPT-4o-mini pour les tâches de classification à volume.

Apify — scraping LinkedIn

LinkedIn est très difficile à scraper directement. Les protections anti-bot sont agressives, les structures changent souvent, et les tentatives en scraping brut finissent généralement par un blocage d'IP.

J'ai fait le choix d'utiliser Apify pour cette source : c'est une dépendance externe, ça a un coût, mais ça évite de maintenir un scraper LinkedIn fragile. Le compromis est acceptable pour la fréquence de crawl visée (hebdomadaire).

HTTP natif n8n — web et Trustpilot

Pour le web et Trustpilot, j'utilise les nœuds HTTP de n8n directement, avec un parsing manuel du HTML. Pas de Playwright ici — la majorité des pages qui m'intéressent (blog, pages produit, Trustpilot) sont suffisamment statiques pour que le rendu HTML côté serveur soit exploitable.

Pour les cas où le rendu JavaScript est nécessaire, j'ai mis en place un fallback similaire à ce que j'avais construit dans le projet Scrapy de détection de technologies : tenter d'abord sans rendu, activer le rendu complet uniquement si la page semble vide.

Construction étape par étape

1. La liste des concurrents à surveiller

Le point de départ est une table Supabase qui contient les entreprises à surveiller pour chaque client. Elle stocke le nom de l'entreprise, son domaine web, son URL Trustpilot, et son URL de page LinkedIn.

La normalisation en amont est importante. Un domaine mal formaté (avec ou sans www, avec ou sans https) casse les appels HTTP en aval. J'ai ajouté un nœud de nettoyage dédié qui standardise tous les identifiants avant d'entrer dans la boucle.

Principe simple

Mieux vaut rejeter une entrée mal formée en entrée de boucle que de debugger une erreur HTTP au nœud 35.

2. Trustpilot — la source terrain

C'est la source qui m'a le plus surpris. Les avis négatifs sont une mine d'information commerciale quand on sait les lire.

Un avis noté 1 ou 2 étoiles sur le support client d'un concurrent, répété sur plusieurs semaines, c'est un signal concret. Ce n'est pas de l'analyse — c'est ce que les clients disent publiquement.

Exemple de signal extrait après parsing et nettoyage :

{
  "source": "trustpilot",
  "rating": 2,
  "topic": "support_client",
  "raw_review": "Le support ne répond jamais en moins de 5 jours. On a perdu des données à cause d'un bug non corrigé depuis des semaines.",
  "signal_detected": "frustration récurrente sur la qualité du support et la réactivité"
}

Les difficultés rencontrées :

• la structure HTML de Trustpilot change parfois sans prévenir ;
• certains concurrents ont très peu d'avis (moins de 10), rendant l'analyse peu fiable ;
• les avis peuvent être très émotionnels et difficiles à classifier sans contexte.

3. LinkedIn — filtrer avant d'analyser

Sur LinkedIn, j'ai rapidement compris que la majorité des posts ne mérite pas d'être analysée. Avant même d'appeler le LLM, j'applique un filtre basique sur le contenu des posts.

Les catégories que j'écarte systématiquement :

• posts de félicitations internes ("Bienvenue à [Prénom] dans l'équipe") ;
• posts marque employeur génériques ;
• partages d'articles sans ajout de contenu ;
• posts événementiels sans information produit.

Les catégories que je garde :

• annonces de lancement produit ou fonctionnalité ;
• recrutements ciblés (ingénieurs, commerciaux sur un segment précis) ;
• partenariats ou intégrations annoncés ;
• changements de direction ou de structure ;
• prises de parole sur des sujets sectoriels.

flowchart LR
    A[Post LinkedIn] --> B{Filtre\npré-analyse}
    B -->|Bruit| C[Écarté]
    B -->|Signal potentiel| D[Analyse IA]
    D --> E{Signal\nexploitable ?}
    E -->|Non| F[Ignoré]
    E -->|Oui| G[Stocké\nSupabase]

4. Site web — la source la plus hétérogène

C'est techniquement la source la plus complexe. Chaque site a sa structure. J'ai défini une liste de chemins standards à tester pour trouver le contenu éditorial :

CONTENT_PATHS = [
    "/blog",
    "/actualites",
    "/news",
    "/ressources",
    "/articles",
    "/cas-clients",
    "/insights",
    "/changelog"
]

Pour chaque concurrent, le pipeline teste ces chemins dans l'ordre jusqu'à trouver une page avec du contenu lisible. Si aucun ne retourne quelque chose d'exploitable, le concurrent est marqué comme "pas de source web détectée" pour ce cycle.

Ce qui m'a pris du temps

Beaucoup de sites chargent leurs articles entièrement en JavaScript. Le HTML retourné côté serveur ne contient quasi rien. J'ai dû gérer ces cas séparément avec un fallback Playwright, ce qui ralentit significativement cette branche du pipeline.

5. Nettoyage et normalisation

C'est la partie du pipeline qui prend le plus de temps à bien faire — et celle qu'on a tendance à bâcler parce qu'elle est ingrate.

Le vrai travail n'était pas l'IA

Le vrai travail était de rendre les données assez propres pour que l'analyse IA soit utile. Un modèle qui reçoit du HTML brut avec des menus de navigation, des footers, des scripts et des publicités en entrée produit une réponse inutilisable.

Les opérations de nettoyage appliquées systématiquement :

• suppression des balises HTML résiduelles ;
• retrait des scripts, styles, commentaires ;
• déduplication des lignes identiques ;
• troncature au-delà d'un seuil de tokens (pour éviter les dépassements de contexte) ;
• normalisation des encodages ;
• retrait des blocs de navigation, footer, sidebar détectés par pattern.

6. Assemblage du contexte pour l'IA

Avant d'appeler le modèle, j'assemble un contexte structuré qui sépare clairement les sources et ajoute le profil client.

Tu analyses une veille concurrentielle multi-source.

Entreprise surveillée : {{company_name}}
Secteur : {{sector}}

--- SOURCE TRUSTPILOT ---
{{trustpilot_summary}}

--- SOURCE LINKEDIN ---
{{linkedin_summary}}

--- SOURCE SITE WEB ---
{{website_summary}}

--- CONTEXTE CLIENT (Signar) ---
{{client_profile}}

Objectif : identifier uniquement les signaux réellement exploitables commercialement.
Ne retiens pas les informations génériques ou non actionnables.

Retourne un JSON strict avec pour chaque signal :
{
  "signal_type": "customer_pain | product_move | hiring_signal | strategic_shift | pricing_change",
  "source": "trustpilot | linkedin | website",
  "severity": 0.0 à 1.0,
  "confidence": 0.0 à 1.0,
  "commercial_angle": "angle concret pour un usage commercial",
  "recommended_action": "action recommandée, précise et actionnable"
}

Le fait de structurer les sources dans des blocs séparés améliore significativement la qualité de l'analyse. Le modèle fait moins de confusion entre ce qui vient de Trustpilot et ce qui vient du site web.

7. Déduplication par hash

Sans ce mécanisme, le même signal revient chaque semaine. Un avis Trustpilot négatif qui date de trois mois restera dans les résultats à chaque crawl si on ne le déduplique pas.

La stratégie est simple : générer un hash à partir des éléments stables du signal.

const crypto = require('crypto');

const base = [
  item.companyDomain,
  item.source,
  item.signalType,
  item.rawContent.slice(0, 200) // début du contenu pour éviter les variantes mineures
].join(':');

const hash = crypto.createHash('sha256').update(base).digest('hex');

return { ...item, hash };

Avant d'insérer en base, le pipeline vérifie si ce hash existe déjà dans Supabase. Si oui, le signal est ignoré. Si non, il est inséré avec la date de première détection.

8. Priorisation et sortie

Une fois les signaux stockés, un dernier nœud calcule un niveau d'urgence basé sur la combinaison severity × confidence et la fraîcheur du signal.

flowchart LR
    A[Signal stocké] --> B[Score urgence\nseverity × confidence]
    B --> C{Seuil\n> 0.6 ?}
    C -->|Oui| D[Urgence haute\nnotification]
    C -->|Non| E[File normale\nrevue hebdo]

Les signaux à haute urgence peuvent déclencher une notification Teams ou Slack pour que l'équipe commerciale soit alertée sans attendre la revue hebdomadaire.

Ce que j'ai cassé (et ce que ça m'a appris)

Trop faire confiance à l'IA en premier

Ma première version envoyait directement le HTML brut des pages au modèle en lui demandant de "trouver les signaux intéressants". Le résultat était imprévisible, coûteux en tokens, et souvent inutile.

La correction a été de ne plus considérer l'IA comme une baguette magique, mais comme une couche de traitement finale qui n'est utile que si tout le travail en amont est fait proprement.

Le bruit LinkedIn

J'ai sous-estimé la quantité de contenu inutile sur LinkedIn. Sur 100 posts récupérés pour une entreprise, il m'arrivait de n'en garder que 3 ou 4 après filtrage. Le reste : contenu RH, événementiel, posts génériques.

La solution a été d'ajouter un filtre pré-IA qui écarte les posts par pattern de titre et de contenu avant même d'appeler le modèle. Ça réduit les coûts et accélère le traitement.

Les sites web hétérogènes

Certains sites n'ont pas de blog. D'autres ont un blog sans dates. D'autres encore publient tout en JavaScript. J'ai eu des cas où le pipeline récupérait les menus de navigation comme contenu principal parce que la page d'articles ne renvoyait rien d'exploitable.

Exemple réel

Un concurrent avait une page /blog qui renvoyait uniquement un shell JavaScript. Le contenu de ce que j'ai parsé : "Loading... Please enable JavaScript." — et le modèle a consciencieusement analysé cette phrase comme du contenu éditorial.

Le workflow n8n qui grossit vite

Au bout de quelques semaines d'itération, le workflow principal comptait plus de 60 nœuds. Naviguer dedans devenait difficile. Debugger une erreur sur la branche LinkedIn sans affecter la branche Trustpilot devenait un exercice délicat.

La solution a été de découper en sous-workflows : un workflow principal pour l'orchestration et la boucle, et un sous-workflow par source (Trustpilot, LinkedIn, web). Chaque sous-workflow est testable indépendamment.

Ce qui a marché

Le croisement des sources

C'est la vraie valeur du système. Une source seule produit du bruit. Plusieurs sources alignées produisent du contexte.

Exemple concret observé :

• Trustpilot : accumulation de plaintes sur le temps de réponse du support sur les 30 derniers jours
• LinkedIn : recrutements ouverts sur des postes Customer Success et Support
• Site web : publication récente d'un article "Comment nous améliorons notre support client"

Pris séparément, chaque signal est anecdotique. Ensemble, ils dessinent clairement une entreprise en tension opérationnelle qui cherche à rattraper une situation dégradée.

C'est exactement le type d'angle commercial qui mérite d'être transmis à un commercial.

La sortie structurée

Forcer une sortie JSON stricte change tout. Au lieu de recevoir un texte libre que quelqu'un doit relire et interpréter, on obtient directement :

Exemple de signal structuré

{
  "company": "ExampleCorp",
  "signal_type": "customer_pain",
  "source": "trustpilot",
  "severity": 0.78,
  "confidence": 0.71,
  "commercial_angle": "Mettre en avant la qualité du support et le temps de réponse garanti. Ce concurrent est clairement en difficulté sur ce point depuis plusieurs semaines.",
  "recommended_action": "Créer une alerte commerciale pour les comptes du même segment. Préparer un angle de démo centré sur le support."
}

Ce format est directement exploitable dans une app, dans un CRM, ou dans un email de synthèse hebdomadaire.

Les signaux répétés

Les meilleurs signaux ne sont pas les plus spectaculaires. Ce sont souvent les plus répétitifs.

Un avis négatif isolé sur le support : pas très actionnable. Le même type de plainte qui revient 8 fois en 3 semaines : c'est un pattern. Le pipeline détecte et agrège ces répétitions plutôt que de les traiter comme des signaux indépendants.

Ce que j'ai appris

TechniqueProduitWorkflow

• Le nettoyage compte plus que le modèle. La qualité de l'analyse est proportionnelle à la qualité du contexte préparé. Pas l'inverse.
• Modulariser tôt. Un workflow de 60 nœuds sans structure devient ingérable. Un workflow de 15 nœuds qui appelle 3 sous-workflows de 15 nœuds reste lisible.
• Logger systématiquement. Chaque signal doit tracer sa source, sa date de détection, et la version du prompt utilisé. Sans ça, les erreurs sont très difficiles à reproduire.
• La déduplication est indispensable. Sans hash, la base se remplit de doublons en quelques semaines.

• Une veille n'a de valeur que si elle aide à décider. Un flux d'actualités ne suffit pas. Il faut des signaux filtrés, scorés et contextualisés avec un angle commercial explicite.
• Un commercial ne veut pas "lire des données". Il veut savoir pourquoi agir maintenant, et quoi dire concrètement.
• Moins de signaux, mieux vaut. J'ai eu des versions qui remontaient 40 signaux par semaine par entreprise. Résultat : personne ne lisait. Filtrer pour ne garder que les 3-5 signaux vraiment utiles change l'adoption.

• n8n est excellent pour itérer. Moins pour maintenir un système de production complexe sur le long terme.
• Un système imparfait mais observable vaut mieux qu'un système ambitieux opaque. Pouvoir voir où une erreur s'est produite, rejouer un nœud, et suivre le volume de signaux semaine après semaine est plus utile que d'avoir un pipeline "parfait" impossible à déboguer.

Limites actuelles

Pas la peine de les cacher.

Ce qui reste fragile

• Scoring encore heuristique. Les seuils severity et confidence sont calibrés manuellement. Ils fonctionnent, mais ils ne sont pas appris sur des données historiques.
• LinkedIn dépendant d'Apify. Si l'acteur Apify que j'utilise casse, cette source tombe. C'est une dépendance externe non maîtrisée.
• Trustpilot parfois incomplet. Les concurrents avec peu d'avis (< 10) ne produisent rien d'exploitable. Le pipeline le détecte et passe, mais la couverture n'est pas universelle.
• Pas d'historique de tendance. Aujourd'hui, je vois les signaux du moment. Pas l'évolution dans le temps. Savoir qu'un concurrent avait 4/5 étoiles il y a 6 mois et a chuté à 2.8/5 maintenant serait beaucoup plus parlant.
• Validation humaine absente. Les premiers résultats sont envoyés tels quels. Il n'y a pas de boucle de feedback qui permettrait d'améliorer le filtrage en fonction des signaux réellement utilisés.

Ce que je referais autrement

StructureSchémaTests

Ce que j'avais :

workflow_veille_v1.json
workflow_veille_v2_final.json
workflow_veille_v2_final_corrigé.json

Ce que je ferais :

/workflows
    orchestrator.json         ← boucle principale
    /sources
        trustpilot.json
        linkedin.json
        website.json
    /processing
        cleaner.json
        analyzer.json
        deduplicator.json

Définir le schéma de signal dès le départ, avant d'écrire le premier prompt.

J'ai passé trop de temps à faire évoluer le format JSON de sortie au fur et à mesure que je comprenais ce qui était utile. Chaque changement impliquait de mettre à jour le prompt, le parsing, la table Supabase et la logique d'affichage.

Créer un jeu de test fixe avec des entreprises dont je connais déjà les signaux. Utiliser ces exemples pour valider chaque modification du pipeline.

Sans référence stable, impossible de savoir si une modification améliore ou dégrade les résultats.

Répartition observée des signaux

pie title Répartition indicative des signaux exploitables par source
    "Trustpilot" : 42
    "Site web / blog" : 35
    "LinkedIn" : 23

Et si on place les sources selon leur rapport utilité / bruit :

quadrantChart
    title Sources de veille — Utilité vs Bruit
    x-axis Peu de bruit --> Beaucoup de bruit
    y-axis Peu utile --> Très utile
    quadrant-1 Utile mais bruité
    quadrant-2 Très exploitable
    quadrant-3 Peu prioritaire
    quadrant-4 À filtrer fortement
    Trustpilot: [0.35, 0.85]
    Site web: [0.48, 0.70]
    LinkedIn: [0.78, 0.55]

Conclusion

Ce projet m'a confirmé quelque chose que je savais en théorie mais que j'avais besoin de vivre en pratique : la donnée publique est abondante. La valeur vient du tri.

Trustpilot, LinkedIn et les sites web produisent chaque semaine des signaux réels sur ce que font les concurrents, comment leurs clients les perçoivent, et dans quelle direction ils vont. Ces signaux sont là, accessibles, gratuits. Ce qui est difficile, c'est de les collecter proprement, de les nettoyer, de les croiser, et de les contextualiser pour qu'ils servent à quelque chose de concret.

L'IA est utile dans ce pipeline — mais à la fin, après le vrai travail. Elle classe, résume, contextualise. Elle ne remplace pas la collecte, le nettoyage et la structuration.

Ce système reste imparfait. Le scoring est encore heuristique. LinkedIn est fragile. L'historique n'existe pas encore. Mais il tourne, il remonte des signaux utilisables, et il peut être amélioré progressivement.

Ce qui m'intéresse dans ce type de système, ce n'est pas de remplacer l'analyse humaine. C'est de faire remonter plus vite les quelques signaux qui méritent vraiment qu'un humain s'y attarde.

La suite : ajouter de l'historique pour détecter les tendances, intégrer une validation humaine sur les premiers résultats, et construire une boucle de feedback qui améliore le filtrage dans le temps.

Ce que j'ai envie d'explorer ensuite

• Détection de tendances dans le temps (évolution du score Trustpilot sur 3 mois)
• Clustering des signaux par type et secteur
• Validation humaine légère avec feedback loop
• Alertes conditionnelles basées sur des combinaisons de signaux
• Export hebdomadaire structuré vers CRM