FSD v14.3.2 : Tesla améliore son menu de signalement des interventions conducteur (et ce n’est pas encore parfait)

Imagine la scène : tu rentres chez toi, le FSD supervisé t’a ramené jusqu’à ton allée sans accroc, et tu reprends le volant pour reculer de quelques mètres — histoire de te garer pile en face du chargeur mural. Rien d’anormal, juste une contrainte de stationnement que le FSD ne peut pas anticiper. Et là, un menu s’affiche sur ton écran central et te demande poliment : pourquoi tu as repris le volant ?

C’est exactement ce que Tesla a introduit avec FSD v14.3.2 : un système de signalement des interventions conducteur. Et ce qui m’a frappé, c’est qu’on en est déjà à la troisième version de ce menu en quelques semaines seulement.

L’intention est clairement bonne. Mais la méthode soulève des questions sérieuses sur la qualité des données envoyées à Tesla. On y revient.

Qu’est-ce que le système de signalement d’intervention FSD ?

Une “intervention conducteur”, dans le jargon Tesla, c’est le moment où tu reprends le volant alors que le FSD supervisé est actif. Ça peut arriver pour mille raisons différentes : tu n’aimes pas la trajectoire prise dans un virage, le système hésite trop longtemps à une intersection, ou — comme dans mon exemple — tu dois simplement manœuvrer dans un espace que le FSD ne gère pas.

L’idée derrière ce système de signalement d’intervention, c’est de collecter des données structurées pour comprendre pourquoi les conducteurs désengagent le système. Est-ce une question de préférence personnelle ? De confort ? D’une situation vraiment critique ? Ou d’un problème de navigation GPS ?

L’enjeu stratégique est majeur : ces données alimentent directement les données d’entraînement du FSD. Chaque signalement est censé aider les modèles d’IA à comprendre leurs propres limites et à progresser. Sur le papier, c’est brillant. En pratique, ça se complique.

De “Other” à “Navigation” : la première correction en urgence

La version initiale du menu proposait quatre options : Preference, Comfort, Critical, Other. Simple, lisible — mais trop simple.

Les retours de la communauté Tesla ont été immédiats et unanimes : l’option “Other” était beaucoup trop vague. En pratique, les conducteurs l’utilisaient massivement pour signaler des situations liées à la navigation GPS — une sortie d’autoroute ratée, un itinéraire qui ne correspondait pas à leur destination réelle, une erreur de calcul d’itinéraire.

Tesla a réagi vite : “Other” a été remplacé par “Navigation” dans une correction en temps réel publiée sous le même numéro de version. Chapeau pour la réactivité. Mais cette correction express révèle aussi que le menu initial manquait d’une vraie réflexion UX en amont — ce qui, pour un système aussi critique, aurait mérité plus de soin dès le départ.

La troisième version : plus discrète, mieux intégrée

Un menu qui ne bloque plus ton écran

Le changement le plus visible de cette troisième itération, c’est l’UX. Le menu est désormais intégré dans la fenêtre de demande de Voice Memo — format compact, discret, qui ne prend plus tout l’écran.

Avant : une fenêtre modale plein écran s’imposait au conducteur, potentiellement distrayante, clairement intrusive. Ce n’est pas idéal quand tu viens de reprendre le volant dans une situation qui demande ton attention.

Après : une interface réduite, intégrée dans un flux déjà existant, qui s’efface presque. @DirtyTesLa a confirmé et illustré cette évolution dans un tweet du 1er mai 2026 — une source communautaire fiable sur ce type de changements logiciels.

Ce changement améliore concrètement l’expérience de conduite sans sacrifier la collecte de données. C’est le bon équilibre à trouver.

Pourquoi l’UX compte autant que les données

Il y a une logique implacable derrière ce choix d’interface :

• Un menu intrusif → le conducteur clique n’importe quoi pour faire disparaître la fenêtre → qualité des données collectées catastrophique
• Un menu discret → le conducteur prend le temps de répondre honnêtement → données plus fiables, plus exploitables

Le lien est direct : la qualité de l’interface conditionne la qualité de l’entraînement du FSD. Ce n’est pas un détail cosmétique, c’est un choix architectural qui a des conséquences réelles sur ce que Tesla apprend de tes interventions.

Le problème de fond : quand le FSD reçoit de fausses données

Revenons à mon allée. J’ai repris le volant pour reculer et me garer près de mon chargeur. Le FSD n’avait rien fait de mal — il n’avait même pas commis d’erreur. C’était un choix délibéré de ma part, dicté par une contrainte de stationnement purement personnelle.

Pourtant, le menu s’affiche. Et quelle que soit l’option que je choisisse, Tesla va recevoir un signal qui ressemble à une intervention corrective. C’est là que le bât blesse.

Le biais de signalement est structurel : toute reprise du volant est traitée comme un événement à expliquer, même quand elle n’a strictement rien à voir avec une limitation du FSD. On génère ainsi des faux positifs de signalement — des données qui laissent croire au système qu’il a échoué là où il n’avait en réalité rien à corriger.

La question qui suit est légitime : si une part significative des biais dans les données d’entraînement repose sur ces faux positifs, quel impact sur l’évolution du FSD à long terme ? Ce n’est pas une attaque contre Tesla — c’est une question que tout passionné sérieux de conduite autonome doit se poser.

Ce qui manque encore : l’option “Aucune raison”

La limitation la plus frustrante du système actuel est simple : la sélection d’une raison est obligatoire. Impossible de fermer le menu sans choisir une option. Tu dois justifier ton geste, même quand il n’y a rien à justifier.

La communauté est claire sur ce point. Les demandes convergent vers une seule fonctionnalité : une option de fermeture sans sélection, ou une option neutre du type “Pas de problème avec le FSD”. Quelque chose qui permette au conducteur de dire : j’ai repris le volant, mais ce n’est pas ton problème.

Des signaux laissent penser que Tesla travaille sur cette quatrième révision. La logique est là, les retours sont documentés, et la mécanique d’itération rapide montre que l’équipe logicielle écoute.

Mais sur un sujet aussi critique que l’intégrité des données d’entraînement, chaque détail compte. L’enjeu n’est pas seulement l’expérience utilisateur — c’est la robustesse méthodologique de tout le programme FSD. Et dans un contexte où la conduite autonome reste scrutée avec méfiance en France et en Europe, c’est précisément sur ce terrain que Tesla doit être irréprochable.

La question de la fiabilité des données de sécurité Tesla n’est pas nouvelle — et ce système de signalement en est une nouvelle illustration. Tesla itère vite, la direction est bonne. Mais tant que fermer le menu sans sélection reste impossible, une partie des données envoyées restera structurellement biaisée. les experts consultés sur la collecte de données embarquées insistent d’ailleurs sur ce point : la qualité d’un dataset d’entraînement dépend autant des données collectées que de celles qu’on choisit délibérément d’exclure.