Une mise à jour logicielle a immobilisé certains hybrides Jeep 4xe pendant le week-end

• Certains propriétaires de Jeep Wrangler 4xe hybrides ont subi une immobilisation du véhicule à la suite d’une mise à jour logicielle OTA déployée pendant le week-end
• La mise à jour concernait la télématique du système d’infodivertissement Uconnect et a été déployée alors qu’elle n’était pas prête
• Le problème ne survenait pas immédiatement après la mise à jour, mais se manifestait ensuite de manière grave par une erreur du groupe motopropulseur en conduite, pouvant immobiliser le véhicule
• Jeep a interrompu le déploiement de la mise à jour après les signalements, mais celle-ci avait déjà été téléchargée sur plusieurs véhicules
• Jeep a ensuite publié un correctif et a recommandé aux propriétaires ne l’ayant pas encore installé de l’ignorer

---

Problème de mise à jour logicielle OTA sur les véhicules hybrides Jeep 4xe

Vue d’ensemble du problème

• Certains propriétaires de Jeep Wrangler 4xe hybrides ont constaté qu’après avoir installé une mise à jour OTA pendant le week-end, leur véhicule pouvait s’arrêter brusquement en roulant
• Ce problème est dû au déploiement prématuré d’une mise à jour télématique du système d’infodivertissement Uconnect, alors qu’elle n’était pas suffisamment prête

Déroulement de l’incident

• Le problème n’apparaissait pas immédiatement, mais entraînait ensuite une perte de puissance en conduite puis l’arrêt du véhicule
• Certains propriétaires ont vécu cela dans des zones résidentielles ou à basse vitesse, mais des cas de défaillance du groupe motopropulseur sur autoroute ont également été signalés

Réponse et mesures prises

• Jeep a suspendu le déploiement de cette mise à jour après les premiers signalements, mais de nombreux véhicules l’avaient déjà téléchargée
• L’équipe sociale de Stellantis a indiqué sur les forums Jeep aux propriétaires qui ne l’avaient pas encore installée d’ignorer la fenêtre contextuelle de mise à jour

Recommandations temporaires

• Aux propriétaires ayant déjà installé la mise à jour mais n’ayant pas encore subi de panne, il a été recommandé d’éviter d’utiliser le mode hybride ou le mode électrique
• Jeep a ensuite procédé à un déploiement d’urgence d’un correctif

Contexte et enseignements

• Comme dans le cas de Crowdstrike l’an dernier, l’incident souligne qu’une mise à jour logicielle un vendredi après-midi peut provoquer des problèmes à grande échelle
• Avec cet épisode, Stellantis a également retenu l’importance du timing des mises à jour et des tests préalables
• À ce stade, Stellantis n’a pas encore fourni de réponse officielle ; d’autres informations seront ajoutées ultérieurement

[GN⁺]

Avis sur Hacker News

• Mon 4xe s’est immobilisé devant chez moi après la mise à jour logicielle de samedi, et je veux expliquer, du point de vue d’un propriétaire de 4xe, à quel point la réponse de Jeep/Stellantis a été désastreuse
  • Jusqu’à 8 h lundi matin, il n’y a eu aucune communication ni reconnaissance officielle de la part de Jeep ou de l’entreprise
  • Je n’ai découvert le problème qu’en cherchant sur des groupes Jeep sur Facebook si d’autres personnes rencontraient les mêmes symptômes
  • Même l’information la plus « officielle » se limitait à un message publié sur un forum off-road par le compte « JeepCares » géré par Jeep, et les indications données par ce compte étaient elles-mêmes contradictoires. Ils disaient d’abord que la mise à jour Uconnect et la mise à jour télématique étaient séparées, puis ont ensuite conseillé de reporter la mise à jour Uconnect, comme si les deux étaient liées
  • Faute d’informations de la part de Jeep, les gens se sont appuyés sur toutes sortes de rumeurs du genre « redémarrer Uconnect dans tel ou tel mode éteint le voyant moteur ». En pratique, cela faisait disparaître le symptôme, mais ne réglait pas le problème de fond
  • Aucun moyen de savoir si l’on a reçu la mise à jour défectueuse
  • Impossible aussi de savoir si l’on a reçu le correctif
  • Les concessionnaires ne sont au courant de rien non plus
  • Et au moment même où j’écris ces lignes, je reste exposé au risque d’une perte soudaine de puissance en plein milieu de l’autoroute qui pourrait immobiliser la voiture
  • Le fait que le système de puissance, c’est-à-dire le moteur, puisse s’arrêter alors que le véhicule roule sur l’autoroute est vraiment sidérant. D’après l’article, cela s’est effectivement produit : pour certains c’était à basse vitesse près de chez eux, mais d’autres affirment que le groupe motopropulseur a lâché alors qu’ils roulaient sur l’autoroute. C’est un problème vraiment choquant
  • Que ce genre de chose arrive dans le monde réel est complètement dingue. En faisant une due diligence d’investissement dans l’industrie automobile il y a quelques années, j’avais signalé qu’il fallait impérativement vérifier que le véhicule était à l’arrêt et le moteur coupé avant toute mise à jour. Je me souviens que tout le monde avait trouvé ma remarque curieuse au lieu de voir qu’une telle situation pouvait mener à un problème
  • On dirait typiquement le cas d’une équipe qui n’a pas tenu la date initiale, a repoussé encore et encore, puis a fini par publier le code à l’arrache parce que tout le monde avait ses vacances prévues et plus aucune marge pour assumer la responsabilité. Pression sur les délais, biais de confirmation, on a poussé du code malgré des signaux montrant qu’il y avait un problème, et maintenant les personnes clés sont dans un avion, injoignables ou en congé sans ordinateur portable
  • Je me demande comment ils ont validé le fait qu’une mise à jour logicielle puisse s’exécuter pendant que le véhicule roule et entraîner une perte de puissance. Quand je travaillais autrefois chez un équipementier automobile, il y avait plusieurs garde-fous pour éviter les risques de corruption pendant les mises à jour, et le plus basique était que l’entrée en session de programmation UDS elle-même intégrait des critères de vitesse du véhicule ou de mode de conduite
