L’industrie des hélicoptères s’inscrit dans un temps assez long, particulièrement pour les programmes d’appareils militaires dont le développement suit des contraintes spécifiques par rapport au civil. Dans la Défense, les fonctions sont livrées graduellement et non en une seule fois, comme l’exigerait un appareil commercial. Les moyens ne sont pas nécessairement disponibles dans une première version, les systèmes d’arme évoluent sans cesse et leurs interfaces avec l’hélicoptère doivent évoluer en parallèle. La conception des appareils doit donc prendre en compte l’étagement des livraisons, elle doit intégrer des conditions de compensation (offset) dans la mesure où les clients, des nations, imposent des retours en termes d’emplois et de transferts de technologie. À la moitié d’un cycle opérationnel, qui dure entre trente et quarante ans, donc environ quinze ans après la mise en service, l’appareil doit être complètement remis à niveau, ce qui oblige à le démonter entièrement. Les aspects réglementaires, parmi lesquels on trouve les impacts environnementaux de l’usage des peintures ou des rayonnements radioactifs (même très faibles), doivent être anticipés et couvrir les phases de production, d’exploitation et de maintenance. Un autre exemple est le contrôle de la prolifération des armements qui, pour salutaire qu’il soit, ne supprime pas les besoins des armées. Toutes ces nécessités se retrouvent au moment de la conception, d’où l’importance d’en maîtriser et d’en améliorer les processus ; elles montrent en quoi les aéronefs doivent être pensés dans la durée.

1. Avant Phenix, quelques repères chronologiques

Retraçons brièvement l’histoire du Tigre, un programme militaire, dont les origines remontent aux années 1970. En 1975, le président Giscard d’Estaing lance une phase d’exploration d’un hélicoptère militaire, le Super-Puma1. Cette décision est prise à un moment où la division Hélicoptères de la snias, dirigée par François Legrand, produit des Alouette-II et III, Gazelle, Puma et Super-Frelon.

Le 18 septembre 1985, Aérospatiale et mbb créent la société Eurocopter et le 13 novembre 1987, un accord franco-allemand est conclu pour deux versions d’hélicoptère : le hap (Hélicoptère appui protection) à destination des Français et le hac (Hélicoptère appui combat) à destination des Allemands.

En 1993, une tension apparaît avec l’Allemagne, qui ne souhaite plus continuer avec le hac. Celui-ci avait été conçu dans le cadre de la guerre froide. La chute du mur de Berlin changeait évidemment la donne et les besoins. Une nouvelle ingénierie commence qui se traduit par la définition de l’uht (UnterstützungsHubschrauber Tiger).

En 1992, s’ajoute un contrat de développement du NH90. Ce deuxième programme est à mener en parallèle du Tigre, dont le premier vol a lieu le 27 avril 1991 à Marignane. Le 16 janvier 1992 est créé Eurocopter SA.

L’industrialisation du Tigre commence en 1996 et la qualification commence en 2000 pour s’étendre logiquement jusqu’en 2002. Alors que les travaux battent leur plein, en 2001, un contrat est signé avec l’Australie. La même année la première version opérationnelle du Tigre est livrée à l’armée française.

En 2005, un autre est signé avec l’Espagne. Dans ce cas comme dans celui de l’Australie, l’exigence d’assemblage est négociée avec le contrat.

La mise en place d’un plm commun, même sur le seul périmètre des hélicoptères, n’est pas simple. Il y a la pression liée aux commandes. Il y a les demandes des clients qui conduisent à des modifications profondes des appareils, ce qui signifie des charges importantes en ingénierie, ce qui n’est pas vraiment compatible avec la prise de recul nécessaire à une modélisation globale. Parmi les facteurs de complexité, les activités de bureau d’études sont dispersées en France, en Allemagne, en Australie ; en ajoutant l’Espagne, dans quatre pays se déroulent les essais en vol, les chaînes d’assemblage et les livraisons des machines. On a donc quatre centres, quatre chaînes. S’il existe un centre de formation commun dans le Var, les données des produits sont soumises à de grosses contraintes d’accès pour des raisons de confidentialité. Les données sont soumises à des ségrégations sévères pour éviter qu’elles ne soient lisibles par d’autres que les propriétaires des appareils. Et ce d’autant plus que le Tigre est co-développé dans deux pays et dispose de moyens d’essais et de support dans quatre.

