La Défense comme maître d’ouvrage des systèmes technologiquement complexes

6La première approche concerne la contribution de la Défense à la conception des grands programmes complexes (SAPOLSKY, 2003 ; DAVIES et HOBDAY, 2005). Ceux-ci supposent la mobilisation d’une grande variété de compétences au sein d’un réseau d’entreprises organisé de manière modulaire et hiérarchique, dont l’activité est coordonnée par une firme qui occupe la fonction d’intégrateur de systèmes (VERSAILLES, 2005 ; BRUSONI et al., 2011). Brusoni et al. (2001) et Hobday et al. (2005) ont analysé la spécificité de ce type de réseau en mettant en évidence le fait que la division des connaissances était faiblement corrélée à la division des tâches. Dans le domaine de l’armement, les acteurs parties prenantes (Défense, entreprises et recherche publique) entretiennent des relations complexes et denses qui s’articulent autour de la fonction d’intégration (VERSAILLES, 2005 ; GHOLTZ, 2005).

7La Défense exerce la fonction de maître d’ouvrage, ce qui renvoie à deux grandes caractéristiques (COHENDET et al., 1987 ; MÉRINDOL, 2009) : tout d’abord, la Défense est l’usager final des programmes ; ensuite, elle est aussi l’un des opérateurs de son développement. La Défense participe au design du programme (GHOLTZ, 2005). En effet, elle élabore les spécifications techniques et évalue la performance du système d’armement en fonction des attentes des opérationnels. Dans beaucoup de cas, elle contribue aussi directement à la conception de l’architecture technologique par l’intermédiaire de ses services d’acquisition et de ses centres de R&D. Les ingénieurs au sein de la Défense font évoluer la conception au fur et à mesure de leurs échanges sur les problèmes d’intégration rencontrés.

8La Défense comme maître d’ouvrage requiert une capacité multi-technologique (BRUSONI et al., 2001) indissociable de sa position dans le réseau d’intégration système. Ses compétences technologiques et organisationnelles doivent lui permettre de coordonner les contributions et de générer un consensus autour de la solution technique. Cette capacité multi-technologique suppose des ingénieurs et des chercheurs spécialisés, ainsi que des ingénieurs généralistes porteurs de valeurs et de références communes et capables de faciliter la traduction d’enjeux technologiques en réponses opérationnelles (MÉRINDOL, 2009).

La Défense en tant que lead user

9Le rôle de la Défense peut aussi être appréhendé d’une manière fondamentalement différente. Les recherches en sciences de gestion (VON HIPPEL, 1986, 2005) ont montré que le client peut être non seulement une source d’informations sur l’usage, mais aussi une source d’idées et de solutions sur les fonctionnalités de la technologie.

10Son expérience et la connaissance reliée à un milieu spécifique d’application est difficilement transférable (« sticky information »). La collaboration entre l’usager et les fournisseurs de technologies permet de réduire les coûts de coordination et d’apprentissage (VON HIPPEL, 1994). La gestion de l’innovation implique alors un processus complexe de réflexivité entre les usagers et les entreprises autour de la fonction de la technologie. Ce processus est particulièrement important pour les technologies dites « flexibles » (NAHUSI et al., 2009 ; AKRICH, 2006), pour lesquelles il existe peu de limitations à leur adaptation à un contexte d’application donné. Dans ce contexte, les usagers contribuent directement à la solution technologique à mettre en place (BILGRAM et al., 2008). C’est le cas, par exemple, pour les technologies de l’information et de la communication (TIC).

11Le milieu militaire représente un domaine spécifique d’application des technologies. Si beaucoup de technologies sont aujourd’hui développées dans des réseaux d’innovation tirés par les besoins commerciaux, leur implémentation dans le milieu militaire requiert des savoir-faire spécifiques qui reposent sur une expérience concrète des opérations militaires. Ainsi, la Défense peut contribuer au processus d’innovation pour les technologies flexibles à travers les expériences individuelles et collectives que les militaires ont retirées de leurs activités opérationnelles. Cela permet d’introduire des fonctionnalités nouvelles allant, par exemple, de cartes interactives géo-positionnées à des systèmes de communication permettant une combinaison inédite de systèmes d’armes.

