Comment LinkedIn détecte l’automatisation : analyse du code de 16 extensions, tests cloud et moteur de détection de LinkedIn

Nous avons analysé 16 extensions d’automatisation de la prospection sur LinkedIn pour comprendre comment elles traitent les sessions, les cookies, les appels du navigateur et les serveurs des fournisseurs.

Nous avons également créé deux comptes auprès de chacun des six services cloud, puis vérifié les adresses IP de sortie attribuées dans une base indépendante de réputation antifraude.

La troisième partie de l’étude portait sur le propre code des pages de LinkedIn. Ce code comprend un outil d’analyse des extensions comportant 6 167 cibles, un « spectroscope » du modèle objet de document (DOM) et une empreinte d’appareil en 48 points qui peut accompagner les requêtes de session.

Ce guide présente les signaux susceptibles d’accroître le risque pour le compte, les architectures d’automatisation qui exposent davantage de ces signaux et la manière d’auditer vous-même n’importe quelle extension en cinq minutes environ.

En bref : 9 éléments à connaître avant toute installation

1. LinkedIn peut rechercher des extensions connues dans les navigateurs basés sur Chromium. Ce système s’appelle Active Extension Detection (AED). Lors de notre relevé, le code de LinkedIn sondait 4 934 identifiants d’extensions Chrome, et la liste s’allongeait d’environ 12 entrées par jour.
2. Les outils servant de passerelle pour les cookies créent l’une des configurations les plus risquées. Ces extensions lisent votre cookie de session LinkedIn li_at et le téléversent dans le cloud du fournisseur, qui peut alors utiliser votre compte depuis l’IP d’un centre de données. Nous avons relevé ce schéma dans le code de 9 outils largement utilisés.
3. Lire les cookies ne revient pas à exporter votre session. Certains outils lisent les cookies, mais conservent la session en local. La véritable question consiste à déterminer où va la valeur du cookie ; nous avons donc suivi son parcours pour chaque outil de ce guide.
4. Bloquer la télémétrie de LinkedIn peut révéler l’outil au lieu de le dissimuler. Certaines extensions bloquent les points de terminaison de suivi de LinkedIn. Si l’un d’eux continue à transmettre des données, LinkedIn peut constater que les autres canaux de télémétrie sont bloqués.
5. Votre empreinte d’appareil peut accompagner les requêtes de session. LinkedIn collecte 48 signaux d’appareil, notamment les caractéristiques graphiques et audio, les polices, l’IP locale via la communication en temps réel sur le Web (WebRTC) et les indicateurs d’automatisation. Cette empreinte est chiffrée et jointe aux requêtes de l’interface de programmation d’applications (API) pendant la session.
6. La détection se comprend mieux comme un modèle de scoring. La présence d’une extension, les traces de code, les anomalies réseau et le comportement du compte peuvent tous ajouter des signaux de risque. Des limites quotidiennes prudentes sont utiles, mais elles ne corrigent pas une architecture risquée.
7. La prospection manuelle n’est pas à l’abri des restrictions. Un volume élevé, l’ouverture massive de profils et un trop grand nombre de signalements « I don’t know this person » peuvent également affecter les utilisateurs qui agissent manuellement.
8. Les outils cloud peuvent laisser une trace IP visible. Lors de notre test de six outils cloud, cinq des six outils exécutés côté serveur ont placé les comptes derrière des IP de centres de données ou de proxys considérées comme très risquées par une base antifraude indépendante. Un fournisseur a attribué la même IP aux deux comptes de test, et trois outils sans lien entre eux ont acheminé leur trafic par le même fournisseur en amont.
9. La sécurité du compte n’est pas une préoccupation marginale. Sur neuf marchés anglophones, environ 12 050 recherches mensuelles concernent les restrictions LinkedIn, les limitations de compte, la vérification d’identité ou les bannissements.

Pourquoi vous pouvez faire confiance à ce rapport

Ce guide repose sur trois sources de preuves : l’historique du produit, le code des extensions et des tests cloud en conditions réelles.

La première source est Alexander Erin, fondateur de Linked Helper, qui occupe cette fonction depuis octobre 2016.

Il a écrit la première version de Linked Helper, qui était une extension Chrome. À son apogée, elle occupait la première place pour la requête « LinkedIn » dans le Chrome Web Store et comptait environ 80 000 utilisateurs. Il a également vu les premiers systèmes de détection de LinkedIn affecter des extensions concurrentes. En août 2019, il a disposé de trois jours pour adapter Linked Helper à une deuxième vague de détection.

L’équipe a ensuite décidé de quitter le Chrome Web Store et de reconstruire Linked Helper sous la forme d’une application de bureau autonome.

La deuxième source est le code.

Pour ce rapport, nous avons téléchargé les versions publiées des extensions de 16 outils concurrents, les avons déminifiées et avons suivi ce qu’elles font de votre session LinkedIn. Nous avons vérifié le code fichier par fichier et conservé les numéros de ligne permettant de vérifier le comportement.

Nous nous sommes également appuyés sur l’enquête BrowserGate, qui a analysé le JavaScript de production de LinkedIn de décembre 2025 à mars 2026. Ce travail a documenté des systèmes de détection que notre expert décrivait déjà du point de vue de la défense depuis 2019.

La troisième source est un test en conditions réelles.

Le code peut montrer ce qu’une extension est capable de faire, mais pas l’adresse IP qu’un service cloud attribue une fois votre session arrivée sur ses serveurs. Pour vérifier ce point, nous avons créé deux comptes auprès de chacun des six outils cloud, tous depuis la France.

Pour chaque compte, nous avons relevé l’IP de sortie, sa réputation dans IPQualityScore (IPQS), le type d’appareil, le système d’exploitation (OS) affiché par le cloud et la présence éventuelle de l’extension associée dans la liste de détection de LinkedIn. IPQS est une base indépendante de renseignements antifraude et indique LinkedIn parmi ses clients sur son site web.

À la fin de ce guide, vous disposerez de trois livrables concrets :

1. Une cartographie des risques associés aux principales architectures d’automatisation
2. Une liste de contrôle pour auditer le code de n’importe quelle extension
3. Des benchmarks pour une utilisation moins risquée dans les situations où ils restent applicables

Pourquoi la sécurité du compte constitue le principal enjeu

Les restrictions de comptes LinkedIn restent une préoccupation majeure pour les équipes commerciales, les recruteurs, les fondateurs, les agences et les équipes chargées de la croissance. Chaque mois, des utilisateurs recherchent des réponses sur les restrictions, les contrôles d’identité, les limites applicables aux demandes de connexion et les sanctions soudaines visant les comptes.

La plupart des conseils se limitent aux plafonds d’activité quotidienne et au volume de messages. Ces aspects sont importants, mais ils ne constituent qu’une partie du risque. LinkedIn peut également observer des signaux techniques, notamment les extensions du navigateur, les empreintes d’appareil, les environnements de session cloud et la réputation des IP.

Ce rapport se concentre sur cette couche technique. Au lieu de supposer ce que LinkedIn pourrait détecter, nous examinons la conception des outils d’automatisation, les signaux qu’ils exposent et la manière dont chaque architecture peut influencer le risque pour le compte.

1. Les architectures à l’origine des risques liés à l’automatisation de la prospection sur LinkedIn

Les appellations marketing telles que « cloud », « AI », « extension Chrome » et « sécurisé » ne suffisent pas à expliquer le risque pour le compte.

Les véritables questions sont les suivantes :

1. Comment l’outil accède-t-il à votre compte ?
2. Où les opérations sont-elles exécutées ?
3. Où vont vos données ?
4. Quelles traces la configuration laisse-t-elle ?

La plupart des outils d’automatisation de la prospection sur LinkedIn peuvent être rattachés aux composants ci-dessous. Certains utilisent un seul modèle, tandis que d’autres en combinent plusieurs au sein du même produit.

Flux de données de l’extension Chrome Dux-Soup. Les nœuds rouges représentent votre session LinkedIn ou vos données quittant votre environnement pour le cloud d’un fournisseur. Les nœuds gris représentent les données qui restent dans votre navigateur.

1.1 Extensions qui s’exécutent dans votre navigateur

Une extension de navigateur peut combiner plusieurs modèles d’automatisation. Leur distinction est importante, car certains conservent votre session en local, tandis que d’autres transfèrent les données de session dans le cloud d’un fournisseur.

a) Extraction locale via votre propre session

Dans ce modèle, votre session LinkedIn reste sur votre machine. L’extension appelle directement depuis votre navigateur l’API interne de LinkedIn, appelée Voyager, en utilisant votre connexion LinkedIn existante.

Techniquement, cela peut prendre la forme de fetch(..., {credentials: "same-origin"}) avec un en-tête CSRF token dérivé de votre cookie JSESSIONID. Les jetons de protection contre la falsification de requêtes intersites (CSRF) contribuent à prouver qu’une requête appartient à la session actuellement connectée dans le navigateur.

Seuls les résultats extraits, comme les profils ou les e-mails, sont téléversés chez le fournisseur. Votre jeton de session lui-même n’est pas exporté.

Les exemples confirmés par notre audit comprennent Octopus CRM, GetProspect, Findymail, Apollo et Dux-Soup avec ses offres Turbo, Pro et Free. Octopus CRM présentait l’implémentation la plus sobre de ce groupe, car il ne demandait pas l’autorisation Chrome cookies et utilisait des appels Voyager locaux tels que fetch(voyager, {credentials:"same-origin", "CSRF-token": U()}).

L’avantage est que votre IP, votre session de navigateur et votre empreinte d’appareil restent cohérentes. Votre jeton de session ne quitte pas votre navigateur.

• Une requête Voyager isolée, sans le trafic de page qui l’accompagne, peut créer un schéma de requêtes inhabituel, que nous abordons au § 2.7.
• L’extension peut aussi rester visible pour les outils d’analyse des extensions de LinkedIn, présentés aux § 2.1 et § 2.2.

Il existe également un risque de maintenance.

De nombreuses extensions reposent sur des hypothèses codées en dur concernant la structure de l’API interne de LinkedIn, les formats de requête, les en-têtes et les paramètres. Si LinkedIn modifie ces éléments, une extension obsolète peut commencer à envoyer des requêtes mal formées ou inhabituelles jusqu’à ce que le fournisseur détecte le changement, publie un correctif et que les utilisateurs installent la mise à jour.

b) Extensions servant de passerelle pour les cookies ou téléversant la session

Dans ce modèle, votre session LinkedIn quitte votre machine. L’extension accède à l’ensemble des cookies LinkedIn au moyen d’appels tels que chrome.cookies.getAll(...), sélectionne des valeurs comme li_at, JSESSIONID ou li_a, puis les envoie au serveur du fournisseur.

Le cloud du fournisseur peut ensuite utiliser votre compte à votre place depuis sa propre adresse IP. Comme l’a indiqué notre expert à propos d’un outil de ce type, « l’extension sert de passerelle pour extraire le cookie et n’a aucune autre fonction ».

Le tableau ci-dessous présente ce que nous avons trouvé dans le code. Il distingue également les outils qui exportent les données de session de ceux qui conservent la session LinkedIn en local et n’envoient que les résultats.

Expandi : le cas le plus intéressant du jeu de données

Expandi (par l’intermédiaire de l’extension Expandi Connector) mérite une analyse approfondie, car il illustre plusieurs techniques employées sur le marché de l’automatisation de la prospection sur LinkedIn. Ces techniques peuvent réduire certains risques, mais elles peuvent aussi laisser des signaux observables par les systèmes de détection.

Comprendre leur fonctionnement et les traces qu’elles continuent de laisser fournit un cadre utile pour évaluer tous les autres outils d’automatisation.

Flux de données de l’extension Chrome Expandi Connector, reconstitué par l’audit du code. Les nœuds rouges représentent votre session LinkedIn ou vos données quittant votre environnement pour le cloud d’un fournisseur. Les nœuds gris représentent les données qui restent dans votre navigateur.

Technique 1 : injecter un script dans le contexte de la page LinkedIn

Un script de contenu s’exécute normalement dans un environnement isolé et ne peut pas accéder au XMLHttpRequest de la page.

Pour contourner cette limite, Expandi injecte un véritable nœud <script src="chrome-extension://ohcplcf…/linkedin/injected.js"> dans le DOM actif (linkedin/content.js:2-7).

Ce nœud contient une URL littérale chrome-extension:// dans la page. L’outil d’analyse Spectroscopy de LinkedIn (§ 2.2) peut parcourir passivement le DOM, rechercher cette sous-chaîne, extraire l’identifiant d’extension de 32 caractères et le signaler.

Cette méthode de détection ne nécessite aucune liste de cibles. Une affirmation telle que « nous ne figurons pas sur la liste AED » ne suffit pas si l’extension injecte une ressource chrome-extension:// visible. Dans ce cas, le mode d’injection devient lui-même une trace.

Niveau de confiance : constaté dans le code. L’injection est explicite et le mécanisme Spectroscopy est documenté dans l’analyse du code de production de BrowserGate.

Technique 2 : remplacer XMLHttpRequest.prototype.send par surcharge dynamique

Le fichier injected.js:3-27 d’Expandi remplace la méthode native send de la page afin que chaque réponse de l’API Voyager récupérée par votre navigateur puisse être copiée vers l’extension. La surcharge s’exécute dans le même contexte global que le JavaScript de LinkedIn, ce qui constitue précisément l’objectif de l’injection du script dans la page.

Une méthode send modifiée n’est plus native, et n’importe quel script de la page peut le vérifier. Par exemple, Function.prototype.toString.call(XMLHttpRequest.prototype.send) renvoie le code source de la fonction d’enveloppe au lieu de "function send() { [native code] }", et Expandi ne tente pas de masquer toString.

Une référence intacte provenant d’un nouvel <iframe> de même origine ne correspondrait pas non plus à la méthode send modifiée de la page. Cela crée une différence détectable entre l’API originale du navigateur et l’état actuel de la page.

LinkedIn déploie déjà des sondes de cette catégorie. Le groupe de moteurs internes d’empreinte APFC/DNA présenté au § 2.6 comprend des contrôles directs contre les robots et une fonctionnalité signals destinée à détecter les déclarations incohérentes du navigateur. LinkedIn charge également le script externe HUMAN/PerimeterX depuis li.protechts.net (§ 2.8a), conçu pour détecter des altérations comme la modification des prototypes et du comportement de toString.

Niveau de confiance : la modification figure dans le code. La méthode de détection découle du fonctionnement de cette modification.

Nous n’avons détecté aucun blocage de télémétrie par cette méthode ; tout verdict issu de ces sondes peut donc encore être transmis. Nous n’affirmons pas avoir observé LinkedIn signaler un utilisateur précis d’Expandi. Notre affirmation, plus limitée, est que la capacité de détection existe et que la modification est suffisamment visible pour entrer dans son champ d’action.

Technique 3 : envoyer un appel distinct à Voyager GraphQL pour récupérer l’e-mail

Le fichier injected.js:34-44 d’Expandi envoie une requête programmatique GET /voyager/api/graphql avec withCredentials:true. Il construit un CSRF-token à partir de votre JSESSIONID (injected.js:30-31) afin de récupérer les coordonnées ou l’adresse e-mail qu’une consultation normale de profil ne charge pas par défaut.

LinkedIn peut considérer cela comme une anomalie dans le schéma de requêtes (§ 2.7). Il s’agit d’un appel d’API sans action utilisateur correspondante, déclenché après le chargement sur des profils où l’utilisateur n’a pas ouvert la rubrique de coordonnées « Contact info ».

À grande échelle, le schéma « chaque profil consulté entraîne également la récupération de son e-mail » devient caractéristique d’un outil d’enrichissement et d’extraction. Il est visible dans les journaux côté serveur sans aucune intervention du navigateur. L’appel utilise votre véritable session et transporte l’en-tête d’empreinte chiffré, mais c’est le schéma comportemental qui le trahit.

Niveau de confiance : constaté dans le code. L’appel est explicite et l’anomalie est, par conception, observable côté serveur.

La découverte la plus sérieuse : certaines extensions collectent davantage que les données LinkedIn

La variante la plus sérieuse consiste à collecter l’intégralité des cookies de tous les sites auxquels vous êtes connecté, et pas seulement de LinkedIn. L’extension expandi.ai de Konnector, un fournisseur distinct d’Expandi.io, renvoie chrome.cookies.getAll({}) à son application web pour tous les domaines.

