1. Une informatique reflet des origines multiples

Au début des années 2000, Astrium, filiale « lanceurs et satellites » d’eads, est encore en pleine intégration. Le secteur spatial européen a connu une vingtaine d’années de fusions et d’acquisitions qui ont transformé le paysage entrepreneurial. Le bloc Matra-Marconi Space, constitué au début des années 1990 entre les Français Matra-Espace et les Anglais Marconi Space, est associé à la division « lanceurs » de l’Aérospatiale et aux satellites allemands dasa. Ce dernier est lui-même le résultat de regroupements entre Daimler-Benz Aerospace, mtu München, Dornier, erno, Tsystems et Messerschmitt-Bölkow-Blohm. Astrium se trouve ainsi présent sur des sites variés. En Allemagne, ce sont ceux de Munich et de Friedrichshafen ; au Royaume-Uni, Poynton, Stevenage et Portmouth ; en France avec Toulouse, Vélizy, Élancout ; en Espagne, avec Tres Cantos. Chaque site a son passé. Par exemple, Friedrichshafen est le lieu historique de Dornier, Portsmouth celui de gec Marconi Space, (gec étant General Electric Company), Toulouse celui de Matra Espace. Chacun d’entre eux continue à développer selon ses méthodes et ses propres outils informatiques, malgré un organigramme commun et des clients institutionnels communs (esa, cnes, dlr, dod…).

Les activités spatiales regroupées au sein d’Astrium sont en fait segmentées selon des lignes de produits et des marchés très différents. Les lanceurs disposent de 3 ou 4 produits, dont les fusées Ariane. Ils comptent des métiers spécifiques liés à la pyrotechnie, à la chimie, aux matériaux soumis à des conditions extrêmes. En une centaine de secondes, ce sont plus de deux cents tonnes de poudre qui brûlent. La durée de vie d’un lanceur est courte comparée à celle d’un satellite, d’un hélicoptère ou d’un avion : entre vingt minutes et trois jours. Les clients sont des institutionnels comme l’Agence spatiale européenne ou l’État français. Les satellites, en revanche, obéissent à de tout autres principes. Ils se regroupent pour l’essentiel autour de deux marchés distincts. Le marché « Observation de la terre et Science » rassemble des produits prototypes et unitaires, jamais semblables. Ces satellites répondent à des missions d’une grande diversité : scientifiques, commerciales et militaires, allant de l’imagerie optique, radar ou radio, sur des orbites basses comme les satellites Spot, ou géostationnaire comme les satellites Meteosat, sur des orbites complexes terre-soleil comme soho et gaia, et allant même jusqu’aux missions interplanétaires comme MarsExpress, VenusExpress et Rosetta. Chaque satellite est littéralement construit « autour » de sa charge utile, ce qui donne des formes et des tailles très différentes allant du micro satellite d’environ 100 kg à des satellites de plusieurs tonnes gros comme un autobus à étage avec des panneaux solaires de plus de 30 m de long une fois déployés. Leur durée de vie est comprise entre 3 et 15 ans et les clients sont principalement des institutionnels et des États.

Le marché des télécommunications comporte tout à la fois des satellites destinés à la diffusion des programmes de télévision, à l’acheminement des flux téléphoniques ou internet, publics et militaires. Ce sont des produits généralement quasi-unitaires (groupes de 2 à 6) et exceptionnellement des constellations de plusieurs dizaines. Les satellites de télécom sont des produits assez semblables pour leurs plateformes en orbite géostationnaire, mais différents par leurs antennes complexes et les charges utiles gérant des fréquences à chaque fois spécifiques. La taille des satellites de télécom est à l’inflation depuis plusieurs décennies à cause de la puissance et des débits de communication demandés toujours plus importants. Les plus gros font 6 à 8 tonnes à l’époque de Phenix. Leur durée de vie est de 15 à 17 ans. Le marché où s’affrontent des entreprises privées est extrêmement compétitif.

Dans ce contexte de produits et de marchés cloisonnés au sein d’Astrium, les priorités d’harmonisation des processus et outils informatiques ont été gérées séparément dans les trois secteurs : lanceurs, satellites d’observation-science et satellites de télécommunications. Chaque secteur a ainsi visé d’améliorer son efficacité dans son périmètre marché-produit, même si chacun de ces périmètres s’étend sur les quatre pays : France, Allemagne, Angleterre et Espagne.

