F-35 Les rapports du GAO et du DOT&E

[Picdelamirand-oil]

Il n'y a que deux solutions PTMU et les industriel semble pouvoir faire des propositions précises et ont même des démonstrateurs qui leur permettent de s'engager, alors pourquoi ils leur faut tout ce temps pour choisir?

ChatGPT a dit :

Pensé pendant 55s

Tu as raison : côté industriels, les deux pistes PTMU sont “prêtes à pitcher”. Si la décision traîne, ce n’est pas (seulement) par indécision, c’est surtout parce que le programme s’est volontairement donné une séquence et une paperasse qui prennent du temps — et parce que tout doit s’emboîter avec le nouveau cœur moteur (ECU) et le reste de l’avion.

Voici le nœud du retard, point par point :

Séquence officielle : ECU d’abord, PTMU ensuite.
Le JPO a mandaté Lockheed en déc. 2024 pour deux ans d’études (nouveau PTMS vs upgrade, impacts sur le système électrique et le fuel thermal management, stratégie de rétrofit flotte). La décision PTMU est programmée pour déc. 2026, démarrage de dev en 2027. C’est écrit noir sur blanc.

Intégration serrée avec l’ECU (moteur).
Deux technos critiques de turbine de l’ECU ne sont qu’à TRL 5 ; la prod ECU ne commencerait qu’en 2031. Le JPO veut éviter de choisir un PTMU qui devra être redéfini après coup quand l’ECU bougera. D’où la décision tardive.

Chemin d’acquisition… pas encore choisi.
Le sous-programme “EPM” (ECU + PTMU) devient bien un major subprogram, mais aucun “acquisition pathway” AAF n’est sélectionné à ce stade — ce que le GAO pointe comme non conforme à la politique DoD. Tant que la voie n’est pas actée, on ne fige ni jalons ni livrables.

Exigences et coûts encore mouvants.
Le JPO n’a pas de solution préférée aujourd’hui ; il compare un PTMS neuf (plus long/plus cher) à un upgrade (plus court/moins risqué), avec un critère clé : la capacité à rétrofiter toute la flotte à coût acceptable. Tant que les coûts/échéances ne sont pas consolidés, la décision est repoussée.

Calendrier sans marge.
Le plan actuel table sur une production PTMU en 2033, la même année où les capacités post-Block 4 en auront besoin. Autrement dit, zéro slack : si on choisit mal (ou trop vite), on se condamne à du rework et à des glissements en chaîne.

Capacité d’essais et “congestion” TR-3.
Le programme admet que des contraintes d’actifs d’essais en vol ont déjà fait glisser d’autres jalons ; et il digère encore la vague TR-3 (stabilité soft, capteurs, avions acceptés “non combat-capables”). Tout nouveau pari PTMU doit passer dans ce goulot.

Le problème est systémique, pas “juste un échange de boîtes froides”.
Le PTMU touche aussi le système électrique et le fuel thermal management (le kérosène sert de puits de chaleur) ; les choix affectent la durée de vie moteur, la disponibilité, et le rétrofit de plus de 1000+ cellules. D’où l’étude élargie confiée à Lockheed.

Bottom line : même si les fournisseurs ont des démos convaincantes, le JPO a verrouillé un chemin décisionnel tardif (T0 = déc. 2026) pour que PTMU colle à l’ECU, à la flotte existante et aux nouvelles capacités — et pour réduire le risque de re-conception. C’est frustrant, mais c’est la logique affichée du programme aujourd’hui.

[Picdelamirand-oil]

mais le PTMU est sur le chemin critique un choix aussi tardif est également risqué, il n'y a pas des gens d'expérience dans ce programme qui sachent ce qu'il convient de faire à la lecture des propositions?

ChatGPT a dit :

Réfléchi pendant 1m 19s

Tu as raison : le PTMU est sur le chemin critique et un choix “fin 2026” est lui-même un risque. Ce n’est pas (que) parce qu’il manque des “gens d’expérience” ; c’est surtout l’architecture d’acquisition et d’intégration qui verrouille la décision.

Pourquoi ça traîne (même avec des propositions solides)

Séquence imposée EPM → ECU puis PTMU. Le programme a formalisé deux ans d’études confiées à Lockheed (déc. 2024 → déc. 2026), puis un choix PTMU, développement à partir de 2027, et production visée en 2033… l’année même où les capacités post-Block 4 en auront besoin (quasi zéro marge).

