Vous êtes sur la page 1sur 35

Faire de la recherche

en management de
projet

Ouvrage collectif
Vuibert, 2004

Chapitre 12 – L’approche plate-forme 1


Chapitre 12

L’approche plate-forme : le management de familles de projets


articulés autour d’éléments communs : composants,
sous-systèmes, plates-formes
Christine TRIOMPHE et Sandrine FERNEZ-WALCH

Les entreprises ont à faire face aujourd’hui à une multiplication de projets variés et
interdépendants, pour des raisons présentées en détail dans le chapitre IX et résumées ici :
volonté d’accroître la variété des produits offerts, d’accélérer le rythme de renouvellement
des produits (améliorations continues et rupture radicale en permanence), d’être plus
innovant et de partager l’innovation plus rapidement entre les produits, désintégration
verticale de certains secteurs d’activité (exemple de l’informatique, de l’automobile) qui
pose la question de la coordination des coopérations inter-entreprises sur les projets. Il en
résulte, pour l’entreprise, la nécessité d’une gestion globale des interdépendances entre
projets. Dans le chapitre IX, trois formes de management multi-projets ont été présentées,
l’approche plate-forme est l’une de ces trois formes.

Ce chapitre aborde le problème du partage d’éléments entre projets de conception et de


développement de nouveaux produits dans une logique de standardisation et de recherche
d’économie de variété, partage qui peut se limiter à quelques composants, organes ou être
organisé de façon globale autour d’un système commun : la plate-forme. La plate-forme
représente un stade avancé de gestion du partage entre des projets qui pourraient être
conduits indépendamment. Cette volonté de partager des éléments pose des problèmes de
management multi-projets, principalement des problèmes de gestion de l’interdépendance
des projets, qui sont similaires dans leur formulation quel que soit l’élément partagé, mais
qui ont des impacts différents en fonction de l’importance de l’élément partagé. Par
conséquent, ce chapitre ne traitera pas seulement du problème des plates-formes au sens
strict, même si une large place leur est accordée, mais aussi de celui d’une démarche
systématique d’identification et d’exploitation des éléments communs à plusieurs projets.

Par conséquent, nous désignons de façon générique sous le terme « approche plate-forme »
la volonté d’une ou plusieurs entreprises de manager, de façon globale, un ensemble de
projets utilisant un ou plusieurs éléments communs (composants, organes, sous-systèmes,
systèmes, plate-forme) dans une double perspective : standardiser la conception tout en
différenciant au maximum les produits finis. Cette démarche vise un double objectif :
réduire les coûts et les délais de développement mais aussi réaliser des économies liées à la
standardisation tout au long de la chaîne logistique globale.

Cette démarche soulève de nombreuses questions, tant au niveau stratégique et


organisationnel de l’entreprise qu’au niveau de la création et du pilotage des projets.
• Comment découper et articuler les différents projets : projets de composants,
projets d’organes, projets de plates-formes, projets de produits finis ?
• Comment gérer les projets de plates-formes ? Comment maîtriser les risques
associés et évaluer leur rentabilité ?

Chapitre 12 – L’approche plate-forme 2


• Comment construire et manager un ensemble de projets articulés autour d’une
plate-forme, de sous-systèmes et/ou de composants communs (nous parlerons dans
la suite du chapitre de famille de projets) ?
• Comment coordonner les familles de projets ?
• Comment maîtriser les impacts organisationnels pour l’entreprise et les projets ?

Avant d’apporter des éléments de réponse aux problèmes de coordination des projets et des
familles de projets posés par une approche plate-forme dans la deuxième partie, nous
allons tout d’abord analyser, dans la première partie, en quoi consistent l’approche plate-
forme et le management des projets de plates-formes.

I L’approche plate-forme : une large diffusion


L’approche plate-forme est une solution adoptée par un nombre croissant d’entreprises
pour répondre au dilemme standardisation - différenciation, en jouant sur les processus de
conception et de développement des nouveaux produits. L’approche plate-forme repose sur
une architecture modulaire des produits, la plate-forme étant une forme avancée de gestion
de cette modularité (§1.1). Le processus de définition d’une plate-forme relève du
management stratégique de l’entreprise et a des répercussions sur le management des
projets et l’organisation des entreprises (§1.2). La plate-forme peut se présenter selon
divers environnements : plates-formes propriétaires et plates-formes ouvertes (§1.3). Les
plates-formes présentent des spécificités qui doivent être prises en compte dans le
management de tels projets (§1.4).

I.1. De la standardisation à la conception modulaire


Le problème de la diversité est étudié depuis de nombreuses années : il s’agit en effet de
limiter la diversité croissante car elle occasionne des coûts très importants. Dans le même
temps, les entreprises essaient de fournir des produits de plus en plus personnalisés. Cela
se traduit par des pressions simultanées pour augmenter la variété des produits et pour
réduire les coûts de revient. Deux stratégies complémentaires mais difficiles à concilier
sont utilisées : la standardisation des composants des produits et la différenciation, voire la
personnalisation, la plus forte possible pour les clients.

I.1.1. Le dilemme standardisation/différenciation


Selon Giard (1999), la standardisation est la « rationalisation de la conception d’une
gamme de produits homogènes partiellement interchangeables, destinée à couvrir un
ensemble de besoins ». La standardisation se traduit par l’utilisation d’un même composant
dans de nombreux produits au lieu de la limiter à un seul produit. C’est l’idée du terme
anglo-saxon « commonality » que nous traduirons par « communalité ». Ce partage de
composants entre les produits et, par conséquent, entre les projets de conception et de
développement, permet de diminuer les délais et coûts de développement (réduction du
nombre de prototypes par exemple), les coûts de la production et tout au long de la chaîne
logistique : augmentation des volumes de production permettant des économies d’échelle,
réduction des coûts de fabrication, d’approvisionnement, etc.

La standardisation nécessite une recherche de synergies en conception, fabrication et


distribution. Ce problème de rationalisation est du ressort de la stratégie industrielle. Il a

Chapitre 12 – L’approche plate-forme 3


un impact très fort sur la conception des produits, conception qui doit être abordée de
façon globale, au niveau des ensembles de produits partageant les mêmes composants.

La différenciation des produits finis vise à renforcer la compétitivité de l’entreprise en


proposant un ensemble de produits et/ou services spécifiques à des marchés et des clients
donnés. La prise en compte de la spécificité des attentes se traduit par une personnalisation
croissante des services rendus à la clientèle pour des biens d’équipement par exemple et
une segmentation de plus en plus fine des marchés dans le cas de biens de consommation.
Cette démarche, qui implique de pouvoir analyser de façon fiable et précise les attentes des
consommateurs et clients d’aujourd’hui, mais également les besoins de demain, bouleverse
les techniques de marketing et le rôle des acteurs du marketing. Elle a également des effets
sur la chaîne logistique et le management des projets de conception : comment concevoir
et produire un maximum de produits et/ou de services différant par un ou plusieurs
éléments de valeur pour le client, sans nuire à la compétitivité de l’entreprise puisque
justement l’objectif est de la renforcer ?

Dans le dilemme standardisation / différenciation, plusieurs points de vue s’affrontent,


celui du client, celui du projet, celui de la production, même si la nature des intérêts
respectifs des trois parties prenantes peut varier selon le secteur d’activité, le rapport de
l’entreprise au client (« business to business » ou « business to market »), le volume et la
nature de la production (produit unique, petites, moyennes ou grandes séries, flux continu
ou discontinu).
• Le client pousse à la différenciation ; sont mis en avant les dangers d’un partage de
composants communs entre des produits finis : exemple de Volkswagen avec des
modèles trop ressemblants (Volkswagen Polo, Seat Ibiza, Skoda Fabia).
• Comme on l’a vu plus haut, la standardisation offre des avantages en terme de
diminution des coûts et de délais de développement.
• La standardisation de la production permet des économies « d’envergure », en
particulier pour des grandes séries.
L’arbitrage économique doit prendre en compte les coûts de développement et les coûts de
production sur la durée de vie des produits (Gautier, 2003a).

Face au dilemme standardisation - différenciation, les entreprises ont adopté différentes


réponses en production et en conception. C’est le cas de la différenciation retardée,
largement diffusée. C’est le cas également du partage de composants et de sous-systèmes
entre plusieurs projets et du management d’un ensemble de projets partageant un système
complexe : la plate-forme. Le concept de plate-forme renvoie nécessairement à ceux
d’architecture et de modularité.

I.1.2. L’architecture modulaire : un premier pas vers la plate-forme


Le découpage du produit ou architecture est un élément très important dans la mesure où,
selon Ulrich et Eppinger (2003), il vise à définir la construction physique du produit en
termes de fonctionnalités des blocs (éléments du produit) et en termes d’interfaces. Cette
définition repose sur une vision fonctionnelle largement répandue, expliquant d’ailleurs la
diffusion de l’ingénierie système, le concept de système tenant compte de l’approche
fonctionnelle.

Une caractéristique fondamentale de l’architecture est son degré de modularité. Selon


Ulrich et Eppinger (2003), une architecture modulaire a les deux propriétés suivantes :

Chapitre 12 – L’approche plate-forme 4


• les blocs contiennent une seule (ou peu de) fonction(s) dans son (leur) intégralité,
• les interactions entre les blocs sont bien définies et sont généralement
fondamentales aux fonctions primaires du produit.
L’architecture la plus modulaire est celle dans laquelle chaque fonction du produit est
implémentée dans exactement un bloc physique et dans laquelle les interactions (ou
interfaces) entre les blocs sont bien définies et minimales. Les blocs peuvent alors être
conçus de manière séparée. L’opposée de l’architecture totalement modulaire est
l’architecture complètement intégrée (forte interdépendance des blocs qui répondent à
plusieurs fonctions primaires) et toute architecture se situe sur un continuum entre les
deux, comme cela est représenté sur le schéma ci-dessous.

Nous utiliserons, pour désigner les blocs, le terme module, défini par Gawer et Cusumano
(2002), comme « une partie du produit dont les éléments sont puissamment connectés entre
eux et relativement peu connectés aux éléments des autres parties ». Il en résulte qu’un
module peut être interchangeable avec un autre module assurant le même ensemble de
fonctions.

Dans la suite de ce chapitre, nous retiendrons que l’architecture d’un produit est définie par
une combinaison de modules et d’interfaces. À partir de cette définition, on peut imaginer
des situations variées en fonction de la standardisation des interfaces et de la spécialisation
fonctionnelle des modules.

Indépendance des
Dépendance des Standardisation modules (interfaces
modules des interfaces bien définies)

Architecture Architecture
Architecture Partage de basée sur une totalement
intégrée composants plate-forme modulaire

Un produit = un module un module = un module = une un module = une


= toutes les fonctions plusieurs fonctions fonction globale fonction de base

Spécialisation fonctionnelle des modules


Augmentation du nombre de modules

L’architecture dicte la nature des liens entre différenciation et standardisation des produits.
Une architecture modulaire facilite en général le partage d’éléments entre produits selon
des compromis à négocier lors de la conception. Lorsqu’une entreprise envisage le partage

Chapitre 12 – L’approche plate-forme 5


de modules entre produits, tout en essayant de différencier au maximum les produits, elle a
intérêt à favoriser une spécialisation fonctionnelle des modules, tout au moins en ce qui
concerne les fonctions perçues par le client et donc sources de différenciation. En effet, les
modules assurant la différenciation seront interchangeables et l’entreprise standardisera
des modules qui ne participent pas à la différenciation des produits.

Une entreprise peut décider de standardiser seulement quelques modules, avec peu
d’interfaces physiques ou des interfaces standardisées, et de les partager entre plusieurs
produits. C’est le cas des moteurs et des boîtes de vitesse par exemple pour les véhicules
automobiles. L’entreprise peut aussi choisir un ensemble de modules ou système qui
pourra être standardisé et partagé par plusieurs produits : la plate-forme.

I.1.3. Qu’est-ce qu’une plate-forme ?


Selon Meyer et Lehnerd (1997), une plate-forme est un « ensemble de sous-systèmes et
d’interfaces qui constituent une structure commune à partir de laquelle un flux de
produits dérivés peut être développé et fabriqué de manière efficace ». Cette définition est
double et donc complexe à manipuler. En effet, la plate-forme représente en même temps
le système central (qui correspond dans certains cas, mais pas obligatoirement, à un
dispositif physique d’accueil de modules) partagé par plusieurs produits, la plate-forme au
sens strict ; mais elle représente également l’architecture commune, permettant
l’interconnexion avec des modules de différenciation par des interfaces spécifiées. La
plate-forme détermine donc l’architecture de l’ensemble des produits dérivés et sert de
base au développement, dans des conditions économiquement intéressantes, de ces
produits dérivés.