Cependant un point commun se dégage : dans le spatial, la culture de l’information est essentiellement documentaire. Cette approche est certes un héritage de l’époque pré-informatique où les documents étaient le seul moyen de transaction tout au long du cycle de vie d’un produit. Mais elle est surtout issue des logiques de développement « prototype » qui prévalent quand il n’y a pas de production en série après la phase de conception. En effet, dans ce cas, les équipes projets restent intégrées jusqu’à la livraison du produit et les jalons de revues sont continument répartis sans marquer de transition forte entre conception et fabrication. Au fil du temps, les clients institutionnels des lanceurs et des satellites ont imposé des listes documentaires pour les revues qui sont devenues la norme, justifiée pour garantir une traçabilité totale des développements sachant que seuls les documents resteront sur terre alors que le produit, qu’il soit lanceur ou satellite, ne sera plus accessible après le départ de la fusée. De fait, des caisses de plusieurs mètres cube de papier sont emmenées sur les pas de tirs à chaque lancement, souvent plus volumineuses que le satellite lui-même, pour permettre de passer les dernières revues in situ.

Dans ce contexte, l’informatisation des connaissances liées aux programmes spatiaux s’est principalement construite autour du traitement de documents. Au début des années 2000, la question d’utiliser des outils de type pdm (Product Data Management1) se pose dans tous les secteurs d’Astrium. En effet, ces outils permettent de centraliser la gestion de configuration pour référencer de façon cohérente les versions successives des informations d’un produit. À cette époque, ils émergent comme la référence indispensable au système d’information dans l’industrie. Mais les données techniques des satellites et des lanceurs se trouvent disséminées dans les fichiers de documents sans lien les uns avec les autres. Le croisement des informations, leur mise en relation, leur pertinence, ne sont pas inscrits dans une gestion informatisée centrale comme peut l’apporter un outil pdm. On ne retrouve pas une donnée technique par une simple recherche documentaire. Le classement des documents par date et par jalons ne suffit pas à rendre lisibles les liaisons de cohérence entre informations. C’est la mémoire humaine qui établit les liaisons et avec le temps, elle se dilue, voire se perd. Les personnes évoluent professionnellement et emportent leurs connaissances. L’enjeu du pdm chez Astrium ne s’est donc pas limité à choisir un outil informatique. Il s’est agi de construire les liens d’information à partir d’une culture documentaire gravée dans la pratique des programmes et promue par les clients.

Deux éléments de contexte supplémentaires sont aussi importants à comprendre. D’une part les produits se complexifient : aussi bien les lanceurs que les satellites deviennent de plus en plus « paramétrables ». La part du logiciel embarqué devient plus importante et surtout la quantité de paramètres reprogrammables en vol ainsi que le volume de données échangées entre le sol et les produits explose. Cette tendance oblige à gérer des bases de données et non des documents, toujours plus nombreuses et complexes par leur interdépendance et tout au long du cycle de développement. Les documents sont très mal adaptés pour assurer la cohérence des informations contenues dans ces bases de données. Les pdm apparaissent indispensables.

D’autre part les progiciels dits erp (Enterprise Resource Planning) comme sap ont été déployés au début des années 2000 chez Astrium pour intégrer l’informatisation de la finance, des approvisionnements et des stocks. Vu du pdm, l’erp est un monde de données qu’il faut synchroniser avec les informations de conception, notamment les nomenclatures venant du bureau d’études.

Entre 2000 et 2007 avant que Phenix ne démarre, Astrium a déployé dans chacun de ses trois secteurs des logiciels pdm plus ou moins complets et plus ou moins utilisés avec succès. En France et en Angleterre, c’est le logiciel TeamCenter d’origine Unigraphics devenu Siemens qui est déployé. Ce logiciel gère les données techniques des satellites et des lanceurs, mais les méthodes de gestion sont différentes entre les trois secteurs de produits. En Allemagne, l’outil CM2000 a été développé sur mesure pour les satellites chez Dornier.