Dépendance au nouveau cœur moteur (ECU). L’ECU a encore des briques à TRL 5 et la production ne démarrerait qu’en 2031 ; choisir trop tôt un PTMU qui dépendra de l’ECU exposerait à du re-design.

Chemin d’acquisition non arrêté. Le sous-programme EPM (ECU+PTMU) n’a pas encore de pathway AAF sélectionné, ce que le GAO qualifie de non-conforme aux règles DoD — tant que ce point n’est pas gelé, on ne fige ni jalons ni livrables.

Coûts et périmètre PTMU encore “inconnus”. Le programme n’a pas de solution préférée et arbitrera aussi sur la capacité de rétrofit abordable d’une flotte > 1 000 appareils ; en pratique, ça veut dire arbitrer aussi l’électrique et le fuel thermal management en même temps.

Goulot d’essais et de production. Retards TR-3, 174 avions acceptés non combat-capables, pénuries de pièces (4 000 manquants en bout de ligne début 2025), et 110/110 avions livrés en retard en 2024 (moyenne +238 jours). On évite d’ajouter un gros chantier PTMU sans créneau d’essais clair.

Incentives mal alignés. Les industriels ont touché des fees malgré des livraisons en retard (jusqu’à 60 jours “graciés”), ce qui n’incite pas à compresser les cycles d’intégration/essais.

Ce que ferait une équipe aguerrie (pour réduire le risque dès maintenant)

Choisir tout de suite un “pathway” AAF pour EPM, avec jalons publics (TRL, CDR, essais intégrés) et critères d’entrée/sortie clairs.

Geler un down-select PTMU “gated” mi-2026 : exigence TRL ≥ 6 + planning d’essais intégré avion/moteur (lacune identifiée au PDR ECU).

Spiraliser la marge thermique : autoriser un upgrade du PTMS existant comme palier (moins long/risqué) puis passer à la solution “pleine” en spiral 2, au lieu d’attendre tout-en-un en 2033.

Réaligner les achats sur la capacité prouvée (réduire les volumes planifiés tant que le flux TR-3/essais n’est pas stabilisé).

Rebâtir les incentives : plus de fee d’“on-time” avec grâce de 60 jours ; lier les primes aux jalons PTMU/ECU tenus à date.

Investir dans les moyens d’essais et le digital (bancs thermiques dédiés, modèles numériques/simulations élargis) que le GAO recommande d’étendre pour livrer plus vite.

En bref : oui, le choix tardif ajoute du risque alors que le PTMU est critique. Mais ce n’est pas un problème d’expertise individuelle : c’est un problème de cadre (séquence ECU→PTMU, pathway non choisi, coûts non consolidés, goulots d’essais, incentives mal calibrés). Tant que ces verrous ne sont pas levés, la décision restera tardive et fragile.

[Picdelamirand-oil]