La configuration vendue aux Espagnols étant plus performante, la volonté s’est manifestée en France de faire évoluer les produits pour qu’ils atteignent le même niveau. Mais à ce moment-là, les contrats export arrivent en phase de qualification pour les machines françaises. Cette phase est critique pour le programme hap qui avait servi de base à la version espagnole.

2. Un programme attendu

Comme l’ensemble des produits aéronautiques, un hélicoptère est à la fois l’aéronef proprement dit, ce qui vole, mais aussi l’outillage nécessaire à la fabrication, le logiciel embarqué qui contribue à la navigabilité, le manuel de vol et les manuels de formation des pilotes, la documentation technique sans laquelle la maintenance est impossible, la liste des pièces de rechange et sans doute bien d’autres aspects. Derrière la notion de produit coexiste donc une variété de composantes qui demande à être suivies tout au long du cycle de vie du produit. Encore faut-il s’entendre sur la définition du cycle de vie : commence-t-il avec la sortie du bureau d’étude, de la production, avec la fin des essais en vol ? Ces deux exemples situent à grands traits ce sur quoi les divisions ont dû se concerter préalablement à toute démarche d’harmonisation. Il s’agissait en effet de se situer sur un périmètre commun. Il convient d’ajouter d’autres aspects à la mise en accord préalable. Quel devrait être la place de la maquette numérique ? Et à quel point serait forte la volonté d’utiliser les données en amont de la maquette de façon fluide pour éviter les ressaisies, sources d’erreur, pour assurer la continuité de l’information ? De plus, le modèle de données (mpd), qui potentiellement intègre tous les métiers de la conception et peut devenir de ce fait d’une complexité ingérable, se devait d’être tronçonné. Du côté des produits logiciels, des limites à Phenix ont été positionnées avec ce qui a été nommé backbone et qui comprenait les outils génériques des ingénieurs des bureaux d’étude. Celui-ci est resté à l’extérieur de la démarche. Il n’était pas question de rediscuter de l’environnement de travail en cours, dans lequel par exemple se trouvaient Catia v5 ou d’autres logiciels dont l’usage n’était remis en cause par personne. On a aussi exclu ce qui concerne les niveaux de maturité des composants ainsi que les méthodes de résolution de la configuration qui sont trop intimement liés au contexte industriel. Les façons d’appliquer les modifications sont en effet très liées aux processus de production.

Au moment du démarrage de Phenix, Eurocopter a acquis une expérience significative des échanges de données de configuration entre la France et l’Allemagne. Pour ma part, j’y travaillais depuis au moins dix ans. Des travaux d’harmonisation étaient menés dans la gestion des spécifications, de la cfao avec les migrations successives des versions de Catia. Les méthodologies changent pour nous adapter à la 3D, tout en sachant que, lorsqu’elle s’impose par rapport à la 2D, les trois quarts des machines sont conçues avec des plans. La division Hélicoptères, en France, hérite des méthodes et outils de l’Aérospatiale, alors que l’Allemagne hérite de la gestion de configuration du Tornado. Avec le passage à l’an 2000 et les problèmes d’audit technique pointus qu’il a demandé pour vérifier que les systèmes étaient compatibles avec un passage à 00 des années codées sur deux chiffres, les Allemands sont passés à sap qui se trouve utilisé bien au-delà de son périmètre standard. Surtout, il n’est pas utilisé en France pour la gestion des plans, ce qui rend les échanges un peu délicats. Ainsi, seuls des transferts sont mis en place. Aucun alignement métier n’est recherché. Le fait que la gestion de configuration ne soit pas homogène alourdit la gestion des modifications, lesquelles sont nécessaires et importantes. Par exemple, si une armée souhaite disposer d’un radar différent de celui proposé, ou d’un missile x plutôt que du missile y, ce sont les interfaces avec l’hélicoptère qui doivent être spécifiées à nouveau, ce qui se fait d’autant plus aisément que la gestion de configuration l’a prévu dès le début.

