1. Les défis industriels d’Airbus vers 1995

Avec le milieu des années 1980 et les premiers succès d’Airbus, le nombre de programmes d’avion s’accroît. Alors que la décennie précédente avait vu naître les A300 et A310, six lancements sont décidés entre 1984 et 1997, successivement A320, A340 en 1987, A321 en 1989, A319 en 1993, A330-200 en 1995, A340-500 et A340-600 en 1997, et A380 en 2000.

La réussite commerciale est réelle :
– le nombre de commandes double entre 1995 et 2000, jusqu’à approcher 3 600 unités ;
– le nombre de livraisons planifiées augmente de 60 % entre 1994 et 2000.

Si en 1995 Airbus représente 17 % du marché face aux 83 % de Boeing, en 2006 on est à 43 % contre 57 %. Après quelques années plus positives encore, Airbus dépasse son concurrent américain.

L’arrivée des long-courriers A330 et A340 dans les années 1990 positionne le gie Airbus à environ 30 % du marché mondial. Cela provoque chez Boeing une réaction par les prix extrêmement agressive qui oblige à optimiser drastiquement les processus industriels. Il fallait absolument réduire le temps de développement des avions, et réduire le rework. Cette augmentation des performances des programmes devait permettre une montée en cadence grâce à l’harmonisation technique entre les partenaires, ainsi qu’une meilleure maîtrise des coûts, des délais et de la qualité.

L’ingénierie Airbus est interpellée à double titre par ces succès. D’une part le développement accéléré de nouveaux modèles d’avions l’oblige à être plus rapide dans la définition détaillée des avions. Il convient de garder à l’esprit que le gros de ce travail commence avec l’annonce publique, laquelle (si elle s’appuie sur un avancement technique certain) se cale fondamentalement sur le marché. Elle est souvent une réponse à l’annonce faite par un concurrent ou la volonté d’être le premier sur un créneau donné. Une annonce fixe un calendrier, elle scande en quelque sorte l’ingénierie. D’autre part, un programme avion induit une charge de conception qui s’étale et se spécialise dans le temps. On a la définition de l’avion de base, celui qui ne vole pas, mais qui donne la structure durable à partir de laquelle sont dérivés les avions réels. Ceux-ci sont organisés en versions qui traduisent les possibilités de motorisation (en général plusieurs types de moteurs sont proposés) et les évolutions technologiques essentielles. Enfin, les séries prennent en compte les choix particuliers des compagnies aériennes clientes ; le premier exemplaire est la tête de série qui réclame une conception propre. Les bureaux d’études, qui sont impliqués à ces trois niveaux, ont une charge de travail récurrente qui ne s’arrête donc pas avec la certification, même si elle ne réclame pas le même niveau de ressources tout au long de la vie de l’avion.

Airbus cherche à répondre à ces impératifs, d’une part en réduisant le temps d’ingénierie par la parallélisation des activités, à la fois à l’intérieur du gie, et en externe avec des collaborations qui dépassent les 40 % avec l’A380 et les 50 % avec l’A400M. D’autre part est visée une meilleure efficacité dans la gestion des données. La décennie qui commence au milieu des années 1990 voit en effet se complexifier les produits : l’A380, aux dimensions doubles de celles de l’A320, entraîne un alourdissement considérable de la gestion des données.

Le projet ace (Airbus Concurrent Engineering) est né en 1994 de ces objectifs globaux. Il fait écho à l’initiative semblable que Boeing lance en 1995, avec le B777 en ligne de mire. Sa mise en œuvre s’étend sur trois programmes avion : celle de l’A340-500/600, appelée A3456, celle de l’A3XX qui devient plus tard le A380, et enfin de l’A400M dont le nom initial était fla pour Future Large Aircraft. Soulignons que les périodes de développement de ces programmes se chevauchent. En outre, il faut garder à l’esprit qu’il est impossible de faire converger d’entrée les méthodes des trois programmes par exemple avec un développement unique. Si les programmes se recouvrent, ils ont un décalage dans le temps qui rend la réutilisation des méthodes et outils partiellement impossible. Un programme ne peut pas changer de méthodes et outils dès que la conception détaillée a commencé ! Les trois programmes ont donc été menés en parallèle mais avec des versions de méthodes et outils spécifiques.