Dans une approche plate-forme, on trouve donc deux types d’éléments : les éléments
servant à créer les produits dérivés, que nous appellerons modules de différenciation, et les
éléments servant à la standardisation des produits (composants communs, organes, plates-
formes), que nous appellerons modules standards.

Le flux de produits dérivés est souvent appelé famille de produits, bien que ce terme soit
utilisé de façon plus ou moins restrictive. Il s’agit d’un ensemble de produits particuliers
qui partagent la plate-forme et s’adresse à un ensemble homogène d’applications sur un
marché. Du côté clients, on peut reconnaître la présence d’une famille de produits
cohérente et bien positionnée à l’aspect de chacun des produits qui la composent. En même
temps, les produits sont suffisamment distincts pour que leurs utilisateurs leur attribuent
une valeur spécifique (Meyer et Lehnerd, 1997).

Un exemple souvent cité (Meyer et Lehnerd, 1997) est celui de la famille des imprimantes
Deskjet de Hewlet-Packard (HP). HP vend des imprimantes à des clients ayant des besoins
différents regroupés en trois segments de marché : famille, étudiants et « petits bureaux ou
petites entreprises ». Pour répondre à leurs besoins, HP aurait pu développer un seul
produit ou trois produits entièrement différents et lancer pour cela trois projets de façon
indépendante. La solution retenue par HP a été de construire une plate-forme commune et
de différencier les produits finis en modifiant seulement quelques modules. Le résultat est
que chaque imprimante a un design exprimant son appartenance à la famille des
imprimantes jet d’encre HP tout en répondant aux attentes spécifiques de chaque segment.

Chapitre 12 – L’approche plate-forme 6


Des produits complémentaires peuvent également être développés. Il s’agit de modules
optionnels d’extension du produit initial, qui utilisent les interfaces standardisées et
étendent les fonctionnalités du produit initial. Par exemple, le lecteur de disque ZIP sur un
ordinateur, ou le lecteur de DVD : ces 2 produits constituent des produits
complémentaires, qui peuvent être externes (initialement) à l’ordinateur ou qui peuvent
être intégrés physiquement. On parlera de produits complémentaires lorsque ces éléments
ne sont pas obligatoires au fonctionnement du produit de base.

La définition de l’architecture de la famille de produits, c’est-à-dire le découpage en


modules et interfaces, est essentielle car source de flexibilité statique (différenciation
possible à un moment donné, mesurée par la facilité à créer des produits dérivés) et
dynamique (évolutivité de la plate-forme dans le temps). En effet, l’architecture
détermine :
• la modularité interne de la plate-forme au sens strict (le système partagé), qui
conditionnera l’évolutivité de la plate-forme : une conception modulaire de la plate-
forme favorisera son évolution ;
• les interfaces externes de la plate-forme au sens strict (entre le système partagé et les
modules de différenciation) qui permettent le développement des produits dérivés et
des produits complémentaires.

Lorsque la conception des produits est fondée sur une plate-forme, l’architecture du
produit est modulaire. On assiste, dans de nombreux secteurs, à une recherche de
minimisation du nombre d’interfaces entre les modules, les interfaces étant limitées et
standardisées. Les concepteurs essaient de trouver un équilibre entre intégration et
modularité, qui se traduit souvent par :
• une augmentation de l’intégration fonctionnelle dans les modules (les modules
réalisent des fonctions plus globales, effet de zoom arrière), qui permet une
limitation du nombre de modules à gérer (de la conception à la production),
• une standardisation des liens entre modules.
La question centrale est le positionnement de la plate-forme sur un axe intégration –
modularité (voir le schéma § I.1.2) et la définition de son périmètre (que faut-il
standardiser et inclure dans la plate-forme ?).

Étant donné le caractère systémique de l’architecture modulaire des produits, un module


(appartenant à la plate-forme ou un module de différenciation) peut très bien être conçu
lui-même comme un système comportant une plate-forme et des modules de
différenciation. C’est le cas des systèmes d’électronique embarquée dans le secteur
automobile. On observe ainsi des logiques de plates-formes « en cascade » concernant, non
seulement une entreprise, mais également ses fournisseurs. Cela a forcément des
répercussions sur l’organisation de la filière et les modes de coordination entre ses
différents maillons.

La plate-forme a un caractère dynamique : elle est une base technique de développement


pour les projets de produits dérivés ; elle alimente les projets et évolue au fur et à mesure
que les développements de projets l’enrichissent (cas de l’électronique embarquée dans
l’automobile, Hémery et Kesseler, 1999). Les plates-formes de l’électronique embarquée
correspondaient au début à une platine équipée de quelques composants communs : une
fonction de réception audio (tuner), un microprocesseur et un amplificateur. Peu à peu,

Chapitre 12 – L’approche plate-forme 7


elles ont intégré également un système de positionnement satellite (GPS) et une fonction
de transmission (GSM).

La plate-forme semble être une solution séduisante pour les entreprises face au dilemme
standardisation - différenciation. Mais est-ce toujours possible ? La plate-forme est-elle
adaptée à toutes les situations ? L’architecture est-elle un choix de conception ou bien est-
elle imposée par des facteurs de contingence (complexité technique des produits par
exemple) ? Les plates-formes étudiées concernent surtout des projets « produits ». Qu’en
est-il des projets « ouvrage » ? Peut-on imaginer un ouvrage (réseau autoroutier,
bâtiment, etc.) conçu selon une logique de plate-forme ?

La plate-forme ne s’adapte pas seulement à des produits physiques mais également à des
produits virtuels, tels les logiciels. Comme l’expliquent Meyer et Seliger (1998), chaque
couche technologique, qu’il s’agisse de l’ordinateur, du système d’exploitation, du logiciel
ou de l’application, a une architecture produit qui peut donner lieu à une plate-forme.

Dans le développement de logiciels, la plate-forme est la structure commune à partir de


laquelle seront réalisées des applications dérivées, spécifiques à chaque segment de marché
ou à chaque client. Par exemple, dans une automobile, l’autoradio, ou le système multi-
média embarqué, est aujourd’hui souvent conçu selon une approche plate-forme, qui existe
à 2 niveaux : au niveau du système physique (cependant cet élément est le moins
standardisé), et surtout, au niveau du système de pilotage logiciel. La plate-forme
représente à peu près les 2/3 de l’application finale : elle est réalisée selon une architecture
modulaire, constituée d’un module central et de modules dédiés à chaque fonction (le
module de gestion du tuner, le module de gestion du lecteur CD, le module du lecteur
MP3, etc.). Des modules spécifiques permettent d’adapter la plate-forme aux besoins d’un
client. Dix à quinze applications d’autoradios différents peuvent être développées à partir
d’une même plate-forme logiciel pour différents constructeurs automobile.

I.1.4. La plate-forme, un « demi-produit clé » de l’entreprise ?


Le management multi-projets étant basé sur une gestion constructive des interdépendances
entre les produits, le choix de la plate-forme est fondamental. Comme on l’a vu plus haut,
une plate-forme a les attributs suivants :
• c’est un système central, contraignant l’architecture des produits, qui sert de base de
développement à un ensemble de produits (dérivés et complémentaires) ;
• ce système ne doit pas être un élément de valeur différenciateur pour les clients car il
doit être « partagé » par des clients différents dans la mesure où c’est lui que l’on
standardise ;
• il doit permettre à l’entreprise de trouver des effets bénéfiques à une standardisation.
Le choix d’une plate-forme est donc un processus de décision collectif, qui implique une
réflexion à un niveau stratégique de l’entreprise et qui fait le lien entre les différentes
fonctions de l’entreprise : production, logistique, recherche et développement,
marketing, etc..

Le processus de choix d’une plate-forme est peu étudié dans la littérature, hormis quelques
rares éléments sur les processus de décision : validation et sélection stratégique parmi
plusieurs alternatives (Halman et al., 2003). Pourtant, il contraint et engage fortement
l’entreprise à long terme. Une erreur dans le choix d’une plate-forme risque de remettre en
cause la rentabilité de l’entreprise, du fait, en particulier, de la rigidité introduite dans le

Chapitre 12 – L’approche plate-forme 8


développement de produits. Par ailleurs, la plate-forme intègre le progrès technique. Le
progrès technique étant très rapide, la définition d’une plate-forme à un moment donné ne
correspond pas forcément à celle définie plusieurs années auparavant (voir l’électronique
embarquée). D’où la nécessité de relier la réflexion sur les plates-formes avec le
management des ressources technologiques.

Selon Hamel et Prahalad (1990), les compétences-clés d’une entreprise lui permettent de
concevoir des produits-clés qui donneront naissance à des produits finis, valorisés sur des
segments stratégiques différents. Moisdon et Weil (1998) proposent la notion de "demi-
produit", comme élément de capitalisation des compromis dans des dynamiques
d’apprentissage collectif, favorisant ensuite l’intégration des évolutions technologiques
aux projets de développement de produits.

Nous considérons que la plate-forme est un des « demi-produits clés » qui se nourrit, et
incarne les compétences-clés de l’entreprise, à partir duquel l’entreprise va choisir ses
segments stratégiques et marketing. L’approche plate-forme représente une avancée pour
le modèle des compétences-clés auquel on a souvent reproché son manque
d’opérationnalité. Une analyse de la littérature récente montre le lien entre la définition
d’une plate-forme et les compétences-clés de Hamel et Prahalad (1990) ou l’approche par
les ressources (Wernerfelt, 1984). C’est l’idée d’un « cœur » d’actifs multi-dimensionnel
qui inclut les processus tout au long de la chaîne de valeur, la segmentation de marché, le
positionnement des marques, le rapport avec les fournisseurs et les distributeurs (Halman
et al., 2003). Ce cœur d’actifs multi-dimensionnel ne se traduira pas de la même façon
selon que l’on a affaire à des plates-formes propriétaires ou des plates-formes ouvertes.

I.2. Des plates-formes propriétaires aux plates-formes ouvertes


La diffusion de l’approche plate-forme concerne de nombreux secteurs d’activité
(automobile, électronique, informatique, logiciel, etc.) avec des logiques différentes : de la
plate-forme « produit » propriétaire, développée entièrement par une seule entreprise, à la
plate-forme ouverte, qui devient « générique », à la conception de laquelle plusieurs
entreprises participent. Ces différences ont un impact important sur les projets et leur
management : dans le premier cas, un projet entièrement conduit par l’entreprise
propriétaire, dans le second cas, à l’extrême, se pose la question de savoir qui manage,
investit, arbitre, décide dans le cadre des projets. Les deux logiques de plate-forme sont
présentées ci-dessous.

I.2.1. Les plates-formes propriétaires


Une plate-forme propriétaire est une plate-forme développée, utilisée et commercialisée
par une entreprise ou un groupe d’entreprises liées par des relations de partenariat, qui
peuvent être de nature contractuelle. La plate-forme et les modules de différenciation sont
conçus par le propriétaire de la plate-forme et/ou par des fournisseurs. Le propriétaire de la
plate-forme gère les évolutions de la plate-forme et est responsable des projets de produits
dérivés. Il peut gérer lui-même les interfaces de la plate-forme, ou demander à ses
partenaires d’assumer la responsabilité d’une ou plusieurs interfaces. Si la logique
modulaire est bien respectée, les modules de différenciation peuvent être conçus de façon
séparée. Les fournisseurs peuvent à leur tour, pour le ou les modules dont ils sont
responsables, adopter une approche plate-forme.

Chapitre 12 – L’approche plate-forme 9


L’exemple des imprimantes à jet d’encre Hewlett Packard (HP) décrit par Meyer et
Lehnerd (1997), est caractéristique des plates-formes produit propriétaires. À partir d’une
plate-forme initiale, la plate-forme DeskJet, il y a eu développement de produits dérivés
(DeskJet Plus, Deskwriter, DeskJet 500), extension des fonctionnalités de la plate-forme
par des modifications et améliorations fortes de certains modules (impression couleur par
exemple), puis le développement simultané de 2 plates-formes entièrement nouvelles
(conception base 0), présentant des modules et des architectures nouvelles (Plates-formes
600 et 800).

D’autres secteurs, automobile et aéronautique, constituent également des exemples


typiques. Dans ces secteurs, comme dans beaucoup d’autres, on a assisté à un
développement de la standardisation et de la modularité. Les avions sont conçus selon une
logique d’ingénierie système. Chaque avion est décomposé, non en sous-produits selon une
logique physique, mais en systèmes qui répondent à un ensemble de fonctions (système de
pressurisation par exemple) selon une classification appliquée par la profession. Les
anciens fabricants de composants sont ainsi devenus des systémiers, chargés de proposer
des modules de l’avion en réponse à un cahier des charges comportant, soit des fonctions
de haut niveau (fonctions de service en quelque sorte), soit des spécifications techniques de
besoin (spécifications reliées à des fonctions déclinées des fonctions de service).

