F35 JSF Actualité

massemini a écrit:C' était un début d' incendie dans l' une des soutes à armement.
Il y en a un second qui ne sera pas réparé, celui qui avait subi un incendie moteur. Décision récente aussi.

Il y a une source du coup qui parle de 80 millions de dollars pour un F-35 tout inclus ?

massemini a écrit:C' était un début d' incendie dans l' une des soutes à armement.
Il y en a un second qui ne sera pas réparé, celui qui avait subi un incendie moteur. Décision récente aussi.

Là ça fait un peu mal, non ? On dirait le débat de l'obsolescence programmée avec l'électroménager irréparable dans des conditions économiquement acceptables.

Sauf que la facture initiale n'est pas la même. Avion kleenex ?

Apollo11 a écrit:

massemini a écrit:C' était un début d' incendie dans l' une des soutes à armement.
Il y en a un second qui ne sera pas réparé, celui qui avait subi un incendie moteur. Décision récente aussi.

Là ça fait un peu mal, non ? On dirait le débat de l'obsolescence programmée avec l'électroménager irréparable dans des conditions économiquement acceptables.

Sauf que la facture initiale n'est pas la même. Avion kleenex ?

Pas vraiment. Enfin il faudrait voir le détail mais il n'est pas surprenant de mettre a la casse un avion après un incendie si ce dernier a été trop important.

Un éclairage intéressant et bien écrit sur les déboires de la gestion technique du projet F35.
http://www.portail-aviation.com/blog/2018/08/03/f-35-ou-le-paradoxe-de-zenon/

Merci

C'est long (c'est pour ce soir )

Merci Poncho ! Et Syntex  !
Article très intéressant, et apportant des précisions pour celui qui ne peut pas suivre de manière approfondie un tel dossier.
J'ai fait 4 commentaires, pas encore publiés, dont celui-ci :

"En ce qui concerne le type de projets : s'il s'agit de "Cost plus", ce n'est pas une variante de 'forfait' ('fixed price') , mais une variante de 'régie'. Extrait du PMBOK, v5, p 363 : "Les contrats à coûts remboursables peuvent également comporter des clauses prévoyant l'intéressement pour les cas où le vendeur dépasserait, ou n'atteindrait pas, les objectifs définis, tels que les cibles concernant les coûts, les délais ou la performance technique ". 
Il y a 3 sous-types de contrats, tous trois  commençant par 'Cost plus'. Celui qui semble correspondre ici est 'Cost plus incentive fee contract' (CPIF), "l'acheteur et le vendeur partagent tous deux les écarts [de coûts] sur la base d'une formule de partage des coûts préalablement négociée, par exemple un partage 80/20... " (p 364)
Et si Bogdan a changé vers un contrat de type forfait : "Fixed price incentive fee (FPIF)" (comme dans le contrat des ravitailleurs Boeing KC46)alors  il y a une notion de prix plafond, "... tous les coûts dépassant ce prix plafond sont supportés par le vendeur ..." (p363). Mais il ne me semble pas que ce soit le cas avec Lockheed ???

Je me demande donc s'il ne s'agit pas plutôt de rester dans un contrat en régie, mais 
- en passant de  CPFF (cost plus fixed fee contract) ou CPAF (cost plus award fee contract) (initialement) 
- à CPIF (actuellement), ce qui imposerait désormais un partage des coûts "sur la base des performances réelles du vendeur". 
".

C'est Sintex qu'il faut remercier...

sIntex je vous prie

La gestion du projet par LM ressemble furieusement à ces gros Mamouths informatiques menés par des grands groupes (IBM GS, ACCENTURE, CAP GEMINI, ...) pour le compte de maîtrises d'ouvrage Publiques ou assimilées (administrations, grandes banques, France Tel) maîtrisant mal leur sujet, leur organisation, l'explosion non maîtrisée des expressions de besoins, face à des fournisseurs sachant très bien faire dériver le cadre du cahier des charges et connaissant les chausses trappes et non dits des contrats cadre. Ces MOA tombent sous la coupe des machines à avenants, détruisant l'engagement de facto forfaitaire du Maître d'Oeuvre et passent de fait à un mode "régie" ou la majeure partie couts et l'essentiel des risques sont in fine supportés par le client. Et le fournisseur saura se rattraper de sa quote-part éventuelle en majorant ses prestations de maintenance / évolution (et sur le F35, ça tirera à la mitrailleuse lourde!)

