Picdelamirand-oil

Même les Croates n'en veulent pas?

Quand tu fais une coopération avec 4 pays, il y en a toujours un qui utilise des composants américains.

Block 4 Software Issues Could Cause F-35 Capability Delays, Costly Retrofits Traduit avec www.DeepL.com/Translator (version gratuite) Les problèmes logiciels du bloc 4 pourraient entraîner des retards dans la capacité des F-35 et des mises à niveau coûteuses. "Le plus grand défi potentiel est que ces éléments de modernisation n'atteignent pas le combattant aussi rapidement qu'on l'espérait", a déclaré un expert. Par THERESA HITCHENS le 19 mars 2021 à 15 h 44 WASHINGTON : À la suite du dernier examen du Government Accountability Office, le ministère de la Défense devrait à nouveau repousser le calendrier de l'effort tentaculaire de modernisation des F-35. Le nouveau rapport est une nouvelle gifle pour le Joint Strike Fighter, qui est déjà dans la ligne de mire du DoD pour les coupes budgétaires en raison des coûts de maintenance exorbitants de l'avion. Des membres importants du Congrès, dont le président démocrate de la commission des services armés de la Chambre des représentants, Adam Smith, regardent également d'un mauvais œil ce programme, qui devrait coûter près de 2 000 milliards de dollars sur toute sa durée de vie. Le rapport du GAO a conclu que l'objectif actuel de 2027 pour la finalisation de la modernisation du bloc 4 n'est "pas réalisable". Le GAO a déclaré que les coûts de l'effort avaient gonflé de 1,9 milliard de dollars entre 2019 et 2020, portant le coût global à environ 14,4 milliards de dollars. Le développement de logiciels a été le principal moteur des problèmes, selon le rapport - y compris le fait qu'environ un quart des logiciels livrés par le maître d'œuvre Lockheed Martin se sont avérés avoir des défauts après avoir déjà été intégrés dans l'avion. "Nous apprécions et sommes d'accord avec les recommandations du GAO", a déclaré Jessica Maxwell, porte-parole de l'OSD, dans un courriel. "En collaboration avec le Joint Program Office, le sous-secrétaire à la Défense pour l'acquisition et le maintien en puissance travaillera à la mise à jour du calendrier du programme F-35 Block 4 ainsi qu'à l'amélioration du développement des logiciels et des mesures de performance pour mieux soutenir les décisions du programme." "Lockheed Martin a lancé une évaluation logicielle à l'échelle du programme et, en partenariat avec le Joint Program Office (JPO) du F-35, a créé une équipe de révision indépendante (IRT) des logiciels à l'automne 2020 pour examiner les capacités logicielles du F-35", a déclaré un porte-parole de l'entreprise dans un courriel. "Cette équipe, composée de représentants du JPO, de Lockheed Martin, du gouvernement américain et de l'industrie, a fait des progrès significatifs dans l'identification et la prise en compte des opportunités qui fournissent des produits de qualité dans le respect des délais et du budget pour le client F-35." Le résultat potentiel le plus insidieux des conclusions du GAO, selon les sources, est que les problèmes continus dans la livraison des logiciels pourraient retarder l'intégration de sous-systèmes clés, tels que les améliorations du radar, pour suivre le rythme des menaces croissantes des adversaires. (La date limite actuelle de 2027 pour l'achèvement du bloc 4 représente déjà un retard de trois ans par rapport à la date limite de 2024 que le DoD a fixée dans sa base de référence de 2018 pour cet effort). "Le plus grand défi potentiel est que ces éléments de modernisation n'atteignent pas le combattant aussi rapidement qu'ils l'avaient espéré", a déclaré un expert. "Il y a un retard dans la mise en place de ces capacités de modernisation sur le terrain, et une partie de la raison pour laquelle ils font la modernisation est que le monde a changé depuis 2001, lorsque le programme a commencé, et que l'environnement de la menace est différent, à la fois en termes de systèmes radar et et d'équipements adverses potentiels." Une autre retombée potentielle est le spectre des coûts de modernisation, a déclaré l'expert. "Dans la mesure où vous avez continué à produire des avions sans intégrer le nouveau matériel, cette concomitance finit en quelque sorte par créer un coût de rétrofit qui devra être supporté plus tard." Et ce sont l'armée de l'air, la marine et les Marines qui vont finir par supporter la plupart de ces coûts, a ajouté l'expert. "Il y a de nouveaux capteurs qui sortent pour le jet et qui ne s'alignent qu'avec les logiciels plus modernes", a déclaré un autre analyste qui suit le programme de près. "Si l'ancien logiciel est toujours en cours de production et que vous livrez ces nouveaux capteurs, cela ne colle pas. C'est donc là qu'il est vraiment important de tout réaligner et de s'assurer que tout s'équilibre." Ce que le DoD ne peut pas permettre, a ajouté la source, c'est un futur "désordre" où les F-35 sortent des chaînes de montage sans correspondre aux exigences des services américains et des alliés. Le rapport du GAO a attiré l'attention sur le fait que "Lockheed a tout simplement lutté pour que les logiciels soient réalisés aussi rapidement qu'ils l'avaient imaginé", a déclaré l'expert. "Ce qu'ils ont constaté, c'est que les retards dans le développement des incréments logiciels ont retardé la capacité de les tester. ... et dans certains cas, les défauts apparaissaient dans la flotte de test réelle et causaient des problèmes." Les prochaines étapes pour le DoD et l'armée de l'air - qui est responsable de l'achat le plus important de F-35 avec 1 763 appareils - sont d'examiner attentivement ce qui peut réellement être fait, dans quel délai, à quel coût et avec quels compromis en termes de capacité et de proposer un plan, selon les experts externes. "Je pense que le ministère de la Défense et les services doivent tracer une ligne de craie, se ressaisir sur certaines de ces questions et établir des priorités en matière d'investissement", a déclaré l'analyste. Il semble que ce soit également le cas du DoD, dans la mesure où le Pentagone a accepté toutes les recommandations du GAO à cet égard. Dans une réponse au rapport du GAO, contenue dans l'annexe V signée le 1er mars par Dyke Weatherington, qui exerce les fonctions de secrétaire adjoint du DoD pour les acquisitions, le DoD déclare qu'il a l'intention de publier un nouveau calendrier de livraison des capacités et du développement du bloc 4 d'ici le deuxième trimestre de cette année civile. Le DoD indique également que le Joint Program Office intègre de nouvelles mesures de développement agile et de performance logicielle dans les contrats actuels et dans un "contrat d'ingénierie et de test des systèmes en cours de réalisation".

Et pourquoi ça te chiffonne? Nous aussi on risque de faire des F4.2 ready