1. 1. La nécessité de l’ingénierie simultanée

En 1994, quatre sociétés indépendantes constituent le Groupement d’intérêt économique (gie) : Aérospatiale qui vient de passer sous contrôle Matra, British Aerospace, Daimler Chrylser Aerospace, et Construcciones Aeronauticas SA (casa). Mais les définitions techniques de l’avion ont été conçues avec quatre cultures industrielles représentées dans autant de gestions des données et d’outils à même de les manipuler. Les programmes en cours avaient déjà bien établi leurs façons de travailler. Mettre en place des méthodes de développement communes suppose donc de déconstruire celles en place. La difficulté, comme d’habitude, se cristallise sur les interfaces entre sociétés, puisque les données ne sont pas traitées de la même façon partout. Des adaptations sont à faire, mais leur développement se heurte aux mouvements de transformation des bureaux d’études qui durent depuis une vingtaine d’années. Avec les premières expériences de Conception aidée par ordinateur (cao ou, en anglais, cad, pour Computer Aided Design), les partenaires des programmes Airbus ont lancé individuellement des projets de recherche autour de ces technologies afin d’en établir le potentiel et l’applicabilité sur nos programmes avion. Chacun d’entre nous s’est doté d’outils spécifiques sur lesquels nous reviendrons.

Mais surtout, l’évolution vers des ingénieries simultanées n’est pas chose simple d’une façon générale. Et dans l’aéronautique, elle est singulièrement compliquée, car le design doit anticiper des problèmes qui surviendront des dizaines d’années plus tard. Il s’agit donc de récupérer, confronter, enrichir des savoir-faire pendant les quelque soixante mois que dure la conception. Ce n’est déjà pas simple dans une seule entreprise, ça l’est encore moins dans une alliance européenne non hiérarchisée. Les efforts indispensables de standardisation et de pilotage multidisciplinaire se doublent de problématiques culturelles. Car sur le plan humain, cela demande d’ouvrir ce qu’on est en train de faire sans être sûr que ce que l’on fait est juste. La compétence risque sa réputation à révéler ses hésitations. Elle dévoile les chemins de ses origines ; elle empêche d’être assurée quand, en fonction du pays d’origine, on préfère plus ou moins annoncer ce dont on est sûr.

Le but d’ace est de dépasser ces barrières. En Allemagne, l’attribution d’une tâche va de pair avec la délégation de la responsabilité de son bon achèvement ; ce qui s’accompagne d’une définition précise du domaine. En France, le responsable hiérarchique s’estime responsable de l’ensemble des tâches déléguées, il s’attache donc à suivre le maximum de détails, essayant par-là d’être un « super-technicien ». Au Royaume-Uni, on rencontre souvent de purs gestionnaires, qui suivent les avancements sans se mêler du contenu. Lors de la création d’eads en 2001, l’équipe ace, dans laquelle chaque partenaire du programme Airbus avait délégué des membres, est unifiée et localisée à Toulouse. Elle assure les taches de définition des méthodes, tandis que le déploiement reste de la responsabilité des unités opérationnelles. Nous avions une réunion hebdomadaire de revue d’avancement, mais il était monnaie courante qu’elle soit précédée de réunions particulières au sein des Business Units.

C’est dire que compte tenu des cultures différentes des sociétés, il s’agissait moins d’imposer des changements que de trouver des compromis. Pour rester près du terrain, l’effort de convergence a été conçu en relation avec les débuts de programmes.

2. Le déroulement d’ace au fil des programmes

2. 1. Le programme A3456

2. 1. 1. La situation