Eurocopter est donc dans un contexte de systèmes d’information très hétérogènes qui génèrent des flux de documents papier, des flux de données de dmu… Avec la complexité croissante des produits, les volumes deviennent gigantesques, ce qui réclame des équipes dédiées et de lourds contrôles d’intégrité des données. Eurocopter gère trois gros programmes, à savoir l’EC175, le NH90, le Tigre australien2, qui chacun à sa manière pose des questions délicates de partage d’information. L’EC1753 est un hélicoptère civil résultant d’un partenariat avec la Chine ; le NH90 est un hélicoptère militaire fruit d’une coopération entre Eurocopter et l’italien AgustaWestland4 tandis que le Tigre australien est une déclinaison du programme franco-allemand dont la commande passée en 2001 concerne une version dite arh (Armed Reconnaissance Helicopter). Ces trois programmes s’appuient sur des coopérations poussées qui réclament des partages d’outils et de méthodes. Mais jusqu’où aller ? Jusqu’où distribuer les charges de conception sans distribuer la totalité de la conception, la totalité des savoir-faire ? Car les partenaires sont aussi des rivaux présents ou futurs, comme la Chine, dont on sait qu’elle travaille à des offres concurrentes. En 2006, on partage une dizaine de procédures de gestion de configuration, une quarantaine de procédures de gestion de données techniques. Pour situer la taille du domaine d’application, il faut se souvenir qu’un hélicoptère représente plus de 1,2 million de pièces et que 10 000 nouvelles pièces sont créées chaque année. On comprend toute la criticité de la nomenclature technique et des manipulations opérées sur elle. Or ce sont plus de 4 000 modifications qui sont à instruire pour l’ensemble des programmes, avec ce que cela suppose en études de faisabilité, d’impacts et d’implémentation. Les 12 000 appareils en vol nécessitent plus de 500 000 pièces de rechange d’origines diverses (Eurocopter, Thalès, Turbomeca…), dont la moitié sont gérées en configuration, c’est-à-dire soumises à évolutions et options. La conséquence immédiate est la charge en contrôle de navigabilité. Car si, dans la partie avion, les compagnies aériennes jouent un rôle important dans la gestion de la navigabilité, il n’en va pas de même pour les hélicoptères dont le constructeur en assure la responsabilité, quelle que soit l’origine des pièces.

Quelles sont alors les attentes d’Eurocopter en matière de plm ? Ce qu’on peut attendre d’une harmonisation est en premier lieu la simplification des processus. En s’inspirant des pratiques collectées dans l’ensemble du groupe, on pouvait espérer prendre du recul et améliorer l’organisation des travaux de conception et, en particulier, faciliter la maîtrise des échanges de données, réduire le time to market en accroissant l’efficacité. La traçabilité des configurations sur l’ensemble du cycle de vie des machines était un autre enjeu de taille, surtout dans le domaine militaire. Il faut garder à l’esprit qu’une fois qualifié, changer une vis sur le Tigre suppose de recalculer les masses, de mettre à jour la configuration, de mettre à jour les publications techniques, toutes sortes de charges qui font qu’on… ne change pas une vis. En même temps, le respect des engagements contractuels peut nécessiter des changements, chacun d’entre eux engageant les charges en question. D’autant que les trois programmes ont leurs outils de gestion propres. Et par ailleurs, chaque programme d’hélicoptère génère des dizaines d’options qui compliquent les choses. Par exemple, le NH90 se décline en deux versions principales actuellement en service : la tth (transport tactique) et la nfh (lutte anti-surface et anti-sous-marine). Si l’on considère le MRH90 australien et la cabine haute suédoise comme des déclinaisons de la version tth, la gamme est dérivée en 23 versions et sous-versions. On comprend ainsi la dimension des besoins en harmonisation.

3. Une collaboration fructueuse

En 2002, une décision importante est prise. Il faut impérativement un référentiel unique. C’est l’environnement allemand, Hecos, qui est choisi, car il a permis de passer la qualification du Tornado. Comme c’est un système centralisé, il est implémenté deux fois : en Allemagne et en France. Une deuxième décision est prise, celle de développer en interne, pour compléter la solution, un outil spécifique de gestion des modifications. Cet ensemble sera déployé en Australie et en Espagne. Or, Hecos a été conçu au milieu des années 1970 pour soutenir le développement du Tornado, à une époque où les technologies ne permettaient pas des ségrégations fines entre les données. Il a donc fallu multiplier les bases pour les spécialiser et les isoler, mettre en place des transferts entre l’Australie et la France, entre l’Espagne et la France, avec des envois hebdomadaires de morceaux de configuration.