Je ne sais pas ce que vous en pensez, je suis peut être un peu rétrograde, mais j'ai l'impression que cette histoire de C2D2 n'améliore rien du tout. Cela me semble être une justification théorique qui permet d'organiser un merdier encore plus grand que celui d'avant. Et d'ailleurs on voit qu'il est mal appliqué par des gens qui n'en ont aucune expérience. Pour un programme de cette dimension ça me parait très risqué. Même les contrats semblent mauvais en ne prévoyant pas les outils qui permettraient de manager la qualité du logiciel. @Pierre_F @Boule75

Tu vois quand j'ai annoncé 2031 je me suis dit "les gens vont le prendre comme une provocation" et maintenant on en est à discuter si c'est 2045 ou plutôt 2035. Mais mon 2045 n'est pas plus une provocation que ne l'était mon 2031 à l'époque.

Le bureau du programme n'a pas établi de cibles de rendement pour surveiller la qualité des logiciels Nous avons constaté que le bureau du programme F-35 avait fixé des objectifs de performance pour les mesures logicielles liées aux coûts, au calendrier et à la dotation en personnel, mais qu'il n'avait pas établi d'objectifs pour les mesures critiques qui évaluent la qualité des logiciels, ce qui n'est pas conforme à une pratique clé de notre Guide d'évaluation Agile. Nos travaux antérieurs soulignent l'importance d'établir des objectifs de performance quantifiables et significatifs pour les mesures logicielles afin de s'assurer que les efforts de développement logiciel soutiennent les objectifs du programme et progressent vers ces objectifs. Les objectifs de performance permettent aux gestionnaires de programme d'évaluer la performance des entrepreneurs, d'identifier les mesures à prendre pour améliorer la performance et de mesurer les progrès. L'énoncé des travaux pour le contrat du bloc 4 a fixé un objectif pour les paramètres de dotation en personnel liés à la charge de travail prévue. Cependant, aucun objectif de performance n'a été fixé pour les deux problèmes de qualité critiques qui affectent le calendrier du Bloc 4 : la livraison à temps de toutes les capacités dans l'incrément 1 de chaque chute de logiciel et les défauts découverts après la livraison du logiciel à la flotte d'essai. Comme nous l'avons signalé plus haut, l'entrepreneur n'a livré que 69 % de la fonctionnalité prévue pour une récente livraison de logiciels, et les capacités ne sont pas toujours livrées dans le premier incrément de logiciels du calendrier de livraison de logiciels de six mois. En définissant des objectifs d'état final (cibles) pour la fonctionnalité et en comparant ensuite la fonctionnalité livrée à l'objectif, les responsables du programme peuvent voir jusqu'où l'entrepreneur doit aller, puis utiliser cette connaissance pour s'assurer que l'entrepreneur livre la fonctionnalité complète dans le premier incrément d'une livraison de logiciel. Les responsables du programme pourraient également mesurer les progrès par rapport à l'objectif et prévoir la quantité de travail nécessaire pour achever le dépôt jusqu'à ce que l'incrément soit terminé. De même, comme nous l'avons mentionné ci-dessus, les responsables du programme reconnaissent qu'ils découvrent trop de défauts après que l'entrepreneur a livré le logiciel à la flotte d'essai, au lieu de les découvrir dans le laboratoire de logiciels de l'entrepreneur. En fixant des objectifs pour le nombre de défauts que le programme devrait identifier après la livraison du logiciel à la flotte d'essai, le programme pourrait inciter l'entrepreneur à éliminer davantage de défauts dans le laboratoire logiciel. Les responsables du programme nous ont dit qu'ils n'avaient pas établi d'objectifs pour les paramètres essentiels de qualité des logiciels au moment de l'attribution du contrat parce qu'ils étaient encore en train d'apprendre quels objectifs seraient appropriés dans un environnement de développement de logiciels Agile. Ils ont déclaré qu'ils se tournent maintenant vers d'autres programmes, comme le programme F-22, pour comprendre les leçons apprises sur les objectifs de performance de la qualité qui aident à améliorer la performance de l'entrepreneur. Les responsables du programme ont déclaré qu'ils envisageaient d'établir des objectifs pour les mesures de la qualité des logiciels dans le contrat de décembre 2021 dont il est question ci-dessus et qu'ils envisageaient de lier ces objectifs à de futures incitations monétaires pour les entrepreneurs, mais qu'ils n'avaient pas élaboré de plans concrets ni placé ces objectifs sous contrat. En l'absence d'objectifs de performance pour les mesures essentielles de la qualité des logiciels, le bureau du programme F-35 est moins à même de déterminer si l'entrepreneur a atteint des niveaux de performance acceptables en matière de qualité et risque davantage de ne pas atteindre les objectifs du bloc 4. Conclusions On s'attend à ce que le F-35 joue un rôle clé dans les flottes aériennes des États-Unis et des pays alliés pour les années à venir, et de nombreuses capacités actualisées devraient découler de l'effort de modernisation du Bloc 4. Bien que nous reconnaissions les défis liés à la transition vers le développement agile, après trois ans d'efforts, le programme F-35 continue de rencontrer des difficultés à mettre en œuvre efficacement l'approche C2D2 pour développer et fournir les capacités du bloc 4. L'entrepreneur chargé de la cellule continue de livrer les capacités en retard, et le calendrier restant comporte des risques importants et n'est pas réalisable compte tenu du rythme des performances passées. Bien que le bureau du programme soit déterminé à fournir des capacités plus rapidement au combattant, le programme n'a pas respecté son plan itératif initial. En l'absence d'un calendrier réalisable fondé sur les performances passées, le programme risque de continuer à ne pas répondre aux attentes, et le combattant devra attendre plus longtemps pour obtenir les capacités promises. À la base de ces difficultés, le bureau du programme F-35 a déclaré qu'il ne disposait pas des informations sur les performances de l'entrepreneur chargé du développement du logiciel du bloc 4 dont il a besoin pour gérer plus efficacement cet effort. Bien que le programme F-35 prenne des mesures pour collecter les paramètres supplémentaires, seul le temps dira si le bureau du programme identifie les bons paramètres pour obtenir les informations dont il a besoin pour améliorer sa gestion du développement du bloc 4. Nous continuerons à surveiller les paramètres de développement du logiciel du bloc 4 et à inclure nos observations dans les prochains rapports. De plus, si l'on n'exige pas d'outils automatisés pour accéder aux données de performance de l'entrepreneur en temps réel, le programme ne disposera pas de mises à jour opportunes sur les nouveaux paramètres, ne disposera pas de données de programme de qualité et fonctionnera avec des données anciennes ou potentiellement erronées, ce qui pourrait entraîner des retards dans la livraison aux combattants. Enfin, comme le bureau du programme engage l'entrepreneur à identifier la gamme complète des paramètres nécessaires, le programme a la possibilité d'inclure des objectifs de performance de développement de logiciels pour les paramètres critiques de qualité des logiciels dans le prochain contrat afin de mieux garantir que l'entrepreneur atteint les objectifs du programme. Recommandations pour une action exécutive Nous faisons les trois recommandations suivantes au Département de la Défense : Le sous-secrétaire à la Défense pour l'acquisition et le maintien en puissance devrait demander au bureau du programme F-35 de mettre à jour son calendrier du bloc 4 afin de refléter les performances historiques, de développer des calendriers plus réalisables pour le développement et la livraison des capacités de modernisation du bloc 4, et de fournir une base de référence précise pour comparer les estimations de coûts futures. (Recommandation 1) Le sous-secrétaire à la Défense pour l'acquisition et le maintien en puissance devrait ordonner au bureau du programme F-35 d'identifier et de mettre en œuvre des outils automatisés permettant d'accéder à des données en temps réel pour les paramètres de développement des logiciels afin d'éclairer les décisions du programme et de garantir la fiabilité de la qualité des données. (Recommandation 2) Le sous-secrétaire à la Défense pour l'acquisition et le maintien en puissance devrait demander au bureau du programme F-35 de fixer des valeurs cibles de performance logicielle pour les mesures critiques de la qualité des logiciels au fur et à mesure qu'il prend des mesures pour identifier des mesures supplémentaires de développement de logiciels. (Recommandation 3)