ace s’implique dans ce programme dans la période allant environ de 1986 à 2001. Une équipe projet d’une vingtaine de personnes a été créée pour développer et déployer ace. Initialement, c’est le fla (Future Large Aircraft), qui deviendra l’A400M, qui avait été choisi. Mais comme ses implications étatiques complexes repoussaient sans cesse les décisions, il a fallu changer le fusil d’épaule. On est passé au A340-600, qui deviendra le premier programme auquel s’appliqueront les choix de méthodes et d’outils.

En 1995, les premiers travaux de coordination sont lancés avec des études d’utilisation de la cao et des sgdt (Systèmes de gestion des données techniques) entre les partenaires du programme Airbus : as, bae, casa, dasa et Airbus gie, qui forment 5 sociétés indépendantes avec des stratégies, des organisations, des méthodes différentes et des budgets indépendants. Mais la nomination déjà évoquée d’un comité de sponsors de haut niveau et d’un comité de coordination des projets donne une grande légitimité au processus engagé pour le choix commun d’outils pour les développements futurs.

Le processus ne dispose pas pour autant de ressources propres venues d’une mise en commun de compétences ni d’un budget spécial. Il s’appuie sur les National companies, Natcos. C’est cohérent avec son but, qui est de lancer une démarche, un projet commun pour la définition des méthodes et l’adaptation, avec le soutien des fournisseurs choisis, des outils de développement de nouveaux programmes. Il se limite à la définition physique de l’avion, ce qui exclut par exemple les calculs de performance.

Pendant cette période, au-delà des aspects techniques, les difficultés majeures viennent de la langue de travail commune. L’anglais n’est pas maîtrisé par tous au même niveau, ce qui conduit à s’appuyer sur des interprètes pendant les réunions. Il y a également la volonté plus ou moins déclarée de préserver les savoir-faire de chaque industriel avec, pour conséquence, des difficultés d’échange et de synchronisation entre les partenaires. Cela est sans doute à relier au fait que les niveaux d’expérience dans les différents domaines (calcul, dessin, données…) sont très inégaux.

Les quatre partenaires de l’A340-600 disposent de quatre systèmes d’information qui communiquent à l’aide de transferts manuels de fichiers (dex pour Data Exchange). Ce sont des charges importantes, pour chacun d’entre eux, de vérifications, de contrôles de cohérence, de problèmes de réconciliation entre données. Ainsi coexistent les logiciels suivants :

	Br. Aerospace	Aérospatiale	DASA	CASA	Commun
Dessin	CADDS5	CADDS5	CATIA v4 CADAMSM(2D)	CATIA v4 CATIA v5
Bases DMU	OPTEGRA	OPTEGRA	VPM	OPTEGRA
Référentiels données	Distributed vault DPDS	GILDA, GEMAVICC	TAKSY	SPRINT	ACC
Synchronisation bases externes	Échange de données par transfert (dex) Pas de base de données partagée

Les logiciels de gestion des données techniques des quatre sociétés sont locaux. Si elles ont le même objectif final, elles reprennent selon des choix très divers des fonctions comme les librairies de dessin, la planification, les schémas électriques, les catalogues de matériaux, l’effectivité, le release process1, le catalogue des composants sur étagère, les équipements, les standard items2. Une même fonction peut être implémentée chez des Natcos avec, par exemple, des pièces référencées différemment, nécessitant des recoupements manuels.

2. 1. 2. Actions principales

En 1995, une coordination des activités est proposée par les bureaux d’étude as, bae et da auxquels s’associe casa et le gie Airbus. Cela conduit à la création d’une structure avec un comité directeur et un comité de pilotage du projet. Le comité directeur se compose des directeurs du développement avion des quatre partenaires et du gie Airbus : Daniel Deviller (as), T. Williams (bae), Dr. Humbert (da), casa (K. Schmeichel) et du gie Airbus avec le Dr. Schneider. L’implication du gie mérite d’être soulignée, car ce n’était pas une entité opérationnelle. Mais en tant qu’acteur-clé dans la commercialisation et l’après-vente, il souhaite alors suivre les questions de conception. Peut-être faut-il y voir une vision à plus long terme, dans la mesure où, après la fusion de 2000-2001, son rôle s’étendra bien au-delà de la simple coordination d’origine.

