Les dérives du programme F35, cas d’école

A l’instar du Concorde en son temps, de l’ #Eurofighter, l’ #A400M Atlas ou le #NH90, le #F35 se fait « aligner » pour ses sur-coûts et ses retards… Mais qu’en est-il au juste ?

Je ne prétends pas ici faire une thèse complète et exhaustive (je laisse ce rôles aux personnes en charge du programme F35, aux chercheurs et autres théoriciens, ou encore aux journalistes si tant est que tous restent impartiaux dans leurs approches).

En revanche, j’affirme exposer ici le fil directeur (qui en soit trouve déjà sa réponse dans la seule intorduction de cet article) :

La problématique « Qualité / Coût / Délai » est pourtant bien connue (au même titre que son pendant « Force / Intelligence / Capacité Financière ») et je m’étonne donc de voir des rapports s’attardant sur les difficultés de développement du programme et non les causes racines.

Un axe supplémentaire de complexité se porte à la puissance

C’est pourtant un problème bien connu de la Gestion de Projet (en particulier des développeurs informatiques) et la recherche combinatoire :

Lorsque vous apporter un axe (ou degré) supplémentaire de complexité, cela ne se pose pas par une multiplication, mais le nombre de dimensions se porte à la puissance (pour imager, une droite a 2^1 points, un carré 2^2, un cube 2^3…).