Même l’échange isInstalled, qui semble anodin, peut exposer l’intégralité des cookies (KonnectorContent.js:10-28, background.js:19). Le problème dépasse alors le risque lié à l’automatisation de la prospection sur LinkedIn pour devenir un risque plus général de sécurité des comptes.

Exemple de PhantomBuster

PhantomBuster appartient à une catégorie distincte. Il remplit automatiquement sa page de configuration cloud avec votre cookie li_at en un clic (contentscript.js:5265-5266). Il ne s’agit pas d’un POST silencieux, mais un seul clic suffit alors pour transférer la session.

PhantomBuster est également capable de collecter les cookies de session de 15 plateformes (background.js:5140-5230). C’est pourquoi le § 1.2a considère la réutilisation des cookies comme la catégorie la plus risquée.

c) Automatisation du DOM dans la page LinkedIn

Certaines extensions automatisent LinkedIn en cliquant sur les boutons à votre place et en injectant leurs propres panneaux, boutons ou commandes dans la page LinkedIn.

Cela crée deux surfaces de détection. Chaque élément injecté peut posséder un sélecteur unique qu’un outil d’analyse peut rechercher (§ 2.2), et chaque clic programmatique génère un événement dont la propriété isTrusted vaut false. Avec l’API normale des extensions, comme l’a indiqué notre expert, « vous ne pouvez pas le falsifier — il vaut toujours false » (§ 2.5).

En pratique, peu d’outils injectent beaucoup d’éléments dans la page. Ceux qui le font créent toutefois des signaux que LinkedIn peut examiner sans liste de cibles, car l’outil d’analyse peut rechercher directement ce qui a changé dans la page (§ 2.2).

1.2 Services cloud exécutés sur les serveurs des fournisseurs

Un service cloud doit pouvoir accéder à votre compte LinkedIn avant d’automatiser quoi que ce soit. En pratique, il existe deux principaux points d’entrée.

a) Réutilisation des cookies via une session synchronisée

Il s’agit de la partie côté serveur du modèle de passerelle pour les cookies présenté au § 1.1b. C’est l’une des configurations les plus risquées, car votre session peut être réutilisée en dehors de votre propre navigateur.

Le risque provient de plusieurs signaux simultanés :

• Une même session peut apparaître simultanément sur deux IP. La vôtre lorsque vous continuez à naviguer sur LinkedIn, et l’IP du centre de données du fournisseur lorsque le cloud exécute l’automatisation. Notre expert a qualifié cela d’« indice qui ne trompe pas ».
• La réutilisation d’un cookie ne correspond pas à une connexion normale. Elle ne crée aucune entrée visible dans la page des « sessions actives » de LinkedIn ; vous ne pouvez donc pas la voir depuis les paramètres de votre compte.
• L’offre Cloud de Dux-Soup récupère les cookies silencieusement lorsqu’elle est connectée.
• Si le cloud réutilise le cookie dans son propre navigateur, l’empreinte d’appareil peut ne pas correspondre à celle que votre session a toujours utilisée (§ 2.6).
• Si le cloud contourne le navigateur et appelle directement l’API, il peut créer un schéma de requêtes inhabituel (§ 2.7).

Une fois la session transférée dans le cloud d’un fournisseur, vous ne pouvez plus observer l’environnement depuis lequel votre compte LinkedIn est utilisé.

b) Nouvelle connexion du côté du fournisseur

La deuxième méthode consiste à établir une nouvelle connexion depuis l’environnement du fournisseur. Le service lance un serveur privé virtuel (VPS) ou un émulateur de navigateur, puis se connecte à l’aide de votre nom d’utilisateur, de votre mot de passe, du code reçu par e-mail et du code d’authentification à deux facteurs (2FA).

Certains fournisseurs décrivent cette approche en privé. Un outil de publication sur les réseaux sociaux nous a indiqué se connecter via un VPS avec un navigateur de type Multilogin, puis effectuer toutes les autres opérations par l’API. Une autre suite de prospection bien connue a décrit « un vrai navigateur pour les rares actions, et l’API pour le reste ».

(Nous ne les nommerons pas, mais… à son crédit, PhantomBuster documente publiquement son architecture de navigateur cloud.)

Notre expert considère cette méthode comme moins risquée que la réutilisation des cookies. Une nouvelle connexion depuis une nouvelle machine et un nouvel emplacement peut au moins ressembler à une action humaine réelle. Elle associe néanmoins à votre compte l’IP, la zone géographique, le fuseau horaire et l’empreinte du cloud, éléments abordés aux § 2.9 et § 2.10.

Étape suivante dans le cloud : API uniquement ou navigateur émulé

Une fois connecté, le cloud doit encore effectuer le travail. Il peut utiliser un navigateur émulé, appeler directement les API de LinkedIn ou combiner les deux méthodes.

Notre expert présente l’exécution côté cloud comme une estimation et non comme un fait directement prouvé. Son évaluation est sans détour : « Je pense qu’ils sollicitent tous directement l’API. Tous, avec une probabilité de 95 %. »

Il avance trois raisons à cette estimation :

1. Les appels d’API sont beaucoup plus simples que l’analyse de pages LinkedIn qui changent constamment.
2. LinkedIn n’a pas encore suffisamment renforcé l’API pour bloquer les services qui ont publiquement reconnu l’utiliser.
3. Les fonctionnalités de boîte de réception en temps réel des tableaux de bord de ces outils nécessitent généralement un accès direct à l’API. Un navigateur automatisé chargé de l’extraction en arrière-plan ne peut pas récupérer de manière fiable et à la demande une nouvelle conversation concernant une personne précise avec une telle réactivité.

Le risque au niveau du système est que les clouds utilisant uniquement l’API reposent sur des requêtes codées en dur. Il suffit que LinkedIn modifie l’API en ajoutant un en-tête spécial, des noms de points de terminaison propres à chaque utilisateur ou une mutation similaire pour que chaque client codé en dur cesse de fonctionner ou commence à paraître inhabituel.

L’analyse de BrowserGate a constaté qu’une partie de cette infrastructure existe déjà. Un bloc d’empreinte chiffré est injecté dans les en-têtes du protocole de transfert hypertexte (HTTP) de chaque requête API envoyée par une véritable session de navigateur (§ 2.6 et § 2.7). L’infrastructure permettant de distinguer le trafic d’un vrai navigateur des clients API directs semble donc déployée. Le passage de la collecte à l’application de sanctions relève de la décision de LinkedIn.

Cette réserve vaut pour l’ensemble du rapport : de l’extérieur, vous ne pouvez pas prouver la méthode utilisée par un cloud — un client API peut lui aussi imiter une connexion. Nous présentons ce que nous voyons dans le code et signalons les hypothèses relatives au comportement côté cloud comme « très probables ».

Ce que nous avons mesuré lors de l’inscription (6 outils, 2 comptes chacun)

L’analyse du code s’arrête à la frontière de l’extension. Le cloud lui-même constitue une boîte noire pour l’utilisateur, même si LinkedIn peut en voir davantage.

Cette boîte noire ne peut toutefois pas dissimuler entièrement l’adresse IP de sortie utilisée pour votre compte ni l’empreinte d’appareil présentée. Pour les tester, nous avons créé deux comptes auprès de chacun des six outils cloud, tous depuis la France.

Nous avons ensuite vérifié chaque IP attribuée dans IPQualityScore (IPQS). Tester deux comptes par outil est important, car cela montre si un fournisseur réutilise la même infrastructure pour plusieurs clients.

Qu’est-ce qu’IPQualityScore (IPQS) ?

IPQS est un service indépendant de prévention de la fraude présent sur le marché depuis plus de 10 ans. Il évalue les adresses IP à partir des signaux issus de son propre réseau de systèmes leurres (honeypots), de pièges, de robots d’exploration et de flux recensant les abus.

Pour chaque IP, IPQS renvoie plusieurs champs utiles :

• fraud_score, de 0 à 100.
• Des indicateurs de proxy, de réseau privé virtuel (VPN) et de Tor.
• Le type de connexion, par exemple centre de données, résidentielle ou mobile.
• Les données de géolocalisation.
• L’historique récent des abus.