La coordination du projet est assurée par l’ace project board qui se compose des responsables des études sur la cao (lesquelles sont conduites dans les Natcos) : Alain Carcasses (as), Robert Landeg (bae), Wilfried Rieckmann (da), Louis Fernandez (casa), Francesco Sperandio (Airbus gie). Cette focalisation sur les outils est à interpréter comme un pragmatisme propre à canaliser le travail sur les processus métier, comme les évolutions du programme le démontrent.

Au départ, le project board se réunit toutes les deux ou trois semaines pour échanger sur les progrès de l’activité dans chaque société, la définition du programme de travail restant de la responsabilité de chaque société qui garde la maîtrise totale des activités du projet.

L’objectif principal de la mise en place de cette structure est la formation d’un front commun des sociétés partenaires d’Airbus vis-à-vis des fournisseurs des systèmes informatisés de conception afin de pouvoir influencer les évolutions de ces systèmes et d’obtenir de meilleures conditions d’achat et un support efficace pour leur implémentation et maintenance.

En 1997 est créée une équipe-projet centrale. Ses efforts se concentrent sur l’identification des besoins de notre industrie et la définition des cahiers des charges, l’un pour les évolutions de la cao, l’autre pour le développement d’une nouvelle gestion des données techniques. En effet, les limites de l’outil Optegra apparaissent clairement et l’idée s’impose de définir une spécification plus précise des besoins de notre industrie afin de s’assurer de la disponibilité d’un produit satisfaisant nos contraintes, celles du développement des avions et en particulier celles de la gestion de la configuration.

En revanche, le calcul scientifique n’était pas au centre de notre action. Il y avait bien une équipe qui s’occupait de Nastran et Patran, mais les pratiques sont restées séparées, tout en assurant la coordination. Cela se comprend du fait que les parties d’avion distribuées entre les partenaires sont bien séparées et que leur optimisation relève des savoir-faire internes. En ce qui concerne le gie Airbus, qui est impliqué dans la vente et l’après-vente, seule la conception l’intéresse, mais pas le calcul.

La première cible sur laquelle est appliqué le travail de rationalisation est le fla (Future Large Aircraft) qui deviendra l’A400M. Mais le retard qu’il prend oblige à se rediriger sur un autre programme : l’A340-500/600. Mais celui-ci n’est pas entièrement nouveau ; il est au contraire très lié à l’A340, (il s’agit là d’une adaptation de la conception de l’A340 qui avait été conçu avec des méthodes traditionnelles, c’est-à-dire sans l’utilisation de systèmes de dessin assisté par ordinateur, autrement dit sur la planche à dessin !) auquel il apporte des modifications sur des parties spécifiques de l’avion.

2. 1. 3. Bilan

ace est encore à un niveau de définition assez théorique et seules les implémentations peuvent révéler les écarts de compréhension et de compatibilité avec les méthodes de travail. Les nouvelles possibilités technologiques sont utilisées de manière partielle pour valider les concepts, pour les tests, et pour le développement de nouveaux processus de conception.

Mais les équipes comme les budgets sont nationaux. L’avancement du programme dépend donc des priorités de chacun. Le Royaume-Uni est très moteur ; ils sont décidés à aller de l’avant, probablement à cause de la vétusté de leurs systèmes de gestion technique et de l’ampleur des modifications à apporter à la voilure. Les Allemands sont objectivement moins impliqués dans les modifications apportées à l’A340 et ne contribuent qu’à des fins d’essai et non de production.