A ce titre, je rappelle que la maitrise de ce risque peut être réduite en établissant des interactions fortes et en menant une "petite étude" en s'appuyant sur les travaux de Taguchi sur les plans d'expérience (je rappelle que les outils japonais en matière d'Excellence Industrielle, sont des concepts et principes génériques flexibles et et ouverts, non limités à un usage restreint... même si cela est parfois difficilement compréhensible dans la culture occidentale).

Le problème du F35 n’est pas différent de celui de l’Eurofighter ou du NH90. Il souffre néanmoins du fait d’être plus ambitieux (sur les différents axes, qu’ils soient au niveau de la complexité technologique « Next Gen » ou de la coopération et l’interopérabilité).

… Et vous verrez d’ailleurs qu’en soi, dans le principe de cette approche dimensionnelle, il n’est pas différent du Rafale…

Alors qu’en est-il ?

Comme je l’exposais, toute la problématique réside dans le nombre d’axes (ou dimensions) de développements :

Sans sombrer sans les détails (là encore, je ne rédige pas là un dossier d’audit de risques)…

Prenons le cas du #Rafale :

  • Un seul industriel majeur (pas de Workshare)
  • Un seul pays client (lors du développement du produit, les développements ultérieurs, étant souvent des « greffes »)
  • Plusieurs versions (basiquement, Air / Navalisée)
  • Nouvelles technologies (je résume ici sous un seul axe, mais dans certains cas, cela se traduit en plusieurs axes, ce qui est maintement généralement le cas du fait des complexités apportées par l’électronique)
  • Multirôle [ou « omnirôle », pour reprendre le terme cher à Dassault] (capacité d’un même produit à être utilisés pour différents types de missions)

Nous avons donc 3 axes de complexité (versions, technologies, multi-rôle), qui sont donc chacun source de risques de sur-coûts et retards (en soit, les retards sont des sur-coûts masqués).

Certes, ils ne représentent pas tous le même niveau de risque...
Là encore, le QFD apporte une solution pour mesurer l'importance de chacun, ainsi que le niveau d'interactions, ces paramètres pouvant ensuite être transcrits dans la méthode de Taguchi.

Le F35 a parfois été comparé au F16, c’est une aberration !

Autre cas en passant, le #F16 :

Le F35 a parfois été comparé au F16 (dans le sens qu’il se voulait « le nouveau programme US à succès international »), c’est une aberration !

Le F16 doit son succès justement au fait qu’il comportait peu d’axes de forte complexité dans son programme d’origine :

  • Au départ, ce n’est pas un appareil multi-rôle (cela s’est fait au gré de son évolution)
  • … Il n’est pas (du moins peu) multi-version (là encore, par exemple, les versions C/D ont été lancées une fois les vesions « originelles » A/B stabilisées
  • Un seul industriel principal
  • Des avancées technologiques (mais pas encore dans l’ère électronique)
  • Plusieurs clients (il est toujours plus difficile de négocier tout cahier des charges et autres problèmes de dérive de programme avec plusieurs clients)

Dans le cas du F16, son succès universel s’est fait au fil du temps. En « rajoutant » des axes (ou en les développant) de manière successives, cela à l’avantage qu’ils s’appuient sur un tronc commun (la base « originelle ») stabilisé.

Ces complexifications sont ainsi des évolutions, comparables à des « greffes », dont soit la non-faisabilité est connue d’avance (d’où certains refus de développements à l’export de certains F16 ou F18), soit le risque de dérive est supporté de manière indépendante par cette seule verion, ce qui ne met pas en péril ni les versions précédemment stabilisées, ni les autres versions potentielles.

Et le F35 ?

  • Programme en coopération industrielle (partenariat)
  • Plusieurs clients (ce qui tend par ailleurs à vouloir sous-estimer le coût et les risques afin d’assurer les signatures de commandes)
  • Plusieurs versions
  • Multirôle
  • Fortes avancées technologiques « mécaniques »
  • Fortes avancées technologiques « soft » (électronique / informatique embarquée)

Ces dérives sont en majorité imputables à une mauvaise maitrise du projet du fait d’un niveau de complexité trop important, du moins mal évalué.

Ces dérives sont en majorité imputables à une mauvaise maitrise du projet du fait d’un niveau de complexité trop important, du moins mal évalué.

J’enfonce une porte ouverte ? Et pourtant :

Il n’est alors pas admissible que cette complexité (et cela est valable pour d’autres programmes cités en préambule) est été sous-estimée (voire négligée ou même parfois omise), non maitrisée et qu’aucun plan correctif ne se soit véritablement attaqué à ces causes racines, faisant les « singes de la sagesse » en contournant là encore le problème en s’attelant à corriger (« bricoler ») les conséquences de ces causes ; en d’autres terme, à faire du « cache-misère » ! (car, oui : agir sur les conséquences et non les causes, c’est faire du cache-misère)

Il existe de nombreuses « solutions » pour réduire (et/ou simuler un effet de réduction [ou « rationnaliser »]) le nombre d’axes de complexité :

  • En premier lieu, il existe des techniques de conduite de projets permettant cela (il s’agit généralement de solutions jugées « impures » et utilisées pour conduire les projets à « délai urgent »)
  • Il est important d’échelonner tous les axes qui peuvent l’être, et ainsi les « transformer » en évolutions et non plus en axe de complexité originelle, afin de minimiser le risque exponentiel de complexité (je rappelle que, le dimensionnement se mettant en puissance, chaque dimension supplémentaire a un effet exponentiel).

Typiquement, de mon propre avis, c'est ainsi que devraient être gérés la plupart des Exports, en particuliers les clients "mineurs" ou "suiveurs", comme peuvent l'être les Pays-Bas et qui ont, dans le cas par exemple de l'A400M, été source de nombreuses complexités technologiques à comparer de leurs apports (financiers, géo-stratégiques...).

  • Cibler et maitriser les axes à forts risques (cf. QFD + Tagushi + autres outils : 5M, 5 Pourquoi…)
  • « Think Globally, Act Locally » : Le programme est certes pensé de manière global mais peut généralement être sub-diviser en sous-parties (là encore, le QFD et Tagushi, entre autres, peuvent aider à déterminer ces sous-projets).

Attention : ces sous-projets, même s'ils agissent "localement", doivent continuer à penser de manière "globale"

  • « Standardiser » ne veut pas dire « universel » ou « omnirole », mais « communalité » et « interchangeabilité » ! Il convient de choisir le juste milieu entre un équipement capable de satisfaire à tous les besoins et un équipement remplacé selon le besoin (principe des « kits de modularité » … ou « orienté objet »)

Définition : la Standardisation est la recherche du juste (ou « meilleur », selon les définitions) consensus d’une mise en application commune. C’est la recherche d’une amélioration de la communalité.
Ainsi, par exemple, un même Rafale n'embarquera pas les mêmes armements selon la mission... (pensez "global": il convient parfois, pour décomplexifier un sous-système, d'appliquer ce principe à d'autres équipements que les seuls armements)Prenons l'exemple très explicit du pilote : pilote multi-rôle ou pilotes spécialisés ? ... Il convient aux Forces d'estimer quelle est la solution la plus efficiente selon les criticités retenues.

La Standardisation est la recherche du juste/meilleur consensus d’une mise en application commune.

Espérons que des leçons seront tirées (tant par les industriels, que par l’interventionisme [souvent trop important] des clients et venant complexifier le cahier des charges) pour les programmes coopératifs futurs tels que le drone MALE ou encore le FTH…

Julien Maire

Spécialisé dans l'amélioration et la coordination industrielle, avec plus de 15 ans dans le secteur aéronautique & défense.

Vous aimerez aussi...

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *