1. Caractéristiques de l’innovation dans l’industrie logicielle

3 L’industrie logicielle se caractérise par un flux régulier d’innovation, mais aussi un taux d’échec élevé, ce qui conduit les entreprises du secteur à réfléchir à une meilleure intégration des premiers clients dans les projets mettant en œuvre de nouveaux concepts. Ces innovations sont généralement développées par des start-up qui se concentrent sur une technologie particulière. Dans le cas des innovations radicales, elles participent à un processus de création de marché et sont confrontées à la rareté des ressources, en homme et en temps. En effet, l’industrie logicielle est régie par un phénomène qualifié de « winner takes all » (Cusumano, 2004) : dans chaque catégorie, seuls quelques logiciels survivent. Cela résulte des rendements croissants d’adoption liés à ces logiciels, et plus précisément des phénomènes d’apprentissage par l’usage, d’externalités de réseau et d’interrelations technologiques (Arthur, 1989). Il s’agit alors pour les éditeurs de logiciel de se focaliser sur leur technologie pour faire partie des leaders reconnus du domaine. Par ailleurs, ils doivent aussi coupler leur offre avec des logiciels conçus par d’autres éditeurs afin de proposer des solutions attractives pour leurs clients.

4 Selon Cusumano (2004), les premières mises en œuvre d’un concept nouveau chez des clients, constituent une étape clé du processus d’innovation, permettant le passage du concept au produit. Ces mises en œuvre s’effectuent au travers de projets auxquels participent le ou les éditeurs de logiciel innovant, le client, et éventuellement une société de services informatiques. Le rôle des clients et des utilisateurs dans de tels projets, sont, nous l’avons évoqué, peu abordés par la littérature en management de projet. Ainsi, la mise en œuvre d’un nouveau concept de logiciel nous paraît un cas intéressant pour mieux caractériser ces rôles et les compétences associées.

2. L’innovation utilisateur

5 Dans la littérature sur l’innovation par les utilisateurs, von Hippel (1986) a défini la notion de lead user : ce sont des individus ou des organisations qui ressentent des besoins qui deviendront ceux d’un grand nombre de clients, et qui espèrent retirer un bénéfice particulier de la satisfaction de ces besoins. Concernant les « produits numériques », Franke et von Hippel (2003) affirment : « Lead Users can design and develop any kind of innovation in the field of information product, like software. » Pour von Hippel (2005), les firmes doivent générer des concepts innovants en partenariat avec des lead users, et ce dans pratiquement tous les domaines. Confrontées à l’accélération du rythme des innovations dans chaque industrie, il peut même être profitable de laisser certains utilisateurs développer les innovations eux-mêmes. Ainsi von Hippel (2001) suggère une approche selon laquelle des utilisateurs reçoivent des outils qui leur permettent d’assumer la conception du produit.

6 Dans le cas du logiciel, cette littérature concerne principalement les logiciels Open Source et décrit des projets gérés par des communautés auto-organisées de développeurs volontaires. Logiquement la question organisationnelle n’est pas, ici, centrale. Plus généralement, la littérature sur l’innovation par les utilisateurs aborde peu les questions liées à l’organisation, à la gestion des projets d’innovation et au rôle qu’y tiennent les lead users.

3. La littérature en développement de produits nouveaux

7 La littérature en développement de produits nouveaux (NPD) et management de projet développe, quant à elle, une réflexion organisationnelle relative au processus d’innovation. Les concepts de heavy weight project manager, de light-weight project manager en contrepoint du précédent (Clark et Fujimoto, 1991), de Champion (Roberts et Fusfeld, 1981), ou encore de Gatekeeper (Allen, 1971), entre autres ont ainsi été élaborés pour décrire l’organisation des projets d’innovation et les rôles que doivent y tenir les acteurs-projet, selon le type de projet et le type d’organisation qui les portent. La notion de heavy weight project manager (HWPM) correspond dans la littérature francophone à celle de directeur de projet (Giard et Midler, 1993 ; Midler, 1993), qui peut être assisté d’un gestionnaire opérationnel de projet (Charue-Duboc, 1997). Clark et Fujimoto (1991) recommandent des chefs de projet « heavy weight » afin de diriger des équipes chargées de développer des produits complexes dans des firmes bureaucratiques et matures. Pour leur part, Hause et al. (2006) notent que lorsque l’innovation concerne des firmes de petite taille, des équipes géographiquement distribuées, dans des industries en évolution rapide, comme dans l’industrie du logiciel, des formes organisationnelles particulières peuvent favoriser l’innovation. Ainsi les auteurs soulignent que dans les phases de « fuzzy front end » un responsable R&D peut diriger efficacement un processus d’innovation radicale.