L’Aérospatiale procède à des tests méthodologiques sur des morceaux d’avion sous sa responsabilité. Les Allemands font de même, quoique de façon moins intensive car leur contribution est moindre, cela entraînant une moindre nécessité de modification. Quant aux Espagnols, ils se lancent dans le sujet dans une démarche orientée Catia, logiciel qu’ils avaient acquis auparavant et sur lequel ils montaient en compétence.

2. 2. Le programme A3XX/A380

2. 2. 1. La situation

La participation aux travaux d’ace s’effectue essentiellement entre 1985 et 2000 pour l’A3XX et se prolonge pour ce qui devient l’A380 le 19 décembre 2000, date de lancement, et le premier vol le 27 avril 2005.

Une réorganisation importante est lancée par Charles Champion, directeur du programme, pour affronter la complexité nouvelle créée par la taille et les performances de l’avion. Des sortes de sous-programmes sont définis et gèrent tout à la fois ingénierie, fabrication et maintenance de sous-ensembles clé. Ils sont gérés par des équipes dites acmt (Aircraft Component Management Team) réparties entre les quatre pays du consortium et qui disposent d’une autonomie en termes d’achats et de fournisseurs. La voilure est sous la responsabilité du Royaume-Uni (qui intègre donc les bords d’attaque faits en Belgique par BelAirbus) ; le nez et le centre du fuselage sont deux acmt France ; le fuselage avant et le fuselage arrière sont en Allemagne ; l’empennage et le cône arrière en Espagne. Il y a également les acmt liés aux équipements (moteur, train), ceux liés aux systèmes, à l’intérieur et, last but not least, à la fal (Final Assemby Line) réalisée en France. On superpose donc les organisations nationales et celles de la découpe industrielle en acmt dont les responsables sont évalués sur la qualité de leur pré-intégration.

L’équipe-projet centrale ace croît en effectif et approfondit sa recherche de méthodes et d’outils communs. Elle fait face à un triple challenge : l’augmentation de la complexité, le changement de l’organisation interne et la croissance de l’externalisation de la production. Une organisation spécifique ace est créée pour réaliser les travaux de définition et le suivi des modifications des processus, méthodes et outils par rapport à l’existant avec une structure permanente de projet à deux niveaux : une partie chez Airbus CE avec un personnel détaché des quatre partenaires, qui établit un programme de développement et de déploiement commun, et des équipes spécifiques chez les quatre partenaires (jusqu’à cent permanents) qui seront impliquées dans les travaux d’uniformisation et en charge du déploiement. Ce sera jusqu’à huit cents personnes en tout qui contribueront.

La tâche est lourde, car des points d’amélioration importants sont identifiés lors des premiers déploiements. Le besoin de définir des processus intégrés spécifiques à une technologie ou à un produit (les ITP, Integration Technology Processes) structure la démarche d’harmonisation des méthodes et outils chez toutes les Natcos et la synchronisation des échanges de données. La figure ci-après, qui liste les thématiques des itp, montre bien leur étroite relation avec la fabrication.

(Fig. 1)

(Airbus)

L’équipe-projet centrale est dotée d’un budget annuel d’environ cent millions de dollars. La somme sert au développement des méthodes et outils et au soutien central aux déploiements, ce qui représente seulement une partie des coûts du déploiement directement couverts localement par les acmt qui ont par définition la responsabilité métier.

2. 2. 2. De nouvelles orientations progicielles

Les offres progicielles avaient fait l’objet d’une première analyse menée par les Natcos qui s’étaient mises d’accord sur cadds (avec l’exception de casa) et Optegra de Computervision et cela au tout début d’ace, vers 1995. Computervision possède alors un produit de dessin de grand renom, cadds, qui est présent dans de nombreuses industries. Optegra est une gestion de configuration plus limitée, car si elle traite bien de la maquette numérique, la gestion de configuration produit n’est pas à la hauteur des besoins de notre industrie. Cela avait conduit l’équipe ace à travailler à la définition détaillée des fonctions attendues.