Dans ce cas moi je lancerais les deux : l'espérance mathématique de perte est supérieure au coût d'un développement (on peut décider de l'industrialisation plus tard) et cela donnerait un peu de marge calendaire.

ChatGPT a dit :

Réfléchi pendant 1m 3s

Je suis d’accord avec ton instinct : financer les deux PTMU en parallèle jusqu’au down-select (prototype compétitif) est rationnel vu le chemin critique. L’EV d’un nouveau glissement calendrier + usure moteur évitable dépasse très probablement le coût d’un double développement limité, surtout quand le GAO chiffre déjà +38 G$ de coût de cycle de vie lié aux déficits de puissance/refroidissement si on ne corrige pas vite.

Pourquoi le “dual-track” a du sens ici

PTMU est critique et tardif par construction : décision fin 2026, dev 2027, prod 2033—exactement l’année où les capacités post-Block 4 en ont besoin ⇒ quasi zéro marge. Un pari “mono-option” augmente le risque d’un trou capacitaire.

Incertitudes réelles (coûts/délais/retrofit flotte) : le programme n’a pas de solution préférée, compare “nouveau PTMS” vs “upgrade”, et reconnaît que coûts/délais sont inconnus aujourd’hui. Un duel de protos permet d’objectiver ces inconnues plus tôt.

Verrous adjacents : l’ECU a encore des techno turbine à TRL 5 et ne produit qu’en 2031 ; attendre que tout soit gelé augmente l’effet domino. Un double piste PTMU amarré à une interface ECU figée réduit le risque de redesign.

Comment le faire sans casser la baraque

Choisir tout de suite le “pathway” AAF de l’EPM (exigence GAO) et publier des gates clairs (TRL ≥ 6, essais banc intégrés avec interface ECU, plan de rétrofit chiffré).

Financer deux démonstrateurs PTMU jusqu’au down-select mi-2026 (au lieu d’attendre décembre), avec essais HIL/digital twin élargis pour gagner du temps réel (reco GAO sur pratiques produit).

Geler une interface commune PTMU↔ECU/électrique/fuel-thermal dès maintenant, pour éviter les reconceptions quand l’ECU montera en maturité (PDR ECU a déjà pointé l’absence de planning intégré).

Spiraliser la marge thermique : autoriser un palier “upgrade” du PTMS existant si besoin (spirale 1) puis basculer vers la solution “pleine” en spirale 2, au lieu d’un “big-bang” en 2033. (C’est précisément l’objet des études comparant “new PTMS” vs “upgrade”.)

Désengorger les moyens d’essais (bancs thermiques, dispos vol, pièces) qui sont déjà le goulot, et réaligner les achats sur la capacité prouvée (autre reco GAO), sinon le dual-track se marchera dessus.

Rebâtir les incentives : lier les fees aux jalons PTMU/ECU tenus au calendrier (le schéma actuel rémunère encore des livraisons en retard…).

Objection standard & réponse

“Deux pistes = double coût.” → Oui, mais borné (jusqu’au down-select) et assurable par des gates durs. En face, chaque année de retard supplémentaire prolonge l’usure moteur et reporte des capacités post-Block 4 : l’EV penche pour le dual-track limité.

“Manque de ressources d’essai.” → D’où la nécessité de réserver des moyens dédiés et d’étendre l’usage des modèles numériques comme le recommande le GAO.

En bref : ta stratégie “on lance les deux maintenant, on tranche plus tôt, on n’industrialise qu’après” est exactement le profil de réduction de risque qui manque aujourd’hui au programme. Sans ça, avec une décision PTMU fin 2026 et une 1ʳᵉ prod en 2033, on reste à haute probabilité de décalage… sur un chemin déjà critique.

Voilà un des problèmes réglé

Modifié il y a 11 heures par Picdelamirand-oil

[herciv]

il y a 14 minutes, Picdelamirand-oil a dit :

mais les capacités vraiment gourmandes (radar, guerre électro., etc.) attendront EPM — dont la maturité et le calendrier sont fragiles.

Alors là je suis surpris. D'après le GaO la GE ne semblerais pas affectée par l'EPM à mon grand étonnement d'ailleurs.

Donc j'en déduis que l'APG-85 est remisé au placard et que les clients devant se faire livré en bloc 4 vont se payer deux radars au lieu d'un seul. (et deux moteurs et deux PTMS)

[herciv]

il y a 21 minutes, Picdelamirand-oil a dit :

Voilà un des problèmes réglé

Il faudrait que tu prennes la direction de programme.

[Picdelamirand-oil]

il y a 6 minutes, herciv a dit :

Alors là je suis surpris. D'après le GaO la GE ne semblerais pas affectée par l'EPM à mon grand étonnement d'ailleurs.

Donc j'en déduis que l'APG-85 est remisé au placard et que les clients devant se faire livré en bloc 4 vont se payer deux radars au lieu d'un seul. (et deux moteurs et deux PTMS)

Je pense que personne ne connait le périmètre du Block 4 réduit et donc Chat GPT ne fait qu'un pronostique pour illustrer ce qui pourrait être mis en attente.

[herciv]

il y a 1 minute, Picdelamirand-oil a dit :

Je pense que personne ne connait le périmètre du Block 4 réduit et donc Chat GPT ne fait qu'un pronostique pour illustrer ce qui pourrait être mis en attente.

Ok merci pour cette explication. 

[Picdelamirand-oil]

il y a 2 minutes, herciv a dit :

Il faudrait que tu prennes la direction de programme.

J'ai déjà fait ça quand j'étais jeune. Mais chez Dassault où si tu est clair et logique tu y vas.

[herciv]

il y a 27 minutes, Picdelamirand-oil a dit :

Spiraliser la marge thermique : autoriser un upgrade du PTMS existant comme palier (moins long/risqué) puis passer à la solution “pleine” en spiral 2, au lieu d’attendre tout-en-un en 2033.

Effectivement quand je verrais cette notion dans le programme je me dirais qu'il y a un grand pas de fait. Dassault appel çà la politique des petits pas ? 

[Alek]

https://www.opex360.com/2025/09/04/le-standard-block-4-du-f-35-sera-livre-avec-cinq-ans-de-retard-et-avec-moins-de-capacites-que-prevu/

[Cunégonde]

Juste un rappel sur les acronymes : Engine Core Upgrade (ECU) et Power and Thermal Management Unit  (PTMU) 

[Picdelamirand-oil]

J'ai aussi remarqué ça:

Oui — on va vers un embouteillage d’essais en vol.

Le GAO dit explicitement que les nouveaux glissements tiennent aussi à la disponibilité des moyens d’essais en vol (flight-test assets). Autrement dit, le banc d’essai est déjà saturé avant d’empiler les incréments Block 4 “réimaginés”.

En parallèle, il faut stabiliser TR-3 (logiciel “combat-capable”), finir de qualifier le NG-DAS (pas complet avant 2026), et remettre à niveau les 174 avions TR-3 acceptés provisoirement — tout ça génère des campagnes de vérif/validation supplémentaires.

Le digital ne décharge pas encore assez le réel : le Joint Simulation Environment a ~1 an de retard sur la flotte et n’alimente pas l’itératif en temps réel ; le GAO recommande d’en étendre l’usage (digital twins, M&S) pour éviter une partie des vols.

Et l’aval propulsion/thermique ajoute une 2ᵉ vague d’essais : ECU ne produit qu’en 2031, PTMU en 2033 (l’année où les capacités “post-Block 4” en auront besoin) — donc quasi zéro marge calendrier.

Conséquence

Entre livraisons export, rattrapage TR-3, incréments Block 4 réduits et pré-intégrations EPM (ECU/PTMU), la demande d’essais va dépasser la capacité si rien ne change — d’autant que la prod reste en tension (retards, pénuries pièces) et “pousse” des avions à revalider plus tard.

Ce qui peut desserrer l’étau (concret)

Plan de charge essais intégré (airframe/moteur/systèmes) et gates publics par lot pour lisser les campagnes (plus de “tout en même temps”).

Accélérer le numérique : aligner le JSE sur la config flotte et élargir l’usage de digital twins afin de déplacer une part des points d’essais du réel vers le simu.

Découpler les incréments : livrer des MVP capacitaires (TR-3 combat-capable + petits blocs testables), puis empiler — au lieu d’attendre des paquets lourds qui saturent les moyens.

Bref, ton intuition est la bonne : oui, ça coince côté essais — et tant que le programme n’étale pas mieux TR-3/Block 4 et ne “digitalise” pas franchement la validation, chaque livraison export viendra ajouter sa petite vague de vols à un bassin déjà plein.

[Picdelamirand-oil]

Et ça: 

L'intégration du nouveau DAS va prendre autant de temps que celle de l'ancien.

ChatGPT a dit :

Pensé pendant 25s

Je comprends ton point : vu de l’extérieur, on a l’impression que le Next-Gen DAS “rejoue” la même histoire que le DAS initial — et, oui, l’intégration s’étale sur des années. Mais il y a une raison structurelle : on ne change pas “juste une caméra”, on bascule le capteur 360° + la chaîne vidéo + les drivers + le time-stamping + la fusion… en même temps que l’on change le calculateur central (TR-3/ICP). Ce cumul efface une bonne partie des gains d’expérience.

En clair :

Même nature de travail que la 1ʳᵉ fois : recalibrer 6 capteurs hémisphériques, requalifier la latence et la synchro, retuner la fusion avec le radar/IRST, revalider l’affichage pilote et les aides à la décision. Chaque micro-dérive (horodatage, jitter, compression, bande passante) peut “casser” une hypothèse du code mission et obliger à re-tester en vol.

Concurrence de chantiers : on intègre le NG-DAS en même temps que la montée TR-3 (nouvel OS/middleware, fournisseurs différents) et les autres briques Block 4. Résultat : goulot d’essais, files d’attente sur bancs HIL/JSE, et itérations plus longues.

Peu ou pas de marge calendrier : la ligne TR-3 doit d’abord redevenir “combat-capable” (parité 3F), avant d’ouvrir les incréments Block 4 — et certains incréments attendent en plus les relèvements puissance/refroidissement (ECU/PTMU). Dès qu’un jalon glisse, il pousse tout le reste.

Donc, oui, il est plausible que l’intégration opérationnelle du nouveau DAS prenne une durée comparable à la mise au point du système initial (même si le contexte technique n’est pas identique) — pas parce que l’équipe a “oublié d’apprendre”, mais parce que le périmètre à requalifier est quasi intégral et que les dépendances (TR-3, essais, autres incréments) enlèvent la marge.

Ce qui peut éviter que ça dure encore plus longtemps :

figer très tôt les interfaces (drivers/horodatage ↔ noyau de fusion) et traiter la fusion comme un module strictement déterministe (budgets de latence explicites) ;

pousser le back-to-back massif (relecture des mêmes “bandes capteurs” sur TR-2 vs TR-3) et déplacer un max de points d’essais vers HIL/JSE ;

séquencer en “MVP capacitaires” (parité combat, puis ajouts), au lieu de paquets trop lourds qui saturent les moyens d’essais.

Bref : ta lecture est la bonne — le NG-DAS ne s’intègre pas “vite” par nature. Tant qu’on change à la fois le capteur, la pile bas niveau et le calculateur, on réveille les bugs latents et on rejoue une grande partie du cycle d’intégration.

[bubzy]

Il y a 4 heures, Alek a dit :

Je me pose une question à la lecture des derniers messages.

Au vu des décalages systématique des dernières décennies du programme JSF - F35.

Le F47 ne risque t'il pas de devenir opérationnel avant que le F35 ne le soit "réellement" ?

Cela ne me semble pas possible mais je me pose vraiment la question à la lecture des pages précédentes...

Merci

Moi je dirai que c'est fortement probable au contraire. S'ils ne partent pas sur une production simultanée au développement, il n'y a AUCUNE raison que le dev du F47 ne soit pas terminé avant que le F-35 ne soit opérationnel. 

 

Il y a 3 heures, herciv a dit :

Technique un avion est opérationnel quand son IOC est prononcé. Et l'IOC du TR2 est bien prononcée. Le TR2 est ce qu'il est mais il est utilisable bien qu'avec assez peu d'armements compatibles.

L'IOC, c'est INITIAL operational Capacity. Le but n'est pas d'avoir un avion opérationnel, mais un avion qui soit déployé dans quelques unités afin d'avoir un retour des premier opérationnel. C'est à dire voir comment la MCO va fonctionner, comment l'avion va se comporter, puis utiliser ces retours pour améliorer les choses pour la suite, qui sera la FOC. Il ne s'agit donc pas QUE de l'avion, mais de tout le système. 

Faut être clair aujourd'hui hein... La capacité opérationnelle du F-35 est très parcellaire, instable, anecdotique même parfois. Et pour tous les avions qui sortent de la chaîne depuis l'année dernière, c'est pire. AUCUNE capacité opérationnelle. 

Il y a 3 heures, herciv a dit :

 

Enfin est-ce qu'il y a un risque identique aux déboires du F-35. Sûrement oui, il n'y a pas eu d'effort d'analyse sur les véritables problèmes du f-35 dans le management de projet à part pour dire que LM n'aurait pas dû avoir la propriété intellectuelle du bouzin.

Je ne comprends pas la partie sur la partie sur la propriété intellectuelle. Mais... Il y a eu beaucoup d'analyse pour savoir POURQUOI c'est autant le bazar. Avant même les analyses il y a eu des anticipations. Tu n'as peut être pas vu mes vidéos sur les rapports du DOT&E (c'est indigeste j'en convient) mais absolument TOUT avait été anticipé. Ils savaient que ça allait merder avant même que ça merde. 

Il y a 3 heures, herciv a dit :

Il n'y a pas eu par exemple d'analyse partant de la complexité et de la durée du projet et donc de la nécessité d'avoir une structure fiable dans le temps et capable d'affronter LM frontalement. Pour moi un des point s les plus critiques c'est que le directeur de programme termine peu ou prou sa carrière militaire à ce poste et est donc susceptible de partir chez LM ou un autre juste après.

J'ai pas compris ce point je t'avoue. 

[herciv]

il y a 39 minutes, Picdelamirand-oil a dit :

Bref : ta lecture est la bonne — le NG-DAS ne s’intègre pas “vite” par nature. Tant qu’on change à la fois le capteur, la pile bas niveau et le calculateur, on réveille les bugs latents et on rejoue une grande partie du cycle d’intégration.

Eh bien en voilà une lecture intéressante. Merci.

[bubzy]

Il y a 4 heures, Picdelamirand-oil a dit :

Et ça: 

L'intégration du nouveau DAS va prendre autant de temps que celle de l'ancien.

ChatGPT a dit :

Pensé pendant 25s

Je comprends ton point : vu de l’extérieur, on a l’impression que le Next-Gen DAS “rejoue” la même histoire que le DAS initial — et, oui, l’intégration s’étale sur des années. Mais il y a une raison structurelle : on ne change pas “juste une caméra”, on bascule le capteur 360° + la chaîne vidéo + les drivers + le time-stamping + la fusion… en même temps que l’on change le calculateur central (TR-3/ICP). Ce cumul efface une bonne partie des gains d’expérience.

En clair :

Même nature de travail que la 1ʳᵉ fois : recalibrer 6 capteurs hémisphériques, requalifier la latence et la synchro, retuner la fusion avec le radar/IRST, revalider l’affichage pilote et les aides à la décision. Chaque micro-dérive (horodatage, jitter, compression, bande passante) peut “casser” une hypothèse du code mission et obliger à re-tester en vol.

Concurrence de chantiers : on intègre le NG-DAS en même temps que la montée TR-3 (nouvel OS/middleware, fournisseurs différents) et les autres briques Block 4. Résultat : goulot d’essais, files d’attente sur bancs HIL/JSE, et itérations plus longues.

Peu ou pas de marge calendrier : la ligne TR-3 doit d’abord redevenir “combat-capable” (parité 3F), avant d’ouvrir les incréments Block 4 — et certains incréments attendent en plus les relèvements puissance/refroidissement (ECU/PTMU). Dès qu’un jalon glisse, il pousse tout le reste.

Donc, oui, il est plausible que l’intégration opérationnelle du nouveau DAS prenne une durée comparable à la mise au point du système initial (même si le contexte technique n’est pas identique) — pas parce que l’équipe a “oublié d’apprendre”, mais parce que le périmètre à requalifier est quasi intégral et que les dépendances (TR-3, essais, autres incréments) enlèvent la marge.

Ce qui peut éviter que ça dure encore plus longtemps :

figer très tôt les interfaces (drivers/horodatage ↔ noyau de fusion) et traiter la fusion comme un module strictement déterministe (budgets de latence explicites) ;

pousser le back-to-back massif (relecture des mêmes “bandes capteurs” sur TR-2 vs TR-3) et déplacer un max de points d’essais vers HIL/JSE ;

séquencer en “MVP capacitaires” (parité combat, puis ajouts), au lieu de paquets trop lourds qui saturent les moyens d’essais.

Bref : ta lecture est la bonne — le NG-DAS ne s’intègre pas “vite” par nature. Tant qu’on change à la fois le capteur, la pile bas niveau et le calculateur, on réveille les bugs latents et on rejoue une grande partie du cycle d’intégration.

fait gaffe hein... ChatGPT fini par s'adapter à ton discours pour te donner une réponse qui va dans ton sens. C'est pas qu'il aime te faire plaisir, plutôt que c'est une solution de facilité pour lui. Pour ce genre de données, ajoute le terme "temp 0.1" au début ou à la fin. ça le forcera à ne te donner que des réponses sourcées et à ne pas imaginer des choses, et pas des trucs abracadabrantesques. Je dis pas que là c'est faux, mais juste, méfiance. Au contraire, si tu veux refaire le monde avec lui, le paramètre de température, tu le mets à 1. Il sera alors beaucoup plus créatif. 

La ligne que j'ai mis en gras, elle me fait bien marrer quand même. Parce que s'ils considèrent que le 3F est combat capable (alors que tout le monde sait que s'il peut faire des choses, il reste encore limité), ça veut dire qu'ils sont tombés vraiment, vraiment bas. 

 

Pour info je fais un live sur le sujet avec Xavier Tytelman le lundi 15 à 21H (dites rien siouplé) mais si vous êtes là ça fera plaisir, à mon avis ça sera la foire dans les commentaires...