Une harmonisation de la gestion des données techniques est lancée en 1999 entre la France et l’Allemagne pour intégrer à la fois le Tigre et le NH90, et les programmes-pilotes au tournant des années 2000 en montrent la capacité. Un pdm basé sur l’offre vpm de Dassault Systèmes est envisagé par le Tigre, mais les problèmes de fonctionnement dissuaderont de continuer et, en 2002, la piste est abandonnée. En 2005, la gestion de configuration du NH90 est améliorée et en 2006 le programme ecmi est lancé pour le NH90 puis pour le Tigre. En 2008, convaincu de ne pas pouvoir s’appuyer sur une offre fiable de Dassault Systèmes, Eurocopter lance un appel d’offres et c’est à ce moment que le contact est pris avec Jean-Yves Mondon. Nous savions en effet qu’un grand programme était en cours dans le groupe et, plus, nous ne pouvions pas gérer le projet seuls. Le souci était d’éviter un différend entre la France et l’Allemagne sur le choix de l’outil. Les historiques déjà évoqués amenaient à craindre les difficultés rencontrées avec vpm ou celles liées à sap. Nous voulions une solution opérationnelle et efficace. Dans un premier temps, nous avons travaillé sur la manière d’éviter ces problèmes passés.

Dans un deuxième temps, je rejoins le groupe mpd et constate que le modèle de données va beaucoup plus loin que ce que nous avions envisagé. Nous étudions son applicabilité à notre contexte partagé entre des phases de développement très différentes. En septembre 2007, alors que l’effort commun du groupe se développe avec Phenix, il faut arrêter le programme ecmi qui avait démarré seulement deux ans plus tôt. L’accueil a été très froid. J’étais alors responsable du bureau des méthodes et outils et je me souviens qu’il n’a pas été simple de justifier la démarche auprès du chef de Projet ecmi, Christian Powalla. Mais en octobre de la même année, le comité de pilotage ecmi, qui comprenait, entre autres, le responsable de l’engineering, Bernard Rontani et le président d’Eurocopter, Lutz Bertling5, entérinent l’arrêt du programme et ce dernier informe en décembre Jean Botti (cto d’eads) des conditions de l’arrêt. La décision est prise de se baser sur Phenix et les travaux communs du groupe dans la conception du Tigre.

Dans la phase d’exécution, le pilote du Tigre arrive à la suite du benchmark technique mené dans le cadre de Phenix. On demande aux éditeurs de travailler encore un peu pour prendre en compte nos besoins propres et de passer quelques semaines à Marignane. Les moyens dont nous disposons sont de loin plus réduits que ceux d’Airbus et le changement de décor est complet. Si chaque éditeur dispose d’un local, son équipe apporte son propre matériel. Des réunions hebdomadaires sont organisées pour le suivi. Avec Dassault Systèmes cependant, à travers son directeur technique Dominique Florack, un point quotidien est fait tous les soirs. Une réunion quotidienne avec Jean-Yves Mondon contribue à la bonne relation avec les éditeurs.

Les outils sont chargés avec une configuration Tigre allemande et une autre, française. Il s’agit d’implémenter les deux méthodes de gestion de configuration en s’appuyant sur le modèle mpd et ce avec le soutien de l’équipe mpd. Il faut ici saisir la nouveauté. Chaque division du groupe était plus habituée à traiter les problèmes de son côté et c’était une première que de partager les expertises, celles du groupe, de cimpa, d’Eurocopter. En mai 2008, nous mettons à disposition des éditeurs des jeux de données et des scénarios. J’ai relevé de grandes différences dans les attitudes. ptc, par exemple, a impliqué deux ingénieurs qui sont restés du début à la fin et ont traité la totalité de sujets. Ce fut à peu près la même chose pour Siemens. Côté Dassault Systèmes, associé à ibm, la répartition des rôles ne m’a jamais paru bien claire. Des personnes sont passées, six ou sept peut-être, je n’ai pas su vraiment combien ils étaient et quels étaient leurs domaines respectifs. Au bout du compte, Siemens et ptc répondent à notre cahier des charges, ce qui nous rassure puisque nous savons que Phenix est orienté de la même façon. Quel que soit le choix final, nous savons qu’il correspondra à nos besoins, ce qui nous permet de sécuriser la démarche auprès du management, mais aussi de ne pas nous impliquer dans la sélection finale. Ayant pris le travail en cours et satisfaits de son orientation, nous n’avions pas besoin de nous immiscer dans la complexité de la négociation finale.