8 Mais les travaux en management de projet et NPD partagent une conception souvent implicite selon laquelle les clients ont peu d’influence sur l’activité de développement de nouveau produit (von Hippel, 2005).

9 Cela conduit à notre question de recherche : quels sont les différents rôles joués par les lead users dans un processus d’innovation multi-acteur ? Nous nous proposons de traiter cette question en croisant les littératures relatives à l’innovation par les utilisateurs et au management de projet.

1. Le projet Exinis

18 Exinis a pour clients des professionnels du droit à qui elle propose documents et synthèses. Ainsi, l’entreprise compile une énorme quantité d’informations. Le web manager d’Exinis France, William, a imaginé les possibilités offertes par un système de base de connaissance alimenté automatiquement par toutes les publications disponibles sous forme de texte. Parmi plusieurs idées, il a conçu une application permettant de faciliter le travail des éditeurs et rédacteurs en charge des synthèses juridiques, en automatisant l’insertion de références normalisées (« balises ») aux textes de lois. Il s’agissait ainsi de réduire le temps consacré à une tâche fastidieuse.

19 William a retenu Temis, du fait de son partenariat avec Mondeca dans le cadre du projet PressPro. La passerelle OntoPop était alors en cours de conception. Trois fournisseurs ont été impliqués :

20

• Temis était chargé de l’élaboration de la « cartouche de connaissance juridique »,
• Mondeca était chargé de développer une « ontologie juridique »,
• 4D Concept, SSII, était chargée du développement des interfaces utilisateur.

21 William a imaginé l’architecture logicielle et choisi les fournisseurs. Informaticien, ayant travaillé en recherche avec des linguistes et passionné par le concept de web sémantique, il était responsable du projet auprès du comité de direction d’Exinis France. Hugo et Ursule, deux utilisateurs que nous qualif ions d’« utilisateurs experts », ont travaillé avec les acteurs du projet pendant toute sa durée, plusieurs demi-journées par semaine. Après avoir imaginé une solution combinant IDE, ITM et des services web open source, William aidé de Hugo et Ursule, a formulé les spécifications de l’application, et ce à partir d’un prototype de la solution développé par Temis et Mondeca.

Tableau 1

Les acteurs impliqués dans le projet Exinis

Exinis	Temis	Mondeca	4DConcept
– William, à l’initiative et responsable du projet, dédié. – Charles, spécialiste des bases de données, chef de projet opérationnel, dédié. – Hugo et Ursule, deux utilisateurs compétents en gestion des connaissances. – Des groupes d’utilisateurs.	– Chef de projet, dédié. – Expert linguiste, chargé de la cartouche de connaissance juridique. – Deux développeurs informatiques.	– Chef de projet, dédié. – Chef de projet Couplage, dédié à la conception de la passerelle OntoPop. – Expert ontologue, chargé de l’ontologie du domaine. – Trois développeurs informatiques.	– Chef de projet dédié, chargé des interfaces utilisateurs. – Un développeur informatique.

Les acteurs impliqués dans le projet Exinis

22 Hugo et Ursule ont ensuite travaillé aux différentes tâches avec les fournisseurs (chefs de projet de Temis et de Mondeca, chef de projet couplage de Mondeca, et chef de projet de 4D Concept). Cette implication s’est avérée décisive pour la compréhension des usages. Elle a permis à Hugo et Ursule de développer leurs compétences initiales et de faire des suggestions concernant le couplage IDE/ITM, ce qui a entraîné de nouveaux développements de la part de Mondeca.