À cette diversité d’approches informatiques s’ajoute une confusion sur la vision des processus entre gestion de configuration et gestion documentaire. Le besoin d’harmonisation s’impose donc à la fois au niveau informatique, méthode, processus et secteur de marché. Les efforts s’engagent dans Astrium vers 2005, soit deux ans avant Phenix, pour étendre et harmoniser l’utilisation du pdm TeamCenter.

2. Les données d’Astrium au lancement de Phenix

Quand Phenix démarre début 2007, chaque pays au sein d’Astrium a donc hérité de ses outils de traitement documentaires, plus ou moins customisés, c’est-à-dire transformés par rapport au progiciel du commerce. La culture de la donnée et l’utilisation d’outils pdm a du mal à s’imposer.

Les informations des produits sont réparties dans les outils divers de chaque métier intervenant dans la réalisation d’un programme. Ces outils et leurs utilisateurs ne communiquant pas forcément bien entre eux, l’accès aux données en dehors des documents est une affaire de spécialiste. Les outils sont des progiciels complexes comme doors, TeamCenter, vpm, Catia 2D/3D, ClearCase, Faust, Sis, de nombreux outils de simulation nécessaires à chaque métier, des outils de gestion documentaires comme Panagon et de gestion de configuration comme Regis et CM2000, des outils de gestion logistique et planning sap, Prodaxis, Jit, Primavera…

Par ailleurs, pour les raisons historiques évoquées précédemment, le bureau d’étude en particulier sur les satellites n’est pas le leader de la décomposition du produit en composants avec une nomenclature arborescente comme dans l’industrie automobile ou aéronautique. Ce sont les directions de programmes (et les clients institutionnels) qui imposent la vue selon une arborescence documentaire. Les données gérées dans les pdm sont donc avant tout le reflet des arborescences de documents, et la gestion des nomenclatures servant à alimenter l’erp se heurte à des problèmes de méthodes. De nombreuses discussions s’engagent entre les programmes, le bureau d’étude, les achats et la fabrication-assemblage-essais sur la manière de gérer en cohérence la nomenclature des composants à partir des documents. Cette manière de poser le problème est à l’inverse de ce que font la plupart des industriels sur les produits manufacturés, qui décrivent les documents à partir de la nomenclature. Ces discussions vont durer jusqu’à ce que Phenix apporte la vision harmonisée du groupe eads et que le projet plm Connect se mette en place dans Astrium comme expliqué plus loin.

(Fig. 1)

(Astrium)

La figure 1 donne un aperçu de la complexité des liens à gérer entre les principales informations techniques d’un satellite. Les informations sont représentées avec cinq couleurs différentes correspondent aux cinq principaux domaines de métier les produisant. Bien que n’étant pas reliées et gérées sous cette forme avant Phenix, les informations étaient déjà produites car elles sont nécessaires au développement d’un satellite :

– les exigences (ou « requirement set »), en bleu, qui expriment les performances attendues ;

– la définition de l’architecture du satellite (spécifications, block diagrams, chaînes fonctionnelles…), en orange, qui décrit « de quoi » le satellite est fait et qui le fait (répartition industrielle des équipementiers) ;

– le design (dossier de plans) et la logique d’assemblage, en jaune, qui réunit les dessins et documents de conception des pièces et la nature de leurs arrangements ;

– la préparation de la fabrication/assemblage, en vert, qui explicite le « comment faire », avec les procédures et l’ordre des opérations ;

– la réalisation de la fabrication et l’assemblage, en rose, qui inventorie les composants réels présents dans un satellite particulier.

Au cours du cycle de développement d’un produit, les données sont produites de façon quasi chronologique selon les couleurs de gauche à droite. Mais dans le détail du déroulement d’un programme, il faut gérer un enchevêtrement de créations et de mises à jour qui viennent de tous les métiers.

La réconciliation des données en cohérence est indispensable et s’effectue au moment des revues à l’aide de documents rédigés uniquement dans ce but. Ce travail, qui consiste à établir des listes d’informations (documents, données, références…) et des tableaux de correspondance, est fastidieux et principalement manuel. Il a l’inconvénient d’arriver a posteriori, obligeant de refaire une partie du travail quand des incohérences sont détectées. Les nouvelles générations de pdm associées à des méthodes de travail innovantes permettront d’améliorer la qualité et l’automatisation de ces réconciliations, ouvrant la possibilité de mieux répartir l’effort des vérifications et de raccourcir les temps de correction plutôt que d’attendre les revues finales.

