Si vous avez installé une app récemment, vous avez surement remarqué le petit popup RGPD qui vous demande votre consentement pour les cookies et le tracking. Vous cliquez évidemment sur "Refuser" en vous disant que c'est réglé... Ben en fait... non.

Des chercheurs ont passé au crible 400 applications mobiles populaires (200 sur Android, 200 sur iOS) et résultat, 100% d'entre elles violent au moins une exigence du RGPD. Et près de la moitié de ces apps continuent à contacter des trackers MÊME APRÈS que vous ayez dit non.

Sympa le "consentement" !

Du coup, plutôt que de vous laisser vous faire gauler par ces mouchards, je vous propose un petit guide pour auditer vous-même les apps que vous utilisez. Sans vous prendre la tête, promis.

Ce qu'il vous faut

• Un téléphone Android (iOS, c'est plus compliqué, Apple verrouille tout)
• TrackerControl , l'outil d'audit qu'on va utiliser
• 10 minutes de votre temps
• L'option "Sources inconnues" activée dans les paramètres sécurité d'Android (l'app n'est pas sur le Play Store...)

Étape 1 : Installer TrackerControl

TrackerControl est donc un outil open source développé par des chercheurs. La bestiole analyse le trafic réseau de chaque app pour détecter les connexions vers des serveurs de tracking.

Rendez-vous sur le GitHub du projet et téléchargez l'APK. Installez-le en autorisant temporairement les sources inconnues.

Étape 2 : Lancer l'audit

Une fois installé, TrackerControl se comporte comme un VPN local (vos données ne sortent pas de votre téléphone, rassurez-vous). Activez-le et lancez l'app que vous voulez auditer.

L'outil va alors intercepter toutes les connexions sortantes et les classer : publicité, analytics, tracking social, fingerprinting... Y'a de quoi faire le tri !

L'interface de TrackerControl - sobre mais efficace ( Source )

Étape 3 : Interpréter les résultats

Ce qu'il faut surveiller :

• Connexions AVANT toute action : Si l'app contacte des trackers dès son lancement, avant même que vous ayez vu un popup de consentement, c'est une violation du critère "Prior consent"
• Connexions APRÈS refus : Relancez l'app après avoir refusé le tracking. Si des connexions partent quand même vers Google Analytics, Facebook ou autres... bingo !
• Le nombre de domaines contactés : Une app de lampe torche qui contacte 15 serveurs différents, c'est suspect (oui ça existe)

Détail des trackers détectés - on voit tout ce qui sort ( Source )

Les 6 critères RGPD que les apps violent

L'étude suivante a identifié six types de violations :

• Prior : L'app collecte VOS données avant de vous demander votre avis
• Informed : On vous dit pas vraiment ce qu'on fait avec vos données
• Freely-given : Pas le choix, c'est "accepte ou dégage"
• Specific : Le consentement est trop vague, genre "améliorer nos services"
• Unambiguous : L'interface est conçue pour vous faire cliquer sur "Accepter"
• Revocable : Vous dites non, mais ça continue quand même (près de la moitié des apps)

C'est flippant, non ? Comme je vous l'expliquais dans mon article sur le mythe du smartphone espion , le vrai problème n'est pas le micro qui vous écoute... c'est ce réseau de data brokers qui aspire tout ce qu'ils peuvent.

Dépannage

Et si TrackerControl ne détecte rien, vérifiez que le "VPN" est bien actif (icône de clé dans la barre de notifications). Certaines apps détectent les VPN et changent leur comportement, du coup relancez plusieurs fois pour être sûr.

Pour aller plus loin dans la protection de vos données, j'ai publié également ce guide sur la suppression de vos données personnelles qui vous donnera quelques pistes.

Voilà, maintenant vous avez les outils pour aller à la pêche aux trackers. De quoi regarder vos apps d'un autre œil, j'imagine !

Source

Après le DMCA, après la DADVSI , après SOPA, après PIPA, après EARN IT... voici le NO FAKES Act ! Bref, un nouveau projet de loi américain pondu par des gens qui visiblement n'ont jamais lancé un git clone de leur vie.

Le texte ( S.1367, 119e Congrès , introduit en avril 2025) part d'une intention louable qui est de protéger les gens contre les deepfakes non consentis. Vous savez, ces vidéos truquées où votre tête se retrouve sur un corps qui n'est pas le vôtre, de préférence à poil...

Mais comme toujours, l'enfer est pavé de bonnes intentions et la méthode choisie va potentiellement atomiser tout l'écosystème de l'IA open source.

En fait, une large partie des services qui hébergent du contenu généré par les utilisateurs devront mettre en place une logique de notice-and-staydown basée sur du "digital fingerprinting" afin de pouvoir retirer le contenu signalé et empêcher que les mêmes œuvres réapparaissent après notification. De quoi faire pleurer donc n'importe quel admin sys qui a déjà dû gérer un serveur de modération.

Et là où ça se corse c'est que contrairement au DMCA et ses exceptions , ce texte ne prévoit pas de véritable mécanisme de contre-notification façon DMCA. Quelqu'un signale votre contenu comme étant un deepfake ? Hop, c'est retiré. Vous pensez que c'est une erreur ? La seule voie prévue pour espérer une remise en ligne passe par une action en justice (sous 14 jours) contre l'expéditeur de la notification. Alors direction le tribunal fédéral, les amis...

Et les coûts de conformité estimés par la CCIA donnent le vertige car en moyenne, ça devrait tourner à environ 1,64 million de dollars la première année pour une simple startup. Et je ne parle même pas des projets open source qui distribuent des modèles d'IA générative... Comment Stable Diffusion ou Whisper pourraient-ils implémenter du fingerprinting sur des modèles que n'importe qui peut télécharger et faire tourner localement ? Mystère et boule de gomme !

Le truc bien moche, c'est que le texte prévoit des dommages et intérêts pouvant grimper jusqu'à 750 000 dollars par œuvre pour les plateformes non conformes. Autrement dit, si une plateforme ne réagit pas correctement après notification, elle peut devenir bien plus exposée à ce que font ses utilisateurs avec des outils d'IA... Voilà donc de quoi sérieusement refroidir les ardeurs de quiconque voudrait partager un petit modèle open weights.

Dans un autre style, ça me rappelle l'affaire youtube-dl où le DMCA avait été utilisé pour faire retirer un outil open source de GitHub sauf que là, on passe à l'échelle supérieure.

Voilà donc encore un lance-flammes législatif imaginé pour tuer une mouche et malheureusement, l'open source risque d'être le dommage collatéral de ce texte mal calibré.

Voilà les amis... l'avenir de l'IA ouverte pourrait bien se jouer dans les mois qui viennent aux US, et ça, ça va faire mal.

Source

GPT-4o , Claude Opus, Grok, Llama et j'en passe... On le sait, toutes ces IA sont en concurrence dans votre petit cœur de vibe codeur... Mais voici VRAIMENT ce qui se passe quand vous mettez ces 10 modèles d'IA autour d'une table **pour jouer au Mafia **!

Et vous allez voir, c'est pas beau à voir.

Pour ceux qui connaissent pas, le Mafia (ou Loup-Garou pour les intimes), c'est ce jeu où une équipe de vilains doit éliminer les gentils sans se faire griller. Bref, un jeu de bluff, de manipulation et de mauvaise foi assumée, ce qui en fait le terrain de jeu parfait pour tester si nos chères IA savent mentir.

La chaîne YouTube Turing Games a donc organisé cette petite expérience sociale avec 10 modèles : GPT-4o, GPT 5.1, Claude Opus 4.5, Claude Sonnet, Grok, Llama 4, DeepSeek, Gemini, Gemini Pro et Kimi.

Trois d'entre eux ont été désignés comme la Mafia (GPT 5.1, Llama 4 et Gemini Pro), un comme le Sheriff capable d'enquêter sur les autres (Grok), et le reste comme de braves couillons de villageois.

Si vous développez un logiciel open source auto-hébergé, vous connaissez sûrement ce dilemme qui est de comment savoir si votre projet est réellement utilisé sans devenir l'affreux Big Brother que vous combattez ? Soit vous ne mesurez rien et vous codez dans le vide, soit vous collez du Google Analytics ou assimilé et vous trahissez l'esprit même du self-hosting.

Benjamin Touchard (que certains d'entre vous connaissent peut-être via son projet Ackify ) a décidé de résoudre ce problème avec SHM, pour Self-Hosted Metrics . Son idée c'est de proposer une télémétrie respectueuse de la vie privée, où chaque instance génère sa propre identité cryptographique dès le premier démarrage.

Concrètement, quand vous intégrez le SDK dans votre application (dispo en Go et Node.js 22+), chaque installation génère une paire de clés Ed25519, un peu comme quand vous générez vos clés SSH pour la première fois. Tous les échanges avec votre serveur SHM sont ensuite signés cryptographiquement, ce qui garantit l'intégrité des requêtes et leur origine. L'instance a une identité persistante (pseudonyme), mais ça n'identifie pas l'utilisateur final.

Côté données collectées, ensuite c'est vous qui décidez. Votre app envoie périodiquement un JSON avec les métriques que vous avez définies, et le dashboard s'adapte dynamiquement. Y'a pas de schéma imposé, pas de PII (données personnellement identifiables) et par défaut, le SDK collecte aussi des infos système (OS, CPU, RAM), mais c'est désactivable.

Pour ceux qui veulent héberger le bouzin, c'est du Docker classique... Vous créez un fichier compose.yml, vous configurez le DSN PostgreSQL, vous récupérez les migrations SQL, et hop un docker compose up -d. Le dashboard est alors accessible par défaut sur le port 8080 et affiche automatiquement vos métriques métier, la distribution des versions, le nombre d'instances actives, etc.

Et pour les utilisateurs finaux qui ne veulent vraiment pas participer, un simple DO_NOT_TRACK=true dans les variables d'environnement désactive complètement la télémétrie.

Le code du serveur est sous licence AGPL (les SDKs ont leur propre licence, vérifiez sur le dépôt) et y'a aussi des badges SVG à coller dans vos pages README pour afficher fièrement le nombre d'instances de votre app qui tournent.

Bref, si vous distribuez un logiciel auto-hébergé et que vous voulez savoir combien d'instances sont actives sans compromettre la vie privée des utilisateurs, c'est le top !

Merci à Benjamin pour le partage !