• Je travaille récemment dans une grande entreprise d’éclairage domestique et j’ai de l’expérience dans le développement d’OS de routeurs qui gèrent les ampoules ainsi que la connexion Internet/utilisateur. Notre architecture OTAU utilise un système de mise à jour A/B avec deux boot slots (lien de référence). Avec cette approche, même si une mise à jour échoue, il y a un rollback automatique vers la version précédente, donc nous n’avons jamais eu de brick. Et pourtant, cela s’applique à un appareil électroménager à moins de 100 dollars. Du coup, on se demande si l’absence d’un tel dispositif de sécurité dans un SUV à 50 000 ou 60 000 dollars vient d’une logique de réduction des coûts. Même en doublant la capacité NAND, on resterait bien en dessous de 0,5 % du coût total de ce niveau de véhicule. Si c’est vraiment une corruption du boot slot, je peux le comprendre, mais il est décevant de voir à quel point les constructeurs automobiles semblent peu se soucier du code qu’ils déploient
  • Ayant de l’expérience à la fois dans l’IoT grand public et dans l’automobile, je peux comparer les deux secteurs. Ce n’est pas pour les défendre. Les grands constructeurs sont eux aussi extrêmement sensibles à l’optimisation des coûts, et je ne pense pas que le problème ici soit lié aux boot slots. Dans la plupart des cas, les logiciels automobiles sont justement conçus pour empêcher toute mise à jour pendant que le véhicule roule. Ce qui s’est probablement produit ici, c’est qu’il y avait un bug grave dans le nouveau firmware. On peut critiquer l’industrie automobile dans son ensemble comme étant au ras des pâquerettes, mais Stellantis n’est pas particulièrement une entreprise connue pour offrir des salaires au sommet du marché
  • Les appareils Android, y compris beaucoup de véhicules qui l’ont adopté, réduisent eux aussi le risque de brick grâce à des partitions A/B. Mais cette approche n’élimine pas complètement le risque. S’il y a une logique complexe et plusieurs appareils enfants à mettre à jour en même temps, il faut que 2*N partitions s’alignent, avec une possibilité d’échec à chaque checkpoint. En général, si le checkpoint « tout est bon » est enregistré trop tôt, on peut se retrouver dans un état irrécupérable même si un service essentiel échoue ensuite
  • Sur un appareil à 50 000 ou 60 000 dollars comme une voiture, un coût de 0,5 % a aussi un impact énorme. Par exemple, la marge opérationnelle de Ford est de 2 %, donc une hausse de 0,5 % du coût par véhicule rogne 25 % de cette marge. Les volumes annuels sont relativement limités, et les exigences sur les puces sont strictes, ce qui rend inévitablement les composants plus chers. Les mises à jour A/B ne sont pas une solution parfaite non plus et, si elles sont mal configurées, elles peuvent aussi conduire à des boucles infinies
  • J’ai entendu dire que dans l’automobile, on peut se battre férocement pour moins de 5 $ par appareil. Il est possible que les mises à jour A/B aient carrément été exclues du cahier des charges, ou que la taille croissante des OTA ait fini par buter sur les limites de capacité. Pour plus de sécurité, on utilise aussi parfois une approche A/B/A (où B est un OS allégé), mais en pratique cela devient difficile faute de temps de développement
  • Il existe des entreprises qui utilisent l’A/B même sur des appareils à 100 $, donc il est probable que ce problème ne relève pas d’une réduction de coûts mais plutôt de priorités et de compétences. Il est possible que les garde-fous de mise à jour aient été absents du cahier des charges, puis que la pression du planning et l’évitement des responsabilités aient fini par produire ce genre d’accident. En réalité, dans cet incident précis, il ne s’agissait pas d’un brick mais d’un bug critique en conduite