3. Phenix dans le spatial

3. 1. Réduire la complexité

Phenix arrive donc au moment où Astrium essaie d’harmoniser et de rationaliser les données techniques (leurs méthodes et leurs outils de gestion) entre les pays et si possible entre les secteurs de marché. Les difficultés et les résistances culturelles sont réelles. Cette initiative apparaît comme l’occasion de converger sur une solution méthode et outils non seulement moderne mais aussi qui ne serait pas imposée par l’un des pays membres d’Astrium. Une des difficultés majeures fut de trouver un compromis équilibré entre la solution de principe définie par les experts au niveau du groupe eads selon une ligne moyenne entre avions, hélicoptères, lanceurs et satellites, et les besoins particuliers dans chacun des cas. Phenix n’apportait pas seulement des réponses sur le pdm mais une approche globale du plm (Product Lifecycle Management). Il fallait impliquer l’ensemble des acteurs qui allaient participer au déploiement du plm dans Astrium. L’objectif était double. D’une part profiter de l’effort au niveau du groupe eads et notamment de l’harmonisation de l’outil pdm par les achats du groupe. D’autre part rationaliser et rajeunir les outils qui arrivaient en fin de vie chez Astrium.

Profiter de l’effort au niveau groupe eads a consisté à rechercher une harmonisation par les achats. L’enjeu était de gagner immédiatement des sommes importantes sur les coûts des licences pdm. Astrium était donc intéressé par l’initiative du groupe. Mais il était aussi intéressant de participer à la vision globale du plm et à la définition du déploiement des nouveaux outils. En effet, les outils informatiques chez Astrium arrivaient à un seuil où il fallait de toute façon prendre des décisions : comment rationaliser et interconnecter trop d’outils hétérogènes ? Deux visions différentes s’opposaient pour gérer la complexité : le tout-intégré, contre des écosystèmes locaux.

Quant aux outils vieillissants, il s’agissait à la fois de l’héritage des sociétés avant la création d’eads mais aussi des outils et de l’architecture du système d’information de plus en plus inadaptés à gérer les nouveaux produits en développement : produits plus complexes, équipes plus internationales et délocalisées, transactions par documents inadaptées… et plusieurs dizaines de nouveaux programmes de satellites engagés tous les ans. On se retrouvait avec des outils plus ou moins récents faisant plus ou moins la même chose dans les différents pays, mais n’effectuant pas les nouvelles tâches nécessaires comme notamment la synchronisation des volumineux échanges de plans en 3D entre les bureaux d’études France-Allemagne-Angleterre, avec le besoin de rationaliser les investissements de maintenance et de renouvellement. De nombreuses initiatives se sont terminées dans l’impasse quand les acteurs d’un pays refusaient d’adopter la solution d’un autre pays (syndrome du not invented here comme ce fut particulièrement le cas pour le pdm). De ce point de vue, Phenix est arrivé à point nommé dans Astrium en offrant l’occasion de solutions alternatives neutres entre les pays pour remplacer et adapter une partie de l’héritage informatique.

La démarche fut de réduire la complexité sous un triple aspect. Réduire la complexité des outils en déployant sur tous les secteurs et dans tous les pays les solutions des éditeurs sélectionnés par Phenix. L’effet de rationalisation était immédiat au niveau des achats de licences, suivi d’un effet d’harmonisation au niveau des utilisateurs. En deuxième lieu, fut mise en place une architecture simplifiant les échanges de données 3D entre les pays ; ainsi la fabrication et l’assemblage des satellites furent dotés d’un même environnement de travail qui a consolidé la gestion de configuration centralisée des programmes. Enfin, la complexité des méthodes fut diminuée en déclinant les concepts établis par Phenix qui pouvaient être mis en œuvre par les nouveaux outils. Par exemple la notion simplificatrice de « vue » illustrée en reprenant la figure 1 présentée plus haut : parmi tous les liens existants entre les informations d’un produit, on peut choisir de ne montrer que certains chemins de liens correspondant à des besoins précis de gestion et de transactions entre les métiers. Cette sélection dans la multitude est montrée à travers la figure 2.

(Fig. 2)

(Astrium)