L’apport de Phenix a été déterminant. Le travail d’identification et de structuration des données fait dans le mpd a permis de simplifier la relation avec les éditeurs, d’éviter les conflits internes qui naissent immanquablement quand les idées ne sont pas finalisées et qu’il faut les faire converger dans l’urgence. Les problèmes de déploiement de sap et de vpm laissaient encore une trace. Le mpd couvrait nos besoins, nous étions alignés avec le groupe. Fin 2008, le pilote du Tigre étant positif, nous commençons à travailler sur la phase de déploiement du plm. Évidemment, il nous faut un budget et le montant irrite sérieusement notre directeur financier. C’est le soutien de Jean Botti qui fera pencher la balance entre la nécessaire rigueur financière et l’investissement dans un programme d’harmonisation qui ne s’amortit qu’à moyen terme. En mai 2009, Airbus Hélicoptères vote le financement du programme EPP (Eurocopter Phenix Program) qui prend en compte à la fois les développements présents et futurs ; il s’étend jusqu’à 2016.

En 2009, le plan de déploiement pour le Tigre est décalé, car le marché évolue vers le service, ce que le mpd ne prenait pas en compte. Il faut reprendre son baluchon et rechercher à nouveau le soutien de Phenix. Jean-Yves Mondon l’accorde et accepte d’ajouter la vue services dans les travaux. L’extension est appliquée à l’EC175, fabriqué en partenariat avec la Chine. L’appareil est assemblé sur deux lignes, une en France à Marignane et une en Chine à Harbin et à partir de 2012, et la plateforme logicielle élaborée dans le cadre de Phenix6 est déployée dans les deux pays.

Avec le H160, qui est repositionné en 2013 par Guillaume Faury quand il remplace Lutz Bertling, c’est une seule méthodologie de gestion de configuration qui est mise en œuvre. Enfin en 2015, c’est-à-dire trente-deux ans après le tout début du programme, les données du Tigre vont migrer vers un environnement standardisé, vers lequel évoluera aussi le NH90 vers 2020.

4. Conclusion : des retombées puissamment fédératrices

Le programme Phenix a porté avec lui une nouvelle vision industrielle. Par la mobilisation du management sur lequel il s’est appuyé, il a créé une force d’entraînement articulée autour de la notion de produit. Ce faisant, il a montré que, malgré leurs profondes différences, les phases de conception avaient en commun des préoccupations et des organisations communes, qu’elles pouvaient partager une large part des méthodes et des outils. Il a montré que l’harmonisation avait non seulement du sens, mais qu’elle était possible. Elle a permis, et c’était une première, de faire travailler ensemble des compétences en ingénierie venues des trois divisions du groupe, aux cultures spécifiques. La portée fédératrice du programme s’est imposée grâce à la mobilisation conjointe des expertises et des managements. Avec la structure Phenix se sont diffusées des compétences qui manquaient à Eurocopter. De nouveaux métiers sont apparus, notamment autour de la gestion de configuration. Les lieux d’échange et la phase de benchmark ont permis d’accroître l’expertise et par conséquent d’améliorer les processus. Sans doute, le calme apporté par Jean-Yves Mondon a largement contribué à apaiser les négociations avec les entités sceptiques. Le développement du Tigre semble bien sécurisé pour une trentaine d’années, ce qui, ajoutées aux trente-deux ans écoulés depuis son lancement, porte le programme à presque soixante-dix ans. Qu’il se porte bien et on ne sera plus loin du siècle !