Il n’existe aucun seuil officiel transformant l’évaluation d’une IP en verdict de sécurité. Les propres exemples d’IPQS considèrent néanmoins les scores supérieurs à 75 comme très risqués, et l’entreprise revendique une précision d’environ 99,95 % pour la détection des proxys et VPN.

Nous utilisons IPQS comme point de référence indépendant pour comprendre ce qu’un système antifraude moderne peut observer. Une IP ayant fait l’objet de nombreux abus, un point de terminaison proxy connu ou une adresse IP appartenant à un centre de données et partagée par de nombreux comptes sans lien entre eux peuvent tous constituer des signaux couramment évalués par les systèmes de risque.

Les IP de centres de données ne sont pas nécessairement malveillantes. Elles sont souvent jugées moins fiables que les connexions résidentielles ou mobiles, car elles proviennent de fournisseurs d’hébergement et non de réseaux grand public. Dans le contexte de LinkedIn, elles peuvent devenir plus révélatrices lorsque de nombreux comptes apparaissent depuis la même infrastructure cloud.

IPQS s’est également avéré utile, car ses données de géolocalisation correspondaient souvent à celles affichées par LinkedIn dans les sessions de sécurité des comptes pendant nos tests. Certains fournisseurs de proxys annonçaient des emplacements qui ne correspondaient pas au pays identifié par IPQS ou LinkedIn, ce qui crée un autre facteur de risque : une incohérence géographique entre l’emplacement déclaré et celui observé pour la connexion.

IPQS n’est pas le moteur de risque privé de LinkedIn. Son score ne constitue ni un verdict sur la sécurité du compte ni une conclusion juridique. Il s’agit d’un benchmark indépendant permettant de comparer la qualité et la réputation des IP que les outils d’automatisation attribuent aux comptes des utilisateurs.

Résultats du test d’inscription aux services cloud

Ce que montre le tableau

1. Skylead constitue l’exemple le plus clairement préoccupant.

Les deux comptes de test utilisaient exactement la même IP de centre de données, 58.97.254.1, avec un score de fraude IPQS de 100. Deux profils sur une seule IP de centre de données correspondent au type de regroupement de comptes que la logique d’accès parallèle de LinkedIn peut évaluer (§ 2.9).

2. L’infrastructure signalée était partagée, et pas seulement au sein d’une même marque.

Dripify, Skylead et We Connect acheminent tous leur trafic par le même fournisseur en amont, HostRoyale Technologies (ASN 203020). Si une plage d’adresses de ce fournisseur voit sa réputation se dégrader auprès de LinkedIn, plusieurs outils peuvent être touchés simultanément.

3. HeyReach a ajouté un problème distinct de contrôle.

Ses IP affichaient des scores de fraude de 100, et son extension bloquait la déconnexion de deux manières : une interception webNavigation (background.js:1-17) et une règle declarativeNetRequest (rules.json:1-14). Cela peut empêcher l’utilisateur d’invalider la session après avoir transmis l’intégralité du tableau de cookies via api.heyreach.io/.../CreateLinkedInAccountFromCookies.

4. Meet Alfred présentait le contraste le plus net lors de ce test.

C’était le seul outil à attribuer aux deux comptes des IP non signalées avec un score de fraude de 0, et il imitait un agent utilisateur mobile. Une IP non signalée n’élimine toutefois qu’un seul facteur de risque. L’outil conserve toujours les identifiants dans son cloud et utilise le compte à la place de l’utilisateur depuis une autre machine.

5. Personne ne vérifie l’IP qui vous est attribuée.

Aucun des six outils ne proposait de vérificateur de qualité du proxy. Un outil peut attribuer une adresse signalée, ou un utilisateur peut ajouter un proxy de mauvaise qualité, sans recevoir d’avertissement clair. Le « contrôle de l’emplacement » désigne en outre généralement un contrôle au niveau du pays, et non de l’État ou de la ville (§ 2.9).

Nous ne pouvons pas observer le fonctionnement interne de ces serveurs, et nous considérons les hypothèses relatives à leur mode d’exécution comme « très probables ». En revanche, l’IP, l’infrastructure partagée, l’empreinte et la présence dans la liste de détection ne sont pas des déductions : nous les avons mesurées (voir l’encadré IPQS ci-dessus).

1.3 Outils contrôlant un navigateur complet

L’automatisation par navigateur utilise un environnement de navigateur complet plutôt qu’une simple extension légère ou un client API direct. Cette catégorie se divise en deux modèles très différents.

Outils basés sur un navigateur cloud

Un outil basé sur un navigateur cloud exécute un navigateur comme Chrome sans interface graphique ou Puppeteer sur le serveur du fournisseur. PhantomBuster est le seul fournisseur de ce groupe à reconnaître publiquement cette architecture.

Ce modèle présente néanmoins des faiblesses.

Puppeteer est détectable, et tout un secteur de la lutte contre les robots s’est développé autour de la détection de l’automatisation des navigateurs.

L’hébergement de plusieurs comptes crée également un risque de corrélation lorsque de nombreux « utilisateurs » partagent le processeur graphique (GPU), la pile audio et d’autres caractéristiques d’empreinte d’un même serveur.

Outils de bureau autonomes

Un outil de bureau autonome exécute un navigateur distinct basé sur Chromium sur la machine de l’utilisateur. Linked Helper utilise ce modèle.

Cette approche crée une surface de détection plus restreinte qu’une extension Chrome ou qu’une ferme de comptes cloud. Il n’existe aucun identifiant du Chrome Web Store que l’outil Active Extension Detection de LinkedIn puisse sonder (§ 2.1), aucun code d’extension injecté dans la page LinkedIn (§ 2.2 et § 2.3), et le compte conserve l’IP locale et l’empreinte de la machine de l’utilisateur.

Il existe aussi un avantage structurel. LinkedIn peut analyser à loisir toute extension publique du Chrome Web Store et concevoir un détecteur avant de déployer quoi que ce soit. Face à une application de bureau autonome, les tests de détection doivent être mis en production, où ils peuvent être observés.

L’utilisation d’un navigateur ne garantit pas la sécurité. Elle réduit seulement certains risques techniques. Les choix du développeur en matière d’empreinte, de navigation, de temporisation et de simulation des clics continuent d’influencer le risque.

Exemple détaillé : Dux-Soup combine plusieurs modèles dans un seul produit

La plupart des outils correspondent à une seule ligne de la cartographie des architectures. Dux-Soup est différent, car config.getEdition() déploie une architecture différente selon l’offre.

Dux-Soup constitue donc un exemple utile pour ce guide. Un même produit illustre l’extraction locale, le téléversement de session, l’exposition à l’AED, le blocage de la télémétrie et des limites de volume élevées dans différentes parties de sa configuration.

Flux de données de l’extension Chrome Dux-Soup. Les nœuds rouges représentent votre session LinkedIn ou vos données quittant votre environnement pour le cloud d’un fournisseur. Les nœuds gris représentent les données qui restent dans votre navigateur.

• Les offres Free, Pro et Turbo utilisent l’extraction locale (§ 1.1a). Voyager est appelé dans le navigateur de l’utilisateur avec un CSRF-token dérivé de JSESSIONID, de sorte que la session reste locale. Niveau de risque : moyen.
• L’offre Cloud utilise le téléversement de session (§ 1.1b et § 1.2a). Le service worker exécute chrome.cookies.getAll({domain:"linkedin"}), puis envoie l’intégralité des cookies, localStorage et les données navigator à app.dux-soup.com via PUT /api/{user}/sessions/{domain}. Il contrôle ensuite le compte par l’intermédiaire d’un canal Socket.io (sw.js:1, libs/socket-io/socket.io.js:1562). Il s’agissait de la charge utile de session la plus étendue observée parmi tous les outils.
• La présence de l’extension dans la liste AED de LinkedIn est confirmée (§ 2.1). L’identifiant d’extension ppdakpfeaodfophjplfdedpcodkdkbal et le fichier de sondage fetchforwarder.js figurent dans detection_db.json. À chaque consultation d’une page, LinkedIn peut récupérer chrome-extension://…/fetchforwarder.js, et une réponse positive peut signaler que l’extension est installée avant même que l’utilisateur clique.
• La configuration anti-détection crée son propre signal (§ 2.8). Des règles declarativeNetRequest bloquent li/track, sensorcollect, protechts et merchantpool (rules.json ; bouton d’interface killtracking). Ces règles se trouvent dans un fichier JSON statique que tout le monde peut consulter, et l’absence de télémétrie qui en résulte peut devenir une anomalie.
• Les limites combinent des réglages prudents et agressifs (§ 6). La valeur par défaut de maxinvites est fixée à un niveau raisonnable de 20/jour. La même interface porte maxvisits à 500/jour et propose une analyse « Turbo » d’environ 10 pages/minute, très au-delà d’un comportement de navigation humain normal.

