Le JSF, du spectre de l’échec aux questions fondamentales

Bloc-Notes

   Forum

Un commentaire est associé à cet article. Vous pouvez le consulter et réagir à votre tour.

   Imprimer

 423

Selon une chronologie que nous serions tentés de ne pas juger fortuite ni due au hasard, un jour après que nous ayons publié (le 25 mars 2010) des remarques (russes et chinoises) sur des appréciations fondamentales sur la catastrophe du JSF, paraît un autre texte dans le même sens d’une appréciation fondamentale. Il s’agit d’une présentation commentée de Graham Warwick, sur le blog bien connu Ares, de Aviationweek.com, ce 26 mars 2010, de documents publiés par la DARPA. Cet ’organisme (agence) de recherches fondamentales appliquées des questions technologiques des armements dépend bien entendu du Pentagone.

Voici la présentation qu’en fait Warwick, avant de développer plus en détails les observations de la DARPA, notamment avec une présentation d’une méthodologie nouvelle pour la production d’avions de combat. Cette méthodologie, par le fait même, met fondamentalement en question, et le JSF, et les méthodes de développement du JSF.

«Is complexity to blame for the F-35's development delays and cost increases? Or, more precisely, is an aerospace-industry design process that has failed to adapt to the increasing complexity of weapon systems to blame?

»The Defense Advanced Research Projects Agency thinks so, and has produced an interesting chart to illustrate its point. The chart plots product complexity against development time for three industries: integrated circuits, automobiles and aerospace vehicles.

»Integrated-circuit makers have held development times steady even as chips have soared in complexity. Car manufacturers have actually reduced their development timespans. Only the aerospace industry, according to the chart, has seen development time (and cost) increase in lockstep with product complexity.

»DARPA defines complexity as parts count plus lines of software code, which it admits is an imperfect metric. But if you look at the F-35, it works. Once seen as the low end of a hi-lo fighter mix with the F-22, the F-35 is actually a far more complex vehicle: three versions and 6 million lines of avionics software (19 million in the complete system) compared with one model and 1.7 million lines for the F-22.

»DARPA blames the systems engineering process the aerospace industry has used for the past 40 years…»

Notre commentaire

@PAYANT On observera effectivement que les principes des réflexion de la DARPA sont lourds de sens pour le programme JSF. Elles reviennent à proposer le verdict que le programme JSF est développé selon une méthode qui est fautive, viciée et, par conséquent, reviennent à implicitement à admettre que le programme JSF peut désormais être considéré comme un échec, justifiant l’appréciation du programme que nous faisons de plus en plus souvent comme celle de la “catastrophe JSF”. Concrètement, elles ajoutent un peu plus d’eau au moulin fonctionnant de plus en plus puissamment, qui considère le JSF non comme un programme difficile, marqué de nombreux revers, mais bien comme un programme condamné dont l’abandon commencerait à devenir une option qu'il faudrait envisager sérieusement.

Pour autant, nous pensons que l’approche de la DARPA est, pour le moins, tronquée et critiquable. Elle revient à dire que le JSF est “trop compliqué” au niveau des ambitions de performances et de de la gestion, et qu’il faut rechercher des méthodes plus simples. Les exemples a contrario, de domaines où le progrès “marche” par opposition au programme JSF, sont contestables. L’industrie automobile, si elle progresse et produit effectivement des modèles qui “fonctionnent”, commence à rencontrer des obstacles importants, avec des exemples de plus en plus nombreux de blocages dus à des éléments technologiques, parfois même des pannes concernant un modèle qu’on pourrait qualifier de systémiques, devant lesquelles les constructeurs se trouvent en grandes difficultés, sinon impuissants.

Là où la DARPA accuse une méthode, c’est-à-dire un travers bureaucratique, nous serions sans aucun doute tentés d’ajouter de façon beaucoup plus fondamentale un autre accusé, qui est le domaine de la technologie elle-même, – ou le “technologisme”, selon notre jargon. Si le domaine de l’aéronautique, et surtout de l’aéronautique de combat, est le plus touché, ce n’est pas à notre sens à cause de spécificité bureaucratique et technologique propres, mais parce qu’il est par excellence le domaine confronté aux conditions les plus exigeantes de la réalité physique du monde. L’avion se déplace très vite, dans toutes les dimensions de l’espace, dans des conditions d’emploi extrême. Son avance incontestable à cet égard n’est pas l’exception qui confirme la règle mais bien l’exemple le plus avancé de ce qui attend le technologisme confronté aux conditions naturelles du monde. En cela, et tenant compte de la complexité grandissante et ultra-rapide du technologisme, il ne fait que précéder des problèmes qui vont devenir généraux. Plus la technologie avancera très vite, plus sa complexité d’emploi sera très grande même dans les conditions moins contraignantes qu’affrontent les autres domaines cités.

La DARPA n’examine que la méthodologie de développement du JSF. Elle ne met nulle part en question l’avancement du technologisme, – c’est-à-dire le Progrès lui-même. On comprend aisément cette démarche, mais on la comprend avec une réelle suspicion: la DARPA vit pour et par le progrès technologique et il serait surprenant qu’elle mette en cause sa raison d’être. Il nous semble donc qu’elle confond la cause et la conséquence. La méthodologie du développement du JSF est, dit la DARPA, la cause de la catastrophe, alors que nous serions inclinés à penser qu’elle n’en est que la conséquence. Même si l’on veut faire un nouveau JSF, un autre JSF “moins compliqué” à la place de l’actuelle catastrophe, à supposer d’ailleurs que la pieuvre bureaucratique du Pentagone accepte cette idée, cette moindre complication sera néanmoins basée sur des technologies de progrès, des technologies avançant à une rapidité exceptionnelle qui est celle du rythme de notre progrès et, à notre sens, le JSF “moins compliqué” sera confronté à de nouveaux problèmes qui lui seront propres, qui s’avéreront peut-être, sans doute, tout aussi insolubles.

Personne n’a encore identifié les véritables causes de la “catastrophe JSF”. Avancer que c’est sa “complication” qui est cette cause est une hypothèse, certes, mais rien ne prouve qu’elle soit la bonne. Il n’y a pas que le JSF qui rencontre des difficultés. Les obstacles qu’on constate dans ce programme sont catastrophiques parce que ce programme est immense et qu’il est en soi un enjeu absolu, ce qui implique que des forces bureaucratiques, industrielles, politiques, voire idéologiques jouent également leur rôle dans les pressions qui pèsent sur lui. Mais le problème fondamental posé par l’intégration des technologies alors que la progression de ces technologies est d’une rapidité foudroyante, jusqu’à des situations de blocage de plus en plus nombreuses, est un problème qui se pose à tous les constructeurs aéronautiques et qui n’épargne pas d’autres domaines que l’aéronautique, de plus en plus nombreux. Observer cela, c’est envisager que le véritable sens de la “catastrophe JSF”, en plus de ces dimensions économiques et bureaucratiques, touche à la validité même du progrès et, par conséquent, à la question fondamentale de son sens, c’est-à-dire de son éventuel échec. Ce n’est plus une question de gestion, d’économie, voire de bureaucratie. C’est, comme nous le disons de plus en plus souvent, la question même de notre civilisation.

Le constat objectif que nous pouvons proposer pour conclure est que, dans ce domaine de la réalisation des problèmes fondamentaux qui commencent à caractériser le programme JSF, les choses, là aussi, progressent vite.


`

Mis en ligne le 27 mars 2010 à 06H49