Aller au contenu
La Lettre IT
Glossaire

Télémétrie

Collecte automatisée de mesures d'usage et de santé — compteurs, traces, journaux — remontée par un système. Indispensable à l'exploitation, elle devient du pistage dès qu'elle identifie des personnes.

Dans les synthèses

3 min de lecture
Développement & outils

Hister : un moteur de recherche privé pour vos pages visitées et fichiers locaux

En bref

  • Hister indexe l'intégralité du contenu des pages web que vous visitez et de vos fichiers locaux, stockés privément sur votre machine ou serveur.
  • Le projet, créé par l'auteur de Searx, offre une interface web, un terminal, et une intégration MCP pour les assistants IA.
  • Ce type de recherche personnelle complète a existé chez Google Chrome en 2008 avant suppression en 2013, et plusieurs utilisateurs en réclament le retour.

Dans les commentaires

Débat partagé : plusieurs commentateurs saluent le retour d'une fonctionnalité disparue (Google Chrome 2008-2013) et confirment l'utilité pratique en production. Quelques réserves portent sur la maintenance de binaires non packagés, les frictions nomenclature, et des cas d'usage alternatifs (Zotero, ChatGPT comme contournement).

Lire la suite

Notre lecture

Hister adresse un vrai besoin : retrouver de l'information déjà rencontrée sans dépendre de Google ou d'une API tierce. La résonance utilisateurs en production (au moins un signale un mois d'utilisation stable) et la nostalgie pour la fonction Chrome 2008 valident le concept. Le principal frein court terme reste la distribution : binaires téléchargés directs plutôt que paquets de distribution, ce qui peut ralentir l'adoption auprès de bases d'utilisateurs prudentes. Le changement de nom imminent ne modifie pas la valeur technique. À tester pour les équipes ayant une charge de recherche documentaire élevée (chercheurs, consultants, développeurs archivant des décisions) et acceptant de faire tourner une petite infra locale. Pas d'action immédiate pour les autres.

Lire la synthèse complète
3 min de lecture
IA & modèles

Jev Ultrafast : un agent navigateur avec espace d'actions dynamique et indexé

En bref

  • Jev Ultrafast est un agent navigateur construit sur une architecture à deux décisions par cycle : identification d'une opération (clic, texte, sélection, scroll, attente) puis de sa cible sur l'élément indexé.
  • Démonstrateurs : recherche Google Flights en 7,1 secondes, article Wikipedia trouvé en 2,8 secondes, aucune injection de JavaScript côté navigateur ni sélecteurs générés.
  • L'approche repose sur un modèle LLM petit et rapide pour le texte seul, tandis qu'une API TypeSafe gère les décisions structurées (opération, cible).
  • Code open source disponible avec support OpenRouter, Gemini, GLM, DeepSeek.
  • Le projet affiche aussi Browser Use Cloud, une version cloud en waitlist, distincte de l'implémentation locale.

Dans les commentaires

Débat partagé, avec réserves fortes sur l'accessibilité et les limites réelles.

Lire la suite

Notre lecture

Jev Ultrafast présente une architecture intéressante : cycle court (une décision réseau par action), état structuré plutôt que screenshots répétés, validation géométrique. Les gains de latency observés sur deux tâches sont réels mais limités à un contexte contrôlé. Le point critique non résolu : TypeSafe reste une dépendance cloud payante, ce qui contredit l'angle « local et rapide ». Les problèmes de télémétrie non opt-in et les rapports de démo cassée réduisent la confiance. Intéressant pour comprendre un design d'agent efficace, mais loin d'être une solution clé en main ou une percée fiabilité. À tester en local avant d'investir.

Lire la synthèse complète
5 min de lecture
Sécurité

Les constructeurs automobiles collectent et revendent les données de conduite de leurs clients

En bref

  • General Motors a reçu une amende record de la FTC pour avoir vendu les données de conduite de ses clients à des courtiers en assurance, souvent sans consentement éclairé.
  • Tous les grands constructeurs automobiles pratiquent la collecte massive de données comportementales (vitesse, localisation, horaires), mais les contrôles de confidentialité restent opaques et fragmentés.
  • La législation américaine proposée (DRIVER Act) reste insuffisante : elle garantit l'accès et la suppression des données, mais n'interdit pas leur collecte initiale.
  • Les utilisateurs n'ont que peu de moyens techniques pour bloquer cette télémétrie une fois le véhicule acheté.

Dans les commentaires

Débat partagé entre acceptation technique des données comme nécessité systémique et rejet moral de leur monétisation sans contrôle. Quelques commentateurs relèvent des dimensions positives (données de gestion du réseau électrique pour les VE), mais largement dominé par le scepticisme quant à la réalité des garanties légales existantes.

Lire la suite

Notre lecture

Le problème est réel et systémique : tous les constructeurs le pratiquent, pas seulement GM. La dimension importante pour une organisation est moins technologique que réglementaire et contractuelle. La DRIVER Act, probablement adoptée, restera insuffisante parce qu'elle n'interdit pas la collecte en amont. La Californie (AB-1542) crée un précédent fédéral possible, mais reste à appliquer. Sur le plan technique, les utilisateurs ont peu de moyens : le blocage réseau (fusibles, Faraday) fonctionne partiellement mais entraîne des risques de fonctionnalité et de stockage local en attente. Les contrats de financement compliquent encore l'opt-out. Pour les équipes achats ou de flotte d'entreprise, la question vaut la peine d'être soulevée explicitement lors des négociations constructeurs, mais pas d'action d'urgence : la situation évolue sous pression réglementaire (FTC, Californie, Trump, défenseurs). À surveiller plutôt qu'à résoudre aujourd'hui.

Lire la synthèse complète
3 min de lecture
Sécurité

Neuf agents de code face à votre machine : ce qu'ils font vraiment en local

En bref

  • Un développeur a passé neuf coding harnesses (Claude Code, Codex CLI, Gemini CLI, Aider, Cline & consorts) au banc d'essai sur un simple laptop, en regardant non pas la qualité du code produit mais ce que chaque outil s'autorise à faire sur le poste : lecture de fichiers hors du projet, exécution de commandes shell, sorties réseau, modèles de permission et qualité réelle du sandbox. Le constat est peu flatteur : les garde-fous varient énormément d'un outil à l'autre, beaucoup reposent sur la bonne volonté de l'utilisateur qui clique « approuver », et le mode permissif ( « YOLO » ) est devenu la norme de fait parce que les confirmations permanentes tuent la productivité. Le comparatif sert surtout de cartographie des compromis : plus l'agent est autonome, plus il a les mains dans votre système de fichiers et vos identifiants.

Dans les commentaires

Utile mais déjà périmé : intérêt réel, scepticisme méthodologique

Lire la suite

Notre lecture

Si vos développeurs utilisent ces outils sur des postes qui portent des clés SSH, des tokens cloud et du code client, vous avez déjà un problème de gouvernance. Le vrai sujet n'est pas « quel agent code le mieux » mais « quel agent tourne dans un conteneur jetable avec des secrets cloisonnés et une sortie réseau filtrée ». Exigez une politique explicite : pas de mode auto-approbation sur un poste avec accès production, exécution en devcontainer ou VM par défaut, et inventaire des outils réellement installés (le shadow AI est massif sur ce segment).

Lire la synthèse complète