Du côté de la cao, la pérennité de l’existant, cadds, le progiciel en place chez Airbus, est sérieusement mise en doute. Le rachat de Computervision, son éditeur, par ptc (Parametric Technology Corporation) en 1998 pose en effet problème car ptc commercialise un autre système cao, Pro/Engineer3. De ce fait, l’expérience acquise sur cadds chez Airbus, logiciel présent depuis longtemps, perd en force. ptc laisse entendre que sa stratégie produit est orientée Pro/E et non cadds. Une nouvelle analyse du marché est menée et l’offre Catia est reconsidérée et finalement retenue. Dassault Systèmes a une réputation mondiale. Boeing l’a achetée et Dassault l’utilise depuis quinze ans : l’adéquation aux besoins aéronautiques est incontestable. De sorte que la préférence de ptc pour Pro/E a dirigé Airbus… vers Catia.

Du côté des données, ptc est prêt à se lancer dans une collaboration très étroite avec Airbus. Il travaille à une nouvelle offre de gestion des données techniques, Windchill, qu’il développe en se calant au mieux sur les besoins d’Airbus. Un ingénieur est détaché de bae pour coordonner depuis Boston (le siège de Computervision/ptc) les échanges entre les équipes Airbus et ptc. Sa mission dure au moins deux ans. Il assure le suivi des travaux et une revue des développements se tient tous les trois mois à Boston avec l’équipe de direction du projet. On ne pouvait guère collaborer plus.

Dans ce contexte, il n’est pas surprenant que Windchill ait été préféré à son concurrent Enovia. De surcroit, cette offre de Dassault Systèmes provenait du rachat de l’offre ibm, pdm assets, effectué en 1998 et manquait de maturité.

Mais Windchill n’est pas choisi pour fonctionner sans adaptation. Au contraire, il sert de socle à un développement interne très important, le logiciel Primes (Product Relative Information Management Enterprise Systems), adapté aux besoins spécifiques et confidentiels d’Airbus. Primes va gérer en arrière-plan (backbone est l’expression consacrée) les descriptions des structures des produits, les changements qui sont opérés sur ces structures, les validations qui les permettent, le référencement des dessins 2D et 3D, et bien sûr les interfaces vers tous ces systèmes nationaux qui continuent de fonctionner. ptc doit procéder à des adaptations importantes de ses logiciels cadds5, Optegra et Windchill.

Dans ce cadre est réalisée une base de données de référence pour le partage des données générées dans les systèmes locaux du A380. Elle est aussi appliquée à l’A400M, avec un fonctionnement différent.

Un autre aspect d’ace est de faire de l’A380 le premier programme pour lequel la cao est entièrement utilisée par tous les partenaires. La 3D est déployée partout, mais basée sur des implémentations locales indépendantes. Combinant les nouveaux systèmes pour la cao avec des systèmes existant pour la gestion des données techniques, une maquette numérique se généralise également. On a affaire à une certaine hétérogénéité qui pourtant commence à se réduire. La convergence n’est pas une mince affaire.

2. 2. 3. Le bilan

Des choix sont faits qui avancent vers le partage de solutions logicielles. Le tableau ci-après en montre l’étendue. Cependant, un même nom d’application peut cacher des implémentations différentes, dues essentiellement aux interfaces avec les systèmes environnants qui traduisent parfois des différences dans les approches. De sorte qu’il faut relativiser la tendance et la considérer pour ce qu’elle est : une progression, à ne pas confondre avec une assimilation. Les décisions de déploiement des progiciels restent de la stricte responsabilité de chaque partenaire. Des différences subsistantes découleront les problèmes industriels que rencontrera l’A380 du fait d’une synchronisation trop lente des maquettes numériques entre les quatre Natcos.

	Br. Aerospace	Aérospatiale	DASA	CASA	Commun