J'ai proposé un modèle qui faisait la part belle à des drones bon marchés, mais nombreux, et qui étaient efficace surtout en saturant les défenses adverses. Je voudrais améliorer un peu ce modèle en proposant des leurres encore meilleurs marché qui augmenteront la saturation, notamment via l’utilisation de mini-drones aéro-largués, opérant en collaboration d’aéronefs habités, ou en essaim depuis des « vaisseaux mères » en dehors de la bulle du SDAI. Tout l’enjeu est de maintenir le drone à un coût raisonnable tout en lui conférant les capacités suffisantes (portée, guidage autonome, charges diverses type leurre, GE ou explosive) ce qui plaide pour des engins modulaires. Ces concepts ayant déjà inspiré des expérimentations comme celles Gremlins de la DARPA devraient être sources d’inspiration pour le SCAF. On pourrait envisager l’achat sur étagère d’une flotte d’ADM-160 MALD pour expérimenter. Ces drones consommables bénéficient d’un système d’accroissement de la SER de manière à simuler un escadron de chasse ou de bombardier en formation d’attaque. Développé par Raytheon et commandés à plus de 3 000 exemplaires par l’US Air Force, ce dispositif permettrait de saturer les radars, jouant ainsi le rôle de « fumigène », voire d’épuiser les stocks de missiles ennemis. https://en.wikipedia.org/wiki/ADM-160_MALD

On le saura dans 10 ans

Là je n'ose plus faire de prévisions... J'avais une règle privée pour faire des prévisions qui était: Le temps Indien = 8 X le temps normal Le temps F-35 = 4 X le temps normal Le temps Typhoon = le temps Gripen = 2 X le temps normal Le temps Dassault = 0.9 X le temps normal Mais si j'applique ça à la prévision de 2027, ça me fait 4 X 6 = 24 à rajouter à 2021 ce qui fait 2045.... Il se sera passé quelque chose avant.