2. La surface de détection : ce que LinkedIn peut voir, collecter et comparer

Il s’agit du cœur technique de ce guide. Pendant des années, une grande partie de la logique de détection de LinkedIn ne pouvait être décrite qu’à partir de l’expérience des spécialistes de la défense. L’enquête BrowserGate a changé la donne en disséquant le JavaScript de production de LinkedIn, notamment un module d’environ 2,7 Mo.

Cette analyse a découvert trois systèmes fonctionnant conjointement dans les pages LinkedIn :

1. Active Extension Detection (AED) sonde activement votre navigateur pour rechercher les extensions installées (§ 2.1).
2. Spectroscopy analyse passivement le DOM à la recherche des traces laissées par les extensions (§ 2.2).
3. APFC/DNA collecte une empreinte d’appareil comportant 48 caractéristiques (§ 2.6).

Ces signaux alimentent le pipeline de télémétrie de LinkedIn, notamment le point de terminaison li/track (§ 2.4). L’analyse des extensions s’exécute dans les navigateurs basés sur Chromium, notamment Chrome, Edge, Brave, Opera et Arc. BrowserGate a trouvé dans le code un contrôle littéral userAgent.indexOf("Chrome").

La liste des cibles continue également de s’allonger. Elle est passée de 38 extensions en 2017 à environ 461 en 2024, puis à 4 934 lors de notre relevé. Cela représentait une progression d’environ 12 nouvelles entrées par jour, signe que la liste était activement tenue à jour.

Le nombre 4 934 désigne les identifiants uniques d’extensions Chrome, tandis que 6 167 correspond à la liste plus large des cibles de sondage associant un identifiant et un fichier.

Nous présentons ci-dessous chaque vecteur de détection : mécanisme → données transmises aux serveurs de LinkedIn → outils concernés → méthode de vérification par vos soins.

2.1 L’outil d’analyse des extensions (AED) : une extension installée peut être visible

Le code des pages LinkedIn comprend un tableau codé en dur de paires {extension id, file}. Il peut s’agir de fichiers comme des logos, popup.html, manifest.json ou toute ressource exposée par l’extension via web_accessible_resources.

La page exécute silencieusement des appels fetch() vers des chemins tels que chrome-extension://<id>/<file>. Si la requête aboutit, LinkedIn peut déterminer que l’extension est installée.

Les détails du fonctionnement en production sont importants, car l’analyse est conçue pour rester discrète :

• Elle peut exécuter en parallèle une salve d’environ 6 200 requêtes fetch() au moyen de Promise.allSettled.
• Elle peut également analyser les éléments un par un avec un délai configurable staggerDetectionMs, ce qui la rend moins visible dans l’onglet « Network ».
• Elle peut attendre que le navigateur soit inactif au moyen de requestIdleCallback, afin que vous ne perceviez aucun ralentissement.
• Les erreurs sont absorbées par des blocs catch vides ; aucune erreur n’apparaît donc dans la console.
• Les résultats sont transmis sous la forme AedEvent {browserExtensionIds: [...]}.

Si l’extension figure dans la liste de LinkedIn, son installation peut être enregistrée à chaque consultation d’une page avant même que l’utilisateur agisse.

Vous pouvez le vérifier en environ trois minutes.

Ouvrez linkedin.com, accédez aux outils de développement, puis ouvrez l’onglet « Sources » et recherchez l’identifiant de votre extension dans tous les fichiers chargés. Vous trouverez cet identifiant dans chrome://extensions.

Ouvrez ensuite l’onglet « Network », filtrez sur li/track et rechargez LinkedIn. Vous pourrez observer les requêtes POST de télémétrie groupées quitter la page. Pour une vérification plus approfondie, recherchez AedEvent ou chrome-extension:// dans les fichiers JavaScript de LinkedIn.

2.2 Le spectroscope du DOM : l’outil d’analyse qui n’a pas besoin de liste

Un deuxième système analyse directement la page active. Il parcourt récursivement l’intégralité du DOM, y compris les nœuds de texte et les valeurs d’attributs, à la recherche de la sous-chaîne chrome-extension://.

Lorsqu’il la trouve, il extrait l’identifiant d’extension de 32 caractères et transmet un SpectroscopyEvent.

Ce système diffère de l’AED, car il n’a pas besoin d’une liste de cibles. Une nouvelle extension peut tout de même être détectée si elle injecte un élément, un style, un iframe ou un script renvoyant vers ses propres ressources chrome-extension://.

Ensemble, l’AED et Spectroscopy couvrent deux états courants d’une extension.

• L’AED peut détecter une extension installée mais inactive.
• Spectroscopy peut détecter une extension qui modifie activement la page LinkedIn.

Cet outil d’analyse s’applique au modèle d’automatisation du DOM présenté au § 1.1c.

2.3 Instantanés de page provenant d’un Web Worker

À des moments aléatoires, un worker d’arrière-plan peut recueillir un instantané structurel de la page. Cet instantané comprend les balises sans leur contenu textuel, ainsi que les éléments script/style avec leur contenu.

L’instantané est chiffré et envoyé pour une recherche de traces côté serveur. Vous ne pouvez pas voir ce que LinkedIn recherche, car cette analyse n’a pas lieu dans votre navigateur.

Nous connaissons ce mécanisme par expérience directe. C’est l’algorithme qui a détecté la première version de l’extension Chrome de Linked Helper en août 2019. La solution à court terme a consisté à rendre la copie de l’extension de chaque utilisateur structurellement unique, ce qui a permis de gagner du temps. Cette expérience est l’une des raisons pour lesquelles Linked Helper a quitté le Chrome Web Store et a été reconstruit sous la forme d’une application de bureau autonome.

Nous présentons cet épisode comme un fait historique. LinkedIn disposait de cette catégorie de détection de la structure des pages bien avant les découvertes de BrowserGate.

2.4 Le pipeline de télémétrie : li/track

Les systèmes ci-dessus convergent vers https://www.linkedin.com/li/track. Le nom de la méthode dans le code est fireTrackingPayload.

Ce point de terminaison reçoit des événements comportementaux, comme les mouvements de la souris, les clics et la saisie, ainsi que des verdicts des outils d’analyse comme AedEvent et SpectroscopyEvent.

Le mécanisme de transmission est conçu pour être fiable :

• Les événements sont regroupés par lots allant jusqu’à 29 par requête.
• Les requêtes ayant échoué sont retentées jusqu’à 4 fois.
• Les charges utiles sont compressées au moyen de la compression Lempel-Ziv (LZ) via compressToBase64.

Des points de terminaison associés traitent les données d’empreinte, notamment /platform-telemetry/li/apfcDf et /apfc/collect.

Retenez ces noms, car ils réapparaissent au § 2.8. Les extensions qui tentent de bloquer la télémétrie de LinkedIn doivent en bloquer l’intégralité. Oublier un seul point de terminaison peut révéler le blocage lui-même.

2.5 isTrusted : l’indicateur de clic qu’un script de contenu ne peut normalement pas modifier

Chaque événement du DOM comporte un indicateur isTrusted en lecture seule. Un véritable clic humain renvoie true.

Un événement créé par le script de contenu d’une extension renvoie false. Cela comprend dispatchEvent, new MouseEvent et les appels programmatiques .click(). Avec l’API normale des extensions, le constat de notre expert est direct : « vous ne pouvez pas le falsifier. Il vaut toujours false. »

Une réserve précise s’impose pour que l’affirmation résiste à l’examen. Les événements générés via l’API chrome.debugger peuvent renvoyer isTrusted:true. Chrome affiche alors toutefois une bannière jaune permanente indiquant que « ce navigateur est en cours de débogage par une extension ». La faille existe, mais elle ne passe pas inaperçue.

Selon les dernières informations directes de notre expert, LinkedIn n’appliquait pas encore de sanctions massives sur la base de cet indicateur. Il estimait que ce n’était « qu’une question de temps ». Une seule instruction if suffirait à LinkedIn.