Dans ce contexte, l’avionneur, ou le constructeur automobile, peut décider de faire


partager à plusieurs produits un ou plusieurs modules, voire une plate-forme. Les Airbus
(A 320, A 330, etc.) ont des tableaux de bord communs permettant au pilote de pouvoir
facilement passer d’un avion à un autre. Boeing, qui a longtemps différencié ses tableaux
de bord, est en train d’adopter la même pratique. Les constructeurs automobiles conçoivent
des modèles différents à partir d’une même plate-forme, comprenant le plancher, le
système de suspension, le tablier et les bavolets. C’est le cas de la Laguna II, de la Velsatis
et du nouvel Espace chez Renault. De l’extérieur, les trois produits paraissent
complètement différents, étant donné le design des véhicules, imaginé pour répondre aux
attentes de cibles distinctes. Ces véhicules partagent également un nombre important
d’organes (boîte de vitesse, moteurs, etc.).

Depuis quelques années, la tendance dans l’automobile est à l’accroissement de


l’utilisation de modules communs et de plates-formes. « Dans 4 ans, 85 % des modèles
seront fabriqués sur 3 plates-formes seulement » pour les 2 marques Peugeot et Citroën, a
déclaré le PDG de PSA J-M. Folz, (Capital, août 2001) « tout en diversifiant le plus
possible les gammes respectives des deux marques ». On voit même des firmes
concurrentes s’allier pour concevoir une plate-forme commune qui sera ensuite utilisée par
chacune des entreprises pour concevoir des produits spécifiques concurrents comme, par
exemple, le projet X83 entre Renault et GME, qui a donné naissance au véhicule utilitaire
Trafic, commercialisé par Renault. Cet exemple illustre bien les nouvelles formes de co-
pétition qui se développent largement aujourd’hui.

Dans le secteur automobile, on assiste à la désintégration verticale de la filière et à une


ouverture croissante de la plate-forme (Jolivet et Navarre, 2001). Comme cela a déjà eu
lieu au niveau de la production il y a quelques années (aujourd’hui, a peu près 70 % d’une
voiture n’est pas fabriqué par le constructeur), cette désintégration se poursuit aujourd’hui
au niveau de la conception des véhicules, avec une spécialisation croissante des entreprises
sur des compétences-clés. Le rôle des équipementiers a fortement évolué : ils sont passés
de sous-traitants fabriquant des pièces selon des cahiers des charges très précis à des co-

Chapitre 12 – L’approche plate-forme 10


concepteurs, autonomes et responsables de la conception de modules complets. Le projet
étant le lieu de l’intégration des compétences, ces évolutions ont des conséquences sur le
management de projet, qui doit intégrer ces nouvelles relations inter-firmes : co-
développement, co-conception, co-exploration, partenariat (Midler, 2001).

La plate-forme automobile est donc en train d’ouvrir ses interfaces. General Motor’s a
d’ailleurs proposé le projet AUTOnomy, qui consiste en la réalisation d’une plate-forme de
véhicule avec un châssis de type « skateboard », qui contient tous les systèmes principaux
du véhicule, avec des interfaces permettant la connexion facile de modules
complémentaires permettant d’adapter la plate-forme à de multiples usages (Maccormack,
2003).

I.2.2. Les plates-formes ouvertes, utilisées par un réseau d’entreprises


Une plate-forme ouverte est une plate-forme développée par une entreprise, qui devient
leader de plate-forme, mais qui est utilisée par un réseau d’entreprises pour développer des
produits dérivés et des produits complémentaires. Selon Gawer et Cusumano (2002), cette
configuration se développe de plus en plus et se trouve lorsque l’on a des produits
complexes avec les caractéristiques suivantes :
• des producteurs indépendants fabriquent les composants du produit,
• beaucoup d’entreprises développent des composants et peuvent innover,
• le taux de progrès technologique est rapide,
• la demande de produits complémentaires est incertaine.

Gawer et Cusumano (2002) ont repéré un certain nombre de leaders de plate-forme dont
Intel. Cette entreprise, initialement simple fournisseur de composants (micro-processeurs),
est devenue leader de plate-forme pour ordinateur de bureau (PC). Au départ, le PC est une
plate-forme propriétaire conçue par IBM ; IBM a décidé d’ouvrir les interfaces afin de
favoriser la diffusion de la plate-forme et fait évoluer son PC d’un état de plate-forme
propriétaire vers une plate-forme ouverte. Mais, l’innovation est venue d’Intel, le
fabriquant d’un des composants de la plate-forme, qui a fait évoluer la plate-forme. Intel a
modifié l’architecture de la plate-forme avec un impact potentiel important, en
introduisant, en autres, le bus PCI, interface entre la carte-mère et les cartes-filles (carte-
vidéo, carte-son, carte modem, etc.), et plus récemment, le bus USB, permettant la
connexion « hot plug-and-play » de modules complémentaires externes. Ces
standardisations d’interfaces ont permis le développement par de nombreuses entreprises
de modules de différenciation (les cartes-filles, par exemple) et la création de nombreux
produits complémentaires innovants (la web-cam, le lecteur de disque Zip auto-alimenté, la
clé-mémoire USB, par exemple). Microsoft a une stratégie un peu différente avec
Windows : cette entreprise occupe une position plus dominante avec un code propriétaire
et des interfaces partiellement ouvertes, et des stratégies d’élimination de certains
concurrents.

Dans les exemples précédents, la plate-forme est en fait une entité « générique » : en
ouvrant ses interfaces, la plate-forme devient à l’extrême une pure architecture avec des
interfaces standardisées et connues, le système partagé ayant disparu. Le PC a une
architecture entièrement modulaire, basée sur une plate-forme « générique », définissant
les règles de découpage en modules et les interfaces standardisées ; tous les modules
(standards ou de différenciation) peuvent être fabriqués par des entreprises différentes,

Chapitre 12 – L’approche plate-forme 11


certaines entreprises réalisant l’assemblage des modules et créant par là même des produits
dérivés.

Les leaders de plate-forme doivent collaborer avec d’autres entreprises pour créer les
nouvelles générations de produits. Ils doivent trouver un équilibre entre concurrence et
collaboration avec les fabricants de produits dérivés et complémentaires, dont les produits
sont nécessaires au succès de la plate-forme. Les leviers des leaders de plate-forme
tournent autour de l’architecture du produit : le degré de modularité, l’ouverture ou non
des interfaces, la gestion de la propriété intellectuelle et la diffusion ou non de
l’information aux entreprises du réseau pour la conception des produits complémentaires.
La standardisation et l’ouverture des interfaces permettent la diffusion et la croissance du
réseau d’entreprises utilisant la plate-forme, ce qui assure un retour sur le leader, mais
présente le risque pour le leader de se voir concurrencer et de perdre sa position
dominante.

Dans de nombreux secteurs d’activité, se sont diffusées les logiques de conception


modulaire et de plates-formes, qu’elles soient de type plate-forme produit ou plate-forme
« générique », qu’elles soient de type propriétaire ou ouverte. Ces logiques permettent de
diminuer le coût de l’innovation, qui peut être réalisée indépendamment sur les modules
lorsque l’architecture est modulaire. Ces logiques ont des conséquences importantes sur le
management de projets. Elles encouragent l’émergence de sociétés spécialisées dans la
conception et la fabrication d’un module. Elles intensifient les problèmes de conduite des
projets liés à l’éclatement des frontières organisationnelles et à l’apparition de nouveaux
modes de collaboration inter-entreprises (voir le chapitre VIII). Par ailleurs, se pose la
question de savoir, en particulier pour les projets de plates-formes propriétaires, si ces
projets doivent être conduits indépendamment ou non de ceux visant à développer des
produits dérivés.

I.3. Comment manager les projets de plates-formes ?


Selon Meyer et Lehnerd (1997), le processus de développement d’une famille de produits
comporte cinq phases :
• définition de la stratégie de plate-forme,
• identification des éléments - clés de la plate-forme,
• élaboration d’une conception structurée de la plate-forme (architecture) et définition
des blocs correspondants,
• établissement du plan de lancement des produits dérivés,
• organisation d’une équipe pluridisciplinaire autonome pour le développement de la
plate-forme.
Dans ce processus, la conception d’une plate-forme apparaît, non seulement comme une
étape d’une stratégie clairement identifiée, mais également comme devant faire l’objet
d’un projet particulier. En réalité, il semble que la naissance d’une plate-forme renvoie à
des situations plus variées :
• Un produit fini sert au développement de produits dérivés et devient progressivement
une plate-forme, sans qu’il y ait eu au départ de stratégie délibérée. Ce cas, évoqué par
Halman et al (2003), semble relativement fréquent.
• Les plates-formes existent déjà dans l’entreprise et constituent la base du
développement de nouveaux produits. Des projets de nouvelles plates-formes sont
décidés afin de faire évoluer les plates-formes existantes.

Chapitre 12 – L’approche plate-forme 12


• La plate-forme est construite dans le cadre d’une stratégie délibérée autour d’une
nouvelle technologie ou d’un savoir-faire : la nouvelle technologie devient le cœur
d’un sous-système permettant le développement d’une famille de produits ; c’est
l’exemple du développement du Walkman chez Sony : en 1990, Sony dominait le
marché avec 200 modèles basés sur seulement 3 plates-formes (Clark and
Wheelwright, 1992b).

Deux questions sont posées.


• Le débat récurrent sur la place de l’émergent et du délibéré en management est lancé.
Doit-on définir une plate-forme à partir d’une stratégie délibérée (planification
stratégique par exemple), auquel cas se pose la question de savoir si la direction
générale a la connaissance permettant d’identifier les innovations possibles ? Vaut-il
mieux faire émerger la plate-forme, en considérant par exemple (Moisdon et Weil,
1998b), que l’innovation vient surtout des échanges entre les concepteurs dans le cadre
de stratégies ascendantes ?
• Lorsque la conception d’une plate-forme est un processus délibéré, doit-on intégrer le
développement de la plate-forme dans un projet de développement de produit dérivé ou
bien créer un projet spécifique pour respecter les particularités de la conception d’une
nouvelle plate-forme ? Cette question est cruciale pour les managers car elle renvoie à
des problèmes organisationnels complexes liés au dilemme standardisation -
différenciation.

I.3.1. Les particularités des projets de conception d’une plate-forme


Les projets de création de plates-formes sont d’une part, des projets de développement
d’un système non achevé qui sera partagé et réutilisé par plusieurs projets, et, d’autre part,
des projets ayant généralement un fort caractère innovant. Ils renvoient aux projets de
« demi-produit », étudiés par Moisdon et Weil (1998b), Hatchuel et Weil (1999), et aux
projets d’offre innovante (POI) caractérisés par Lenfle et Midler (2002). Selon Lenfle et
Midler (2002), un POI cherche à « élaborer des connaissances sur un couple
fonctionnalités/principe technique », connaissances qui pourront ensuite être déclinées en
une variété d’applications. Les POI présentent cinq caractéristiques qui les rendent
difficiles à gérer : difficulté à spécifier le résultat du projet, ambiguïté stratégique,
innovations « poussées » dans la filière, nécessité de créer de nouvelles connaissances,
« urgence masquée ». Nous allons analyser le cas particulier d’un projet de création de
plate-forme en reprenant ces caractéristiques.

• Une difficulté à spécifier le périmètre de la plate-forme et les résultats à


atteindre
Les projets de plates-formes, comme les POI, concernent des produits intermédiaires pour
lesquels le marché de référence est difficile à cerner : prévisions à long terme, prise en
compte d’attentes différentes (selon les produits dérivés). Par conséquent, les objectifs du
projet sont plus flous. La solution proposée doit rester suffisamment ouverte pour
permettre les développements futurs de produits dérivés. Or, le marché du futur produit est
un repère important dans la conduite d’un projet : il sert à définir le concept du produit, à
construire une solution par rapport à un référentiel, à évaluer la pertinence de scénarios de
conception, à justifier économiquement le projet (projets à rentabilité contrôlée). Dans un
projet de plate-forme, quelle orientation donner ? Cette question pose le problème des
frontières de la plate-forme et du partage des fonctionnalités entre la plate-forme et les
futurs produits dérivés : que faut-il inclure dans la plate-forme ? Qui décide du périmètre ?

Chapitre 12 – L’approche plate-forme 13