12Von Hippel (1986) a défini le statut de lead user afin de caractériser le rôle clé de certains usagers en tant que sources de l’innovation. Les lead users présentent des caractéristiques qui les différencient des autres usagers : ils sont en avance sur les besoins du marché et leur innovation va ensuite bénéficier à d’autres usagers. Ils vont influencer les comportements sur les marchés. Morisson et al. (2004) précisent que les organisations lead user sont composées d’individus autodidactes férus de technologie, insatisfaits des modes de résolution de problème adoptés par l’entreprise, qui vont dès lors s’impliquer dans la définition de nouvelles solutions technologiques. Disposant d’une indépendance de point de vue, ils développent des comportements créatifs en étant en avance sur la proposition de solutions. Ils inscrivent souvent leurs actions dans des communautés d’usagers. Les lead users présentent des compétences rares et faiblement substituables dans le processus d’innovation de par la concomitance de leurs expériences concrètes et de leurs comportements créatifs. Ils émergent généralement dans des domaines d’activité où le cycle de vie de la technologie est court et ses contextes d’utilisation nombreux (FRANKE et al., 2003). Nous partons de l’hypothèse que l’innovation dans le domaine militaire est propice à l’émergence de lead users en raison de la spécificité des contextes d’usage et du besoin de rechercher des solutions technologiques toujours plus performantes.

Maître d’ouvrage et lead user, deux conceptions qui vont être combinées

13Ces deux modèles d’innovation se structurent autour de cinq grandes caractéristiques qui vont les différencier.

14La première de ces caractéristiques porte sur la nature du projet technologique : dans un cas, il s’agit de grands programmes ayant pour focale l’intégration des systèmes. Dans l’autre cas, il s’agit de technologies dites flexibles, dont la focale repose sur les voies créatives permettant d’adapter la technologie aux contextes, voire d’aller jusqu’à l’émergence d’une nouvelle solution/fonctionnalité technologique.

15La deuxième caractéristique est la manière dont la Défense est impliquée dans le projet : la conception de l’architecture technologique du programme, pour le maître d’ouvrage, et la définition de nouvelles fonctionnalités technologiques dans un contexte dédié, pour le lead user.

16La troisième caractéristique est reliée aux formes de co-conception de la technologie. Dans les programmes complexes, la co-conception se focalise sur des échanges portant sur la fonction d’intégration de systèmes. Pour les technologies flexibles, l’interaction prend sa place dans des contextes locaux d’utilisation et d’application de la technologie.

17La quatrième caractéristique renvoie aux processus et aux drivers de l’innovation. Dans le cas du maître d’ouvrage, on se situe dans un modèle technology push, dans lequel l’innovation, les processus et les concepts ont comme point de départ l’évolution des technologies et de l’architecture des systèmes. Le management des projets s’articule autour du stage gate processes (COOPER et al., 2012). La phase de conception se distingue clairement de la phase de développement et de production. Dans le cas du lead user, on se situe davantage dans des projets se caractérisant par des flexible processes (BIAZZO, 2009). Les projets sont portés par une approche market pull, dans laquelle c’est le besoin de l’usager qui est le point de départ de l’innovation. Le lead user joue un rôle clé dans la phase d’idéation (LETTL, 2007). La phase de conception chevauche en partie la phase de développement : l’identification des problèmes et de leurs solutions sont des phases qui s’articulent toutes les deux autour de l’expérimentation et de la pratique (BIAZZO, 2009).

18Enfin, les modèles du maître d’ouvrage et du lead user se distinguent par la définition des compétences clés : dans le premier cas de figure, celles-ci s’articulent autour des compétences multi-technologiques et, dans l’autre, elles sont associées au profil d’usagers autodidactes de la technologie tournée vers la nouveauté. Le Tableau 1 de la page suivante synthétise les principales caractéristiques des modèles d’innovation du maître d’ouvrage et du lead user.

Tableau 1

Les caractéristiques des modèles d’innovation militaire portés par le maître d’ouvrage et le lead user