L'approche de la gestion du développement des logiciels du bloc 4 ne reflète pas entièrement les principales pratiques de pointe Nous avons constaté que le bureau du programme F-35 recueille des données sur de nombreux paramètres de développement du logiciel du Bloc 4, une pratique clé de notre Guide d'évaluation Agile, mais le programme n'a pas respecté deux autres pratiques clés pour le suivi des progrès du développement du logiciel. Plus précisément, le programme a demandé à Lockheed Martin de fournir certaines données sur les paramètres de développement de logiciels dans le cadre du contrat du Bloc 4, mais il n'a pas accès à des outils automatisés pour saisir les données de performance en temps réel pour ces paramètres afin de faciliter la prise de décisions programmatiques. Enfin, si les responsables du programme ont fixé des objectifs de performance pour les paramètres suivis, notamment pour s'assurer que le programme respecte son calendrier de déploiement de logiciels de six mois, ils n'ont pas fixé d'objectifs pour la qualité des logiciels. Le bureau du programme des F-35 ajoute de nouveaux paramètres pour mesurer la qualité des logiciels Le bureau du programme F-35 recueille des données sur les paramètres logiciels pour suivre l'évolution du développement du logiciel du bloc 4, une pratique clé de notre guide d'évaluation agile, et prend des mesures pour obtenir des paramètres supplémentaires qui donneraient un meilleur aperçu de la qualité des logiciels. Depuis plus de 20 ans, nous avons toujours insisté sur la nécessité pour les organisations de collecter et d'utiliser des données sur la performance des programmes pour aider à informer et à mesurer les opérations et les résultats de l'organisation. À cette fin, notre Guide d'évaluation Agile, qui identifie les pratiques clés pour le développement de logiciels Agile, indique que des mesures claires, significatives et exploitables fournissent aux gestionnaires des informations pour mesurer la performance des programmes, et que ces mesures doivent être adaptées en fonction des besoins de développement de logiciels d'un programme et conformément à leur cadre Agile établi. De plus, l'instruction d'acquisition de logiciels du DOD d'octobre 2020 stipule que les programmes du DOD doivent développer et suivre les mesures de développement de logiciels, mais ne définit pas ces mesures et permet aux programmes de déterminer les mesures qu'ils suivent. Nous avons constaté que le contrat du bloc 4 exige que l'entrepreneur communique au programme F-35 des données sur les paramètres relatifs à la qualité, aux performances, aux coûts, au calendrier et à la dotation en personnel des logiciels, afin d'éclairer le développement des logiciels, mais ces paramètres ne donnent qu'un aperçu limité des aspects de la qualité du développement des logiciels dans le cadre de l'approche Agile. Le programme F-35 a établi les paramètres initiaux dont l'entrepreneur doit rendre compte dans son contrat de novembre 2018. Les responsables du programme nous ont dit que les activités de développement du bloc 4, à ce moment-là, étaient axées sur la résolution des lacunes du programme de base, plutôt que sur le développement de nouvelles capacités, ce qui a influencé les types de métriques que le bureau du programme a décidé d'inclure dans le contrat. Les mesures actuellement sous contrat comprennent le confinement des défauts, qui mesure le nombre total de défauts qui ne sont pas détectés depuis le développement jusqu'aux essais en vol et sur le terrain, et les lignes de code source, qui mesurent la taille du logiciel. Depuis l'attribution du contrat en novembre 2018, les responsables du programme ont expliqué que, lors de la transition vers le développement de nouvelles capacités, ils ont reconnu la nécessité de disposer de plus d'informations que les paramètres contractuels fournis et ont pris des mesures pour collecter d'autres paramètres sur le développement de logiciels. Par exemple, le bureau du programme a collaboré avec l'entrepreneur pour obtenir des données sur 19 paramètres en plus de ceux exigés par le contrat, afin de mieux comprendre la qualité et la performance du développement de logiciels. Voici quelques exemples de mesures non prévues au contrat que le programme reçoit périodiquement : la métrique d'épuisement des problèmes logiciels, qui fournit des informations sur la quantité de travail de développement logiciel restant dans la portée du projet ; et la mesure de la stabilité des exigences en matière de développement de logiciels, qui aide le programme à déterminer dans quelle mesure les changements ou les ajouts aux exigences entraînent des retards de calendrier ou des dépassements de coûts, entre autres effets. Malgré ces ajouts, les responsables du programme ont reconnu qu'ils ne recueillent pas toutes les mesures dont ils ont besoin pour mieux comprendre les risques du programme et prendre des décisions de gestion plus éclairées, mais qu'ils prennent des mesures en ce sens. Les responsables du programme ont expliqué qu'ils utilisent les conseils fournis par le DOD et se coordonnent avec d'autres bureaux de programme qui ont utilisé le développement de logiciels Agile pour identifier des mesures de développement de logiciels Agile plus informatives. En outre, en août 2020, le programme a formé un groupe de travail conjoint, composé de responsables du programme et de représentants de Lockheed Martin, afin d'identifier les autres mesures que le programme devrait collecter. Il a également formé un autre groupe, composé de responsables du programme et de représentants de l'entrepreneur, afin d'identifier les processus d'utilisation de ces mesures qui aideraient mieux le programme à s'assurer que l'entrepreneur livre le logiciel à temps avec moins de défauts, et à identifier et résoudre les défauts du logiciel plus tôt dans le processus de développement du logiciel. Sur la base des résultats de ces efforts, les responsables du programme ont déclaré que la prochaine itération du contrat du bloc 4, qui devrait être attribué en décembre 2021, nécessitera de nouveaux paramètres pour aider à atteindre ses objectifs. Le programme prévoit d'exiger que l'entrepreneur fournisse, entre autres, les informations suivantes le nombre de fonctionnalités planifiées et le nombre de fonctionnalités achevées pour chaque incrément de logiciel, ce qui permettrait de connaître les progrès réalisés par rapport au calendrier prévu et de s'assurer que toutes les capacités sont livrées comme prévu dans le premier incrément de chaque baisse de logiciel, et des mesures de la densité des défauts pour chaque incrément logiciel afin de mesurer le nombre de défauts dans un incrément logiciel et de mesurer la qualité du logiciel produit par l'entrepreneur. Les responsables du programme ont déclaré que ces mesures devraient donner un meilleur aperçu de la livraison des capacités dans les délais et des défauts logiciels, deux problèmes clés qui empêchent le programme de respecter son calendrier de développement. Ces responsables ont également déclaré qu'ils avaient l'intention d'inclure d'autres termes dans le contrat de décembre 2021 qui donneraient au programme une plus grande flexibilité pour demander des mesures supplémentaires sur les progrès du développement du logiciel à l'entrepreneur de la cellule. Le bureau du programme n'a pas accès à des outils automatisés permettant de saisir des données en temps réel pour les paramètres de développement qu'il suit Nous avons constaté que le bureau du programme F-35 n'a pas accès à des outils automatisés pour saisir en temps réel les données relatives au développement du logiciel du bloc 4 pour les paramètres qu'il surveille, ce qui n'est pas conforme à nos pratiques clés et à la nouvelle instruction d'acquisition de logiciels du DOD. Notre guide Agile et l'instruction du DOD indiquent tous deux que les programmes doivent utiliser des outils automatisés dans toute la mesure du possible pour collecter des données sur les paramètres logiciels. Nos travaux antérieurs indiquent que les données automatisées permettent aux gestionnaires de prendre des décisions fondées sur des données et d'assurer une surveillance soutenue par des informations pertinentes en temps réel. De plus, l'utilisation d'outils de développement de logiciels pour saisir et afficher les mesures en temps réel permet de s'assurer que l'information sur le rendement est communiquée fréquemment et efficacement aux gestionnaires du programme. Nous avons constaté que l'accès actuel du programme aux données de mesure des logiciels ne permet pas d'effectuer des évaluations rapides ou fiables de l'effort de développement de logiciels du Bloc 4, ce qui entrave la capacité du programme à effectuer une surveillance des entrepreneurs. Les responsables du programme nous ont dit qu'ils n'ont pas inclus dans le contrat une disposition leur donnant accès à des outils automatisés pour recueillir des données en temps réel sur les progrès de l'entrepreneur de la cellule parce qu'ils ont intentionnellement gardé le langage contractuel large pour maintenir un maximum de flexibilité alors que le programme passait à une approche de développement logiciel Agile. Bien que Lockheed Martin utilise une interface logicielle pour recueillir et analyser certaines données métriques sur le développement de logiciels, cette interface n'est pas accessible aux responsables du programme F-35. Par conséquent, les responsables du programme dépendent des rapports périodiques, généralement mensuels ou sur demande, de l'entrepreneur pour prendre des décisions programmatiques. Selon une évaluation des frais d'attribution du bureau du programme sur la performance de l'entrepreneur de juin 2019 à mars 2020, l'accès aux données et aux informations reste un point de préoccupation pour les responsables du programme F-35, car les données métriques nécessaires pour prendre des décisions rapides ne sont pas facilement accessibles. Par exemple, le programme reçoit des données sur la quantité de travail accompli dans une itération logicielle, mais ces données sont disponibles trimestriellement au lieu d'être fournies automatiquement en temps réel par l'interface logicielle de l'entrepreneur. Les données fournies par l'entrepreneur sont en retard, parfois jusqu'à 30 jours. Par conséquent, les responsables du programme ont expliqué qu'ils n'ont pas un aperçu du rendement de l'entrepreneur en temps réel. Les responsables du programme ont déclaré qu'ils travaillaient avec l'entrepreneur pour obtenir l'accès à son interface logicielle, mais ils ont fait état de progrès lents sur cette question. De plus, les responsables du programme ont déclaré qu'ils envisagent d'inclure une exigence d'accès aux données en temps réel dans leur contrat de décembre 2021, ce qui est dans près d'un an, et le développement du Bloc 4 se poursuit. Sans outils automatisés pour recueillir des données en temps réel sur le développement des logiciels, les responsables du programme n'ont pas accès aux informations qui leur permettraient d'évaluer les progrès et d'atténuer les risques liés au développement et à la livraison en temps opportun. Les responsables du programme F-35 ont également indiqué que les données de mesure du bloc 4 fournies dans les rapports de Lockheed Martin n'étaient pas présentées de manière cohérente et comportaient des erreurs, ce qui a limité leur compréhension. Notre guide Agile note que les outils automatisés aident les programmes à s'assurer que la qualité des données recueillies est fiable. Dans l'évaluation par le bureau du programme de la performance de l'entrepreneur de la cellule entre juin 2019 et mars 2020, le bureau du programme a signalé des erreurs dans les données de l'entrepreneur, qui, selon les responsables du programme, proviennent probablement d'une erreur humaine dans la génération des rapports de performance. Le programme a déclaré que les erreurs et les données communiquées de manière incohérente ont diminué l'utilité des informations livrées et n'ont pas permis une évaluation fiable de l'état du développement du bloc 4. Les responsables du programme nous ont dit qu'ils travaillaient avec l'entrepreneur pour élaborer des lignes directrices visant à garantir la fiabilité des données communiquées au bureau du programme F-35. Ils s'efforcent également de faire en sorte que tous les employés de l'entrepreneur aient une compréhension uniforme de chaque mesure, y compris des données sous-jacentes requises, afin que le bureau du programme puisse parvenir à des conclusions communes. Cependant, en l'absence d'outils automatisés pour collecter les données de métrique logicielle, le bureau de programme continuera de courir le risque de recevoir des données incohérentes ou incorrectes sur la performance de Lockheed Martin en matière de développement de logiciels.