De cette manière on peut définir des filtres adaptés aux besoins des utilisateurs qui ne voient certes qu’une petite partie des informations, mais beaucoup plus simple et complètement adaptée à leur rôle. Ces utilisateurs pourront consulter leur vue jour après jour pendant toute la durée du développement et voir les données apparaître au fur et à mesure de leur création et toujours à la bonne version.

3. 2. Gérer l’adoption du changement

La question des liens entre les objets a généré de très nombreuses discussions car c’était l’effet le plus visible du changement avec le fait de passer sur de nouveaux outils. Parler des liens impliquait de définir qui avait le droit de créer une donnée et un lien et dans quel outil, qui pouvait les modifier ou les supprimer, les consulter… Ce sujet revenait à légiférer sur les propriétaires des informations, donc de légiférer sur le pouvoir des organisations métiers mais par le biais des données techniques. Si bien que les organisations ont vu l’arrivée du plm dans l’entreprise comme une perturbation de leur pouvoir, que ce soit l’occasion de l’étendre ou le risque de le voir réduire. La plupart des acteurs et des organisations n’avaient (n’ont toujours ?) qu’une vision très locale du cheminement des données pendant le cycle de vie du produit, et tendance à s’approprier non seulement les outils mais aussi toutes les données utilisées pour leur propre activité (celles produites en sortie mais aussi celles nécessaires en entrée). Il a fallu expliquer le concept de master data qui s’appuie sur l’unicité de la donnée (one source, one data) mais dont la version peut être mise à jour au fil du temps. Les contraintes informatiques pour créer/modifier et accéder aux données ont permis de poser les bases de la gouvernance du cycle de vie du produit (maturités, jalons, validité, configurations) en s’obligeant à définir la liste des données maîtres (d’où le terme master data), les propriétaires de ces données au cours du cycle de vie et s’accorder sur le déroulé des transactions. Ce dernier point reste sensible chaque fois que l’on redéfinit des interfaces informatiques. En effet, les acteurs ont rarement le réflexe de considérer le flux de données et de transactions comme indépendant des outils.

Pendant plus d’un an, des réunions regroupant une quarantaine de spécialistes des différents métiers dans les trois principaux pays d’Astrium ont été nécessaires pour débattre et agréer une compréhension commune et des axes de solutions. Pour certains domaines, la remise en cause était profonde (interface pdm-erp) et il a fallu s’assurer que les risques d’impact sur le business étaient maîtrisables aussi bien pour passer l’information que pour l’historiciser, la stocker, en permettre un accès ultérieur…

3. 3. Une mobilisation importante structurée en trois étapes

Le projet Phenix au niveau du groupe eads a duré de début 2007 à fin 2009 et a permis de définir le concept méthodologique du plm et la rationalisation du pdm pour l’ensemble des programmes avions, hélicoptères, lanceurs, satellites et électroniques de défense. Pendant cette période, Astrium a nommé par l’intermédiaire de sa direction informatique commune à l’ensemble du spatial une quinzaine d’experts issus de toutes les branches des organisations « lanceurs et satellites ».

C’est ensuite, pour la mise en œuvre des choix et recommandations Phenix dans Astrium qu’il a fallu s’organiser. L’approche a été gérée différemment entre les lanceurs et les satellites. Chaque branche a ainsi pu définir un plan tenant compte de ses priorités et des particularités de son système d’information. Sur les lanceurs, le projet s’est limité à développer un démonstrateur sur un programme encore en phase préliminaire. L’approche étant que la solution plm des lanceurs se définirait progressivement et conjointement avec ce programme, permettant de prendre plus tard et sur des bases plus mûres la décision stratégique d’harmoniser les autres programmes de lanceurs. Sur les satellites, le plan était différent. Avec plusieurs dizaines de programmes initiés tous les ans chacun très différents les uns des autres, il était difficile de trouver un satellite qui soit représentatif de l’ensemble pour réaliser un démonstrateur du plm. Le risque était de ne pas démontrer une garantie suffisante pour réussir déploiement et adoption sur l’ensemble du business. Si bien que la démarche retenue a été en trois étapes :

1. Prototypage rapide

2. Projet pilote « Aspire »

3. Projet « plm Connect »