23 L’implication des utilisateurs a évolué selon trois phases :

24 – Première phase : des ateliers utilisateurs impliquant Hugo et Ursule, ont été organisés chaque semaine, qui ont permis à William d’élaborer les spécifications fonctionnelles de la solution, et ensuite aidé les fournisseurs à comprendre les usages. Ils ont aussi impliqué ponctuellement Charles, ainsi que les chefs de projet de Temis et Mondeca, les experts (linguiste de Temis et ontologue de Mondeca) et le chef de projet de 4D Concept. – Deuxième phase : plusieurs groupes réunissant quelques utilisateurs « non experts » ont été invités à une dizaine de réunions. Au cours de celles-ci, des propositions concernant les choix de conception leur étaient présentées, afin qu’ils expriment leur préférence. Mais le but de William était avant tout de les faire adhérer à ses propres choix de conception.

25 – Troisième phase : préproduction, au cours de laquelle des groupes d’utilisateurs ont testé la solution.

26 William a supervisé l’ensemble du projet et suivi le travail de Charles, qui a coordonné et surveillé la progression des tâches en étroite collaboration avec les chefs de projet des fournisseurs. William a aussi pris un certain nombre d’initiatives tout au long du projet :

27

• Il a fait développer une base de connaissance test, pour évaluer les performances du couplage IDE/ITM, ce qui a mis en évidence des problèmes liés au temps d’accès à ITM et à la lenteur du transfert d’information entre IDE et ITM. Cela a conduit Mondeca à modifier ITM.
• Il a demandé des développements spécif iques pour des raisons pédagogiques. L’objectif était de montrer aux dirigeants d’Exinis les possibilités qu’offriraient à terme l’adoption de la nouvelle plate-forme logicielle.
• Il a réorienté le projet et redéfini les priorités. Certaines tâches se révélèrent plus complexes que prévu, ce qui conduisit à une révision de certains éléments du contrat, à réduire le nombre de tâches attribuées aux fournisseurs et à augmenter le budget du projet, mais aussi à la définition de quelques tâches supplémentaires.

28 Le rôle tenu par William fut considéré comme essentiel par les acteurs projet des fournisseurs, du fait de ses compétences transversales, de sa vision globale et de sa capacité à réorienter le projet.

29 La coordination entre Temis et Mondeca sur la personnalisation de la passerelle OntoPop a été définie par l’élaboration de la méthodologie OntoPop. Cette méthodologie planifie les différentes tâches et modalités d’interaction entre les acteurs projet afin de réaliser l’intégration informatique de la plate-forme OntoPop. Elle a été rédigée à partir de l’expérience acquise au cours du projet PressPro et finalisée lors du projet Exinis.

2. Le projet PressPro

30 Nous présentons plus rapidement le projet PressPro en insistant sur ses différences par rapport au projet Exinis. Ce projet a été initié en juin 2003, par le chef du département documentation de PressPro, David, après une rencontre avec des représentants de Mondeca. Il cherchait à extraire et à catégoriser automatiquement les informations contenues dans les articles de la presse « people », tâches qui constituaient la majeure partie du travail des documentalistes de ce groupe de presse. Il eut l’idée de coupler IDE et ITM et souhaita également que Xyleme, éditeur de XLM, logiciel d’archivage au format XML, intègre le projet. Dans un premier temps, un cahier des charges définissant le niveau de performance prévu a été établi. Cependant comme la passerelle n’était pas encore développée, il était impossible de proposer un prototype qui aurait facilité la rédaction des spécifications. David devait diriger le projet et rapportait au comité de direction, et le responsable informatique de la documentation de PressPro devait jouer le rôle de gestionnaire de projet en charge du développement des interfaces utilisateurs. Plusieurs ateliers utilisateurs ont été mis en place, rassemblant par groupe l’ensemble des documentalistes, les chefs de projet des trois éditeurs de logiciels, ainsi que David, pendant plusieurs mois.