Par ailleurs, ces projets nécessitent généralement des investissements importants et, dans le
même temps, posent le problème de l’évaluation de l’intérêt (financier en particulier) d’un
projet complexe et de long terme (peu traité dans la littérature). Comment affecter les coûts
de développement, comment réaliser l’arbitrage économique ? Pour un projet de plate-
forme comme pour un projet de module commun, conduire une étude de rentabilité isolée
ne semble pas pertinent car la recette n’est perçue que sur un produit fini intégrant
éventuellement ces éléments. Ce problème d’évaluation est analysé par Gautier et Giard
(2000).

• Une ambiguïté stratégique


La conception d’une nouvelle plate-forme peut conduire à des modifications de
l’architecture des produits, la nouvelle architecture servant de base pour les
développements futurs. La rigidité technique induite crée des incertitudes techniques
(atteinte des fonctionnalités ?), des prises de décision très engageantes, des contraintes de
production. Ces projets peuvent donc remettre en cause des situations et fonctionnements
acquis (voir la deuxième partie de l’article) et sont par là même stratégiquement ambigus.
« L’ensemble des possibles est largement ouvert, où se nouent les ruptures technologiques,
où peuvent se construire des stratégies avec des enjeux considérables » (Lenfle et Midler,
2002). Par ailleurs ces projets risqués, déconnectés des marchés, posent le problème de
l’arbitrage stratégique entre des actions de court terme et des actions de long terme.

• La question de l’évolution de la plate-forme


La question centrale est de savoir qui a l’initiative de la création ou de l’évolution de la
plate-forme : le « propriétaire » de la plate-forme, un des co-concepteurs, ou un des
membres du réseau dans le cadre des plates-formes ouvertes. Dans un certain nombre de
cas, et particulièrement dans le cadre des plates-formes ouvertes, ces projets soulèvent de
nouvelles questions : Comment convaincre les partenaires, les co-concepteurs, etc.
d’adhérer au projet en adoptant la nouvelle technologie ou en acceptant l’évolution de la
plate-forme ? C’est le cas par exemple d’Intel lorsqu’il fait évoluer la plate-forme du PC
en modifiant l’architecture et en créant le bus PCI.

• La nécessité de créer de nouvelles connaissances


Ce besoin existe dans les projets de plate-forme lorsque celle-ci est très innovante
techniquement. Ce type de projet nécessite alors de créer de nouvelles connaissances. Ce
point sera traité en détail dans le chapitre XI.

• Une nouvelle temporalité


Comme pour les POI, il est nécessaire d’accorder à un projet de plate-forme le temps
nécessaire à l’expérimentation et à la réflexion. Cette situation présente le risque de voir le
projet ne jamais aboutir. Pour Lenfle et Midler (2003b), « la désynchronisation des
dimensions « technique » et « marché » augmente le risque de ne jamais converger ». Il y a
donc lieu d’organiser « l’urgence » dans le projet afin de favoriser le processus de
convergence.

• Une architecture contraignante et commune à plusieurs produits


Cependant, les projets de plates-formes possèdent des spécificités. La notion d’architecture
n’apparaît pas dans les autres POI, tels que le nouveau concept, la nouvelle technologie, le
prototype, ou bien dans la notion de « lignée de produits ». Cette notion d’architecture a un
impact fort sur l’articulation et l’organisation des projets gravitant autour d’une plate-

Chapitre 12 – L’approche plate-forme 14


forme, éléments qui seront développés dans la deuxième partie du chapitre. Par ailleurs, les
projets de plates-formes comme, d’ailleurs, les projets de conception de composants et de
sous-systèmes communs, portent sur un élément qui sera partagé et réutilisé par plusieurs
projets, ce qui pose le problème de la coordination entre les projets (voir la partie II). La
conception d’éléments communs nécessite de prendre en compte simultanément les
besoins et exigences liés à plusieurs produits.

Étant donné toutes ces spécificités, faut-il créer des projets spécifiques pour la conception
d’une plate-forme ou bien coupler ce projet avec un projet de développement de nouveau
produit ?

I.3.2. Faut-il créer des projets spécifiques pour la conception des plates-formes ?
L’analyse des projets dédiés de plates-formes est très peu développée dans la littérature,
soit parce que ce n’est pas le cas le plus fréquent (l’intégration du développement d’une
plate-forme dans un projet de développement de nouveau produit étant peut-être plus
répandue en pratique), soit parce que cette solution introduit une situation complexe
nouvelle particulière. Nous présentons ici les avantages et inconvénients de chaque
alternative, en tenant compte des spécificités énoncées ci-dessus.

• Intégrer la conception d’une plate-forme dans un projet de développement de


nouveau produit
Ce choix présente les avantages d’une mobilisation plus forte des équipes de
développement sur un produit fini avec un marché mieux identifié, et d’une meilleure prise
en compte des exigences du produit.
Les risques sont les suivants : des solutions trop spécifiques à un produit et pas assez
génériques ; des solutions trop orientées vers le court terme ; une différenciation des
produits finis au détriment de la standardisation des composants ; un projet focalisé sur le
respect du triptyque Qualité, Coût, Délai alors que le niveau élevé d’incertitude et de
nouveauté augmente fortement les risques du projet. Par ailleurs, quel produit privilégier
dans une logique de famille de produits ? Par exemple, chez Renault, lors du
développement de la plate-forme de la famille de véhicules du segment M2S, quelle
voiture choisir pour développer la nouvelle plate-forme ? La voiture du segment M2 (la
Laguna2), marché le plus important en volume et le plus rentable ? ou la voiture du
segment S (la Vel Satis), segment haut de gamme, qui doit présenter toutes les évolutions
technologiques ?
Comme pour tout projet, mais de façon plus intense, se pose alors la question du rapport
projet/métiers, avec la nécessité d’acteurs métiers très pointus, le savoir-faire étant
important, devant prendre en compte le progrès technologique, tout en renforçant la
transversalité car les enjeux et les risques sont plus importants.

• Créer des projets spécifiques pour la création de plates-formes


Le développement d’une plate-forme dans un projet spécifique présente les avantages
suivants :
• Ce projet à risque est théoriquement déconnecté des exigences de performance de court
terme mais pose en contrepartie, comme on l’a vu plus haut, le problème de l’arbitrage
stratégique entre le court terme et le long terme.
• Il est possible d’accorder à ce projet le temps nécessaire à l’expérimentation et à la
réflexion (temps laissé à l’exploration de nouvelles technologies).

Chapitre 12 – L’approche plate-forme 15


• Les projets de développement des produits ne sont pas freinés par les projets de plate-
forme (ou d’évolution de plate-forme).
Le problème des projets dédiés de plate-forme est pour l’entreprise d’assurer la
convergence d’un tel projet, plus éloigné des exigences du marché. Les projets classiques
de développement de produits suivent un processus formalisé et bien connu dans
l’entreprise, qui guide le développement. Des phases de durée fixée et des jalons rythment
le déroulement du projet avec une date finale correspondant au lancement du produit. Le
management de projet est focalisé sur un processus de convergence et de respect des
objectifs du projet : le triangle Qualité – Coût - Délai. Découpler un projet de plate-forme
et le développement de nouveaux produits oblige à réinventer l’organisation du processus
de décision dans le temps. La gestion de l’horizon temporel devient alors fondamentale : le
processus de pilotage doit laisser le temps de l’exploration tout en favorisant la
convergence et la capitalisation. Pour cela, la création d’événements est impérative pour
jalonner le projet et obliger à des focalisations successives. En effet, les dynamiques
d’apprentissage collectif sont favorisées par la création d’événements permettant de
coordonner les acteurs et de croiser les apprentissages (Moisdon et Weil, 1998b). Il est
nécessaire d’organiser la confrontation des différents points de vue et la recherche du
compromis. La capitalisation des compromis définit progressivement la plate-forme et son
périmètre.

Les deux logiques de développement existent aujourd’hui dans les entreprises. Certaines,
en particulier des équipementiers automobile, ont réorganisé leurs projets de
développement et sont passés d’une logique à l’autre : il y a quelques années, la plate-
forme était souvent développée dans le cadre du projet du premier produit ; aujourd’hui,
des projets spécifiques de conception de plate-forme sont lancés, avec des équipes de
développement et des chefs de projet dédiés.

Conclusion

Les projets de plate-forme sont des projets stratégiques pour l’entreprise, avec des
conséquences fortes sur l’architecture des produits, à plus long terme que les projets de
développement de produit, nécessitant souvent des investissements importants dont la
rentabilité est difficile à évaluer a priori. Ils interrogent et, par certains aspects, remettent
en cause certains des fondements du management de projet :
• les objectifs du projet et le fameux triangle Performances techniques / Coût / Délai,
sont difficiles à formaliser ;
• le processus de convergence est modifié et le processus de conduite du projet, le
« stage-gate process », peut être dans certains cas à réviser ;
• le processus de pilotage et de mobilisation des équipes est plus difficile ;
• les mécanismes de coordination et les structures organisationnelles sont perturbés :
comment dépasser les cloisonnements dus au cadre de référence des projets ? comment
réaliser un pilotage multi-projets ?

Chapitre 12 – L’approche plate-forme 16


II Le management multi-projets fondé sur l’approche plate-
forme
L’approche plate-forme bouleverse l’organisation du développement des produits dans la
mesure où elle crée de nouveaux types de projets, qui diffèrent par leur temporalité (durée
mais également temps de retour sur investissement), leur coût, leur niveau de risque,
l’incertitude de leur résultat, etc. mais ne peuvent être conduits sans tenir compte de leur
interdépendance, puisque l’approche plate-forme vise une gestion constructive des liens
entre projets (§ II.1). L’architecture des produits (§ II.2) impose des règles de coordination
au management multi-projets. Il en résulte une complexité organisationnelle, qui
questionne aujourd’hui les entreprises malgré des solutions exemplaires adoptées par
certaines (§ II.3).

II.1. L’approche plate-forme : une multiplication des projets


interdépendants
Une entreprise multi-projets peut avoir à gérer, simultanément et dans le temps, plusieurs
types de projets différents. En utilisant et en élargissant la typologie de Clark et
Wheelwright (1995), nous distinguons :
• les projets conduisant à des produits porteurs d’une rupture technologique, projets qui
sont très risqués mais nécessaires au succès à long terme de l’entreprise (qui peuvent
être des POI selon Lenfle et Midler (2003b)),
• les projets de création d’une plate-forme (couplés ou non avec les suivants), ou les
projets d’amélioration de la plate-forme, visant à prendre en compte le progrès
technologique dans l’architecture des produits,
• les projets conduisant à des produits dérivés, déclinés à partir des plates-formes,
• les projets qualifiés de « produits supports », dans lesquels les produits dérivés font
l’objet de changements mineurs (améliorations incrémentales) ; ces projets impliquent
d’ajouter ou de modifier certaines des caractéristiques des produits existants.
Aux quatre types de projets précédents, il faut rajouter les projets de conception de
composants et sous-systèmes communs à plusieurs produits.

L’ensemble des projets de conception et d’amélioration d’une plate-forme, de conception


et d’amélioration des produits dérivés, constitue une famille de projets. Mais ces projets ne
requièrent pas, comme on l’a vu plus haut, les mêmes modes de management et de
pilotage. Cela introduit un premier élément de complexité dans le management multi-
projets.

Un deuxième élément de complexité provient de l’architecture de plus en plus modulaire


des produits. Plus l’architecture des produits est modulaire, plus les projets peuvent, du fait
de l’inter-opérabilité, partager des composants, voire des modules et pas toujours à
l’intérieur d’une même famille de projets. Il s’agit non seulement de gérer les liens à
l’intérieur d’une famille mais également entre les familles. Le problème se complique
encore car des modules peuvent être eux-mêmes intégrés dans d’autres modules, ou des
plates-formes dans d’autres plates-formes.

Un troisième élément de complexité vient du fait qu’on est obligé de relier le portefeuille
de projets avec le portefeuille de produits, puisque l’approche plate-forme crée, via les
projets, des liens générationnels entre produits d’une même ligne et entre lignes de

Chapitre 12 – L’approche plate-forme 17


produits (Cusumano et Nobeoka, 1998). Ce problème est peu traité dans la littérature, du
fait notamment du cloisonnement entre les disciplines : marketing d’une part et
management de projet, ingénierie de la conception d’autre part. En pratique, le portefeuille
de produits est souvent du ressort du marketing stratégique alors que le portefeuille de
projets est plutôt entre les mains de la R & D. Se pose le problème de la frontière entre un
projet et la gestion quotidienne d’un produit, tout au moins pour les entreprises à projets à
rentabilité contrôlée.

Il faut également relier le portefeuille de projets avec le management des technologies et