Dessin	CADDS5 CATIA v5	CADDS5 CATIA v5 (mâts réacteurs)	CATIA v4 CATIA v5	CATIA v4 CATIA v5
Bases DMU	OPTEGRA	OPTEGRA	PRIMES	NAVICAT
Référentiels données	PRIMES	GILDA, ECDB, CIRCE	VPM TAKSY	SPRINT	PRIMES (base commune) / ACC2
Synchronisation bases externes	EPD CONNECT	EPD CONNECT		EPD CONNECT	ACC2

Avec l’arrivée de Primes, la période marque le départ d’une relation avec un éditeur de logiciel, ptc, qui s’inscrira de fait dans la durée dans la mesure où elle est toujours active aujourd’hui. L’idée était de fédérer les gestions de données de chaque pays autour d’une base additionnelle vers laquelle chacun remonterait ses informations.

ace connaît un moment très faste, très productif. Tout le monde contribue. On va au-delà des spécifications pour affronter les processus. Les itp sont une ouverture vers une culture commune. Si la création d’eads, en redistribuant les postes à responsabilité, a quelque peu perturbé les travaux, ceux-ci sont en même temps apparus comme précurseurs d’une volonté unificatrice du groupe.

C’est le moment où se formalisent les grandes étapes (milestones) des programmes de développement avion, de leur contenu, des points de synchronisation, et c’est également le moment où se développe une approche partagée de gestion de la configuration et de la dmu, des programmes de formation aux différents constituants du Concurrent Engineering.

2. 3. Le programme A400M

2. 3. 1. La situation

Les activités ace du programme A400M se déroulent entre 2001, année du lancement, et 2009, année du premier vol, donc bien après fla. Elles sont menées souvent en parallèle de celles de l’A3XX, et le premier reprend les organisations mises en place par le second. Il en approfondit les concrétisations en poursuivant les développements autour de Windchill. Une étape franchit un degré supplémentaire dans l’unification : Primes, qui est installé dans les quatre pays. Les processus métier doivent alimenter la base commune selon des méthodes semblables. Cependant Primes est implémenté sous autant d’instances que de pays. Il ne s’agit pas d’une seule base, mais de bases différentes s’appuyant sur une même plateforme logicielle.

Sur le plan organisationnel, la situation évolue avec l’intégration du groupe eads puis Airbus et la création d’un département « ace » au sein de la direction informatique d’Airbus. Il centralise désormais les budgets liés au programme ; il assure le contrôle global des développements et des déploiements ; il centralise enfin les informations techniques dans des bases de données communes (Catia V5/Windchill) accessibles depuis tous les sites des Natcos. Les sous-traitants ont également accès sur site ou depuis leurs locaux à travers des connexions sécurisées.

Comparé à l’A3XX, le programme A400M souhaite intégrer davantage, approfondir les interfaces. Cela accroît le niveau de complexité. Le programme A400M étant sous la responsabilité de casa, l’investissement est plus important en Espagne. À ses débuts, il est localisé à Toulouse. Ce n’est que plus tard qu’il est transféré à Madrid.

2. 3. 2. Les actions de mises en place

Les processus multidisciplinaires (Design reviews, Virtual design teams…) sont revus et deviennent réellement transnationaux. De nouveaux concepts de gestion de configuration sont définis qui séparent clairement le sous-ensemble fonctionnel, la solution technique qui le met en œuvre et qui peut évoluer, la période et les avions auxquels la solution s’applique.

La maquette numérique (dmu) est utilisée pour la validation de la conception détaillée. Elle permet des prises de décision plus rapides en particulier sur les allocations d’espace et les chevauchements. Elle sert également en avant-vente, car ce qui est montré correspond à la réalité de la conception et non à une vue d’artiste.

Les anciens outils logiciels (dits « propriétaires » c’est-à-dire spécifiques à chaque pays) sont remplacés par les produits choisis collectivement, comme Gilda (Gestion informatisée de la liasse de la division avion) qui gère depuis plus de vingt ans l’ensemble des programmes avions. Depuis 2005 (pour l’A400M), le système a été en partie remplacé par Primes.