Le prototypage rapide visait la partie pdm (Windchill2) de manière à démontrer que les principes et outils choisis par Phenix permettaient bien d’appréhender les particularités d’un programme de satellite. En particulier le cas de gestion du catalogue de « ligne de produit » des charges utiles télécom et son instanciation de manière configurée sur les différents programmes satellites était considéré par la direction télécom comme non-négociable. Le cas type pour le prototypage a été défini en quelques jours par des experts de satellites d’observation et de télécommunication, regroupant un jeu de données réelles extraites des catalogues de charges utiles et de différents satellites. Le prototypage dans Windchill s’est ensuite déroulé sur un mois pendant l’été 2008 et a été présenté aux directions de programmes respectives à l’automne pour autoriser le passage à la phase suivante : le projet pilote Aspire.

Fin 2008, le projet pilote Aspire démarre. Le but est de fournir une solution pdm opérationnelle et harmonisée pour le programme d’observation du champ magnétique terrestre, « Swarm », et pour le catalogue de charges utiles télécom.

(Fig. 3a)

(Atrium)

(Fig. 3b)

(Atrium)

La mission Swarm repose sur une constellation de trois satellites identiques qui doivent être fournis à l’Agence spatiale européenne. La direction de programme est basée en Allemagne. Le catalogue de charges utiles télécom doit pour sa part être saisi et géré de façon centralisée et configurée pour l’ensemble des programmes télécoms à venir. L’équipe de gestion du catalogue est principalement basée en Angleterre, et partiellement en France.

(Fig. 4)

(Astrium)

Les avantages de cette phase de projet pilote Aspire ont été multiples. Elle a permis d’obtenir une preuve opérationnelle du nouveau pdm en moins d’un an. Elle a impliqué les trois pays d’Astrium et les deux business units « Observation de la Terre » et « Telecom ». Elle a mis en place une équipe précurseur pour le développement du plm Astrium, en relation avec ptc, l’éditeur du logiciel pdm, selon les termes du nouveau contrat mis en place par Phenix au niveau d’eads. Enfin, elle a réduit les risques d’impacts sur le business Astrium en cas d’échec grâce au choix de Swarm et du catalogue télécom pour lesquels il existe des solutions de repli immédiates. Pour garantir une solution équilibrée et compatible à la fois des besoins métiers télécom et observation, le chef de projet a été désigné dans la direction technique (cto) indépendante des directions de programmes. Le projet Aspire a délivré la solution opérationnelle en avril 2009, incluant les formations à Windchill pour les utilisateurs (gestionnaires de documentation et de configuration). Les conclusions opérationnelles ont été présentées début 2010 permettant d’engager la phase suivante : le projet plm Connect.

Le projet plm Connect a été la dernière phase de déploiement de la solution plm pour les satellites d’Astrium selon les principes établis par Phenix. Il s’agissait cette fois de définir l’architecture complète des outils informatiques couvrant le plm, c’est-à-dire un système d’information articulé autour des trois principaux éléments. Le premier est le pdm Windchill. Dans ce système informatique, les programmes peuvent gérer de façon configurée un produit satellite, c’est-à-dire en gardant la trace des versions successives de chaque information nécessaire au développement du satellite. Chaque satellite est décomposé de façon arborescente en éléments et chaque élément porte l’ensemble des documents et fichiers de données qui s’y rattachent. En repartant du pré-paramétrage effectué sur Aspire, le projet plm Connect a permis de finaliser l’adaptation de Windchill à tous les cas d’utilisation des programmes satellites ainsi que les interfaces informatiques permettant de collecter et de transmettre les données maîtres du pdm avec le reste du système d’information. Le deuxième est l’environnement de dessin du bureau d’études, dans lequel toute la définition géométrique en 2D et en 3D des satellites est effectuée, et gérée en cohérence avec les données de références du pdm. Une nouvelle architecture de l’environnement géométrique a été définie pour améliorer le partage et la réalisation des plans entre les trois pays, et permettre l’interface de publication (transaction bureau d’étude/programme) vers le pdm. Le troisième, enfin, est l’environnement de travail pour l’assemblage et les essais des satellites. La solution informatique a fait l’objet d’une consultation pour choisir les outils correspondant le mieux à la manière de préparer et mener l’intégration et les essais des satellites. Puis une adaptation de ces outils pour les intégrer comme un seul bloc dans le système d’information Astrium avec en particulier les interfaces vers les deux environnements précédents.