Bien que le programme prévoie généralement ces quatre incréments par logiciel, nous avons constaté, au cours des deux dernières années, que certains logiciels nécessitaient plus d'incréments et prenaient plus de temps à développer que prévu, comme le montre la figure 14. Ces incréments supplémentaires ont retardé la livraison des capacités. Nous avons constaté que les livraisons les plus récentes, en particulier, comportaient plus d'incréments que les quatre prévus. Par exemple, le logiciel livré en juin 2020 comprenait 10 incréments, soit six de plus que prévu initialement. Les représentants de Lockheed Martin ont déclaré que deux de ces incréments ont été ajoutés pour augmenter la fonctionnalité et la maturité des capacités afin d'éviter les retards dans la prochaine livraison du logiciel. Toutefois, selon les représentants de l'entrepreneur, quatre des incréments ajoutés visaient à corriger des défauts logiciels. En outre, le lancement du logiciel prévu en octobre 2020 comprenait huit incréments, soit quatre de plus que prévu. Les représentants de Lockheed Martin nous ont dit que chacun de ces incréments ajoutés visait à corriger des défauts logiciels. Bien que les représentants de l'entrepreneur aient déclaré avoir livré toutes les capacités prévues, selon les responsables du programme, ils ont décidé de ne pas mettre en service ce logiciel afin que tous les défauts puissent être résolus. Les responsables du programme ont également déclaré qu'ils mettraient en service toutes ces capacités lors de la prochaine livraison de logiciels prévue en mars 2021, soit 5 mois plus tard que prévu. De plus, selon les responsables du DOT&E, en raison de ces retards dans la livraison du logiciel d'octobre 2020, le premier incrément de la livraison du logiciel suivant - qui devait être livré en avril 2021 - a été éliminé. Pour chaque livraison de logiciels, une analyse effectuée par une tierce partie a révélé que Lockheed Martin n'a pas toujours livré les capacités du premier incrément comme prévu, ce qui augmente le risque que des défauts soient inclus dans les logiciels mis en service. L'inclusion de toutes les capacités dans le premier incrément d'une baisse de logiciel donne à l'entrepreneur plus de temps pour corriger les défauts avant que les baisses de logiciel soient mises en service dans la flotte. Bien que les représentants de Lockheed Martin conviennent que les capacités devraient être livrées dans le premier incrément possible, les capacités ne sont pas toujours prêtes à être incluses dans le premier incrément. Les représentants de l'entrepreneur ont expliqué que c'était le cas en raison d'un certain nombre de facteurs, tels que des attributions de contrats tardives les empêchant de réaliser de nouveaux travaux, des problèmes de chaîne d'approvisionnement et des problèmes récents de capacité de la main-d'œuvre découlant des restrictions du COVID-19. Ces dernières années, les responsables du programme n'ont pas identifié près d'un quart de tous les défauts avant qu'ils ne soient déjà livrés aux avions d'essai. Idéalement, selon le bureau du programme, l'entrepreneur devrait identifier les défauts dans le laboratoire du logiciel ou avant que le logiciel ne soit livré à l'avion d'essai de développement. Cependant, une analyse réalisée en novembre 2020 par une société de conseil tierce pour le compte du bureau du programme a révélé qu'entre décembre 2017 et septembre 2020, 656 défauts logiciels (soit 23 % de tous les défauts logiciels) ont été identifiés après la livraison du logiciel à l'avion d'essai. Les responsables du DOT&E ont également déclaré que, tel qu'il est actuellement planifié, le calendrier ne prévoit pas suffisamment de temps pour effectuer des tests de régression afin d'identifier et de corriger les défauts avant que l'incrément final du logiciel ne soit terminé, ce qui augmente encore le risque que des défauts soient livrés à la flotte. Selon les responsables des essais, la découverte de défauts après que les capacités ont quitté le laboratoire de l'entrepreneur est plus coûteuse et plus longue à corriger. L'entrepreneur reconnaît que les découvertes tardives constituent un problème et s'efforce d'identifier et de corriger les défauts plus tôt dans le processus de développement. Par exemple, les représentants de l'entrepreneur ont déclaré qu'ils ont agrandi leurs installations de laboratoire d'essai pour augmenter la capacité d'essai. Les pilotes d'essai que nous avons rencontrés ont expliqué que lorsque l'entrepreneur n'a pas livré le premier incrément de la chute logicielle prévue pour avril 2021, ils ont perdu un temps crucial pour identifier les défauts au début du cycle de développement, ce qui a contribué aux incréments logiciels non planifiés et au fait que certains défauts n'ont pas été identifiés pendant les tests. Selon l'étude indépendante du programme sur le développement du logiciel du bloc 4, les responsables du programme ont diffusé sur les aéronefs opérationnels un logiciel qui comportait 386 défauts logiciels découverts ultérieurement par les pilotes sur le terrain. De plus, huit de ces défauts ont eu un effet négatif sur les capacités essentielles de la mission ou sur les risques techniques liés au coût et au calendrier, sans solution de rechange connue. Les responsables du programme ont déclaré qu'ils travaillent avec l'entrepreneur pour s'assurer que toutes les capacités seront incluses dans l'incrément 1 de chaque baisse de logiciel à l'avenir. En outre, les pilotes d'essai et les responsables du DOT&E ont exprimé des inquiétudes quant à la faisabilité du calendrier à l'avenir, étant donné que le programme fait passer davantage de capacités dans les versions logicielles ultérieures. Les responsables des essais ont déclaré que les capacités actuellement livrées sont moins complexes que celles qui sont prévues plus tard dans le calendrier du bloc 4. Un examen de la faisabilité du calendrier du bloc 4 effectué par le sous-secrétaire à la défense pour la recherche et l'ingénierie a également révélé que les versions logicielles prévues entre 2023 et 2025 sont plus complexes et que le calendrier global du bloc 4 présente un risque élevé. Bien que nous sachions que l'entrepreneur ajoute constamment des incréments non planifiés et qu'il est courant qu'il ne livre pas les capacités à temps ou dans le premier incrément d'un abandon de logiciel, nous avons constaté que le bureau du programme n'a pas ajusté son calendrier pour refléter ces réalités, car il a maintenu le désir de livrer le logiciel tous les 6 mois. Selon le guide d'évaluation Agile du GAO, le calendrier d'un programme doit refléter de manière réaliste le temps que prendra chaque activité et les équipes de développement de logiciels doivent examiner les performances passées pour éclairer les estimations futures.45 En outre, le guide d'évaluation du calendrier du GAO note l'importance d'un calendrier de base précis qui peut être utilisé pour suivre les progrès réalisés.46 Les responsables du programme ont déclaré que, bien que le programme ait révisé son calendrier pour livrer les capacités plus tard que prévu initialement, ils n'ont pas formulé un calendrier révisé basé sur les performances passées démontrées de l'entrepreneur. De plus, selon une analyse indépendante du calendrier du bloc 4 réalisée en juillet 2020 par la même société de conseil indépendante mentionnée ci-dessus, les travaux prévus par l'entrepreneur chargé de la cellule sont trop optimistes et ne reflètent pas les performances passées. Par exemple, pour un récent abandon de logiciel, Lockheed Martin n'a réalisé que 64 % du travail prévu et n'a livré que 69 % des fonctionnalités prévues dans les délais. L'étude de juillet 2020 a identifié que la performance de l'entrepreneur à cet égard était conforme à sa performance historique, ce qui signifie que l'entrepreneur fournit constamment moins que la quantité de travail prévue qui devait être achevée. Par conséquent, nous avons constaté que le calendrier restant n'est pas réalisable, car il est fondé sur des hypothèses optimistes quant à la quantité de travail qui peut être achevée et n'est pas ancré dans la réalité. Les responsables du programme ont déclaré que le programme est en train d'examiner la faisabilité de son calendrier et les responsables du DOT&E nous ont dit que le bureau du programme envisage d'établir des délais plus longs pour chaque chute de logiciel, comme les étendre à un an. Cependant, le simple fait d'ajouter du temps au cycle de développement pourrait ne pas répondre entièrement aux défis du programme. En l'absence d'un calendrier de développement logiciel qui reflète la quantité de travail pouvant être accomplie à chaque étape en fonction des performances historiques, le bureau du programme continuera à subir des retards de développement du Bloc 4, et les capacités continueront à être reportées à des versions logicielles ultérieures. Les retards dans le développement et la livraison des capacités augmentent le risque que les capacités soient obsolètes au moment de leur livraison, que les coûts de développement des capacités soient plus élevés et que les capacités soient livrées à la flotte avec des déficiences. En fin de compte, les combattants attendent plus longtemps les capacités dont ils ont besoin pour accomplir leurs missions. En outre, sans une base de référence actualisée pour comparer le calendrier du bloc 4, il sera difficile pour les responsables du programme, les décideurs du ministère de la Défense et le Congrès de comprendre les progrès du programme. Bon DeepL traduit "Software drop" par "Baisse de logiciel" ce serait mieux si c'était "modification de logiciel" mais je n'ai pas corrigé.