des compétences puisqu’une plate-forme peut-être considérée comme un produit clé de
l’entreprise. Nous débordons ici du cadre du management multi-projets (ceci dit où est la
frontière ?) pour toucher à celui du management stratégique avec une réflexion stratégique
abordant les questions suivantes :
• Quelles nouvelles technologies développer ?
• Quelle architecture de produit (contraignante) ?
• Quelle évolution technologique de la plate-forme ?
• Quel partage des plates-formes ?
• Quelle planification des projets et quel rythme d’introduction des nouveaux produits
(plate-forme et produits dérivés) ?
• Quels nouveaux marchés viser ?

De nombreux auteurs insistent sur l’importance de la planification stratégique globale de


l’offre de produits (approche top-down), pour maximiser l’effet de levier et les synergies
entre les projets, et d’une vision à long terme des dynamiques des projets. Ulrich et
Eppinger (2003) proposent de construire trois plans : un plan produit, un plan de
différenciation et un plan des « communalités ». Le plan produit reflète la stratégie produit
de l’entreprise, identifiant les portefeuilles de produits à développer et l’échéance de
lancement sur le marché. Le plan de différenciation explique comment créer les multiples
versions d’un même produit, qui sera ainsi différent dans la perception qu’en a le client. Le
plan des « communalités » décrit le partage des éléments. Il en résulte un planning du
lancement des produits sur les cinq à dix prochaines années, les niveaux et types de
capitaux investis, l’agenda de R & D pour l’entreprise et ses fournisseurs.

Un certain type d’outil d’aide à la coordination des différents projets (nouvelles


technologies, plates-formes, produits dérivés), assez ancien, connaît un nouveau souffle
avec le développement du management multi-projets. Il s’agit du « technology roadmap »,
outil de représentation croisée des principales fonctionnalités des produits, des
technologies attendues et des projets de développement, en fonction du temps (voir le
chapitre XI pour une présentation de cet outil).

En conclusion, nous proposons une typologie des liens entre les projets en fonction de la
nature des projets liés :
• liens à l’intérieur d’une famille de projets : projets liés à la plate-forme mais aussi
au partage de sous-systèmes et composants communs,
• liens entre les familles de projets (problème de la coordination des familles qui
renvoie à une problématique de porte-feuille, voir le chapitre X),
• liens entre des projets de plusieurs familles du fait du partage de sous-systèmes et
composants communs,

Chapitre 12 – L’approche plate-forme 18


• liens entre les familles de projets, les familles de produits et le portefeuille de
technologies ou/et de compétences clés, ainsi que les autres POI.

Ces liens sont d’autant plus difficiles à coordonner qu’ils posent des problèmes de
synchronisation des transferts entre les projets, transfert de technologies simultané,
transfert séquentiel, mais aussi chevauchement entre les projets, comme le montre le
schéma suivant (Nobeoka et Cusumano, 1998).

Introduction du
nouveau projet
Nouveau projet
Type 1 : nouveau
concept.

Nouveau projet
Type 2 : transfert
de technologies
simultané.
Autre projet en cours

Nouveau projet
Type 3 : transfert
de technologie
séquentiel.
Projet antérieur (autre ligne de produit)
Type 4 : Nouveau projet
Modification de
concept.
Précédent

Dans ces conditions de complexité accrue, se posent les questions suivantes.


• Comment organiser le partage des composants, des plates-formes et des savoir-faire
(dimension métier) tout en conduisant de la façon la plus efficace possible chaque
projet pris séparément, en fonction de ses spécificités ? Comment permettre les
compromis inter-projets pour assurer une gestion constructive des liens et non une
mise en concurrence comme on la trouve souvent dans le cadre d’un management
de portefeuilles de projets ?
• Comment découper et coordonner les tâches de différents projets reliés par
l’architecture des produits en cours de conception ? Quel processus de coordination
mettre en œuvre ?
• Qui arbitre ? A qui confier l’autorité ? A un individu ? Lequel ? Un chef ou un
super-chef de projet ? Un directeur fonctionnel ? Un collectif ?
• Quel processus de décision mettre en œuvre ? Quel arbitrage technique ? Quelle
répartition des coûts, des ressources ? Quels processus, outils, procédures, etc. ?
• Quelles structures multi-projets adopter ? Quel équilibre entre projets et métiers ?
Quelles fonctions centraliser ? Quelles fonctions dédier aux projets ?

Chapitre 12 – L’approche plate-forme 19


II.2. L’architecture des produits fixe-t-elle les règles d’organisation ?
Le management multi-projets pose des questions du même type que celle relative au
management d’un projet mais pour un ensemble de projets. Une question essentielle est
celle du découpage. Comme les projets partagent une plate-forme, des modules et/ou des
composants, l’interdépendance des projets dépend donc en grande partie de l’architecture
de la famille de produits et de la nature des évolutions technologiques. L’architecture peut-
elle permettre de définir l’organisation et la coordination entre les projets ? Une « bonne »
architecture permet-elle de simplifier les liens entre les projets ? Comment prendre en
compte le caractère dynamique de l’architecture ?

L’architecture fixe des règles organisationnelles dans une approche plate-forme, pouvant
provoquer également des refontes profondes des processus de développement et
d’innovation.

II.2.1. L’architecture des produits, déterminant de l’organisation


Dès 1990, Henderson et Clark proposent une analyse permettant de compléter la
traditionnelle distinction entre innovation incrémentale et innovation radicale, en reliant
l’innovation et l’architecture des produits. Ils distinguent quatre types d’innovation en
croisant l’innovation sur les concepts-clés et l’innovation sur les liens entre les concepts.
Nous reprenons l’analyse de Henderson et Clark pour éclairer les modes de coordination
induits par l’architecture des produits dans le cadre d’une approche plate-forme. Rappelons
qu’une plate-forme est un ensemble de modules et d’interfaces standards, définissant une
architecture commune à une famille de produits dérivés. Les produits dérivés sont réalisés
par ajout/modification de modules de différenciation. Les interfaces désignent les liens
entre les modules. La plate-forme représente le système partagé, mais aussi l’architecture
d’ensemble des produits.

Le tableau ci-dessous est adapté de Henderson et Clark (1990) pour intégrer une vision
plate-forme. Nous parlerons de modules au lieu de concepts-clés et d’interfaces au lieu de
liens entre les concepts. L’analyse est illustrée par un exemple issu du secteur
informatique, caractéristique des plates-formes ouvertes « génériques ».

Chapitre 12 – L’approche plate-forme 20


Technologies et savoir-faire sous-jacents aux modules
Interfaces
Renforcés Modifiés
Innovation incrémentale (1) Innovation modulaire (2)
Inchangées Interfaces inchangées Interfaces inchangées
Modules variables (modification sans Nouveaux modules (incorporant de
Architecture rupture technologique) nouvelles technologies)
stable
Projet d’amélioration de la plate-forme Projet de nouveau module de
Projet de produit dérivé différenciation
Projet de module complémentaire

Exemple : passage du micro-processeur Exemple : module lecteur de CD/DVD


Pentium 1,6 GHz au Pentium 2 GHz Clé-mémoire USB
Innovation architecturale (3) Innovation radicale (4)
Modifiées Modules stables (modules pouvant varier Nouveaux modules (avec changement
mais sans changement de technologie) de technologies et savoir-faire)
Interfaces modifiées Nouvelles Interfaces
Architecture
évolutive Projet d’évolution de la plate-forme Projet de création d’une nouvelle plate-
forme

Exemple : introduction du bus PCI ; Exemple : Assistant Personnel de type


introduction du bus USB Palm ; Pocket-PC

Les quatre types d’innovation sont les suivants.


• L’innovation incrémentale consiste à modifier un ou plusieurs modules, sans changer
en profondeur les technologies et savoir-faire sous-jacents, ni les interfaces. Nous
mettons de façon un peu abusive les projets de conception de produits dérivés dans
cette catégorie bien qu’ils ne présentent pas toujours d’innovation (notamment lorsque
les produits sont différenciés seulement d’un point de vue marketing), car les
problèmes de coordination seront similaires. On trouve également les projets
d’amélioration intrinsèque des modules standards ou des modules de différenciation
(dans un but de réduction des coûts par exemple), sans changement d’interfaces entre
la plate-forme et les modules de différenciation.
• L’innovation modulaire consiste à modifier les technologies sous-jacentes à certains
modules mais sans toucher aux interfaces. L’innovation modulaire correspond
principalement à des projets d’innovation technologique sur les modules de
différenciation (par exemple, le remplacement du lecteur CD par un lecteur Combi-
CD/DVD) ou sur les modules complémentaires (par exemple, les clés-mémoires USB).
• L’innovation architecturale correspond à la reconfiguration d’un système établi. Les
interfaces entre les modules sont modifiées (en particulier entre la plate-forme et les
modules de différenciation), sans toucher aux technologies des modules. L’innovation
architecturale renvoie à des projets d’évolution de la plate-forme (et non de rupture)
mais qui ne modifient pas le concept fonctionnel des produits dérivés, donc de la
famille de produits. Par exemple, Intel a modifié l’architecture du PC et créé une
nouvelle interface PCI, permettant de connecter les anciens modules (par exemple, la
carte modem) sans que la technologie de ces modules ait été modifiée. Plus récemment,
Intel a proposé une innovation architecturale avec l’introduction du bus USB, qui

Chapitre 12 – L’approche plate-forme 21


renforce la conception modulaire du PC et autorise la connexion de nouveaux
périphériques, telles les clés-mémoires, tout en assurant la connexion des anciens
modules (souris, imprimante, etc.). Les clés-mémoires, qui constituent des modules ou
produits complémentaires, présentent la particularité d’être reconnues
automatiquement et de pouvoir être connectées « à chaud », ce qui était impossible
avec les anciennes interfaces.
• L’innovation radicale correspond à la création de nouveaux modules incorporant de
nouvelles technologies et de nouveaux savoir-faire, et dont les interfaces sont
modifiées. L’innovation radicale correspond à des projets de création d’une plate-
forme entièrement nouvelle (projet base Zéro), donnant naissance à une nouvelle
famille de produits (par exemple, la création de la plate-forme des assistants-personnels
de la famille Palm, ou celle des pocket-PC).

Les différents types d’innovation ont un impact sur les relations de dépendance entre les
projets et les mécanismes de coordination à mettre en place. Nous distinguons deux
situations extrêmes : une architecture stable et standardisée et une architecture qui évolue.

II.2.2. Une architecture stable et standardisée crée une flexibilité organisationnelle


Les interfaces entre les modules sont standardisées et non modifiées, situation qui
correspond, selon Henderson et Clark (1990), à un « dominant design » établi, c’est-à-dire
un ensemble de choix d’architecture non modifiés et connus. Cette situation, qui
correspond aux cas 1 et 2, peut permettre une flexibilité dans le développement des
produits car elle autorise une décomposition en différents projets selon une architecture
spécifiée et connue, ces différents projets étant relativement indépendants dans le cadre des
contraintes fixées par les interfaces.
• Elle offre une grande flexibilité en différenciation, qui autorise le lancement de
produits dérivés et de produits complémentaires nombreux, ce qui permet une
expansion sur les marchés existants et une extension vers des marchés nouveaux (cas
1).
• Elle permet le développement des modules de façon indépendante, notamment en
fonction des évolutions technologiques (cas 2). Ceci est très intéressant, en particulier
lorsqu’il faut différencier fortement les produits finis selon les marchés-cibles
(Muffatto et Roveda, 2002) ou lorsque le progrès technologique ne va pas à la même
vitesse selon les modules. Ce dernier cas se rencontre fréquemment s’agissant de
produits ayant une architecture avec un cycle de vie long et des modules dont les
technologies ont une durée de vie courte, comme par exemple, les satellites spatiaux ou
l’électronique embarquée dans l’automobile.
• Elle permet de lancer des projets de réduction des coûts sur des modules sans nuire aux
autres modules renforçant ainsi les effets de la standardisation (réduction des coûts sur
les modules communs et plates-formes).
• Elle permet d’explorer des scénarios et de geler le plus tard possible certaines options
techniques. La modularité favorise l’exploration parallèle de plusieurs solutions
(expérimentations simultanées, tests de prototypes en parallèle, etc.). Elle permet de
retarder les choix de conception et de retenir de meilleures solutions. Elle crée
l’opportunité pour les expérimentations, ce qu’interdit la conception intégrée (Spear,
1999).
• Elle autorise des logiques « d’innovation sur étagères » et de développement de demi-
produits, avec le découplage entre les projets innovants et risqués de nouvelles
technologies et le développement de produits nécessaire au renouvellement des

Chapitre 12 – L’approche plate-forme 22