31 Mais, David et les informaticiens de PressPro ne sont pas parvenus à assumer la tâche liée aux interfaces utilisateurs, et six mois après le lancement du projet, celle-ci a été confiée à Xyleme. Dans le même temps, les ateliers utilisateurs ont été suspendus, les documentalistes ayant cessé d’y participer, doutant de la faisabilité du projet et crai- gnant une réorganisation de leur service. Par la suite, deux documentalistes de PressPro, dédiées au projet, ont travaillé dans les locaux de Mondeca avec les chefs de projet et experts de Mondeca et de Xyleme.

Tableau 2

Les acteurs impliqués dans le projet PressPro

PressPro	Temis	Mondeca	Xyleme
– David, chef de documentation de PressPro, à l’initiative et responsable du projet. – Responsable de l’informatique documentaire de PressPro, chef de projet opérationnel. – Deux développeurs informatiques.	– Chef de projet, dédié. – Expert linguiste, chargé de la cartouche de connaissance people. – Deux développeurs informatiques.	– Chef de projet, dédié. – Chef de projet Couplage, dédié à la conception de la passerelle OntoPop. – Expert ontologue, chargé de l’ontologie du domaine. – Trois développeurs informatiques.	– Chef de projet dédié. – Un développeur informatique.

Les acteurs impliqués dans le projet PressPro

32 Le projet progressait principalement sur la conception et le développement des interfaces utilisateur, de l’ontologie « people », et de la passerelle OntoPop. Bien qu’il en eût la charge, David n’a pu assumer la coordination de ces trois tâches, par manque de compétences dans les technologies utilisées par les différents logiciels. De fait, les trois éditeurs de logiciels concernés ont critiqué ce manque de coordination mais n’ont pas voulu l’assumer. Leur relation avec David s’est dégradée, ce dernier estimant les performances de la solution insuffisantes alors que les éditeurs de logiciel jugeaient ses attentes irréalistes. Les spécifications définies initialement se sont alors avérées trop floues, les questions portant sur la qualité de l’extraction d’information ne pouvant être tranchées. Malgré ces tensions, le projet a progressé mais l’attention de David a été accaparée par des problèmes rencontrés pour la personnalisation d’ITM et de XLM, problèmes qui ont été résolus grâce à l’implication forte des deux utilisateurs dédiés. Au contraire Temis a travaillé de manière autonome à la conception de la cartouche de connaissance « people ». Lorsque ce module personnalisé a été proposé aux documentalistes, la qualité de l’extraction terminologique les a déçues, et, du fait du retard déjà pris par le projet cette partie de la solution n’a finalement pas déployée.

33 La comparaison du déroulement de ces deux projets nous conduits à distinguer plusieurs rôles types joués par les clients PressPro ou Exinis : architecte, HPWM, gestionnaire opérationnel, chef de projet intégration, utilisateurs finaux. Le tableau 3 reprend pour chacun les activités qui les caractérisent et les acteurs qui les ont tenus dans les cas étudiés. Pour construire cette typologie, nous nous sommes également appuyés sur la littérature en management de projet (Clark et Fujimoto, 1991 ; Charue-Duboc, 1997).

Tableau 3

Rôles, responsabilités et activités au sein des projets