2.6 L’empreinte en 48 points (APFC) : le passeport technique de votre machine

Qu’est-ce qu’une empreinte de navigateur ?

Une empreinte de navigateur est un instantané technique de votre machine. Elle peut inclure le processeur graphique (GPU) qui effectue le rendu d’une image de test, la manière dont votre pile audio traite un signal, les polices dont vous disposez, votre écran, les cœurs du processeur, la mémoire vive (RAM), le fuseau horaire et d’autres caractéristiques.

Pris séparément, chaque signal peut sembler anodin. Ensemble, ils peuvent devenir presque uniques. Ils sont également difficiles à imiter correctement, car une imitation convaincante exige de reproduire les particularités d’une autre machine, et pas seulement de modifier une chaîne du navigateur.

Le moteur d’empreinte de production de LinkedIn, nommé en interne APFC/DNA, collecte 48 caractéristiques. Les principaux groupes sont les suivants :

• Matériel et système d’exploitation (OS) : cœurs du processeur, RAM, 6 mesures de l’écran, écran tactile, batterie et plateforme.
• Graphismes, audio et polices : hachage canvas, fournisseur et moteur de rendu WebGL, 65 paramètres WebGL supplémentaires, réponse de l’oscillateur et du compresseur AudioContext, et polices installées.
• Réseau : IP locale via WebRTC, type de connexion, débit descendant et temps d’aller-retour (RTT).
• Environnement : fuseau horaire mesuré de deux manières, langue, plugins, types MIME, caméras, microphones et haut-parleurs via enumerateDevices, ainsi que les particularités du stockage.
• Signaux directs de détection des robots : webdriver, détection des environnements d’automatisation, mode de navigation privée et fonctionnalité appelée signals, capable de signaler les combinaisons falsifiées d’OS, de navigateur, de résolution ou de langue.

Un détail mérite d’être souligné. Do Not Track est collecté, mais exclu du hachage. En d’autres termes, LinkedIn enregistre cette préférence, mais elle n’arrête pas le processus plus général de prise d’empreinte décrit ici.

L’instantané est chiffré au moyen du chiffrement à clé publique RSA via apfcDfPK, stocké dans globalThis.apfcDf, puis joint sous forme d’en-tête HTTP aux requêtes API ultérieures de la session. BrowserGate mentionne SyncCollectionHandler et l’indicateur de fonctionnalité sync.apfc.headers pour ce comportement.

L’empreinte n’est donc pas envoyée une seule fois avant d’être oubliée. Elle peut accompagner les actions effectuées par votre session.

Cela crée deux problèmes majeurs pour l’automatisation cloud :

1. Un service cloud qui n’a jamais collecté votre véritable empreinte ne peut pas la reproduire. Comme l’a indiqué notre expert, « pour l’imiter, il faudrait d’abord la collecter ».
2. Il ne suffit pas de collecter quelques données d’empreinte. Il faudrait les collecter exactement de la même manière que LinkedIn (« s’ils dessinent un triangle différent, le hachage sera différent »). Le mécanisme de détection des incohérences signals existe précisément parce que les imitations rudimentaires sont déjà suffisamment courantes pour être détectées.

2.7 Le schéma de requêtes : une action génère de nombreuses requêtes

Ouvrez n’importe quel profil LinkedIn avec les outils de développement actifs : vous verrez un groupe de requêtes se déclencher simultanément. Une consultation normale de page peut comprendre le balisage, les appels Voyager, la télémétrie, les préchargements et d’autres requêtes complémentaires.

Un outil utilisant uniquement l’API peut créer une forme différente. Les données du profil sont consultées, mais la visite de la page du profil qui les accompagne n’a pas lieu. Comme l’a expliqué notre expert, « le profil est consulté, mais sa page n’est jamais visitée et les requêtes qui l’accompagnent ne sont jamais envoyées ».

Il s’agit d’une anomalie dans le schéma de requêtes. Elle peut être visible à partir des seuls journaux côté serveur.

LinkedIn dispose également de plusieurs options actives : renommer les points de terminaison pour chaque utilisateur, ajouter des en-têtes spéciaux et servir des requêtes leurres aux nouveaux comptes d’essai. Comme indiqué au § 2.6, l’en-tête spécial d’empreinte existe déjà en production.

Un cloud utilisant uniquement l’API doit choisir entre deux solutions, toutes deux problématiques. Il peut tenter de falsifier cet en-tête sans collecter honnêtement l’empreinte sous-jacente, ou envoyer des requêtes sans disposer du même contexte fourni par le navigateur. Les deux solutions peuvent laisser une trace.

2.8 Blocage de la télémétrie : une configuration anti-détection qui peut elle-même trahir l’outil

Certaines extensions tentent de se dissimuler en bloquant les points de terminaison de détection et de télémétrie de LinkedIn au moyen de l’API webRequest. La faiblesse de cette méthode tient à l’obligation de disposer d’une liste de blocage exhaustive.

Si l’extension oublie un seul point de terminaison, celui-ci peut signaler que d’autres canaux de télémétrie sont bloqués. Notre expert a qualifié cela de « signal manifeste de bannissement ».

D’après le code de production, la liste actuelle qu’un bloqueur devrait couvrir comprend :

• li/track
• /platform-telemetry/li/apfcDf
• /apfc/collect
• /sensorCollect
• l’iframe li.protechts.net
• le script merchantpool1.linkedin.com

Plus cette liste s’allonge, plus il est facile pour LinkedIn d’ajouter un nouveau point de terminaison avant la prochaine version de l’extension.

Manifest V3 apporte une précision importante. Les écouteurs webRequest bloquants ont disparu pour les extensions publiques, mais le blocage déclaratif via declarativeNetRequest reste possible.

Pour les auditeurs, l’inspection devient ainsi plus simple, car la liste de blocage se trouve désormais dans un fichier JSON statique à l’intérieur du paquet de l’extension.

2.8a Les outils externes de LinkedIn contre les robots

LinkedIn ne s’appuie pas uniquement sur son propre JavaScript. Il charge également des systèmes externes de détection des robots et de scoring.

L’analyse BrowserGate a identifié trois composants importants :

• HUMAN Security, anciennement PerimeterX : un iframe masqué de 0×0 provenant de li.protechts.net, positionné à left: -9999px avec aria-hidden et chargé avec uc=scraping dans l’URL. Les cookies associés comprennent _px3 et _pxvid.
• Merchant Pool : un deuxième script de prise d’empreinte provenant de merchantpool1.linkedin.com, lié au cookie de session de l’utilisateur.
• Google reCAPTCHA v3 Enterprise : scoring invisible lors du chargement de la page.

Ces systèmes sont activés par des indicateurs de fonctionnalités internes tels que pemberly.tracking.*. LinkedIn peut donc tester la détection sur des segments d’utilisateurs et étendre sa couverture sans modifier le fonctionnement du produit visible par les utilisateurs.

Le code confirme ainsi l’ancien avertissement de l’expert : « rien ne les empêche de le mettre en œuvre à tout moment. »

2.9 IP, géolocalisation et sessions parallèles

L’utilisation simultanée d’un même cookie sur deux IP (§ 1.2a) constitue l’un des signaux réseau les plus clairs.

La géolocalisation IP est suffisamment fiable pour créer des signaux de risque. Elle est précise à environ 80 % au niveau de l’État et identifie correctement la ville dans environ deux tiers des cas. Un utilisateur qui semble se trouver simultanément dans deux États peut donc générer un signal relativement peu ambigu.

Les options de contrôle des proxys cloud ne résolvent généralement pas entièrement le problème. De nombreux outils permettent de choisir un pays, mais pas un État ou une ville. Le travail en parallèle, par exemple lorsque l’utilisateur navigue en local tandis que le cloud utilise le même compte depuis une autre région, ajoute le même type de signal.

Notre rapport d’inscription présenté au § 1.2 a montré le problème en pratique. L’IP attribuée par le cloud était généralement une adresse IP appartenant à un centre de données qu’une base antifraude indépendante avait déjà classée comme très risquée. Les scores de fraude IPQS atteignaient 94 ou plus pour cinq des six outils exécutés côté serveur.