• J’ai loué un Jeep Wagoneer, et l’électronique était tellement catastrophique qu’un incident comme celui-ci ne me surprend pas. Le deuxième jour, le hayon ne se fermait plus, avec un message d’erreur au tableau de bord, et le verrouillage électronique ne fonctionnait plus du tout. En cherchant, j’ai vu que beaucoup de gens rencontraient le même problème et qu’il fallait faire une mise à jour logicielle, sans aucune procédure de déverrouillage manuel. Comme l’agence de location était proche, j’ai échangé la voiture, mais j’ai encore rencontré plusieurs problèmes ensuite
  • Quand on recharge un Steam Deck avec son chargeur depuis les sièges arrière, l’ensemble du combiné d’instruments, y compris le système d’infodivertissement, s’éteint puis redémarre en boucle
  • Le siège conducteur s’abaisse pour faciliter la sortie, mais ne revient pas automatiquement à sa position, si bien qu’il recule de plus en plus
  • Une alerte d’erreur de loquet arrière s’affichait en permanence sans possibilité de la couper, alors que le loquet fonctionnait très bien
  • Le voyant TPMS s’allume et s’éteint sans arrêt (signal instable)
  • Des erreurs liées au régulateur de vitesse apparaissent de manière aléatoire
  • Le frein de parking électronique s’enclenche automatiquement lors d’un arrêt momentané sur un parking
  • La climatisation se comporte bizarrement : l’habitacle reste chaud ou l’air conditionné ne fonctionne pas
  • On trouve énormément de gens en ligne qui rapportent des problèmes similaires ou encore plus graves. Il est difficile de croire qu’un véhicule neuf à 80 000 dollars puisse avoir ce niveau de problèmes
  • Lors d’un récent voyage en famille, nous avons changé quatre fois de Grand Wagoneer, et chaque véhicule avait un problème rédhibitoire
  • Jeep et Stellantis/Dodge sont gravement défaillants en matière de contrôle qualité et de conception électronique. Il existe des communautés de fans très actives, mais elles ont tendance à enjoliver des défauts fréquents. Acheter ce genre de véhicule, c’est se tirer une balle dans le pied
• Mettre à jour via OTA des composants critiques comme les ECU me semble un risque franchement difficile à justifier. Si cela doit vraiment se faire, à mon avis cela devrait obligatoirement être réalisé chez le concessionnaire, par des professionnels prêts à effectuer un rollback. Les constructeurs ont commencé à nuire à la sécurité des consommateurs en voulant tout automatiser et monétiser avec des abonnements, et c’est pour cela que, comme passionné d’automobile, je préfère les voitures plus anciennes
• Cet incident survient moins de deux semaines après que Stellantis a imposé récemment un workflow d’ingénierie « vibe coding » (actualité associée)
  • Mais pour pouvoir être déployé en OTA sur une flotte réelle, le code devait au minimum avoir été écrit plus de deux semaines auparavant
• Je conduis une Jeep depuis quelques mois, et la communauté est obsédée par les modifications (mods), tout en se plaignant du fait que l’OS soit fermé et développé par SiriusXM. Et pourtant, le Jeep Wrangler est probablement le véhicule le mieux placé pour être adapté à l’open source
  • Cela ne veut pas dire que la scène du hack logiciel soit inexistante autour des modifications du Wrangler. Il existe même un produit commercial issu de ce qui a été présenté dans ce forum connexe. En revanche, je n’ai pas encore vu de vrai contournement du firmware de l’unité principale
  • Ce n’est pas Jeep, déjà, la société qui avait mis un système publicitaire dans l’infodivertissement affichant des pop-ups à l’arrêt aux feux rouges ? Le constructeur n’a évidemment aucun intérêt à ce qu’un OS open source permette de contourner ce genre de publicité