Le rayon d'action est corrélé à une autre qualité qui est utile même pour la Suisse: la persistance dans la zone de combat. Le coût unitaire d'achat est en faveur du MiG 35, ça devient moins vrai en LCC (Life cycle cost) du fait du prix de sa maintenance et si tu prend en compte une flotte, la situation se dégrade encore parce qu'il te faudra plus de MiG 35 pour une même quantité d'avions capables de voler du fait de sa disponibilité.

Tiré d'une présentation de Dassault aux Brésiliens: https://translate.google.co.in/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.defesanet.com.br%2Ffx2%2Fnoticia%2F2627%2FF-X2---Apresentacao-Consorcio-Rafale-&edit-text= Comme quoi tout n'est pas égal, l'aérodynamique en particulier.

Bon je ne sais pas si vous avez remarqué mais le prix du développement du Block 4 est de 14,396 milliards de dollar, en comparaison le développement du standard F4 du Rafale qui est l'un des plus ambitieux c'est 1,7 Milliards. Et le délai ! De 2013 jusqu'à 2027:. 14 ans de délai pour un nouveau standard. Cela montre quand même à quel point le standard 3F est incomplet. Et en plus ils ont plus de 60 capacités à livrer, il y en avait 8 pour la première livraison et ils en ont livré une qui rendait le logiciel instable ! Bon je continue demain.