L’infrastructure était également partagée. Dripify, Skylead et We Connect acheminent tous leur trafic par HostRoyale Technologies, ASN 203020, et Skylead a attribué à nos deux comptes de test la même IP sur le même /24.

Une « IP dédiée dans votre pays » peut donc sembler moins risquée qu’elle ne l’est en réalité. Lors de notre test, nous avons souvent mesuré une IP de centre de données signalée sur une infrastructure partagée, et aucun des outils testés ne vérifiait la réputation de l’IP avant de l’attribuer.

2.10 Fuseau horaire et paramètres régionaux

Le fuseau horaire et les paramètres régionaux sont des signaux plus faibles, mais ils apportent tout de même du contexte. Comme l’a indiqué notre expert, « un mauvais fuseau horaire ajoute un point de plus ».

L’empreinte collecte deux fois le fuseau horaire selon deux méthodes. Une imitation partielle peut donc se révéler si les valeurs ne correspondent pas. Elle collecte également les langues du système.

Une session « basée aux États-Unis » exécutée depuis une machine réglée sur UTC+5 avec des paramètres régionaux incompatibles constitue le type d’incohérence que la fonctionnalité signals est conçue pour signaler.

2.11 La couche comportementale : les utilisateurs qui agissent manuellement peuvent également la déclencher

Les sections précédentes portent sur la détection des outils. Cette couche concerne le comportement ; c’est pourquoi les utilisateurs de LinkedIn qui agissent manuellement peuvent également subir des restrictions.

Les principaux risques comportementaux sont faciles à comprendre :

• Volume : d’après les cas historiquement observés par notre expert dans le cadre de l’assistance, environ 500 demandes de connexion par jour pouvaient entraîner une restriction sous deux semaines environ. L’envoi d’une demande de connexion toutes les 5 secondes pouvait provoquer une déconnexion. À la date de l’étude, le plafond était inférieur : LinkedIn appliquait une limite glissante d’environ 100 demandes de connexion par semaine pour la plupart des comptes, pouvant aller jusqu’à environ 200 pour les comptes établis de longue date ayant un Social Selling Index (SSI) élevé et environ 250 avec Sales Navigator.
• Manière d’ouvrir les profils : le collage massif d’URL de profils peut ressembler au comportement d’un outil d’extraction. Accéder aux profils par une recherche de nom ressemble davantage à un parcours utilisateur normal. L’ouverture massive d’URL est un déclencheur de restriction documenté, même lorsqu’elle est effectuée manuellement.
• Réactions des destinataires : le taux d’acceptation compte, tout comme les signalements « I don’t know this person ». Même avec un taux d’acceptation de 80 %, 400 demandes de connexion par jour laissent quotidiennement 80 personnes décider si elles doivent ignorer, refuser ou signaler la demande.
• Accès parallèle depuis différents pays : ce point renvoie au § 2.9. Utiliser le compte localement tandis qu’un service cloud agit depuis un autre pays peut ajouter des signaux de risque au niveau du réseau.

L’architecture et le comportement constituent deux couches distinctes. Une configuration plus sobre peut toujours créer un risque si le compte adopte un comportement irréaliste, et une utilisation entièrement manuelle peut aussi provoquer des restrictions lorsque le volume ou les schémas semblent automatisés.

3. Il s’agit d’un modèle de scoring : comment les sanctions de LinkedIn s’intensifient

Aucun des signaux de détection présentés au § 2 ne doit être considéré comme un simple interrupteur marche/arrêt. L’analyse de l’expert correspond à nos observations dans le code, les tests cloud et les schémas comportementaux : « Tout fonctionne comme un modèle de scoring ; chaque signal augmente le score de risque et rapproche le compte d’un bannissement. »

LinkedIn n’a donc pas besoin d’un signal unique et parfait. Il peut comparer de nombreux signaux plus faibles portant sur votre navigateur, le comportement de l’extension, l’adresse IP, l’historique des sessions et les schémas de prospection.

L’échelle des sanctions est bien connue des utilisateurs ayant fait l’objet de mesures :

1. Avertissement : LinkedIn peut afficher un message indiquant « vous utilisez peut-être des outils d’automatisation ».
2. Restriction temporaire : le compte peut être limité jusqu’à ce que vous procédiez à une vérification d’identité, par exemple par SMS ou en téléversant une pièce d’identité.
3. Suspension définitive : lorsque LinkedIn affiche « LinkedIn Member » à la place d’un nom, cela signifie généralement que le compte n’existe plus.

Le risque s’accumule entre les différentes couches. Une extension installée peut ajouter un signal (§ 2.1), les traces de code peuvent en ajouter d’autres (§ 2.2–§ 2.8), les anomalies réseau peuvent constituer un autre groupe (§ 2.9–§ 2.10), et le comportement du compte peut encore faire progresser le score (§ 2.11).

Une architecture moins risquée ne protège pas contre un comportement imprudent. Si vous envoyez trop de demandes de connexion, ouvrez massivement des profils via leurs URL ou provoquez trop de signalements « I don’t know this person », le comportement seul peut créer un risque de restriction.

Le cas inverse est encore plus important pour le choix de l’outil. Un comportement prudent ne corrige pas une architecture risquée. Envoyer 15 demandes de connexion par jour ne supprimera pas les signaux techniques créés lorsque votre cookie de session est réutilisé depuis un centre de données situé dans un autre pays.

4. La liste de contrôle pour auditer le code en 5 minutes

Il n’est pas nécessaire d’être chercheur en sécurité pour effectuer un premier audit d’une extension Chrome. Vous pouvez décompresser l’extension avec un outil d’extraction de fichiers CRX, ou l’installer et inspecter ses fichiers locaux.

Sur macOS, les extensions Chrome installées sont généralement stockées dans ~/Library/Application Support/Google/Chrome/Default/Extensions/. Une fois les fichiers obtenus, recherchez les schémas ci-dessous.

Il s’agit de la même logique d’audit que celle utilisée pour étayer les affirmations portant sur le code dans ce rapport. Ne jugez pas une autorisation isolément. Suivez le parcours de la valeur et déterminez où elle va.

Lorsque vous rédigez le verdict d’un audit, rattachez toujours l’affirmation aux preuves. Si le code montre qu’un cookie est envoyé vers le domaine d’un fournisseur, dites-le directement. Si le comportement côté serveur ne peut pas être observé de l’extérieur, qualifiez l’hypothèse de « très probable » et expliquez comment ce risque peut se concrétiser.

Voici un modèle utile pour rédiger les verdicts, emprunté à l’expert : « L’extension sert de passerelle pour extraire les cookies et n’a aucune autre fonction » ou, pour les clouds : « le service fonctionne très probablement au moyen d’appels directs à l’API ; les risques sont A, B et C ».

Toute accusation doit correspondre à un élément précis du code. Tout le reste doit être présenté comme « très probable ».

5. Le tableau général des risques

Ce tableau traduit les conclusions en termes simples. Il présente le problème, ce qu’il menace et l’endroit où nous l’avons découvert ou mesuré.

Pour le comportement côté serveur, nous qualifions l’hypothèse de « très probable », car il est impossible de prouver entièrement de l’extérieur le mode d’exécution interne d’un serveur cloud. Nous ne présentons comme des faits que ce que nous avons découvert dans le code ou mesuré directement lors de l’inscription.

6. Comment automatiser de manière moins risquée

Ces benchmarks ne sont pertinents que si l’architecture limite déjà les principaux risques techniques. Si votre outil téléverse la session, utilise une infrastructure cloud partagée ou repose sur des configurations de proxy non contrôlées, les seules limites quotidiennes ne supprimeront pas le risque technique décrit ci-dessus.

Effectuez ces vérifications avant d’automatiser votre prospection sur LinkedIn :