Et ça marche encore et encore.
Espérons que la révolution du MCO chez nous permettra de briser la logique de la non-qualité à prix d'or, mais pour cela il faut que le client soit suffisamment formé et cesse de se reposer sur son fournisseur, en mode "ponce pilate" : je m'en lave les mains, c'est à vous de l'faire...

corrigé

Mille excuses

Sintex a écrit:sIntex je vous prie

La gestion du projet par LM ressemble furieusement à ces gros Mamouths informatiques menés par des grands groupes (IBM GS, ACCENTURE, CAP GEMINI, ...) pour le compte de maîtrises d'ouvrage Publiques ou assimilées (administrations, grandes banques, France Tel) maîtrisant mal leur sujet, leur organisation, l'explosion non maîtrisée des expressions de besoins, face à des fournisseurs sachant très bien faire dériver le cadre du cahier des charges et connaissant les chausses trappes et non dits des contrats cadre. Ces MOA tombent sous la coupe des machines à avenants, détruisant l'engagement de facto forfaitaire du Maître d'Oeuvre et passent de fait à un mode "régie" ou la majeure partie couts et l'essentiel des risques sont in fine supportés par le client. Et le fournisseur saura se rattraper de sa quote-part éventuelle en majorant ses prestations de maintenance / évolution (et sur le F35, ça tirera à la mitrailleuse lourde!)

Et ça marche encore et encore.
Espérons que la révolution du MCO chez nous permettra de briser la logique de la non-qualité à prix d'or, mais pour cela il faut que le client soit suffisamment formé et cesse de se reposer sur son fournisseur, en mode "ponce pilate" : je m'en lave les mains, c'est à vous de l'faire...

Mouais

Le client ce qu'il aime bien aussi, c'est ne pas choisir, se réserver la possibilité de changer d'avis, d'avoir l'étude d'une variante en plus comme ça à l'oeil
Et ne pas définir le programme de manière précise

Et les entreprises monnaient les risques pris

Un PPP par exemple pour être vertueux nécessite d'avoir des études préliminaires vraiment poussées (et honnêtes...)

Plus 1 Sintex !
C'est comme cela que nos télécoms, en première ligne dans les années 80, ont toutes disparu dans les années 90. Je connais bien cette histoire ...
Bravo, continuez ...

Merci Sintex 

Je tends cependant à penser qu'il faut distinguer deux choses :

• comment les grands projets sont (mal) gérés, et en particulier pour les projets complexes, s'ils sont gérés de manière traditionnelle (ce qui rend très difficile le management des modifications, si on veut le faire proprement)
  
• les bénéfices qu'ont pu en tirer certains grands de l'informatique (par exemple), avec les habitudes qu'ils ont pu prendre, pour rédiger des contrats de type 'léonins' pour ne plus subir les modifs par les maîtres d'ouvrage  
  

et ceci dans deux types de contextes, très différents :

• la fourniture essentiellement de logiciels, pour lesquels il est possible et même hautement souhaitable, de passer à une gestion de projet "agile" : tant qu'il n'y a pas à produire des pièces hardware, on peut revenir sur un cahier des charges préalable, et le modifier à volonté en fonction de l'évolution du contexte, des technos, de la demande du client, des concurrents, etc.
  
• la fourniture de produits 'hardware', avec des pièces détachées à maintenir à des coûts acceptables, donc produits en une quantité minimale d'exemplaires (même si ceci peut changer avec les imprimantes 3D), et surtout qui ne doivent pas modifier l'aérodynamisme (ceci n'est qu'un exemple)
  

Il ne faut pas tout confondre, c'est déjà assez complexe comme cela, et cela fait arriver à des conclusions hâtives, donc non justifiées, selon les contextes différents.
Pour y voir un peu plus clair, il me semble très important de s'appuyer sur les résultats de recherches menées sur la gestion des projets, ce qui se traduit par un schéma 2 x 2, 

	complexité organisationnelle et humaine faible	complexité organisationnelle et humaine forte