Rôles types	Responsabilités et activités	Acteurs du projet PressPro	Acteurs du projet Exinis
Architecte innovation	– Imagine un nouveau logiciel grâce à ses compétences transversales (agit comme un « gatekeeper »). – Choisit différents logiciels pour construire une nouvelle application. – Convainc la direction générale de sa firme de l’intérêt de l’innovation (agit comme « champion » de l’innovation). – Persuade les éditeurs de logiciels de participer au processus d’innovation. – Dirige la définition des spécifications du projet.	Chef de documentation de PressPro	Web Manager d’Exinis
Heavyweight Project Manager	– Participe à la définition des spécifications du projet. – Supervise le projet mettant en œuvre l’innovation. – Supervise le travail du gestionnaire de projet opérationnel. – Interagit ponctuellement avec les différents chefs de projet des fournisseurs. – Défend le projet auprès de sa direction générale (agit comme « champion » de l’innovation). – Réoriente le projet et redéfinit les tâches lorsque des difficultés ou des opportunités apparaissent. – Interagit avec certains utilisateurs à des moments clés (lancement, choix de conception, tests).	Chef de documentation de PressPro ? Aucun (en fin de projet)	Web Manager d’Exinis
Gestionnaire opérationnel du projet	– Travaille en étroite collaboration avec le HWPM. – Alloue, surveille et contrôle les différentes tâches. – Est responsable de la réalisation des travaux. – Interagit avec les chefs de projet des fournisseurs pour coordonner leurs actions.	Chef de projet PressPro ? Chef de projet Xyleme (après 6 mois)	Chef de projet Exinis
Chef de projet intégration logicielle	– Conçoit et développe des interfaces utilisateurs de la solution logiciel. – Observe les usages. – Collabore avec les utilisateurs.	Chef de projet PressPro ? Chef de projet Xyleme avec des utilisateurs non experts (après 6 mois)	Chef de projet 4D concept avec deux utilisateurs d’experts
Utilisateurs	– Observés par l’architecte innovation pour définir les spécifications du projet. – Transfèrent l’information « adhérente » (von Hippel, 2005) liée à leurs usages aux chefs de projet. – Formulent des avis sur des options de conception. – Testent la solution.	40 documenta listes (non qualifiés en gestion des connaissances)	50 éditeurs/ rédacteurs (deux qualifiés en gestion des connaissances, les « utilisateurs experts »)

Rôles, responsabilités et activités au sein des projets

1. Conception de l’architecture de l’innovation et heavyweight project management

35 Dans les deux projets étudiés, la conception de l’architecture produit, i.e. le choix des logiciels devant être combinés, est revenue au client. Nous suggérons d’appeler la personne qui imagine cette nouvelle architecture chez le client, le « lead user architecte ». Nous pensons que la définition d’une telle architecture produit ne peut résulter que de l’initiative d’un client. D’une part, en tant qu’expert de ses propres besoins, il est à même d’imaginer de nouveaux types d’applications. De plus, alors que les différents éditeurs de logiciel sont focalisés sur leur propre technologie, il est à même de les convaincre de collaborer. Il dispose de deux arguments pour catalyser le processus d’innovation :

36

• Le financement du projet, qui est généralement une aubaine pour les start-up, dont les ressources sont englouties dans le développement logiciel alors qu’elles n’ont encore que peu de clients.
• La démonstration de l’existence d’un marché pour l’application combinant leurs logiciels respectifs. Comme von Hippel (1986) le fait remarquer, les lead users ont des besoins spécifiques qu’aucun fournisseur n’est en mesure de comprendre aussi bien qu’eux. Le client qui imagine la nouvelle architecture démontre ainsi la possibilité d’un nouveau marché. Les start-up ont besoin de ce genre d’information sur le marché, parce qu’elles n’ont pas la connaissance transversale des technologies, ni d’idée précise des besoins qui leur permettrait d’évaluer le marché potentiel de telles applications.

37 Un deuxième rôle que les premiers clients doivent jouer est celui de HWPM (Heavy Weight Project Manager) (Clark et Fujimoto, 1991 ; Clark et Wheelwright, 1992). Comme il s’agit d’un nouveau type de logiciel, il existe une incertitude quant à la complexité de son adaptation aux besoins spécifiques du client, quant à l’acceptation des utilisateurs et quant à son niveau de performance. La nouveauté de la solution conduit à certaines imprécisions dans les spécifications initiales, et implique aussi des redéfinitions dans les tâches à réaliser en cours de projet et dans les budgets. Un acteur ayant les compétences pour piloter cette dynamique est nécessaire. Sa légitimité doit être reconnue en interne par sa direction, qu’il faut convaincre et rassurer et également en externe afin que ses choix soient acceptés par les fournisseurs. Il doit enfin faire en sorte que la personnalisation de la solution soit adaptée aux besoins de son entreprise. Pour cela, il a à définir les modalités d’implication des utilisateurs afin qu’elles soient propices au transfert de l’information adhérente liée à leurs usages et aux tests. Il pourra également conduire d’autres formes de personnalisation qui consistent à adjoindre aux logiciels cœurs formant la plate-forme (Gawer et Cusumano, 2002), d’autres logiciels, comme nous l’avons observé lors des deux projets. Dans les deux cas, sa connaissance des utilisateurs est primordiale.

