Hello @steph1 
Le souci c’est que ce que tu demandes se contredit un peu. Déjà, un profil complet (pas juste le public), ça sort forcément d’une session authentifiée, l’API interne de linkedin. Donc y’a toujours un compte derrière. Quand un outil te dit « sans utiliser tes comptes », ça veut dire qu’il tape dans celui de quelqu’un d’autre, et c’est ce compte-là qui prend le ban, pas toi.
Une fois ce compte posé, tes 3 autres critères (live, en masse, sans cramer le compte) peuvent pas tenir ensemble. En gros t’as trois familles :
1. Le « comptes farming » (Apify, Bright Data, PhantomBuster, vayne…)
Ton compte est tranquille, mais la data vient de comptes tiers qui eux se font griller. Du coup fraîcheur et fiabilité font le yoyo, les actors cassent à chaque update de détection de linkedin. Et souvent le « live » c’est de la file d’attente, pas du temps réel. Le coût grimpe vite quand tu pousses le volume.
2. Les bases déjà scrapées (style Proxycurl, waterfall d’enrichissement)
Du volume, pas cher, mais c’est du cache. Donc ça casse ton critère « live ». Bien si t’as pas besoin de temps réel, sinon oublie.
3. Ton propre compte
C’est ce qui reste le plus propre côté risque, et t’as la donnée complète en temps réel. Le hic c’est que ça monte pas en volume, un compte reste un compte. Et si tu commences à en empiler pour scaler, tu retombes direct dans le cas 1.
Bref tu peux pas avoir les 3 en même temps, faut choisir ceux qui comptent pour ton use case. Volume massif, tu fais du comptes farming et t’assumes la fraîcheur variable. Précision temps réel sur des comptes que tu maîtrises, tu restes petit.
Et linkedin a une détection comportementale assez costaud, donc tout ce qui s’écarte trop du vrai usage se fait repérer vite. C’est aussi pour ça que le scraping de masse pas cher est souvent pourri niveau qualité.
Je précise que je bosse sur un truc dans ce domaine (de l’exécution linkedin pilotée par un agent), donc je suis le nez dedans en ce moment
Si tu veux creuser un point hésite pas.