complexité technique faible	projet SIMPLE	projet COMPLEXE
complexité technique forte	TECHNO - PROJET	projet EPINEUX

voir mon post 48 : https://avia.superforum.fr/t2030p25-simple-complique-complexe-la-difference

Pour prolonger un peu : 

• le monde étant de plus en plus complexe, il devient de plus en plus nécessaire de passer à une gestion de projet "agile", auquel cas il n'y a pas un cahier des charges bien défini dès le départ, mais il évolue en cours de route ; mais ceci suppose qu'il n'y ait pas de hardware, sinon cela produit une partie des effets constatés avec le programme F35
  
• dans ces cas où la gestion de projet agile n'est pas possible (au niveau global, car elle est possible sur des morceaux, sur les aspects informatiques par exemple), il faut continuer à gérer le projet de façon traditionnelle, ce qui pose de très gros problèmes. 
  

Et il faut alors absolument empêcher le projet de déraper, ce qui nécessitait (pour le F35) déjà de ne pas faire cette grossière erreur de vouloir faire un avion à décollage et atterrissage vertical aussi !
Et il faut aussi avoir une gestion de projet comme celle du Rafale, qui montre, s'il en était besoin, que l'on peut gérer un projet de cette complexité technique, avec des coûts contenus, grâce à des 'compromis sans compromis' (excellente expression de Sintex, il me semble ?!   ). 
Cela signifie que le chef de projet a toutes les données en main, et cela suppose aussi (pour l'évolution future) au niveau informatique une "architecture ouverte" qui a permis, sur le Rafale, de remplacer très facilement et très vite l'ancien radar par le nouveau, ce que ne peut pas faire l'Eurofighter.

Edit : merci de me dire ce qu'il faut expliciter, clarifier.
J'ai bien conscience que ces questions ne sont pas évidentes, et qu'il faille discuter pour mieux comprendre la position des uns et des autres, et progresser dans la compréhension de ces questions.

Il me semble qu'il te faut toujours cerner au mieux des tes besoins.
Pourquoi ceux-ci seraient-ils évolutifs ?
Ce sont les moyens d'y parvenir qui peuvent l'être ? Comme l'exemple de l'OLED sur le F-35 ?

Poncho (Admin) a écrit:Il me semble qu'il te faut toujours cerner au mieux des tes besoins.
Pourquoi ceux-ci seraient-ils évolutifs ?
Ce sont les moyens d'y parvenir qui peuvent l'être ? Comme l'exemple de l'OLED sur le F-35 ?

Si effectivement les communications autour du F 35 deviennent un passage obligé, dans une coalition (voir l'article et la déclaration du général français cité), le besoin évolue d'une liaison 16, standard (ouvert), améliorée autant qu'on le pourra, vers un système de communication liaison façon F35.
Il est probable que l'architecture ouverte du Rafale facilite cette évolution, mais il est également possible que nos amis aient fait ce qu'il faut pour empêcher de se connecter, si l'avion n'est pas f35, ou s'il n'y a pas d'accord de leur part...

Ta remarque, Poncho, est très pertinente pour un système qui aurait ses besoins propres, mais elle perd sa pertinence dès qu'il s'agit de permettre aussi une interopérabilité maximale avec un autre système donné, précis, qui impose alors des conditions assez incontournables.

On parle donc d'un système donné et précis dont tu peux définir par exemple un volume / un besoin électrique et en refroidissement et une interface...

Et tu dois probablement être capable de faire un système globalement autonome de sous-système ?

Bref

Pour moi les EU c'est magnifique, mais en général l'europe parvient à une grosse fraction des performances des produits US pour une coup nettement plus modique

(Sans compter que le Harrier, ben NIH !)

Je ne suis pas sûr de te suivre complètement.
Mais en l'occurrence, ici, il ne s'agirait pas de faire un système autonome de celui du F35, mais au contraire un système dans lequel le F35 pourrait s'intégrer, donc un système plus large que le système F35 et ouvert à lui.

A cette condition, et malheureusement à cette seule condition,il serait possible à un pays comme la France de mener des opérations avec des pays (y compris européens) ayant des F35, avec des communications entre ces différents avions. C'est probablement un des aspects du futur système franco allemand.
Et c'est peut-être aussi un des éléments du (futur) standard F4 du Rafale

Cette ouverture au F35, serait donc, 
si j'ai bien compris que le F35 n'émet pas, mais ne fait que recevoir de la part d'autres avions comme le F22,  
une capacité du F35 à accepter de recevoir des émissions émises par un Rafale (puisque tel est l'exemple, ou un Eurofighter), cela signifierait donc (au moins, ou plus exactement par exemple) que les pays européens puissent ajouter à ses F35 un boîtier (devant être reconnu par le système F35) permettant ces communications (à sens unique).

Ce que je veux dire c'est que c'est un élément dont tu peux tenter de réduire les effets secondaires si ces specs changent

Poncho (Admin) a écrit:Ce que je veux dire c'est que c'est un élément dont tu peux tenter de réduire les effets secondaires si ses specs changent

Encore une fois, tout ce que tu dis est pertinent tant que tu fais un système 'autonome', n'ayant pas de relation obligée avec un autre système, obligatoire, et imposant ses conditions (et ses specs, dont tu n'as pas nécessairement le détail, ou qui peut être conçu pour empêcher ces communications ; par exemple par un chiffrement dont tu n'as pas les codes).
Mais cela change complètement dans le cas contraire.

PS. Pour que je sois sûr de bien comprendre ce que tu veux dire, prolonge l'exemple de la communication entre un Rafale / Eurofighter et un F35. Avec un exemple, on se comprend mieux.

Mais sinon, j'ai l'impression qu'un exemple de ce à quoi tu fais référence est justement l'architecture ouverte des systèmes informatiques (de SUN depuis ses débuts dans les années 1980) qui fait que tu peux connecter un nouvel équipement, une nouvelle unité centrale, à un 'ancien' système si ce dernier respecte des normes 'ouvertes'. C'est une des raisons qui a fait le succès de SUN, qui continue à exister et à se développer malgré tous les rachats qui ont eu lieu dans ce secteur depuis des décennies)
Ce que fait le Rafale, et je présume que le directeur informatique de Dassault (que j'avais rencontré dans ces années 80, justement à une présentation SUN ; et qui est un X, pour faire plaisir à Béo ?) a joué son rôle lors de la conception du Rafale.

Et pour prendre un autre exemple : une des raisons qui a permis l'explosion, en Europe, de la téléphonie mobile, dans les années 1995, c'est que les constructeurs européens s'étaient mis d'accord (cela avait pris des années) sur un standard auquel ils s'engageaient à se conformer tous. 

Voilà une méthode qui fonctionne, très bien (et beaucoup mieux que la fermeture de frontières !), et elle a permis que les fabricants européens puissent être prépondérants, et même dominants (malgré l'existence à l'époque d'un standard japonais), pendant plus d'une décennie 
Nokia en étant un parfait exemple, surtout que le pays correspondant (la Finlande) est tout petit, et que s'il avait créé son standard fermé, pour Nokia, cela n'aurait pu fonctionner !
Si Nokia s'est effondré ensuite, c'est parce qu'ils n'ont pas saisi l'opportunité du smartphone, qui ensuite a été proposée à Apple, avec le succès que l'on sait...

PS. Voilà une des raisons du succès de l'Europe : créer un marché unique, avec tout ce qui est nécessaire pour cela, ce qui permet à un acteur européen de s'adresser à un marché plus vaste (pas au début) que le marché américain (et que US + Japon réunis), et de réussir sur ce marché, même si cet acteur est 'petit'. 
C'est tout le contraire du repli que proposent les Brexiters et autres populistes, qui ne veulent pas voir ces réalités en face.

Et si DT peut remporter temporairement des succès, à très court terme (avant les élections de mid term en novembre), c'est uniquement parce qu'il peut s'appuyer sur un marché encore très grand 
(mais dont des banques chinoises peuvent se passer, ce qui fait que la Chine -et la Russie- ne subissent pas autant que les pays européens (UK compris, bien sûr) le diktat de Sam au sujet de l'Iran (et visant aussi -et surtout- l'Europe !). 
Ce qui fait que les pays visés par DT sont moins la Chine (cible affichée, mais qui va obtenir, avec l'Inde aussi, du pétrole iranien à de très bonnes conditions financières !) que les pays européens, UK compris, Brexit ou pas...

Ceux qui voudraient l'imiter en Europe feraient une grave erreur, on commence à le voir en UK avec le Brexit (croissance qui diminue, investissements en UK qui diminuent fortement avec la très grande incertitude actuelle, incertitude dont tout le monde sait qu'elle est un frein énorme par rapport au développement d'une économie).

Edit : avec les récents accords de libre échange de l'UE avec le Canada (36 M) et le Japon (126 M), cela fait désormais 660 millions d'habitants dans cette zone, et 600 millions sans le RU, soit 2 fois plus que les seuls Etats Unis.

Laurent Simon
Les éditions de message auxquels tu intègres des ajouts significatifs sont difficiles à suivre... comme j'ai lu le message en version INI j'ai un risque non négligeable de louper la mise à jour (:d )

Eh oui je suis un peu tête en l'air...

Sinon pour le volet normalisation et standard...
Perso je bosse tous les jours avec les Eurocodes... et même si ce n'est pas tout à fait les mêmes normes d'application d'un pays à l'autre, il y a beaucoup de choses normalisés (notamment les essais dans mon domaines... donc vivent les NF-EN les BS-EN  qu'on exporte du coup plus facilement en Afrique par exemple)

Poncho (Admin) a écrit:Laurent Simon
Les éditions de message auxquels tu intègres des ajouts significatifs sont difficiles à suivre... comme j'ai lu le message en version INI j'ai un risque non négligeable de louper la mise à jour (:d )

Oui, je comprends très bien cela.
C'est pour cela que j'ai créé un autre message.
J'essaie de faire au mieux, pour à la fois éviter cet inconvénient que tu cites, mais aussi ne pas inonder le site de messages, réponses. Il y a peu de personnes qui comme toi suivent tous les messages !
Conclusion, il faudrait que je fasse une différence, selon que la personne à qui je réponds est Poncho (ou un autre très assidu, dont le nombre est très limité, sur les doigts d'une ou deux mains), ou non.

Poncho (Admin) a écrit:Sinon pour le volet normalisation et standard...
Perso je bosse tous les jours avec les Eurocodes... et même si ce n'est pas tout à fait les mêmes normes d'application d'un pays à l'autre, il y a beaucoup de choses normalisés (notamment les essais dans mon domaines... donc vivent les NF-EN les BS-EN  qu'on exporte du coup plus facilement en Afrique par exemple)

Oui. 
Sauf que justement le ferroviaire est à la traîne sur ces aspects normalisation en Europe, ce qui fait qu'un TGV Paris Amsterdam doit embarquer avec lui des transfos, très lourds, pour être compatible avec au moins 4 systèmes de tension différents... pour moins de 400 km (je crois) ...
Et la norme de signalisation ERTMS (de mémoire) tarde à s'imposer en Europe.
Faut-il aussi rappeler qu'une des tares du RER B est que le système de signalisation n'est pas le même entre les parties RATP et SNCF ?!!

Edit, à la décharge des acteurs du ferroviaire : il est clair qu'il est plus facile, rapide et moins coûteux de changer des systèmes dans l'aéronautique (aéroports, tours de contrôle etc) que sur un territoire (tensions caténaires, signalisation)

Edit2: Poncho, le message que j'ai écrit, en messagerie privée, ne veut pas partir. Peux tu m'envoyer un message pour le faire partir ?

Sintex a écrit:Un éclairage intéressant et bien écrit sur les déboires de la gestion technique du projet F35.
http://www.portail-aviation.com/blog/2018/08/03/f-35-ou-le-paradoxe-de-zenon/

Un de mes commentaires, pas encore publiés, sur cet article :

"Etant donnés la complexité du sujet et le très grand nombre de dysfonctionnements, à la fois des 3  avions obtenus et de la gestion de projet, je tends à penser que la rédaction d'un article traitant de tous les thèmes abordés demanderait beaucoup de temps. Il me semble qu'il faudrait se servir intensément du mode Plan de Word, pour bien structurer les idées AVANT de passer à la rédaction. 

Cela aurait probablement débouché sur un article plus long (avec les thèmes traités), en 2 morceaux (et peut être plus), ou bien d'un article plus court, en laissant de côté de nombreux points. 
Pour avoir moi-même écrit un article sur ce sujet (L’un des pères du F-16 attaque en règle le chasseur F-35), je peux témoigner de la difficulté !"

Laurent Simon a écrit:

Poncho (Admin) a écrit:Sinon pour le volet normalisation et standard...
Perso je bosse tous les jours avec les Eurocodes... et même si ce n'est pas tout à fait les mêmes normes d'application d'un pays à l'autre, il y a beaucoup de choses normalisés (notamment les essais dans mon domaines... donc vivent les NF-EN les BS-EN  qu'on exporte du coup plus facilement en Afrique par exemple)

Oui. 
Sauf que justement le ferroviaire est à la traîne sur ces aspects normalisation en Europe, ce qui fait qu'un TGV Paris Amsterdam doit embarquer avec lui des transfos, très lourds, pour être compatible avec au moins 4 systèmes de tension différents... pour moins de 400 km (je crois) ...
Et la norme de signalisation ERTMS (de mémoire) tarde à s'imposer en Europe.
Faut-il aussi rappeler qu'une des tares du RER B est que le système de signalisation n'est pas le même entre les parties RATP et SNCF ?!!

Edit, à la décharge des acteurs du ferroviaire : il est clair qu'il est plus facile, rapide et moins coûteux de changer des systèmes dans l'aéronautique (aéroports, tours de contrôle etc) que sur un territoire (tensions caténaires, signalisation)

3 seulement pour France / Benelux
Ce qui coince c'est le matériel roulant tout autant que les infra (paradoxalement place limitée pour l'electronique dans une loco), mais tout ça est Hs même si intéressant :d

Laurent Simon a écrit:

Sintex a écrit:Un éclairage intéressant et bien écrit sur les déboires de la gestion technique du projet F35.
http://www.portail-aviation.com/blog/2018/08/03/f-35-ou-le-paradoxe-de-zenon/

Un de mes commentaires, pas encore publiés, sur cet article :

"Etant donnés la complexité du sujet et le très grand nombre de dysfonctionnements, à la fois des 3  avions obtenus et de la gestion de projet, je tends à penser que la rédaction d'un article traitant de tous les thèmes abordés demanderait beaucoup de temps. Il me semble qu'il faudrait se servir intensément du mode Plan de Word, pour bien structurer les idées AVANT de passer à la rédaction. 

Cela aurait probablement débouché sur un article plus long (avec les thèmes traités), en 2 morceaux (et peut être plus), ou bien d'un article plus court, en laissant de côté de nombreux points. 
Pour avoir moi-même écrit un article sur ce sujet (L’un des pères du F-16 attaque en règle le chasseur F-35), je peux témoigner de la difficulté !"

C'est un programme complexe, complexe à suivre

Le forum sur l'article cité plus haut mentionne le rapport (1997) de Rand Corporation qui semble très intéressant (mais que je n'ai pas le temps de lire, ou même survoler)

https://www.rand.org/content/dam/rand/pubs/monograph_reports/2007/MR719.pdf

Comme cet organisme cherche en général à réduire les dépenses, c'est un axe majeur de leur rapport (Affordability), et ils essaient de définir les conditions à réunir pour rendre le jsf 'abordable', mais ils partent sur des hypothèses très lointaines  (26-40 ou 45 M$ / jsf) de celles actuelles...
(note 1 "wing", pour eux = 100 avions)
Ils essaient de trouver des solutions pour une dépense de N milliers de millions de dollars / an, 
mais il faut croire qu'ils ont largement augmenté les budgets (et cela se voit sur la dette américaine qui enfle, dette qu'avec le dollar nos amis sont tout contents de faire payer à la planète entière)

https://www.businessinsider.com/israeli-f-35-may-have-mistakenly-blown-its-cover-while-on-a-mission-2018-7

cité par 
https://www.agoravox.fr/tribune-libre/article/f-35-vous-avez-dit-furtif-206701

Merci

C'est le transpondeur ADSB qui est resté sur off

Et donc pas la perte subite de sa cape d'invisibilité suite à une pluie torrentielle ou à une exposition prolongée à un soleil de plomb :d

Par contre un bon moyen pour ceux qui le suive au radar de calibrer le radar sur la trace ADSB