gammes. Si le module est prêt, on l’incorpore, sinon, on garde l’ancien module d’où
une plus grande souplesse qu’avec une architecture intégrée. Selon Moisdon et Weil
(1998b), « les projets ne sont pas le lieu de toutes les innovations » car cela augmente
trop les risques de dérapage des projets ; les innovations doivent se faire en parallèle
des projets dans des groupes d’innovation, qui constituent des structures
d’accumulation des savoirs. Ils recommandent d’instaurer une transversalité
temporelle, permettant d’injecter dans les projets les innovations en fonction des
opportunités au moment adéquat.
Ces éléments aident à faire face à la complexité. Ils influencent fortement les modes
d’apprentissage de l’organisation. Selon Henderson et Clark, l’architecture du produit
favorise certaines pratiques et procédures spécifiques dans l’entreprise : des canaux de
communication formels ou non, des stratégies de résolution de problèmes, des filtres de
perception de l’information.

Dans une situation de stabilité des interfaces, on peut mettre en place des groupes de
développement par modules. Le développement d’un produit peut faire alors appel à
plusieurs équipes de développement quasi-autonomes, certaines pouvant être extérieures à
l’entreprise responsable de la plate-forme, ce qui se rencontre de plus en plus avec
l’ouverture croissante des plates-formes propriétaires (§ I.2.1). Les équipes ont une grande
liberté d’action à l’intérieur de chaque module car la logique d’interfaçage est stable. Ce
principe s’est développé dans l’automobile avec la conception des modules « black box »
(Clark et Fujimoto, 1991, Jolivet et Navarre, 2001) qui a profondément modifié les
interactions entre les constructeurs et les équipementiers. Les équipementiers réalisent la
conception détaillée des modules à partir de spécifications fonctionnelles et d’une
définition d’interfaces standards, selon une logique de co-conception (Garel, 1999). Dans
de nombreux secteurs (aéronautique, spatial, informatique, ingénierie), on assiste, selon
Navarre et Jolivet (2001), à une architecture des responsabilités autour de modules : la
complexité est gérée dans les modules, l’ensemblier étant centré sur l’intégration spatiale
et fonctionnelle des différents modules. Ce dernier garde la maîtrise de l’architecture et du
style de l’objet. Ces derniers préconisent d’ailleurs le remplacement des « structures
métiers » par des « structures objets » et l’articulation du management de projet autour
d’objets physiques, qui favoriseraient une intégration des compétences (marketing,
conception, fabrication, etc.) par la constitution d’équipes de projets multifonctionnelles
dédiées à un produit ou à un module donné.
• Les canaux de communication entre les groupes peuvent se faire selon les liens entre
les modules considérés par les entreprises partenaires comme critiques.
• Les filtres de l’information incorporent également la connaissance architecturale et des
stratégies de résolution de problèmes résument la connaissance acquise. Aussi
longtemps que le « dominant design » reste stable, une organisation peut segmenter et
spécialiser sa connaissance et s’appuyer sur des procédures standardisées pour la
conception et le développement des produits.

Lorsque l’architecture des produits est stable et standardisée, la plate-forme simplifie les
coordinations à court terme : l’architecture définit les règles de décomposition et
d’organisation des projets gravitant autour de la plate-forme, projets rendus relativement
indépendants du fait de la standardisation des interfaces ; en même temps, cette
architecture est contraignante pour le développement et l’évolution des produits. En
revanche, créer une nouvelle plate-forme peut s’avérer complexe car les transformations

Chapitre 12 – L’approche plate-forme 23


pourront avoir des impacts sur les interfaces entre les éléments. La modularité de
l’architecture de la plate-forme peut dans ce cas faciliter l’évolution de la plate-forme.

II.2.3. Une architecture évolutive oblige à repenser l’organisation multi-projets


Les évolutions de l’architecture ont des répercussions plus larges dans le cadre d’une
approche plate-forme car elles ont des impacts non pas sur un produit isolé, mais sur
l’ensemble des produits partageant la même plate-forme ou le même système. L’évolution
de l’architecture remet en cause les interfaces entre les modules et donc les découpages
organisationnels établis, et, par conséquent, l’organisation des projets de développement de
produits et les mécanismes de coordination et de coopération. Elles modifient les relations
entre les équipes de développement et les relations inter-entreprises.

L’innovation radicale (cas 4) établit, selon Henderson et Clark (1990), un nouveau


« dominant design », c’est-à-dire un nouvel ensemble de technologies et de savoir-faire
clés incorporés dans de nouveaux modules, qui sont reliés selon une architecture
également nouvelle. Elle nécessite donc de nouveaux modes d’apprentissage et de
nouvelles compétences, et ce besoin apparaît rapidement dans l’entreprise. L’innovation
radicale peut entraîner des bouleversements des positions dominantes des entreprises dans
un secteur d’activité : de nouveaux entrants bouleversent l’ordre établi en proposant une
nouvelle architecture pour un produit, et le leader se trouve souvent dans l’incapacité de
s’adapter suffisamment rapidement, phénomène observé dans plusieurs secteurs d’activité
par Henderson et Clark (1990) et Gawer et Cusumano (2002).

L’innovation architecturale (cas 3) semble plus difficile à maîtriser pour l’entreprise multi-
projets : comme les technologies des modules restent stables, l’entreprise ne comprend pas
les nouveaux liens critiques entre les modules, les nouvelles connaissances à développer et
les nouveaux mécanismes de coordination à mettre en place entre les équipes.
L’expérience est un handicap car l’entreprise est généralement organisée en fonction de
l’architecture du produit : il existe des groupes de développement de modules et les
interactions entre les groupes dépendent de l’architecture et des interfaces. L’innovation
architecturale a des implications concurrentielles importantes au niveau du réseau
d’entreprises concourant à la conception du produit.

Pour ces deux types d’innovation, le besoin d’évolution des produits peut être plus long à
appréhender et/ou à mettre en œuvre à cause des cloisonnements résultant de l’architecture
dominante. Il s’agit d’impulser une recherche active de nouvelles solutions en favorisant
un contexte de changement permanent. Des équipes trans-fonctionnelles et un
environnement ouvert favorisent l’apprentissage par rapport aux variations d’architecture
mais se heurtent dans ce cas à l’autonomie des équipes, autorisée auparavant par la
modularité de l’architecture. Une évolution de l’architecture exige une coordination
accrue, qui dépend de la temporalité des liens entre les projets (séquentiels ou simultanés),
et des évolutions organisationnelles. La coordination entre les équipes est difficile, surtout
si la plate-forme est ouverte.

Dans le cadre d’une plate-forme propriétaire, le propriétaire de la plate-forme conduit


généralement les évolutions de ses produits et les « impose » aux co-concepteurs. Les
modifications d’architecture, en modifiant les interfaces, nécessitent souvent des
adaptations des modules de différenciation. Ces adaptations peuvent être contraignantes
voire impossibles pour un co-concepteur lorsque l’élément à modifier est lui-même

Chapitre 12 – L’approche plate-forme 24


constitué d’une plate-forme ; une modification d’interface peut nécessiter une modification
de l’architecture de la plate-forme du module du co-concepteur, dans le cadre d’une
« nested modularity » (modules à l’intérieur de modules à l’intérieur de modules).
Réciproquement, on assiste de plus en plus à des modifications d’architecture initiées par
les co-concepteurs de modules.

Dans le cadre des plates-formes ouvertes, il existe un risque de sclérose de la plate-forme


car se pose de façon cruciale la question du leader de plate-forme dans le « réseau de
conception » : qui va prendre l’initiative de l’évolution ? Plus la plate-forme est ouverte et
le réseau d’entreprises important, plus les modifications d’architecture ont des impacts en
cascade. Amorcer une évolution architecturale nécessite de la part du leader d’investir avec
un risque important de ne pas être suivi par les autres entreprises du réseau. Le leader doit
donc être en mesure de mobiliser une partie du réseau d’acteurs et de les faire adhérer au
projet (Gawer et Cusumano, 2002). Se posent de façon accrue les questions de partage des
connaissances acquises, d’organisation des relations inter-entreprises : quels liens
(contrats ? pactes d’éthique ?) ? Quels droits de propriété intellectuelle ?

En conclusion, on voit que si une architecture modulaire stable et spécifiée offre une
flexibilité organisationnelle pour un développement quasi autonome, permettant
l’éclatement de la conception entre modules, une architecture variable et évolutive des
produits oblige à repenser totalement les modes d’organisation multi-projets et ceci semble
d’autant plus difficile que la plate-forme est ouverte. Ceci renforce l’intérêt des travaux de
recherche sur l’architecture modulaire.

II.3. Les modes d’organisation dans l’entreprise multi-projets


Comment organiser l’entreprise multi-projets ? Quels modes d’organisation mettre en
place pour tenir compte de l’architecture des produits et de la diversité des projets
(§ II.3.1) ? L’entreprise peut favoriser la coordination entre les projets en utilisant des
mécanismes d’ajustement mutuel ou en introduisant un début de formalisme via la
supervision directe (§ II.3.2). Dans ce dernier cas, se pose un problème de construction
d’un ensemble de projets qui renvoie à une logique de portefeuille, dont les contours sont à
définir en fonction notamment des liens entre les projets et/ou des spécificités de chaque
type de projets (§ III.3.3). L’entreprise peut également réfléchir en terme de partage
constructif des ressources humaines (§ III.3.4).

II.3.1. L’architecture agit sur les mécanismes de coordination métiers / projets


De nouveaux besoins de coordination entre métiers et projets apparaissent dans une
entreprise multi-projets. Nobeoka et Cusumano (1998), à partir des exemples de
Mitsubishi et Microsoft, mettent en évidence une organisation matricielle Métiers / Projets
qui tient compte de ces contraintes de coordination, la « matrice différenciée ». Cette
organisation permet aux départements métiers de se concentrer sur la standardisation des
composants des multiples projets, et aux projets de créer des produits différenciés, en
instituant des équipes distinctes, chargées de développer les composants qui
individualisent véritablement les produits. Le travail est réparti en quatre types de groupes
de développement :

Chapitre 12 – L’approche plate-forme 25


• les groupes « composants individuels » développent des composants simples qui
varient d’un produit à l’autre ; ils sont composés d’acteurs métier d’un même
département ; par conséquent, il n’est pas nécessaire d’introduire des mécanismes de
coordination entre départements ou entre projets ;
• les groupes « produit » développent des sous-systèmes différents d’un produit à
l’autre ; les sous-systèmes exigeant des expertises techniques différentes pour répondre
à une ou plusieurs fonctions, il est nécessaire d’introduire un mécanisme de
coordination entre les départements métiers : il faut donc envisager de créer des
groupes de travail inter-départements, mais la coordination entre plusieurs projets n’est
pas nécessaire ;
• les groupes « ingénierie composants » développent des composants communs à
plusieurs projets ; les groupes sont composés d’acteurs d’un même métier développant
le même composant mais pour des projets différents ;
• les groupes « ingénierie composants multi-projets » développent des sous-systèmes
communs à plusieurs projets ; ces groupes rassemblent des acteurs de départements
métiers différents qui interviennent sur tous les projets partageant le sous-système ; par
conséquent, une coordination inter-projets est requise, elle sera d’autant plus délicate
que l’architecture est non stabilisée.

Il nous paraît important de relier la matrice différenciée avec l’architecture des produits,
non suffisamment mise en relief. Nous avons construit le tableau ci-dessous qui analyse les
besoins de coordination inter-métiers et inter-projets en distinguant 4 situations. Ces
situations dépendent de la nature, de la complexité et du degré de transférabilité des
éléments partagés d’un projet à l’autre, et entre les projets et les métiers :
• cas 1 : composant ou module standards, dont les interfaces sont spécifiées et
stabilisées, ce type de module peut être conçu « de façon autonome » au sein d’un
département métier ; il peut s’agir aussi de module spécifique, par exemple module de
différenciation, développé pour un produit particulier, nécessitant pas ou peu de
coordination entre métiers (ce dernier peut être également développé au sein du projet-
produit et se trouve alors dans le cas 2 ; aujourd’hui, on a le plus souvent une
organisation matricielle) ;
• cas 2 : ensemble de modules constituant un sous-système ou un produit (dérivé) ; la
coordination des métiers est requise mais le produit (dérivé) peut être développé (en
tenant compte certes de la plate-forme dont il dépend) dans un projet de
développement produit classique ;
• cas 3 : composant ou module communs, ne nécessitant pas de coordination des métiers,
mais destinés à plusieurs produits ; ils nécessitent une coordination des projets plus ou
moins importante en fonction de la stabilité des interfaces ; ce type de module peut être
développé dans un métier ou dans un groupe module ;
• cas 4 : plate-forme nécessitant une coordination multi-métiers et multi-projets.