Les itp (Integrated Technology Processes), dont la définition a commencé avec l’A3XX, sont approfondis sous leurs différentes facettes : les besoins, les connaissances, les outils spécifiques nécessaires au bureau d’études, à la production, au contrôle qualité pour la production des pièces individuelles ou des ensembles dans le cadre d’une chaine d’approvisionnement donnée et, ce, sur l’ensemble du cycle de vie.

Des nouveaux métiers sont définis4 : le gestionnaire de la maquette numérique (dmu manager), l’intégrateur d’une partie de l’avion (Zone integrator), l’intégrateur de la maquette numérique (dmu integrator), le coordinateur de la structure produit (Product Structure coordinator), le coordinateur des analyses de clash (divergences/recouvrements, Clash follow-up Coordinator).

2. 3. 3. Le bilan

L’A400M est le premier programme pour lequel les mêmes outils de cao et de gestion des données techniques sont utilisés par toutes les Natcos. Windchill gère les données produites par type, série et avion individuel, Catia V5 traite les modèles 3D. Cependant, ils sont basés sur des implémentations locales qui partagent leurs résultats par le biais d’une base de données commune.

	Br. Aerospace	Aérospatiale	DASA	CASA	Commun
Modèles 3D	CATIA v5	CATIA v5	CATIA v5	CATIA v5
Bases DMU	cad Integration	cad Integration	cad Integration	cad Integration
Référentiels données	PRIMES	PRIMES	PRIMES	PRIMES	PRIMES (base commune)
Synchronisation bases externes	Mécanismes automatisés d’import/export direct cad-pdm

Les travaux permettent de finaliser des directives décrivant les méthodes ainsi que les procédures sur lesquelles elles s’appuient. On a ainsi des méthodes sur la gestion de la dmu en configuration, l’utilisation de la dmu avec des logiciels comme dVise ou Catia, une guide de développement de la définition avion, etc.

3. Conclusion

Au début du programme ace, les systèmes d’information spécifiques aux pays traduisent des différences dans les pratiques ; ils produisent « mécaniquement » des données hétérogènes, des échanges et des problèmes d’intégration. De cela découlent des charges de contrôles de cohérence, de correction, gourmandes en temps et en coût. Le changement s’opère selon une démarche de prise en compte simultanée des processus métier et des outils logiciels qui leur sont utiles, et ce pour les programmes A3456, A3XX/A380 et A400M. Elle s’approfondit dans le sens de la mise en commun. Pour l’A3456, chaque Natco a la gestion exclusive des définitions détaillées qu’il élabore ; avec l’A380 arrive une base en arrière-plan qui consolide les données des différentes bases par le biais du dex ; avec l’A400M, c’est un seul type de base (un seul produit) qui est déployé dans toutes les Natcos.

Parvenir à cette mise à niveau des bases demande de modifier les processus de création et de manipulation des données. D’où le concept d’itp qui permet d’identifier, parmi les processus, les éléments clés à mettre en commun. Ce noyau est dégagé dans la période A3456 et développé dans la période A380 (laquelle chevauche fla/A400M). Les difficultés majeures ont été causées par la multiplicité des programmes et l’impossibilité d’introduire des changements de méthodes et outils une fois démarré le design détaillé de l’avion, ainsi que par les stratégies d’implémentation divergentes chez les différents partenaires.

La démarche ace s’est attachée à tenir les deux bouts du problème : d’une part, construire un référentiel méthodologique commun, incrémental, valable pour l’ensemble du groupe, d’autre part, rester ancrée sur les besoins des programmes et s’implémenter pratiquement pour chacun d’entre eux. L’enjeu est resté de faire converger deux forces obéissant à des logiques propres, de maintenir un cap global. Le travail, en exigeant dialogue et partage sur des informations instables, a incontestablement contribué à développer une culture d’entreprise. Elle en fut en tout cas une première recherche dans la division Avion.