Nous avons constaté que l'estimation des coûts de développement du bloc 4 a augmenté de 3,5 milliards de dollars depuis le rapport du DOD sur le bloc 4 présenté au Congrès en mai 2019. Une partie de cette croissance des coûts est attribuable à l'inclusion des coûts des années précédentes, comme indiqué ci-dessus, et à l'ajout d'une augmentation du calendrier de 2 ans pour achever le programme Block 4. Cependant, plus de la moitié de l'augmentation depuis notre rapport de l'année dernière - 1,9 milliard de dollars - est une croissance nette des coûts dans divers aspects du programme de développement du Bloc 4, comme le montre la Figure 12. La mise à niveau technologique clé reste sur la bonne voie pour une livraison en 2023 Les coûts de la mise à jour technologique 3 (TR-3) - un élément essentiel des capacités du Bloc 4 - continuent d'augmenter, mais cet effort reste sur la bonne voie pour l'insertion dans les avions du lot 15 en 2023. TR-3 est la suite de technologies logicielles et matérielles qui fourniront une capacité de traitement actualisée, des unités d'affichage et une mémoire accrue à l'avion. Les responsables du programme considèrent que TR-3 est un outil essentiel pour les futures capacités du bloc 4 qui devraient être livrées à partir de 2023, car ces capacités ne peuvent pas fonctionner sur le matériel actuel, connu sous le nom de Technology Refresh 2 (TR-2). Les coûts totaux du TR-3 ont augmenté de 48 %, soit 296 millions de dollars, depuis mai 2019. Selon les responsables du programme, l'augmentation des coûts du TR-3 s'explique en grande partie par le fait que son développement est plus complexe que prévu initialement. Alors que les composants du TR-3 seront toujours ajoutés aux avions du lot 15 en 2023, le développement suit actuellement 7 mois plus tard que prévu initialement, selon les responsables du programme. Les responsables du programme ont déclaré avoir acheté 30 kits TR-2 hérités supplémentaires, ce qui atténuera le risque de livraisons tardives et permettra de poursuivre la production et les essais des avions, ce qui a également contribué à l'augmentation globale des coûts. Selon les responsables du programme, ces kits TR-2 peuvent être remplacés par des composants TR-3 avant d'être livrés au gouvernement. Les responsables reconnaissent également que tout nouveau retard dans le développement du TR-3 pourrait entraîner un retard correspondant aux capacités du Bloc 4 qui nécessitent le matériel TR-3. Les autres coûts de modernisation ont généralement augmenté En plus des 14,4 milliards de dollars de coûts du bloc 4 indiqués dans la figure 11, le rapport du bureau du programme au Congrès a indiqué qu'il en coûtera 3,1 milliards de dollars supplémentaires pour le développement d'autres aspects de la modernisation des F-35 qui ne font pas partie du bloc 4. Ces coûts " hors bloc 4 " ont connu une augmentation nette de 1,1 milliard de dollars depuis 2019 et comprennent des augmentations dans des domaines tels que la planification des capacités au-delà du bloc 4, les systèmes de formation pour les capacités futures et le prochain rafraîchissement technologique, appelé TR-4. Parallèlement, un sous-ensemble de ces coûts de modernisation non liés au bloc 4 a diminué au cours de la dernière année. Par exemple, les responsables du programme estiment que les coûts de développement d'ODIN - la réarchitecture du système d'information logistique autonome (ALIS) - seront inférieurs de 5 millions de dollars aux prévisions en 2019, bien que cette estimation puisse changer à l'avenir. Plus précisément, selon les responsables du programme, ils ont défini les exigences d'ODIN en septembre 2020 et devront donc réévaluer les coûts estimés d'ODIN. Le calendrier de développement du bloc 4, tel que prévu, n'est pas réalisable Le programme F-35 en est à plus de trois ans de développement du bloc 4, mais il n'a pas livré de nouvelles capacités comme prévu. En outre, le calendrier de développement restant, tel qu'il est prévu, n'est pas fondé sur les données les plus récentes disponibles et n'est pas réalisable. Dans le cadre de l'approche de développement C2D2, le bureau du programme F-35 prévoit de développer, de tester et de livrer progressivement de plus petits groupes de capacités à la flotte de F-35 - des avions livrés qui opèrent dans le monde entier - tous les six mois. La figure 13 représente une représentation théorique de la manière dont le processus de développement et de test du C2D2 est censé fonctionner pour chaque livraison de logiciel tous les six mois. Comme on peut le voir sur la figure 13, Lockheed Martin est censé développer séquentiellement quatre incréments logiciels en vue de chaque lancement de logiciel tous les six mois. Ces incréments sont destinés à affiner et à développer davantage les capacités au fil du temps, à mesure que chacun est testé par la flotte d'essai de développement. Les pilotes d'essai identifient les déficiences potentielles dans chaque incrément et les signalent à l'entrepreneur et au bureau du programme afin que les défauts puissent être corrigés dans l'incrément suivant. Selon le bureau du programme, chaque incrément séquentiel a un objectif spécifique, généralement décrit comme suit : L'incrément 1 doit contenir toutes les nouvelles capacités pour le largage de logiciels afin que les tests initiaux puissent se dérouler comme prévu ; L'incrément 2 doit remédier aux déficiences identifiées lors des tests de l'incrément 1 et faire mûrir les capacités si nécessaire ; L'incrément 3 doit remédier aux déficiences identifiées lors des tests de l'incrément 2 et faire mûrir les capacités si nécessaire ; et L'incrément 4 doit être une version prête pour la production du largage de logiciels de 6 mois, les capacités doivent être mûres et des corrections substantielles ne doivent pas être nécessaires avant la finalisation du logiciel pour sa diffusion dans la flotte de F-35.