Chapitre 12 – L’approche plate-forme 26


Coordination des projets
Coordination métiers / projets
Non nécessaire Nécessaire

Modules standards
(interfaces spécifiées)
Modules communs
(interfaces non stabilisées)
Non nécessaire Modules spécifiques
(Cas 3)
(de différenciation ou
complémentaire)
Coordinatio
(Cas 1)
n des métiers

Ensemble de modules
(sous-système) d’un Plate-forme
Nécessaire
produit (dérivé) (Cas 4)
(Cas 2)

Les cas 1 et 2 correspondent au management de projets qu’on peut qualifié de


« classique », situation dans laquelle il n’y a pas de liens entre les projets ; par contre, les
cas 3 et 4 nécessitent le recours à un management multi-projets. Les besoins de
coordination peuvent être limités par l’architecture de la famille de produits, le fait de
disposer d’une architecture avec des interfaces stabilisées limitant les besoins de
coordination.

La grille d’analyse précédente nous permet de mieux comprendre l’exemple de Microsoft


(Nobeoka et Cusumano, 1998). Microsoft doit coordonner de multiples projets, avec des
transferts de technologie simultanés entre ces projets. Pour le développement du produit
Microsoft Office, trois groupes « produit », appelés « unités produit », conçoivent les
applications : Excel, Word et Power Point. Il en résulte des produits nettement différenciés.
Néanmoins, ces 3 groupes se coordonnent pour l’agencement du pack Office (agencement
du menu de base, implantation des outils, etc.). Les groupes « produit » développent les
modules spécifiques à leur produit (par exemple, la fonctionnalité Diaporama de Power-
Point) mais ils peuvent également concevoir des modules et des composants communs à
tous les logiciels Microsoft. Le groupe produit Word, par exemple, conçoit le traitement de
texte pour tous les logiciels Microsoft. Dans ce cas, les acteurs du groupe « produit » qui
travaillent sur ce sous-système commun forment un groupe « fonctionnel multi-projets » et
doivent se coordonner avec les autres groupes « produit ». Des groupes « composants »
développent les composants, qui exigent peu, voire aucune coordination entre
départements fonctionnels (métiers), ces composants peuvent être réutilisés par les groupes
« produit » sans accorder d’attention particulière à leurs spécifications (module
d’impression ou module de gestion de fichiers). Pour les composants dont la réutilisation
par les autres groupes « produit » nécessite des caractéristiques ou des modifications
spéciales, Microsoft utilise des groupes « composants multi-projets ».

Dans ce découpage, des groupes sont identifiés sans que les responsabilités et les liens
hiérarchiques ne soient précisés. Quels liens entre ces différents groupes ? Qui arbitre en
cas de conflits ? Microsoft, pourtant choisi comme exemple d’application de la matrice

Chapitre 12 – L’approche plate-forme 27


différenciée, montre, qu’en pratique, il n’est pas si simple d’organiser le travail en fonction
de l’architecture des produits, ceci pour plusieurs raisons.
• Il ne suffit pas de répartir le travail en fonction de la nature des modules (simple
composant ou système, spécifique ou partagé par plusieurs projets). Il s’agit
également de prendre en compte les autres caractéristiques d’une architecture
modulaire : les interfaces entre modules (en particulier leur variabilité) et le
caractère évolutif dans le temps des modules. C’est d’ailleurs ce qui fait le
caractère concourant des liens entre projets.
• Comment gérer le fait que certains acteurs appartiennent à plusieurs groupes de
travail ne poursuivant pas toujours les mêmes objectifs ?
• Comment coordonner les différents groupes ? Quelle articulation des groupes et des
métiers, des groupes et des projets ?
• Comment réaliser les coordinations entre projets en pratique ?

II.3.2. Ajustement mutuel ou supervision directe ?


Les modes de coordination utilisés concrètement dans le cadre d’une organisation multi-
projets ont été étudiés par Cusumano et Nobeoka (1998). Ces derniers ont menés des
entretiens auprès de directeurs de projets automobiles aux Etats-Unis et au Japon, qui
indiquent quatre méthodes pour coordonner les multiples projets, qui sont classées ici par
ordre d’efficacité décroissante (49 %, 35 %, 12 %, 4 %) et illustrées (1, 2, 3, 4) sur le
schéma n° 3 :
1. la coordination directe entre directeurs de projets (lors de réunions par exemple),
qui renvoie selon nous au mécanisme d’ajustement mutuel (Mintzberg, 1982),
2. la coordination par un responsable au-dessus des directeurs de projets (supervision
directe selon Mintzberg, 1982),
3. coordination par un directeur fonctionnel : chaque directeur coordonne le travail au
niveau des technologies ou des composants dont il est responsable : (supervision
directe selon Mintzberg, mais par rapport aux expertises techniques),
4. coordination directe entre ingénieurs travaillant sur des projets distincts (observé
dans les départements fonctionnels uniquement et assez rare) ; il s’agit selon nous
d’un ajustement mutuel mais au niveau des tâches des projets et non d’une façon
globale entre projets.

Chapitre 12 – L’approche plate-forme 28


Fonction 1 Fonction 2

3 Directeur général

Directeur de projet

2 1 4 Directeur fonctionnel

Ingénieur

Modes de coordination inter-projets (Cusumano et Nobeoka,


1998)

Il ressort de l’étude que le mécanisme considéré comme le plus efficace est l’ajustement
mutuel. Cela laisse à penser qu’une entreprise multi-projets fondée sur une approche plate-
forme doit réfléchir à deux types de dispositifs organisationnels pour favoriser cet
ajustement mutuel :
• des mécanismes de relations interpersonnelles : contact direct, ajustement mutuel,
volontaire (confiance…), communautés de pratiques, forums, plateau, etc …
• des mécanismes plus formalisés, relevant de la hiérarchie : mécanismes
structuraux, procédures portant sur les tâches, responsabilités du management inter-
projets. La matrice différenciée (§ II.3.1) est une solution adoptée par certaines
entreprises, comme le principe de double responsabilité évoqué par Cusumano et
Nobeoka (1998). Dans une entreprise automobile organisée en matriciel, la
hiérarchie confie la responsabilité d’un composant à un acteur métier. L’acteur
métier, tout en appartenant à une équipe projet, est chargé de la coordination du
développement du composant dans tous les projets qui l’utilisent. Il s’assure que les
projets partagent bien le composant et que les équipes projet se transmettent les
informations adéquates concernant le composant.
Cependant, l’étude montre, que même si l’ajustement mutuel est le mode de coordination
le plus cité, la supervision directe n’en demeure pas moins importante (35 %). Cela
explique probablement l’apparition, depuis peu, de nouveaux échelons hiérarchiques dans
l’entreprise comme celui de directeur multi-projets.

II.3.3. Des Directions multi-projets pour une optimisation globale du pilotage ?


Raisonner sur l’organisation du management multi-projets fondé sur une approche plate-
forme nécessite d’introduire une problématique de portefeuille de projets (voir le
chapitre X).

Si la prise en compte de l’architecture semble plus importante que la gestion des


différences entre les types de projets, une solution consiste à faire superviser par un même

Chapitre 12 – L’approche plate-forme 29


acteur ou groupe d’acteurs (acteurs pouvant appartenir à des entreprises différentes, en
particulier dans le cadre d’une plate-forme ouverte), une famille de projets, car celui-ci
aura une vision globale et stratégique des liens entre les projets créés par l’architecture des
produits. Ce peut être une solution particulièrement séduisante lorsqu’on se trouve dans
des situations d’interfaces peu stabilisés. On peut imaginer de créer un portefeuille par
famille de projets, quitte, si le nombre de projets à l’intérieur de la famille est conséquent,
à le scinder en sous-portefeuilles (créés par exemple en fonction des débouchés des
produits finis). Le responsable de portefeuille aura plus ou moins de pouvoir sur les chefs
de projets dont les projets sont dans le portefeuille (on s’éloigne du problème du périmètre
du portefeuille pour aborder celui de la définition du type de responsabilité qu’exerce un
responsable de portefeuille, voir le chapitre X).

Dans ces conditions, émerge un nouveau pôle de responsabilité, la direction multi-projets.


La direction multi-projets est responsable d’une famille de projets. Elle supervise plusieurs
directeurs de projet, assure une mission d’optimisation globale : coordination, allocation
des ressources et arbitrage entre les projets d’une même famille. Elle est responsable de la
rentabilité de la famille (façon de faire le compromis économique), ce qui favorise les
analyses de rentabilité globale (Gautier et Giard, 2000). Elle est chargée de coordonner les
différents projets portant sur l’ensemble des produits finis de la famille et ceci sur la
totalité du cycle de vie des produits. En même temps, il est préférable, pour relier projets et
produits finis, de lui faire assurer la coordination stratégique du renouvellement d’un
ensemble restreint de gammes de produits (« direction de gamme »).

Si l’entreprise préfère prendre en compte des modes de fonctionnement et de pilotage


différents pour des projets de nature différente plutôt que les liens liés à l’architecture (plus
facile dans le cadre d’une architecture modulaire), alors elle aura des portefeuilles
réunissant des projets de familles différentes, mais possédant les mêmes attributs :
portefeuilles de projets de plates-formes, portefeuilles de développement de projets
dérivés, portefeuille de projets d’amélioration des produits dérivés, auxquels on affectera
des responsables différents. Tous les projets de plates-formes seront comparés les uns aux
autres et réfléchis globalement, en articulation avec la stratégie de l’entreprise. Il en sera
de même entre les projets dérivés. Cette situation présente plusieurs avantages : bien relier
les projets de produits dérivés aux marchés cibles, avoir une vue d’ensemble des liens
entre tous les produits de l’entreprise et pas seulement ceux liés à la plate-forme ou aux
composants communs, bien articuler les projets de plates-formes au management des
technologies et des savoir-faire. Par contre cela implique nécessairement de mettre en
place des dispositifs organisationnels permettant des interactions entre les portefeuilles
pour prendre en compte les liens d’architecture concourants : réflexion stratégique globale
sur l’ensemble des portefeuilles, communautés de pratiques, forums, etc.. Le principe de
double responsabilité, déjà évoqué, nous paraît particulièrement pertinent dans cette
configuration ; les dispositifs de partage des connaissances (voir le chapitre XI) également.

Une situation intermédiaire, qui pourrait peut-être créer un compromis entre ces deux
extrêmes, est d’avoir un portefeuille de projets de plates-formes et plusieurs portefeuilles
de projets dérivés, spécifiques pour chaque famille de produits. On peut imaginer
également d’avoir des portefeuilles correspondant aux familles de projets, divisés ensuite
en deux portefeuilles, un portefeuille réunissant les projets de conception et d’amélioration
de la plate-forme et l’autre les projets dérivés issus de cette plate-forme.

Chapitre 12 – L’approche plate-forme 30


II.3.4. Organiser le partage des ressources de façon constructive
Comme le montrent les paragraphes précédents, le management multi-projets fondé sur
une approche plate-forme oblige les entreprises à repenser les mécanismes de coordination
du travail : à l’intérieur des projets, entre les projets, entre les projets et les départements
métiers. Se posent ainsi des problèmes d’affectation, de partage des ressources et plus
largement de design organisationnel, problèmes qui dans la pratique, sont loin d’être
résolus. En théorie, ces problèmes sont peu traités, ou alors sous un angle particulier, et
non selon une approche intégrée de l’organisation multi-projets (exemple de la matrice
différenciée, présenté dans le paragraphe II.3.1). Aussi, nous proposons ici, non pas des
réponses organisationnelles, qui restent à inventer, mais une démarche de réflexion à
l’intention des praticiens qui souhaiteraient mettre en œuvre un management multi-projets
fondé sur une approche plate-forme. Nous pensons que, dans une approche plate-forme, le
partage des ressources, et plus généralement le changement organisationnel doiventt être
réfléchis en posant les quatre questions suivantes, qui découlent de la réflexion que nous
avons menée tout au long de ce chapitre.

• Faut-il découpler les projets de conception de plates-formes des projets de


produits dérivés ?
La question se pose surtout dans le cas des plates-formes « produit » et pour l’entreprise
propriétaire de la plate-forme. S’il y a découplage, où conduire les projets de plates-
formes ? Dans une direction métier ? En créant une entité (juridique) spécifique ? Si non,
quel produit dérivé choisir ? Comment éviter les inconvénients présentés dans le
paragraphe sur le management d’un projet de plate-forme ? Qu’en est-il également du
développement des composants et des sous-systèmes communs à plusieurs projets ? Où les
concevoir ?