38 Un HWPM apparaît donc nécessaire pour diriger les projets du type étudié et ce rôle doit être tenu par un acteur situé chez le client, que nous appelons « lead user HWPM ».

2. Gestion opérationnelle de projet

39 Le pilotage opérationnel du projet dans son ensemble a été conduit par un chef de projet dédié chez Exinis. Pour l’essentiel, il a joué le rôle de gestionnaire opérationnel du projet (Charue-Duboc, 1997), responsable de la réussite du projet et chargé de veiller à la mise en œuvre des moyens techniques nécessaires à l’atteinte des objectifs définis par le HWPM.

40 Ce pilotage peut s’avérer difficile et incertain. En effet, initialement, il n’existe aucune méthode standard de mise en œuvre de ce logiciel et il est nécessaire de faire collaborer des éditeurs de logiciels qui n’en ont pas l’habitude, Il doit alors être crédible aux yeux des fournisseurs, doté de compétences en gestion de projet logiciel et capable de travailler en étroite collaboration avec le HWPM. Cette proximité, la bonne compréhension des objectifs poursuivis ainsi que la nécessité d’interagir avec chaque fournisseur, nous conduit à considérer que le rôle du gestionnaire de projet opérationnel doit être assumé par un acteur situé chez le client, que nous proposons d’appeler « lead user gestionnaire de projet ».

3. Personnalisation avec les utilisateurs lead users

41 Les utilisateurs d’Exinis ayant certaines compétences dans les technologies logicielles employées eurent une contribution cruciale dans la collaboration avec les experts de Temis et Mondeca. Ces utilisateurs présentent, en tant qu’individus, des caractéristiques de lead user, parce qu’ils sont « à la pointe » d’une tendance reconnue par les experts, celle du « web sémantique », en raison de leur formation en gestion des connaissances, mais aussi parce qu’ils ont compris les bénéfices qu’ils pourraient retirer de l’usage de l’innovation. Chez PressPro, au contraire des utilisateurs qui n’avaient ni compétences ni motivations de ce type ont été impliqués, ce qui a été un obstacle pour le projet.

42 Nous insistons donc sur le rôle majeur joué par les utilisateurs possédant des compétences et une motivation qui les distinguent des utilisateurs ordinaires. Leur contribution à l’expression détaillée des besoins d’utilisateurs les différencie profondément des autres rôles soulignés plus haut. Nous proposons d’appeler ces utilisateurs qui possèdent les caractéristiques de lead user, des « lead user experts ».

4. Contribution des utilisateurs « ordinaires » : multiplicité des usages et tests

43 La contribution des utilisateurs « non experts » n’a pas été la même dans les deux projets étudiés. Pour Exinis, elle n’a concerné qu’un petit nombre d’utilisateurs, elle a consisté à valider des options de conception, et en des campagnes de tests. Pour PressPro, la volonté d’associer l’ensemble des utilisateurs aux ateliers et partant au projet lui-même a été un échec. Cette constatation va dans le sens de ce que préconise les tenants de l’user innovation, à savoir que les apports des utilisateurs au processus de conception ne sont profitables que lorsqu’il s’agit de lead users. L’apport commun des utilisateurs « ordinaires » lors des deux projets étudiés concerne presque exclusivement les tests, ce qui renvoie à la notion d’intelligence collective, prégnante dans l’univers Open Source (Raymond, 1999).