Modèles d’innovation militaire Nature du projet technologique Contribution de la Défense à l’innovation Processus d’innovation Co-conception de la technologie entre la Défense et les entreprises Compétences de la Défense comme usager innovation Défense maître d’ouvrage Grands programmes complexes Réseau hiérarchique et modulaire Contribue à la définition de l’architecture technologique, définit les spécifications, évalue la performance State gate processes Les phases de conception, de développement, de production sont séquentielles Partage la fonction intégration Co-spécifie l’architecture technologique Faible corrélation entre la division des tâches et les connaissances Multitechnologiques Capacité d’intégration Défense lead user Technologie flexible Pratique hétérogène entre les contextes d’application Cycle court de la technologie Développe des fonctionnalités technologiques nouvelles Anticipe les usages possibles pour accroître la performance des missions Flexible processes fondés sur des phases de conception, développement, implémentation qui se chevauchent Co-conception de la solution technologique dans des contextes spécifiques Autodictacte de la technologie Expérience opérationnelle Indépendance d’esprit Comportements créatifs

Les caractéristiques des modèles d’innovation militaire portés par le maître d’ouvrage et le lead user

19Cette première section a permis de clarifier les modèles d’innovation fondés sur les usagers dans le domaine militaire et de faire émerger la question de recherche : quelles sont les implications des différents rôles possibles de la Défense en tant qu’usager innovant sur la gouvernance des projets technologiques ? Comment les deux modèles qui viennent d’être présentés se combinent-ils entre eux et comment permettent-ils de mieux comprendre le rôle de la Défense en matière d’innovation ?

Le contexte institutionnel, économique et technologique

23La première séquence concerne la période de la Guerre froide, des années 1970 à la fin des années 1980. La course aux armements s’intensifie dans les années 1980. Le Pentagone mène une politique industrielle volontariste, avec un objectif de supériorité technologique (ERGAS, 1987). La position de la Défense américaine comme maître d’ouvrage s’affirme alors, avec le rôle pivot joué par chaque armée dans la fonction d’intégration de systèmes. Au cours des années 1980, l’introduction des TIC dans les opérations militaires a permis l’apparition d’usagers innovants au sein même de la Défense, qui présentent des caractéristiques des lead users. C’est en particulier le cas au sein de l’US Air Force (GILLOT, 1998 ; LYNDSAY, 2006).

24À partir de 1990, une seconde séquence apparaît. La fin de la Guerre froide et l’émergence de la société fondée sur la connaissance (FORAY, 2004) sont propices à la coexistence de la position de maître d’ouvrage de la Défense avec celle de lead user. Le maintien de la supériorité technologique doit être envisagé dans un contexte budgétaire plus contraint qu’auparavant. Cette situation amène la Défense américaine à faire le choix de la réduction du nombre de ses fournisseurs (GAO, 2007a). Elle va ainsi jouer un rôle dans les nouvelles stratégies de coopétition des firmes (DEYPERE et al., 2007).

25De plus, le développement des TIC et du marché de l’Internet s’accélère. Cela a entraîné une généralisation des phénomènes de co-création sous des formes variées (PRAHALAD et al., 2004). La Défense n’échappe pas à ces évolutions. L’utilisation des TIC dans les systèmes de commandement et de contrôle a amené des évolutions dans la conduite des missions militaires (MILLER, 2001 ; STOOP, 2005). La Défense comme lead user prend une place croissante, alors que la position de maître d’ouvrage, là où elle est maintenue, connaît une adaptation importante en raison des contraintes budgétaires et de la complexité technologique croissante. En effet, l’introduction des TIC implique un niveau supplémentaire d’intégration de systèmes. Les systèmes de systèmes représentent un ensemble de systèmes d’armes inter-reliés entre eux par des systèmes de communication. Ces derniers se conçoivent de moins en moins indépendamment les uns des autres (MATTHEWS et al., 2000 ; HOBDAY et al., 2005).

26Enfin, la troisième et dernière séquence débute en 2000. Elle est caractérisée par des réponses institutionnelles du Pentagone concernant à la fois la place des TIC dans les opérations militaires et l’institutionnalisation de nouvelles pratiques de gestion des programmes. Cette phase va favoriser la recherche d’articulations entre les deux modèles d’innovation précités (maître d’ouvrage et lead user). Cette articulation est encouragée à la fois par les évaluations du GAO et du Congrès américain et par la doctrine Network centric Warfare qui va impulser une évolution des opérations militaires via la numérisation des champs de bataille.

La Défense américaine comme maître d’ouvrage : vers une nouvelle division des tâches et des connaissances entre le Pentagone et les entreprises