Conduire des projets spécifiques, à l’intérieur d’un département de développement des


technologies et des compétences par exemple, oblige à planifier et à organiser le transfert
des éléments communs aux projets de produits dérivés. Cela implique, par exemple, de
charger un acteur, ou un collectif du département, de s’assurer de l’intégration des modules
dans les projets, et/ou de nommer un responsable du portefeuille de projets de plates-
formes, et/ou un coordinateur « multi-projets » responsable d’un ensemble de projets de
produits dérivés appartenant à une même famille. Cette situation est propice aux politiques
de collaboration entre concurrents pour la conception des plates-formes, dans la mesure où
il n’est pas question, dans ces projets, de modules de différenciation et donc créateurs de
valeur pour les clients.

Si la plate-forme est conçue dans un projet de développement orienté client, il s’agit


d’assurer le transfert des éléments standards sur les autres projets, en recourant par
exemple au principe de double responsabilité et à des dispositifs de restitution des
connaissances. Les problèmes du partage des connaissances et de la planification
stratégique de l’offre se posent de façon accrue et renvoient à l’approche « trajectoire »
(Chapitre XI).

• Quel poids accorder aux dimensions « projet » et « métier » dans le management


multi-projets ?
Le problème de l’articulation entre la dimension « projet » et la dimension « métier »
s’exprime non plus au niveau du management d’un projet mais au niveau d’un ensemble de
projets. Comment répartir de façon pertinente les ressources entre l’activité métier et

Chapitre 12 – L’approche plate-forme 31


l’activité multi-projets, problème d’autant plus important que l’approche plate-forme exige
des expertises techniques renouvelées en permanence ?

Nous avons vu dans le paragraphe II.3.1 que le partage des ressources pouvait être imaginé
en tenant compte de la nature des éléments conçus (module ou ensemble de modules
interdépendants) et de leur degré de spécificité d’un projet à l’autre (élément standard
facilement transférable, élément standard dont les interfaces sont non stabilisées, modules
de différenciation et complémentaires).

Par ailleurs, faut-il affecter à temps plein ou à temps partiel des acteurs « métier » aux
ensembles de projets quand ils existent ? L’avantage du temps plein est que le transfert de
savoir-faire se fera efficacement d’un projet à l’autre (particulièrement intéressant pour des
innovations architecturales et radicales). Mais il faut veiller à bien différencier les produits
finis, à coordonner les familles de projets, à articuler l’expertise métier et l’activité sur les
projets, comme pour le management d’un projet : les acteurs détachés de leur direction
métier risquent de perdre leur savoir-faire métier. Cependant, le temps plein n’est peut-être
pas possible dans toutes les situations ? Lorsque les projets d’un ensemble sont très
gourmands en ressources (problèmes de surcharge, d’autant plus que les entreprises
travaillent le plus souvent sous contrainte de ressources), ou au contraire insuffisamment
gourmands en heures de travail pour justifier une affectation à plein temps de ressources ?

Plusieurs entreprises ont adopté une solution hybride consistant à faire coexister des
ensembles organisationnels différents : des équipes multi-projets qui mobilisent à plein
temps des acteurs « métier », des divisions « métier » indépendantes sollicitées pour des
besoins ponctuels (exemple de General Motors, Mazda, Nissan en 1998, Cusumano et
Nobeoka, 1998) et/ou des départements fonctionnels exerçant des fonctions spécifiques
comme l’architecture véhicule (exemple de Fiat, Cusumano et Nobeoka, 1998).

• Faut-il créer un échelon organisationnel « multi-projets » ?


Une entreprise peut décider de ne pas créer un niveau organisationnel « multi-projets ».
Mais est-ce viable lorsque le nombre de projets est élevé, impliquant plus de mécanismes
de coordination entre les projets, entre les projets et les métiers ? Si l’entreprise décide de
créer un échelon organisationnel « multi-projets », quel critère de regroupement utiliser ?
• La famille de projets ? L’entreprise multi-projets s’organise en tenant compte de la
stabilité de l’architecture (des interfaces) et de l’évolution des technologies à
l’intérieur des modules des produits. L’entreprise ne risque-t-elle pas de privilégier
la standardisation au détriment de la différenciation ?
• Créer des gestionnaires de portefeuilles en réunissant des projets de même nature :
innovation architecturale, incrémentale, radicale, modulaire ?
• Créer des équipes dédiées par type de clientèle ? Cette transformation est mise en
évidence dans le secteur automobile par Hémery et Kesseler (1999), qui
remarquent que les stratégies de plates-formes induisent des changements
organisationnels chez les entreprises partenaires. Cela se traduit chez le fournisseur
par une réorganisation en « lines of business » dédiées aux différents constructeurs
automobiles. Ces unités permettent aux métiers de mieux collaborer en développant
des produits cohérents avec les besoins spécifiques des constructeurs.
Par ailleurs, quelle forme doit prendre le nouvel échelon organisationnel : un simple acteur
(coordinateur multi-projets) ou bien une équipe multi-projets regroupée dans un centre de
développement comme dans le cas de Toyota (Cusumano et Nobeoka, 1998). Au début des

Chapitre 12 – L’approche plate-forme 32


années quatre-vingt-dix, Toyota a créé trois centres de développement, regroupant chacun
des projets partageant des plates-formes similaires (propulsion avant, propulsion arrière,
utilitaire). Les centres réunissent des acteurs métiers, qui interviennent sur les projets du
centre, des administratifs et des directeurs de projets. Des directeurs de centre fixent un
cadre général de directives pour les quatre à cinq projets de leur centre. Les acteurs d’un
même métier sont dirigés par un directeur métier, lui-même détaché dans le centre. Les
spécialités métier ont été réduites, si bien que le nombre d’équipes métier a diminué. Un
quatrième centre de développement a été créé pour développer les modules communs aux
projets, mais qui ne nécessitent pas de coordination quotidienne avec les familles, des
composants communs aux différentes familles ou qui exigent un développement
technologique important. Chaque centre travaille en mode projet et y sont détachés à plein
temps des acteurs métier. La nouvelle organisation de Toyota a amélioré l’efficacité des
transferts entre les projets d’une même famille et résolu le problème des composants
communs (avec le quatrième centre). Mais elle a également induit des problèmes de
management, inévitables étant donné les choix effectués, concernant la coordination des
familles de produits (que l’on peut régler par de l’ajustement mutuel entre les directeurs de
centres mais peut-être aussi avec la nomination d’un directeur multi-familles ?), la relation
entre les directeurs de projet et les directeurs de centres, l’actualisation des compétences
des acteurs métiers, surtout lorsque le métier évolue rapidement, la lourdeur des centres du
fait d’un nombre important de projets. Notons d’ailleurs que Toyota essaie de réduire le
nombre de plates-formes par centre.

• Comment intégrer les évolutions dans un réseau de conception ?


La conception des nouveaux produits mobilise aujourd’hui, de plus en plus, ce qu’on peut
appeler des réseaux de conception. Qu’on ait à faire à une plate-forme propriétaire avec
une entreprise dominante, ou à une plate-forme ouverte, avec une entreprise leader,
l’organisation multi-projets doit prendre en compte ce réseau d’entreprises, ces entreprises
ayant des stratégies d’innovation différentes et parfois conflictuelles.

Les projets de conception de la plate-forme et des éléments communs sont conduits de


façon plus ou moins autonome, par l’entreprise dominante. Chaque entreprise du réseau
mène son propre développement de modules ou de produits dérivés et complémentaires,
tout en enrichissant en permanence la plate-forme. Cette situation crée deux difficultés
majeures, d’autant plus importantes que la plates-forme est ouverte et « générique ».

Comment une entreprise du réseau gère-t-elle l’intégration des projets de plates-formes


externes, problème d’autant plus délicat que ceux-ci peuvent être conduits par des
entreprises (dominantes) différentes ? Comment collaborer avec l’entreprise dominante et
les autres entreprises du réseau pour faire évoluer une plate-forme donnée ? Le problème
d’organisation se pose donc, moins au niveau de la conception des produits et du
management des projets, qu’au niveau stratégique des entreprises du réseau. Comment une
entreprise du réseau planifie-t-elle l’offre de produits en tenant compte de plates-formes
différentes, issues d’entreprises dominantes différentes ?

Comment intégrer au fur et à mesure les évolutions de la plate-forme ? Si les interfaces


entre la plate-forme et les modules de différenciation sont stabilisées, les problèmes
d’intégration ne se posent pas trop car chaque entreprise du réseau peut travailler de façon
indépendante. Une entreprise peut avoir alors intérêt à privilégier une logique de
différenciation des produits et à coordonner ses projets par types de clientèles
(portefeuilles de projets par segment de marché ou segment stratégique). Si l’architecture

Chapitre 12 – L’approche plate-forme 33


évolue, l’entreprise est obligée d’agir sur les éléments qu’elle a développés et de re-
concevoir ses modules, produits dérivés ou complémentaires. Elle a alors peut-être intérêt
à adopter des portefeuilles de projets épousant le périmètre des familles de projets. Il faut
qu’elle organise le transfert des éléments architecturaux (plate-forme, interfaces) depuis
l’entreprise dominante.

Cette réflexion montre que l’organisation multi-projets liée à une approche plate-forme est
loin d’être stabilisée et qu’il n’existe pas de solution idéale mais plutôt des situations
adaptées à des contextes parfois fortement influencés par des facteurs de contingence. Le
caractère plus ou moins ouvert de la plate-forme est un de ces facteurs de contingence. Les
quatre questions évoquées ci-dessus sont interdépendantes ; elles ne peuvent être traitées
séparément. Cela offre de belles perspectives de recherche interdisciplinaire, à l’interface
entre le management de projets, la stratégie et l’ingénierie de la conception des produits.

Conclusion

La littérature sur les plates-formes est de plus en plus fournie et souligne l’intérêt croissant
des entreprises pour une pratique de management qui essaie de standardiser le plus
possible des éléments d’un produit fini à l’autre (composants, sous-systèmes, plates-
formes) tout en différenciant au maximum les produits finis. Une lecture approfondie des
publications de recherche montre de nombreux points d’ombre quant à la mise en œuvre de
cette approche, que nous avons tenté d’explorer.

Le terme de plate-forme, même s’il fait l’objet d’une définition consensuelle (celle de
Meyer et Lenherd, 1997), est complexe à appréhender et recouvre des situations diverses.
C’est pour cette raison qu’il nous a semblé essentiel d’approfondir la compréhension du
concept et son adaptation à des contextes différents. Pour cela, nous avons relié la plate-
forme et l’architecture modulaire des produits, en soulignant entre autres l’importance de
la différence entre les modules standardisés et les modules de différenciation. Nous avons
abordé le problème de l’universalité des plates-formes et examiné deux situations
extrêmes. La plate-forme produit comprend un système partagé (la plate-forme au sens
strict) et des interfaces standardisés ; c’est une plate-forme propriétaire, développée par
une seule entreprise ou un groupe d’entreprises. La plate-forme « générique » a une
architecture standardisée et des interfaces ouvertes, un réseau d’entreprises participe à sa
conception et à son évolution. Nous avons fait évoluer l’analyse des plates-formes au sens
strict vers une problématique de partage d’éléments communs car nous pensons que la
plate-forme n’est qu’un stade, avancé certes, de ce partage. Nous avons essayé de faire le
lien entre l’ingénierie système, la stratégie et le management de projets.

La littérature traite peu des conséquences d’une approche plate-forme sur le management
de projets (et encore moins le management multi-projets) et, quand elle le fait, c’est sous la
forme de solutions exemplaires et contextualisées. Nous insistons dans ce chapitre sur la
spécificité des projets de plates-formes. Nous montrons la difficulté de l’entreprise multi-
projets à gérer des types de projets différant par leurs attributs (projets de conception d’une
plate-forme, projets de produit dérivé, projets de produit complémentaire, projets de
module), mais devant être regardés globalement, dans un esprit de cohérence décisionnelle
et de gestion constructive du partage des ressources technologiques et humaines. Nous

Chapitre 12 – L’approche plate-forme 34


montrons l’apparition de nouvelles formes d’organisation qui sont fortement influencées
par l’architecture des produits.

Ce chapitre montre l’importance qu’il y a à poursuivre l’analyse en reliant, dans la


réflexion de changement organisationnel des entreprises, l’approche plate-forme avec le
management de portefeuilles de projets et les stratégies d’innovation fondées sur des
trajectoires. Les trois formes de management multi-projets sont intimement liées et ne
peuvent plus être traitées de façon isolée en particulier sur les aspects de gestion et
d’organisation des ensembles de projets et de partage des connaissances entre les projets.

Chapitre 12 – L’approche plate-forme 35