• Limitez-vous à environ 15–20 demandes de connexion par jour. Cela correspond à la limite glissante de LinkedIn d’environ 100 demandes de connexion par semaine. L’ancien conseil de « 50–70 demandes de connexion par jour » est antérieur au plafond hebdomadaire.
• Retirez les demandes de connexion en attente toutes les 3 semaines environ. Un grand nombre de demandes de connexion ignorées peut devenir un signal négatif en soi.
• Surveillez votre taux d’acceptation. S’il diminue, le problème vient généralement du ciblage ou de la pertinence du message, et pas seulement de la limite quotidienne.
• Faites vivre le profil avant de lancer l’automatisation. Prévoyez environ un mois d’activité manuelle normale, une vraie photo et un véritable employeur avant d’automatiser un compte récent ou peu actif.
• Ouvrez les profils en recherchant leur nom, sans coller massivement leurs URL. Comme indiqué au § 2.11, l’ouverture massive d’URL peut également entraîner des restrictions pour les utilisateurs qui agissent manuellement.
• Utilisez une IP par compte avec une zone géographique cohérente. Conservez si possible la même ville ou le même État, et faites correspondre le fuseau horaire et les paramètres régionaux à l’emplacement habituel du compte (§ 2.9–§ 2.10).
• N’exécutez pas de sessions parallèles. Évitez d’utiliser le compte localement pendant qu’un outil l’exécute dans le cloud. Évitez également l’activité simultanée depuis deux appareils, deux régions ou en local et dans le cloud.

Une approche moins risquée associe une architecture qui réduit davantage les risques techniques, une origine de session stable, un rythme réaliste et un comportement semblable à celui d’un membre LinkedIn utilisant normalement son compte.

7. Pourquoi Linked Helper utilise une architecture de bureau

Transparence totale

Ce rapport est publié par Linked Helper ; nous devons donc présenter clairement notre propre position. Notre architecture découle des enseignements tirés lorsque la première version de Linked Helper était encore une extension Chrome.

Cette expérience nous a appris un point important : toute extension comporte des surfaces de détection qu’un logiciel de bureau autonome n’a pas besoin d’exposer. Nous avons décidé de ne pas continuer à ajuster une extension pour contourner ces signaux.

Voici comment ce choix répond aux risques abordés dans ce rapport.

Aucune trace d’extension

Linked Helper n’est pas une extension de navigateur. Il n’existe aucun identifiant du Chrome Web Store, aucun paquet d’extension installé dans Chrome et aucune ressource d’extension que l’outil AED de LinkedIn puisse sonder (§ 2.1).

Aucun code n’est non plus injecté dans les pages LinkedIn. Les interfaces d’extension, les scripts de contenu, les boutons et les panneaux injectés peuvent devenir visibles pour Spectroscopy et l’analyse des instantanés de page (§ 2.2–§ 2.3).

Linked Helper conserve les commandes de campagne, les files d’attente et les tableaux de bord dans l’application de bureau. La page LinkedIn n’est pas modifiée par des panneaux ou des scripts d’extension Linked Helper.

Aucun transfert de session vers le cloud

Votre session LinkedIn reste sur votre machine. Linked Helper ne téléverse pas li_at, li_a, les ensembles de cookies, le stockage du navigateur ou les ensembles de session dans le cloud d’un fournisseur.

Cela supprime plusieurs schémas de risque abordés plus haut dans le rapport :

• Aucun navigateur distant n’agit à votre place
• Aucune ferme de comptes dans le cloud n’utilise votre session
• Aucune infrastructure réseau partagée du fournisseur n’est attribuée à votre compte
• Aucune réutilisation cachée de votre session LinkedIn dans le cloud n’est nécessaire

Linked Helper n’automatise pas non plus la prospection sur LinkedIn au moyen d’une couche distincte reproduisant les appels d’API. De nombreux produits cloud dépendent de la reproduction du trafic de l’API LinkedIn, ce qui peut créer un schéma de requêtes différent de celui d’une session de navigateur normale.

Linked Helper fonctionne plutôt au moyen de son propre moteur de navigateur local. Les actions ont lieu dans un environnement de navigateur sur votre machine, en utilisant votre session LinkedIn authentifiée et votre adresse IP, ou le proxy que vous attribuez.

Une identité distincte pour chaque compte

Linked Helper sépare l’identité du navigateur pour chaque compte. L’exécution de plusieurs comptes LinkedIn dans un même profil de navigateur peut créer des signaux de corrélation ; chaque instance de Linked Helper utilise donc des cookies, un stockage et des caches distincts.

Chaque instance peut également générer ses propres caractéristiques d’empreinte du navigateur. Cela réduit la probabilité que plusieurs comptes semblent provenir exactement de la même configuration d’appareil.

Une protection contre les erreurs de compte est également prévue. Si vous essayez de vous connecter à un autre compte LinkedIn dans une instance existante, Linked Helper déconnecte le compte actuel au lieu de mélanger silencieusement les sessions.

Le contrôle des proxys est également important pour les équipes ou les utilisateurs qui gèrent plusieurs comptes. Linked Helper vous permet d’attribuer un proxy à chaque instance afin que vous contrôliez l’identité réseau associée à chaque compte.

Cela diffère de nombreux outils cloud, pour lesquels le fournisseur choisit l’IP de sortie à votre place. Linked Helper comprend également un vérificateur intégré de réputation des IP fondé sur les données d’IPQualityScore (IPQS), afin que vous puissiez évaluer la qualité du proxy avant d’exécuter des campagnes.

Les contrôles comportementaux restent importants

L’architecture ne réduit que certains signaux de risque techniques. LinkedIn peut également évaluer le comportement du compte ; celui-ci reste donc important.

Linked Helper comprend des contrôles qui vous aident à éviter les schémas manifestement mécaniques :

• Navigation dans la page : Linked Helper peut effectuer des recherches et cliquer dans l’interface de LinkedIn au lieu d’accéder directement aux URL des profils.
• Limites d’actions quotidiennes : des valeurs par défaut prudentes contribuent à réduire les pics d’activité irréalistes.
• Limites glissantes sur 24 heures : les limites sont mesurées sur des fenêtres glissantes, et pas seulement sur des journées civiles.
• Délais aléatoires : le temps entre les actions varie au lieu de répéter toujours le même intervalle.
• Volumes quotidiens et plages horaires variables : l’activité des campagnes peut varier d’un jour à l’autre au lieu de répéter des nombres identiques.
• Variantes de messages : vous pouvez alterner plusieurs versions d’un message pour que la prospection ne ressemble pas à la répétition d’un même modèle.

Ces contrôles ne rendent pas l’automatisation exempte de risque ; ils vous aident à adopter un comportement plus proche de celui d’un utilisateur LinkedIn normal.

Une réserve importante

Aucun fournisseur ne peut promettre une sécurité totale, y compris Linked Helper. La couche comportementale décrite dans ce rapport évalue aussi bien les humains que les outils d’automatisation.

Une prospection de mauvaise qualité, un volume excessif, de faibles taux d’acceptation, une activité inhabituelle du compte et un ciblage imprécis peuvent créer un risque quel que soit le logiciel utilisé. Une architecture moins risquée réduit certains signaux techniques, mais ne neutralise pas les risques liés à un comportement imprudent.

La question utile n’est pas de savoir si une solution est « sûre ou risquée ». Il faut déterminer combien de signaux détectables l’architecture expose avant même que votre comportement soit pris en compte.

Linked Helper est conçu pour conserver la session en local, éviter les signaux liés aux extensions et au transfert de sessions vers le cloud, isoler les identités des comptes, vous donner le contrôle de la configuration IP et favoriser un rythme plus réaliste.

Note méthodologique

L’analyse statique a été effectuée sur les paquets d’extensions distribués publiquement en mai–juin 2026. L’audit d’inscription aux services cloud a testé six outils avec deux comptes chacun en juin 2026.

Les versions évoluent et les fournisseurs publient des mises à jour. Les classifications de ce rapport reflètent le code que nous avons lu et les IP qui nous ont été attribuées pendant les tests. Les références de fichiers et les numéros de ligne, les IP de sortie, la réputation des IP et la présence des extensions associées dans la liste de détection sont disponibles lorsqu’ils ont été mesurés.

Les hypothèses relatives au fonctionnement interne des serveurs sont signalées comme « très probables » dans l’ensemble du rapport, car nous ne pouvons pas prouver de l’extérieur toutes les méthodes d’exécution côté serveur. Nous ne présentons comme des faits que ce que nous pouvons démontrer dans le code ou mesurer directement.

Ce guide fournit une vue d’ensemble. Chaque analyse approfondie par marque apporte des preuves supplémentaires, et l’exemple de Dux-Soup au § 1 montre comment un même produit peut combiner plusieurs modèles d’architecture selon les offres. Linked Helper n’est ni affilié à LinkedIn, ni approuvé par LinkedIn, ni partenaire officiel de LinkedIn.