27Avant 1990, la Défense américaine était très active dans la conception des systèmes d’armes (GHOLZ, 2005 ; KING, 2003). La répartition des tâches entre la Défense et les entreprises pouvait cependant varier en fonction des programmes. À titre d’illustration, l’US Army assurait une part importante de la fonction d’intégration des programmes d’hélicoptères de combat Apache et de chars de combat Abrahams. Les services d’acquisition et les centres de R&D de l’US Army réalisaient plus de 50 % des technologies jugées stratégiques pour l’architecture des systèmes. Ils participaient à la résolution de tous les problèmes de conception et assuraient la distribution du travail au sein du réseau d’entreprises.

28D’autres programmes illustraient une autre forme de répartition du travail. Dans le domaine des missiles, par exemple, l’US Army internalisait moins de développement. Elle ne disposait pas d’une vision d’ensemble de l’architecture. Pour les programmes Stinger et Javelin, l’industrie développait 75 % des systèmes et résolvait une bonne partie des problèmes d’intégration. L’US Army représentait le financeur et l’autorité contractuelle d’un programme dont elle était ensuite l’usager final, mais son intervention dans la résolution des problèmes de conception était circonscrite à deux aspects spécifiques : a) les arbitrages sur les choix technologiques lorsque ceux-ci avaient un impact important sur l’enveloppe budgétaire, et b) les arbitrages sur la résolution de problèmes techniques lorsque l’architecture technologique des missiles avait des incidences potentielles sur les spécifications des équipements porteurs (chars, hélicoptères…). C’est à ce titre que l’US Army assurait 25 % de la conception des technologies intégrées dans les missiles. Des illustrations équivalentes existaient en ce qui concerne l’US Air force et l’US Navy.

29À partir de 1990, les contraintes budgétaires et l’introduction des systèmes de systèmes ont entraîné une nouvelle division des tâches et des connaissances. La capacité de la Défense à participer à la résolution de problèmes de plus en plus complexes aux côtés de l’industrie se réduit.

30Les laboratoires militaires de R&D sont de moins en moins les producteurs de technologies. Ils consacrent une part de plus en plus importante de leur activité aux tests et aux évaluations de technologies produites par les entreprises. Bien que près de 30 000 ingénieurs et scientifiques travaillent dans les laboratoires militaires, des spécialistes dans de nombreux domaines technologiques manquent (par exemple, dans l’optique laser, pour l’US Navy). Les laboratoires ont de plus en plus de difficulté à assurer une fonction de traducteur entre les besoins opérationnels et les propositions technologiques de l’industrie.

31L’externalisation des fonctions et des compétences va même plus loin que la seule fonction de R&D [1], puisque certaines entreprises obtiennent le statut de lead system integrator à l’échelle des systèmes de systèmes (GANSLER et al., 2009). Elles sont alors en charge de l’ensemble des fonctions d’animation de réseaux et de gestion d’intégration de technologies au niveau systèmes de systèmes. La Défense se situe alors en retrait dans la conception des programmes, comme le précise un responsable de l’Office of Secretary of Defense : “…The DoD is still present upstream in the programs for the specification of expected performances, and downwards for the evaluation. This most specifically takes place when a company becomes lead systems integrator. The services and the acquisition office manage to transfer appropriate updates about the war fighter needs, but they are not present for problem resolution. They do not watch program management but at major deadlines, and hardly get data about cost management”.

32Toutefois, cette évolution cache l’existence de plusieurs options stratégiques. Malgré les difficultés, l’US Navy cherche à maintenir sa capacité d’intégration système de systèmes. Ce choix reflète sa volonté explicite de préserver sa capacité d’orientation du développement technologique. Il est fortement critiqué par les grandes entreprises du secteur, qui considèrent que l’US Navy n’a pas les compétences requises pour faire face à la complexité technologique et que son intervention réduit parfois l’efficacité des solutions mises en œuvre : “… The [Office for naval research and related procurement office] cannot play the role they used to enact in program conception just two decades ago. The complexity of system engineering and the variety of competences for the various technological components have become too large now. The USN is not able to have the leadership in the problem resolution process anymore. If we try to specify at technical levels, we end up with misleading orientations. These steps incur avoidable delays and additional costs…”