• Je ne comprends pas pourquoi une mise à jour OTA pourrait permettre de briquer un véhicule entier. Le système d’infodivertissement et les systèmes de conduite ne devraient-ils pas être complètement séparés ?
  • Cette conclusion part de l’hypothèse qu’il ne s’agissait que d’une OTA de l’infodivertissement. En réalité, c’est une OTA du véhicule dans son ensemble. Elle peut toucher l’infodivertissement, l’ECU, l’ECM, le TCM, le BCM, et même des rappels majeurs sont résolus via OTA, donc il est impossible d’empêcher les mises à jour des systèmes critiques. En 2025, la majorité des constructeurs disposent de ce type de capacité OTA
  • La cause profonde de ce genre de problème, c’est la réduction des coûts. Le combiné d’instruments et l’infodivertissement remplacent l’analogique par des écrans parce que cela coûte moins cher à produire. Le logiciel aussi finit collé de partout selon une doctrine du type « on ne réécrit jamais, on ne fait que réutiliser », ce qui dégrade inévitablement les tests d’intégration. À l’ère des véhicules électriques, chaque contrôleur moteur a son propre logiciel, et l’OTA peut aussi l’écraser. Toyota est à peu près le seul à avoir accumulé suffisamment d’expérience pour rencontrer moins de problèmes
  • Comme des informations du quotidien interagissent entre les systèmes de conduite et l’infodivertissement — par exemple couper la musique quand les capteurs de stationnement s’activent, ou afficher le niveau de carburant et de batterie restant — une séparation complète est impossible
  • Il m’est déjà arrivé qu’une mise à jour OTA brique l’infodivertissement de mon Tahoe. Ensuite, la caméra de recul ne fonctionnait plus du tout, et même le son des clignotants avait disparu, ce qui m’a coûté presque 2 000 $ entre transport et réparation, sans prise en charge par la garantie. Depuis, j’ai décidé de désactiver toutes les mises à jour
  • Tesla a créé le précédent de ces OTA intégrées, et depuis la plupart des constructeurs ont suivi. Volvo rencontre aussi des problèmes similaires
• Je ne comprends pas pourquoi les systèmes d’infodivertissement posent autant de problèmes à tant d’ingénieurs. Dans le cas de la Mazda 3 (2018), cela a même donné lieu à une class action. Après des années de fonctionnement normal, les menus se sont soudain mis à réagir de manière aléatoire, des boutons semblaient se presser tout seuls, puis le problème disparaissait pendant des jours ou des mois avant de revenir. Au final, j’ai dû débrancher tous les appareils et rouler en n’écoutant que la radio
  • À la racine, il n’y a pas d’intégration verticale : plus de 20 000 ECU séparés par fonction, chacun confié à des sous-traitants pressurés jusqu’à l’os pour réduire les coûts au maximum. Et le résultat, c’est que les constructeurs « traditionnels » et les équipementiers de rang 1 ne se soucient presque pas d’introduire une vraie innovation logicielle
  • J’ai récemment connecté un téléphone Android en Bluetooth à une Mercedes, et malgré le positionnement « luxe », j’ai trouvé cinq bugs d’interface rien que pendant l’installation. La voiture est globalement correcte sur la finition, mais la qualité logicielle relève clairement d’un manque de volonté. (Et au passage, les UI de set-top boxes sont elles aussi beaucoup trop lentes au regard des specs matérielles)
  • Ce problème vient simplement de l’externalisation et de la réduction des coûts. Sans intégration verticale, on confie cela au prestataire le moins cher
  • J’ai travaillé autrefois chez un éditeur de logiciels d’infodivertissement, et ces systèmes incarnaient tous les extrêmes de la réduction des coûts : RAM minimale, CPU minimal, écrans médiocres, y compris sur des véhicules haut de gamme. Depuis toujours, les autoradios sont un symbole de chasse aux coûts dans l’automobile
  • Contrairement aux téléphones où de nouveaux produits sortent chaque année, dans l’automobile un même appareil doit tenir plus de dix ans, avec des équipes minimales capables de garantir un fonctionnement cohérent
• Je n’ai pas souvenir d’avoir entendu parler de cas majeurs où une mise à jour OTA Tesla aurait briqué une voiture entière, c’est-à-dire l’aurait vraiment rendue totalement inutilisable. Il me semble que Tesla a conçu cela avec une structure dual BIOS (comme le dual BIOS sur une carte mère)
  • Je suis les communautés Tesla depuis plus de dix ans, et je n’ai jamais vu de cas de brick via OTA. En général, le pire que les gens racontent, c’est qu’une mise à jour se lance alors qu’ils doivent partir en urgence, ce qui est surtout gênant
  • Tesla fait énormément de tests HIL, et son approche globale des tests ressemble plus à celle d’une entreprise logicielle qu’à celle d’un constructeur automobile
  • En cherchant un peu, on trouve malgré tout des cas où une OTA Tesla a briqué un véhicule. Exemple connexe
• Lien de référence vers la discussion du week-end