Ces trois éléments sont eux-mêmes interfacés avec l’erp où sont gérés les achats, les stocks et la finance de l’entreprise. L’équipe projet qui avait été mise en place pour Aspire a été étoffée au démarrage de plm Connect en respectant l’équilibre des trois pays : France, Allemagne, Angleterre. Basée à Toulouse avec le support d’une société de consultants, elle fut constituée de représentants de tous les pays, de tous les métiers et organisations concernés. Le plan de développement a été défini, ainsi qu’un dossier de décision pour les directions de programme explicitant le bien-fondé du projet, démontrant la nécessité d’agir, les bénéfices et les coûts (Business Case), la maîtrise des risques. Ce dossier était essentiel pour obtenir l’adhésion des deux directions de programme « Observation-Science » et « Telecom ». Il a permis d’une part de ne pas être bloqué par un véto d’une de ces directions de programme, et d’autre part d’obtenir la disponibilité des ressources nécessaires pour l’équipe-projet.

Un plan de communication a été engagé pour présenter sur chaque site (cinq sites dans trois pays) les enjeux et impliquer l’ensemble de la communauté des utilisateurs. La définition de l’architecture informatique et la sélection des logiciels en complément de Windchill s’est déroulée jusqu’à fin 2010. Les dossiers d’exigences ont été constitués jusqu’à la fin de l’été 2011. Les développements ont commencé fin 2011 et ont duré environ deux ans et demi. Astrium Satellite dispose aujourd’hui d’une solution plm opérationnelle conforme aux principes établis par Phenix.

4. Conclusion

Les produits spatiaux en général et les satellites en particulier sont conçus avec une culture de développement prototype, par opposition à la production en série qui prévaut sur les avions, les hélicoptères et les lanceurs. Dans ce contexte, Phenix a fait émerger les principes et les solutions d’un système d’information plm permettant de gérer tous les produits du groupe eads pendant tout leur cycle de vie. Le travail a donné l’occasion de comparer les approches de gestion du cycle de vie, de partager les problèmes vécus et d’identifier des concepts communs malgré les différences inhérentes à chacune des divisions d’eads. Ces résultats ont à la fois confirmé la démarche de modernisation et d’harmonisation informatique engagée dans Astrium à la suite de la fusion industrielle au début des années 2000 et enrichi la vision pour aboutir à des solutions adaptées aux particularités du spatial. C’était le gage du succès, car les directions de programmes satellites n’attendaient rien moins que l’efficacité opérationnelle du plm. En effet, leur crainte était que Phenix impose une solution au titre du pouvoir central d’eads avec une vision influencée par la production en série des avions, sans avoir tenu compte des contraintes de développement unitaire des satellites et la forte culture documentaire imposée par les revues des clients.

Au niveau des outils, les choix d’harmonisation des progiciels pdm et cad ont permis de contrôler les coûts de licence et d’améliorer la qualité des services rendus par les éditeurs. Le remplacement des outils du passé par une architecture informatique rationalisée et des outils récents a été un changement conséquent dans l’environnement Astrium, mais structurant. En effet, l’état des lieux avant Phenix imposait de toute façon à Astrium de prendre des décisions d’investissement et de rationalisation sur le système d’information.

Au niveau des concepts et méthodes plm, Phenix a entre autres défini la notion de structure produit en réseau permise par les nouvelles générations d’outils pdm dans une gestion de configuration augmentée. Ainsi, le concept de « vue » sur la structure produit permet de retrouver les nomenclatures traditionnellement mises en œuvre dans l’industrie, mais de manière adaptée à chaque étape du cycle de vie, permettant ainsi de réduire la complexité des tâches de gestion et de vérification de cohérence pour les acteurs à chaque étape du développement. La mise en pratique sur les satellites a posé les bases de la gouvernance des données maîtres sur laquelle s’est dessinée la nouvelle architecture informatique d’Astrium. Les principes apportés par Phenix ont eu l’effet d’un catalyseur en permettant de désamorcer les résistances interculturelles et en facilitant les discussions entre les différents acteurs pour l’aboutissement des solutions aujourd’hui opérationnelles sur les satellites d’Airbus.