33L’US Army et l’US Air Force ont opté pour un recours croissant au statut de lead systems integrator. Une illustration majeure en est le programme Futur Combat Systems (FCS) de l’US Army, qui constituait un système de systèmes reliant 17 grands armements. La fonction d’intégration était confiée à un consortium composé de Boeing et de Saic, l’US Army ne définissant plus que les spécifications opérationnelles et les conditions des tests grandeur nature du programme (SHANLEY et al., 2007). L’US Army et l’US Air force ne conservaient dès lors, en interne, que des compétences sur des briques technologiques jugées particulièrement critiques pour la conduite des opérations militaires, comme le précise un responsable R&D d’un laboratoire de l’US Air force : “[…] as soon as technologies become a differentiator for the war fighter, or when we have the slightest uncertainty as regards the preservation of industrial competences on a 10-15 year horizon, the USAF decides to internalize the competences…”

34À partir de la fin des années 2000, les évaluations du GAO (GAO, 2003 ; GAO, 2007b) et du Congrès américain (BALLEY GRASSO, 2010 ; LOUDIN, 2011) critiquent le recours au lead systems integrator pour gérer les systèmes de systèmes en raison de l’absence de maîtrise des coûts. Ces deux institutions suggèrent une ré-internalisation de ces fonctions au sein du Pentagone, qui va devenir progressivement effective à partir de 2008 avec l’abandon du recours au lead systems integrator. Cette situation implique de fait pour le Pentagone une nouvelle vague de recrutement d’ingénieurs de haut niveau au sein des laboratoires de R&D militaire et des services d’acquisition. Le Pentagone généralise aussi les méthodes d’ingénierie fondées sur les architectures ouvertes au sein des trois armées (SCACCHI et al., 2011).Cette approche s’était développée progressivement avec la doctrine NCW au cours des années 2000. En particulier, l’US Navy a implémenté très tôt cette méthode pour faciliter la prise en compte des évolutions du software et du hardware au sein des programmes complexes, comme le précise un responsable de l’Office of Secretary of Defense : “[…open architectures…] allow for new modalities for the specification of hardware. They also make software integration easier. This methodology has become a central feature in all projects since the adoption of the NCW doctrine. It was adopted very early in the USN thanks to the commitment of the people at Monterey, and processes have then stabilized and diffused onto all other related projects in the DoD services…”

La Défense américaine comme lead user : l’émergence des opérationnels comme acteurs clés du processus d’innovation

35Au cours des années 1980, deux jeunes pilotes d’avion de combat dans l’US Air force ont été à l’origine de la création d’un logiciel FPAN pour la planification des opérations aériennes sur F-16. À l’époque, le système CAMP utilisé par l’US Air force avait été développé dans le cadre d’un contrat entre les services d’acquisition et IBM. Les utilisateurs finaux, les pilotes de chasse, étaient peu satisfaits du système : ils le jugeaient peu convivial, la préparation et la conduite des opérations étant rendues très complexes. Le projet FPAN a été développé par les deux jeunes pilotes dans le cadre de la communauté de logiciel libre LINUX. L’interface homme/machine était une priorité du projet. Ce logiciel a d’abord été utilisé de manière informelle par les pilotes sans autorisation explicite de leur hiérarchie. Celle-ci ne fut informée de l’usage et de la performance du FPAN qu’au début des opérations de la guerre du Golfe, en 1991. L’absence d’un système de planification et de conduite des opérations qui fût simple et rapide à utiliser constituait un manque, alors même que les opérations aériennes s’intensifiaient. L’usage du FPAN s’est alors généralisé sur F-16 au détriment du système CAMP.

36À partir des années 1990, le développement du projet FPAN prend un nouveau tournant pour s’inscrire davantage dans le mode de management des technologies et des programmes d’armement du Pentagone. Les deux pilotes à l’origine du FPAN furent mutés en 1993 dans les services d’acquisition de l’US Air force afin d’améliorer les travaux sur le logiciel, et ce dans le cadre d’un financement accordé à une équipe de chercheurs en informatique de l’Université de Georgia. En collaboration avec les deux pilotes de chasse, les chercheurs ont écrit les codes de la nouvelle version du logiciel. Les améliorations successives du FPAN via les échanges entre militaires et les fournisseurs de la technologie représentent un réel succès pour le Pentagone. Le programme FPAN fut exporté sur le marché international. Il a conduit à de nouvelles pratiques concernant la planification des opérations et l’utilisation en temps réel de systèmes géo-positionnés. L’exportation du F16 allait de pair avec la diffusion de nouvelles pratiques au sein des armées ayant acquis le système FPAN. Plus encore, le projet FPAN fut adopté par des agences civiles, comme l’US Forest Agency pour la surveillance des forêts. Progressivement, les usages se sont étendus aux secteurs commerciaux. Microsoft a proposé aux deux pilotes à l’origine du FPAN de rejoindre ses équipes pour développer des applications de géopositionnement sur les marchés commerciaux.