Le programme poursuit ses efforts pour remplacer les fournisseurs turcs Le programme continue de relever les défis des fournisseurs associés au retrait de la Turquie de la chaîne d'approvisionnement et a identifié des fournisseurs pour 1 005 pièces produites en Turquie. En juillet 2019, le DOD a retiré la Turquie du programme F-35 et le sous-secrétaire à la Défense pour l'acquisition et le maintien en puissance a ordonné au programme F-35 d'établir des sources alternatives et de cesser de passer des commandes auprès des fournisseurs turcs mars 2020. Nous avons signalé en mai 2020 que le retrait de la Turquie du programme F-35 était susceptible d'aggraver les problèmes existants de la chaîne d'approvisionnement.33 Pour atténuer ces préoccupations, le sous-secrétaire à la Défense pour l'acquisition et le maintien en puissance a déclaré que le programme F-35 est autorisé à continuer d'accepter la livraison de pièces provenant de fournisseurs turcs jusqu'à la fin des livraisons du lot 14 (prévues jusqu'en 2022). En décembre 2020, le programme avait identifié des fournisseurs alternatifs pour les 1 005 pièces. En outre, les responsables du programme ont déclaré que 95 % des pièces d'aéronef et 76 % des pièces de propulsion sont qualifiées à partir des nouvelles sources et que le reste se trouve à différents stades du processus de qualification. Le programme estime qu'il en coûtera 108 millions de dollars pour établir des fournisseurs alternatifs, mais n'a pas négocié ces coûts avec eux et ne sait donc pas encore quel sera l'impact sur les coûts des pièces produites. La fiabilité et la maintenabilité des F-35 s'améliorent mais les objectifs ne sont pas tous atteints Nous avons constaté que les performances en matière de fiabilité et de maintenabilité des F-35 se sont améliorées depuis notre rapport de mai 2020, mais que le programme n'atteint pas encore tous ses objectifs de performance. Les objectifs de fiabilité et de maintenabilité définissent des objectifs quantitatifs spécifiques visant à garantir qu'un avion sera disponible pour les opérations plutôt que d'être mis hors service pour la maintenance. L'année dernière, nous avons signalé que le programme atteignait 10 de ses 24 objectifs de fiabilité et de maintenabilité.35 En juin 2020, les mesures les plus récentes disponibles, le programme atteignait ou était sur le point d'atteindre 17 de ses 24 objectifs. Par exemple, le F-35A est passé d'une situation où il n'atteignait pas son objectif de fiabilité de la mission, qui mesure la probabilité de mener à bien une mission de durée moyenne, à une situation où il a atteint cet objectif à certains moments cette année. Pour plus de détails sur la performance en matière de fiabilité et de maintenabilité, voir l'annexe IV. Les responsables du programme attribuent l'amélioration du respect de sept autres paramètres de fiabilité et de maintenabilité en 2020 à leurs efforts pour financer et mettre en œuvre des projets d'amélioration de la fiabilité au cours de l'année dernière. Les responsables du programme ont déclaré qu'ils ont augmenté le financement de 7 millions de dollars en 2019 à 40 millions de dollars en 2020 et ont mis en œuvre 51 nouveaux projets d'amélioration de la fiabilité et de la maintenabilité. Par exemple, un nouveau projet vise à développer un nouveau revêtement de voilure pour éviter les problèmes de délamination qui, selon les responsables du programme, ont été l'un des plus grands facteurs de baisse de performance en matière de fiabilité et de maintenabilité. Voir l'annexe III pour plus de détails sur le délaminage du revêtement de la verrière. Bien que le programme n'atteigne toujours pas sept de ses 24 objectifs de fiabilité et de maintenabilité, les améliorations mesurables de ces objectifs peuvent prendre du temps à se manifester. Par exemple, les aéronefs mis en service doivent être modifiés et voler pendant de nombreuses heures avant que le programme puisse mesurer les améliorations. Dans notre rapport de mai 2020, nous avons recommandé que le Bureau du Secrétaire à la Défense rende compte au Congrès des risques liés à la fiabilité et à la maintenabilité.37 En réponse à notre recommandation, les responsables du DOD ont déclaré que le programme F-35 fournit des mises à jour au Defense Acquisition Executive via un Interim Program Review Defense Acquisition Board sur l'état des mesures de fiabilité et de maintenabilité de Lockheed Martin. Les estimations des coûts de modernisation augmentent et le calendrier restant, tel que prévu, n'est pas réalisable Nous avons constaté que le programme F-35 en est maintenant à trois ans de développement du bloc 4 de modernisation et que le programme continue de connaître des augmentations de coûts et une expansion du calendrier. Les coûts ont continué d'augmenter en 2020 en raison de retards dans le calendrier et de difficultés à développer certaines technologies, entre autres. En 2020, le programme a ajouté une année à son calendrier du bloc 4 et prévoit maintenant de prolonger le développement du bloc 4 jusqu'à l'exercice 2027. Nous avons toutefois constaté que le bureau du programme n'a pas formulé son calendrier révisé en fonction des performances passées démontrées de l'entrepreneur. Au lieu de cela, le calendrier est basé sur des estimations formulées au début de l'effort du bloc 4, ce qui augmente la probabilité que la date d'achèvement prévue de 2027 ne soit pas réalisable. Les estimations du coût de développement du bloc 4 continuent d'augmenter et le calendrier continue de s'allonger Le coût estimé du développement du bloc 4 a augmenté et le calendrier s'est étendu chaque année depuis que le programme a commencé l'effort de développement en 2018. Plus précisément, pour 2020, le total des coûts déclarés du bloc 4 a augmenté pour refléter les nouveaux coûts de développement. En outre, les coûts rapportés reflètent désormais les données de coûts pour toutes les années de développement du bloc 4, au lieu des estimations de coûts plus limitées sur 7 ans que le DOD avait précédemment rapportées au Congrès. Par exemple, en 2018, le DOD a signalé que le développement du bloc 4 coûterait 10,6 milliards de dollars pour les années fiscales 2018 à 2024. En septembre 2020, le DOD a signalé au Congrès que tous les coûts du bloc 4 devraient dépasser 14 milliards de dollars, couvrant les années fiscales 2013 à 2027. Cette décision de changer la façon dont les coûts sont rapportés découle des efforts du DOD pour répondre à notre recommandation d'améliorer la transparence des coûts totaux associés au développement du bloc 4.38 Plus précisément, en mai 2020, nous avons constaté que les rapports du bloc 4 du DOD au Congrès, requis par la section 224 de la NDAA pour l'année fiscale 2017, ne représentaient pas entièrement les coûts totaux estimés du développement du bloc 4. Le DOD a concentré ses rapports sur les coûts du bloc 4 sur le programme de défense de l'année future et a exclu les coûts précédemment encourus et tous les coûts qui devraient être encourus après une période de 7 ans. Par exemple, en mai 2019, le DOD a signalé au Congrès que le bloc 4 coûterait 10,85 milliards de dollars des années fiscales 2019 à 2025. Cependant, nous avons identifié que des coûts avaient été engagés avant l'année fiscale 2019 et qu'il avait prévu de poursuivre le développement du bloc 4 jusqu'en 2026. En mai 2020, nous avons recommandé au bureau du programme de fournir une perspective plus globale des coûts totaux de développement du bloc 4 afin de fournir au Congrès une meilleure supervision des coûts du bloc 4.40 En réponse à notre recommandation, le programme F-35 a commencé à inclure les coûts des années précédentes et les estimations des coûts futurs dans son rapport sur le bloc 4. Par conséquent, dans son rapport sur le bloc 4 présenté au Congrès en septembre 2020, le coût total du programme de 14,4 milliards de dollars reflète non seulement les coûts engagés précédemment, mais aussi les trois années supplémentaires de développement du bloc 4. La figure 11 montre l'augmentation des délais de développement du bloc 4 et des coûts estimés.

Etant plus lourd il a besoin d'un moteur plus puissant, il n'y a pas de miracle.

Le seul point de comparaison est le Ferry Range sinon ils ont toujours des configurations différentes: SH F-18 : 3330 Km Rafale : 3700 Km Sinon pour comparer un peu plus SH F-18 : Autonomie 2346 Km avec 2 Aim-9; combat Range: 723 Km pour une mission d'Interdiction (c'est l'effet aérodynamique de skieur en chasse neige) Rafale : Combat Range : 1850 km avec 3 bidons, 2 Scalp et deux Mica et en pénétration c'est à dire à basse altitude où tu consomme beaucoup plus. On n'est pas dans les ordres de grandeur là 40 % ça fait à peu près 4 t quand même! Cela peut justifier qu'il ne tire que 7.5 G contre 11.5 pour le Rafale.

Tout le monde n'est pas Dassault, et en plus ils ont modifié un avion existant, ça ne peut pas être optimum.

Il peut emporter 8050 Kg et le Rafale 9500 Kg. Joli avatar

Parce qu'il a une aérodynamique de skieur en chasse neige? qu'il est 40% plus lourd qu'un Rafale pour des performances inférieures?

Oui, de toute façon j'avais calculé que même en mode "surge" pour pouvoir maintenir 10 avions en l'air il fallait au moins 20 avions et si tu compte un peu d'attrition 25 serait mieux disons 30 comme minimum raisonnable. D'un autre coté si ils ne peuvent faire que 2 semaines avec 1.6 Milliards de munitions c'est qu'il leur en faut 2.4 milliards ce qui enlève 8 avions. Comme ma proposition était de 43 avions avec PBL je passe à 35. J'ai donc "pas plus de 35" et "pas moins de 30" donc je viserais 33. Ce qui montre d'ailleurs que les 36 de l'Inde ne sont pas si déconnant que ça, si ils achetaient les armements qui vont avec. Ah,...et puis nous aussi on n'a pas assez d'armements par rapport au nombre d'avions qu'on a.

Un petit calcul pour illustrer mon propos précédant: Si je me réfère au contrat Indien pour définir la proportion d'armes normale, après avoir enlevé les ISE et la rénovation des bases (qui est réalisée par les finlandais) je trouve 6 Milliards pour les avions pour 1.6 milliards pour les armes (sur une base de 64 avions). Si on inverse les proportions on aura que 17 avions qui en mode surge auront une activité équivalente à 17*350*12/250 = 285 avions utilisés normalement et des munitions pour 64*6/1.6= 240 avions utilisés normalement. Cela risque d'avoir de meilleurs effets que la proportion normale.

D'ailleurs il y a sans doute une optimisation à faire là: Avec moins d'avions, mais qui sont plus disponibles, tu peux acheter plus de munitions. C'est d'autant plus vrai que tu t'autorise à utiliser tes avions en "surge" (350 h par mois).