37À partir des années 2000, le rôle des opérationnels dans le processus d’innovation est institutionnalisé. Cela est facilité par la mise en place de la doctrine NCW et par l’implémentation progressive du spiral development dans le processus d’innovation (BOEHM, 2000 ; RAINVILLE, 2001). L’US Navy a été moteur dans ce processus : “… At the center of the NCW doctrine, you have ITs that are flexible technologies. When you want to adapt them to the context of military operations, you need a huge amount of feedback loops between technology providers and people who know what it is like to use them as a war fighter. This changes the way to defining the specs. The process is not a linear one. The spiral development makes it possible to adapt to the new practices. It was first tested at a local level by the war fighters. They worked in close collaboration with the specialists from SEI [FFRDC]. Now we generalize the methodology…”

38Au départ, les ingénieurs des services d’acquisition furent réticents, car la co-conception s’inscrivait dans une relation directe et étroite entre l’usager final et le fournisseur de la technologie. De plus, des difficultés émergeaient sur le plan du contrôle des améliorations produites et de leurs conséquences au niveau de l’architecture des systèmes complexes. Ces difficultés vont être levées lorsque la démarche spiral development va s’inscrire dans les méthodes d’architecture ouverte, facilitant ainsi l’existence d’initiatives locales centrées sur les innovations d’usages. Une nouvelle relation entre intégration de systèmes complexes et innovation d’usages s’instaure alors. Elle sera institutionnalisée à la fin des années 2000 pour devenir une référence du management de la technologie au sein du Pentagone.

39Le nouveau rôle des opérationnels a été lui aussi progressivement institutionnalisé, avec la création des battle labs [2] (BELL, 2003). Au nombre d’une quinzaine aujourd’hui, ces centres d’expérimentation permettent aux militaires qui ont une idée de trouver des structures dédiées au test de nouvelles fonctions technologiques : l’objectif est de stimuler des pratiques performantes fondées sur des usages localisés. Ces battle labs facilitent aussi la prise en compte de nouvelles idées dans la conception des systèmes d’armes, une fois les expérimentations stabilisées. Progressivement, ils ont permis d’institutionnaliser de nouvelles formes de coopération entre les ingénieurs issus des laboratoires de R&D militaire, les industriels et les opérationnels, autour d’exercices de simulation et d’expérimentations, comme le précise un responsable de l’US Army : “…We have introduced incentives for the industry to attend presentations of returns on experience and workshops about doctrinal issues. We also invite them as observers in actual operations, just to foster new forms of exchange between guys who have an experience on the battlefield and the industry. Together, they discuss new technology options and potential advantages…”

40Des communautés d’usagers ont aussi émergé et se sont vu reconnaître un rôle clé au sein des armées. Ainsi, une communauté des pilotes s’est formée (AFMSS Community) pour encourager les développements et applications software autour de la fonction aérienne. Initialement développée par des pilotes de l’US Air force, cette communauté s’est progressivement étendue à tous les pilotes (pilotes de chasse de l’US Navy, pilotes d’hélicoptères de l’US Army), et cela permet aux différents professionnels d’échanger entre eux.

Dualisation de la gouvernance de l’innovation et des relations État-clients et État-entreprises

42La Défense maître d’ouvrage et la firme intégrateur de système se situent en haut de la pyramide au sein du réseau. Elles constituent les acteurs de la hiérarchie « experte » (DOSI et al., 2008) et peuvent intervenir en matière de répartition des tâches entre les acteurs du réseau. La difficulté qu’éprouve la Défense américaine à préserver une activité de co-conception via une stratégie d’in-sourcing la rend moins présente dans le réseau d’intégration de système. Progressivement, la position de maître d’ouvrage repose moins sur sa capacité à résoudre les problèmes technologiquement complexes que sur sa capacité à gérer la flexibilité au sein du programme. La Défense doit mettre en place les modes de management qui permettent d’intégrer en cours de route de nouvelles innovations tout en en maîtrisant les coûts.

43En revanche, le statut de lead user implique une gouvernance qui soit fondée sur des réseaux horizontaux et collaboratifs (VON HIPPEL, 1994). Les relations fondées sur la confiance au sein de communautés sont centrales. Comme dans d’autres secteurs d’activité (BURGER-HELMCHEN et COHENDET, 2011), des typologies existent. En particulier, deux types de communauté d’usagers émergent dans le cas étudié. Tout d’abord, des communautés de développeurs, avec la participation de militaires dans des communautés de type Linux. La deuxième catégorie de communauté se structure autour des pratiques et des expérimentations vécues à travers l’usage des technologies dans les opérations militaires. Ces communautés ont une dimension inter-organisationnelle, elles favorisent le décloisonnement des pratiques au sein des armées.

44Ces deux modèles d’innovation se différencient entre eux en termes de diffusion des connaissances. Le modèle du lead user est indissociable d’une logique de diffusion des connaissances, notamment des nouveaux usages sur le marché. Par ailleurs, les innovations sont difficiles à protéger par les mécanismes traditionnels (secret et brevet), car elles sont facilement imitables une fois que leur usage s’est développé (HARHOFF et al., 2003). Les communautés d’usagers constituent non seulement le niveau clé de développement des connaissances, mais aussi un support pour leur diffusion en interne à la Défense et à l’extérieur. Pour la Défense maître d’ouvrage, l’approche est radicalement différente. L’internalisation des connaissances est fondée sur un pouvoir d’influence qui s’exerce par la maîtrise exclusive des connaissances clés pour préserver la supériorité technologique. Les contraintes de propriété intellectuelle (secret, brevet) imposées aux entreprises ou via les stratégies d’insourcing sont introduites pour réduire tout risque de transfert technologique.

Un nouveau modèle de management de l’innovation : créer la complémentarité entre le modèle du maître d’ouvrage et le modèle du lead user

45Les modèles de lead user et de maître d’ouvrage sont aussi liés à des processus d’innovation différents (state gate processes/flexible processes). Comme dans d’autres secteurs, une des conséquences de l’adoption de technologies flexibles est de changer les processus dans le développement de nouveaux produits (THOMKE et REINERTSEN, 1998). La combinaison des deux modèles passe par un nouveau mode de gestion des programmes complexes qui va pouvoir se développer avec l’adoption de méthodologies fondées sur les « architectures ouvertes ». Cela va faciliter l’existence de phases d’idéation au-delà de la période de conception du grand programme. Ces phases d’idéation vont reposer sur des approches réflexives de l’usage des technologies fondées sur le spiral development, au fur et à mesure que les usages et les nouvelles fonctionnalités des opérationnels émergent des tests et de la pratique.

46Les ingénieurs et les opérationnels voient leur rôle évoluer sensiblement. Les ingénieurs responsables des grands programmes doivent favoriser le maintien de ces phases d’idéation au-delà de la conception des programmes, tout en faisant des choix qui permettent d’en maîtriser les coûts. Ils doivent à la fois préserver une ligne stratégique définie par les priorités autour des grands programmes et des grandes masses budgétaires associées, et des stratégies plus émergentes, autour des nouveaux usages. Les opérationnels, quant à eux, voient leur rôle se renforcer à deux niveaux différents, comme cela sera précisé ci-dessous, et ils trouvent au sein des battle labs du Pentagone les moyens d’activer ces deux types de rôle :

• au niveau des grands programmes, dans les phases de spécifications des performances attendues et de leur évaluation par des tests dans la phase d’élaboration des prototypes ;
• dans les phases d’idéation, en testant et en imaginant de nouveaux usages autour des technologies flexibles. La réflexivité et la réification des pratiques et des usages s’articulent autour de l’expérience opérationnelle et des comportements créatifs de certains militaires.

47La dualisation des modes de gouvernance évoquée dans la paragraphe « Dualisation de la gouvernance de l’innovation et des relations État-clients et État-entreprises », ainsi que le nouveau rôle dédié aux ingénieurs et aux opérationnels dans le processus d’innovation vont permettre de coordonner les deux types de processus au sein d’architectures ouvertes, comme le montre la figure de la page suivante.

Figure 1

Les nouvelles formes de gouvernance de l’innovation

Les nouvelles formes de gouvernance de l’innovation