1L’entrepreneuriat académique peut être décrit comme un processus d’exploration collective dans lequel les fins (opportunités) poursuivies, les moyens (ressources) mobilisées et les collectifs (sociotechniques) concernés sont émergents – un résultat de l’exploration, plus qu’une donnée de départ. L’enrôlement de partenaires est une source de débordements : toute modification dans le « sociogramme » de l’innovation est susceptible de remettre en cause son « technogramme ». Le cadrage de ces débordements, à travers l’accommodation des intérêts de nouveaux alliés dans l’artéfact technique qui tient le collectif entrepreneurial ensemble, est coûteux. Dans le cas étudié dans le chapitre 1, l’association entre le logiciel Médiation et les internautes à la recherche du meilleur prix, par exemple, implique le développement de mécanismes assurant la communication avec une multitude de sites marchands, d’algorithmes facilitant la recherche d’informations et maximisant la pertinence des résultats proposés à l’utilisateur, d’une architecture informatique autorisant des millions de connexions, d’outils de suivi permettant de visualiser et de chiffrer le trafic généré…

2Or, au fur et à mesure que le réseau de la spin-off s’étend et que l’on passe de l’entrepreneuriat à l’entreprise, de l’exploration à l’exploitation, cette sensibilité de la technologie à ses partenaires devient problématique. La jeune pousse doit se détacher de ses premiers utilisateurs, contrôler l’adaptation de sa technologie, afin d’assurer la capacité de son produit à circuler [Mustar, 1994; Mustar, 1997]. C’est à cette phase du développement des spin-offs académiques que s’intéresse le présent chapitre, en étendant l’étude de l’entrepreneuriat au-delà de la création d’une nouvelle entreprise. On montre que leur travail consiste non seulement à construire des associations exploratoires, mais aussi à stabiliser celles-ci pour former un réseau étendu et consolidé, dans lequel leurs produits peuvent circuler sans être constamment remis en cause.

3Nos analyses s’appuient sur une étude de cas qui présente l’évolution de la spin-off Rocher Technologies1. L’étude de cas est focalisée sur deux périodes : les années 1980-90, au cours desquelles la technologie qu’exploite Rocher Technologies a été développée, et la période actuelle (c’est-à-dire fin 2007 – début 2010). On retrace d’abord la genèse de l’entreprise et du logiciel qu’elle commercialise aujourd’hui, pour souligner le rôle que jouent les spin-offs académiques dans la consolidation des réseaux émergents qu’elles contribuent à construire. On examine ensuite, à travers la description du produit et des partenaires actuels de Rocher Technologies, comment l’entreprise transforme une technologie en un produit qui est capable de circuler dans un réseau de plus en plus vaste et solide.

CONSOLIDER DES RESEAUX EMERGENTS

4Rocher Technologies est un éditeur d’outils pour le développement de logiciels embarqués critiques, c’est-à-dire des logiciels tels que « s’ils ne marchent pas, il y a des morts : un logiciel d’airbag, un pilote automatique d’avion, le contrôle commande d’une centrale nucléaire, le freinage d’une voiture ou d’un train… ». L’entreprise tient son nom du langage Rocher, développé à partir des années 1980 par une équipe de recherche dirigée par Michel dans un centre de mathématiques appliquées situé à Sophia-Antipolis (« Labo1 »). Quel est le lien entre les logiciels embarqués critiques et le langage Rocher ?

Du langage au produit

5Le langage Rocher annonce publiquement sa naissance dans un article scientifique daté de 1983. Il se présente comme un langage dédié aux programmes temps-réel qui ont la particularité de devoir « répondre à des stimuli entrants générés par l’environnement extérieur dans un délai “contrôlable” ». Rocher résout ce problème du temps de réaction par l’hypothèse synchrone, qui consiste à supposer que « les sorties du système réactif sont […] conceptuellement synchrones avec ses entrées », que le temps est en quelque sorte gelé.

6Quelles sont les origines et les conséquences de cette hypothèse ? Comme dans de nombreuses histoires d’innovation, tout commence avec une préoccupation qui non seulement n’a pas, du moins à première vue, grand-chose à voir avec les applications qui feront le succès de ce langage par la suite, mais en plus paraît assez ludique et raisonnablement démunie d’importance. Il s’agit ici d’une course de voitures robots, organisée par un journal de microinformatique. Travaillant à la programmation de la voiture robot qu’ils ont l’intention de présenter dans cette compétition, deux chercheurs de Labo1 se heurtent à l’incapacité des langages classiques d’exprimer des algorithmes de contrôle de manière satisfaisante et à la nécessité d’énoncés spécifiques pour gérer le temps. Ils esquissent alors un nouveau langage, pour les besoins de leur voiture robot. L’histoire ne retient pas si ce langage leur permet de gagner la course ; ce que l’on sait en revanche, c’est qu’il réussit, du moins, à intéresser un autre chercheur du centre, Michel, qui se penche sur ses aspects mathématiques et lance, en 1982, le projet Rocher. Voici comment il résume cette histoire :

« [Labo1] a été créé par un mélange de deux équipes, de deux disciplines différentes : les automaticiens et les informaticiens. Et il se trouve que les automaticiens travaillaient typiquement sur le contrôle des systèmes temps réel. Et qu’à l’époque on ne savait absolument pas programmer ce genre de choses. Et les automaticiens viennent avec une idée, un jour, sur une façon de programmer en fait une petite voiture pour un journal […]. Et arrivent avec des idées extrêmement originales au niveau de la programmation. […] Ca ne ressemble pas du tout à la façon classique de faire des gens. […] Moi, je trouvais ça très joli ; par contre je ne savais pas du tout comment on pouvait en parler, le rendre sérieux. Et donc ça m’a éveillé l’esprit. […] Et donc l’idée que j’ai eue par rapport à ce qu’ils proposaient, c’était de dire comme on fait du temps réel, tout serait plus simple si les machines calculaient infiniment vite. Hypothèse absurde. Mais c’est par les hypothèses absurdes qu’on progresse. »

7Cette « hypothèse absurde » a pour corollaire une telle efficacité qu’on pardonne volontiers au langage le peu de cas qu’il fait de la réalité à laquelle il est censé se conformer :

« L’hypothèse synchrone forte peut paraître totalement irréaliste à première vue, puisque les vraies machines ne sont pas infiniment rapides. Toutefois, nous verrons qu’elle est en fait extrêmement utile et a des conséquences étonnamment bonnes : elle simplifie vraiment beaucoup de problèmes […]. »

8Une de ces conséquences est une meilleure fiabilité des programmes générés. Le lien entre le langage Rocher, avec son hypothèse synchrone, et les logiciels critiques, qui deviendront son domaine d’application, commence à se dessiner. On est en 1984. Il faudra une quinzaine d’années, et de nombreux déplacements, pour que ce lien se réalise.

9Pas très loin de là, deux chercheurs d’un laboratoire de mathématiques appliquées à Grenoble (« Labo2 ») s’attellent à une tâche similaire, quoique bien moins amusante que la préparation d’une course de voitures robots : créer un langage de programmation que des ingénieurs automaticiens pourraient utiliser dans le développement d’applications critiques. Ce langage voit bientôt le jour sous le nom de Cristal. Comme Rocher, Cristal est un langage synchrone – et bénéficie donc de la meilleure fiabilité que permet l’hypothèse synchrone. De même, les deux langages sont formels, c’est-à-dire qu’ils reposent sur une sémantique mathématique, ce qui permet la génération automatique de code (à partir d’un modèle formel) qui est correct par construction (ce qui supprime la nécessité de tout une série de tests ultérieurs). Rocher et Cristal ont cependant quelques différences, notamment en ce qui concerne les types de données auxquelles ils sont adaptés : des événements discrets, pour le premier, et des flots semi-continus de données, pour le second2.

10Les différences entre Rocher et Cristal se creusent au fur et à mesure que les langages circulent, suivant les déplacements des chercheurs impliqués dans leur développement. En 1986, une société (« Entreprise1 ») embauche deux anciens doctorants de l’équipe Cristal, qui utilisent des concepts de ce langage pour créer un outil avec lequel est développé un système de surveillance et d’arrêt d’urgence pour des centrales nucléaires. Trois ans plus tard, un autre ancien doctorant de l’équipe Cristal est embauché par une spin-off de l’INRIA (« Spin-off1 »), pour réaliser une étude de marché sur le potentiel commercial d’un tel outil. Au cours de son étude, il constate qu’un constructeur d’avions (« Entreprise2 ») a développé un outil similaire pour réaliser les commandes de vol par ordinateur. L’idée naît donc de créer un produit commercial sur la base de ces deux outils. Pour cela, un laboratoire commun à Labo2 et à Spin-off1 (« Labo3 ») est créé en 1993. C’est là que se trouve située la réalisation du « transfert » de la science vers le marché : l’histoire raconte que Cristal est « transféré avec succès à l’industrie » en 1993. Un deuxième transfert suit : le résultat de l’intégration de ces deux outils, nommé Surcod, revient chez Entreprise2 :

« [L’équipe de Labo3] montre que [Surcod], c’est la même chose pour les ingénieurs [d’Entreprise2] que [l’outil qu’ils utilisaient auparavant], mais que c’est beaucoup plus simple, que c’est beaucoup plus rigoureux, etc. Et comme [Entreprise2] a un énorme problème – c’est qu’il faut certifier les programmes d’avionique, alors partir d’une base plus simple, c’est toujours mieux, parce qu’il y a moins de choses à expliquer […]. Et donc l’équipe [de Spin-off1] réussit l’exploit, pour tout dire, [de faire en sorte] qu’[Entreprise2] adopte [Surcod]. […] C’est des commandes de vol, ce n’est pas tout à fait rien. Dans un [avion] il n’y a pas de pilote ; le pilote il a un joystick en plastique ; c’est ce qu’il y a derrière le joystick en plastique, plus des tas d’autres choses. »

11Surcod est commercialisé par Spin-off1 jusqu’au rachat, en 1999, de cette société par une entreprise suédoise de télécommunications (« Entreprise3 ») qui l’intègre dans sa ligne de produits, pour le revendre, deux ans plus tard, lorsque la crise des télécommunications la frappe de plein fouet. Avant de revenir sur cette vente – qui est le moment où les histoires des deux langages synchrones et de Rocher Technologies se croiseront de manière définitive – faisons un bref retour un peu plus au sud et quelques années auparavant.

12À Sophia-Antipolis, Rocher poursuit son développement. Un premier compilateur (Rocher V2) naît de la collaboration entre l’équipe de recherche et une autre société qui opère dans le secteur aéronautique (« Entreprise4 ») et qui, comme le raconte Michel, a la vertu de « [poser] des problèmes d’un ordre de grandeur plus dur que ceux que [l’équipe de recherche se pose] spontanément ». Entreprise4 « implémente » le langage Rocher dans plusieurs projets (par exemple, pour la spécification de la logique de contrôle du train d’atterrissage d’un avion) qui alimentent de nouvelles questions et guident ainsi la suite des développements :

« Ces grands programmes, qui se sont présentés dans la jeunesse de [Rocher], ont permis d’identifier de nouveaux problèmes et directions de recherche, à qui les ingénieurs [d’Entreprise4] apportaient souvent leurs propres solutions préliminaires. Voici une histoire qui illustre le rôle pionnier qu’a joué cette entreprise à l’égard de [Rocher] […]. Certains exemples donnés par [Entreprise4] montraient des boucles combinatoires légitimes lorsque les pièces étaient assemblées. La compilation du programme entier nécessitait donc des analyses de causalité constructive. C’était là une forte motivation d’attaquer le problème de la causalité sérieusement dès le départ ; ce n’était plus une question purement théorique qu’on pourrait facilement mettre de côté. »

13Une nouvelle génération de compilateurs (Rocher V3) – « énormément plus efficace que la précédente » – voit le jour à la fin des années 1980. Suivant l’intérêt croissant de quelques clients pilotes, une tentative « d’industrialisation » est menée en 1988 en collaboration avec Entreprise4, un autre grand groupe opérant dans le secteur de la défense (« Entreprise5 ») et une société d’ingénierie (« Entreprise6 »), qui sera remplacée par une autre spin-off de l’INRIA (« Spin-off2 »). Quel est son résultat ? « Une espèce d’échec, parce que le produit n’était pas encore assez mature », explique Michel.

14Alors que le consortium s’attelle à l’industrialisation de Rocher V3, l’équipe de recherche de Labo1 poursuit ses travaux, en mettant Rocher « au contact de gens différents » : des chercheurs d’une autre société (« Entreprise7 ») spécialisée dans le hardware. De cette collaboration assez rare – car « le hardware et le software, ça ne se cause pas du tout » – résulte, en 1992, Rocher V4. Qu’a-t-il de différent ? « [Rocher] V2, explique Michel, c’était lent et ça faisait des codes objets qui pouvaient exploser […] en taille. [Rocher] V3, c’était rapide, mais ça faisait exactement la même chose. [Rocher] V4, c’était encore plus rapide et ça faisait des codes géniaux et petits. »

15Ce nouvel arrivé finit par décourager Entreprise7, qui se trouve aux prises avec l’industrialisation du langage Rocher, mais dans sa version 3. Elle « passe le bébé » à une autre spin-off de l’INRIA (« Spin-off3 »). Alors que Spin-off3 s’affaire, à son tour, à la commercialisation de Rocher, Michel et son équipe continuent à travailler avec des partenaires hardware :

« Pendant ce temps-là, moi je continue à développer ma techno recherche […] avec d’autres boîtes tout à fait différentes. [Entreprise7] étant morte, je travaille avec […] [Entreprise8]. Et on a des résultats extrêmement intéressants avec un labo de recherche [d’Entreprise8] […]. On améliore énormément tout ça et on fabrique un langage qui s’appelle [Rocher] V7 […], capable de faire et du logiciel et du matériel. »

16C’est cette nouvelle, et septième, version du langage Rocher qui passera l’épreuve de l’industrialisation. Avant de voir comment, résumons les parcours des deux langages synchrones que nous avons suivis ici. Le langage Cristal se voit combiner – au fil des déplacements d’anciens membres de l’équipe de recherche qui lui a donné naissance – à deux outils que des utilisateurs ont « bricolé » pour leur propre usage. Il est « transféré avec succès à l’industrie » dès le début des années 1990 : commercialisé par Spin-off1 et utilisé par un client comme le constructeur d’avions Entreprise2. Quant à Rocher, au lieu de se contenter de l’intérêt que lui témoignent ses premiers utilisateurs (notamment Entreprise4 et Entreprise5), ce langage continue à circuler, en traversant les frontières sectorielles, et à se transformer, au gré des rencontres : Rocher V3, qui semblait prêt à être « industrialisé », devient V4 (avec Entreprise7), puis V7 (avec Entreprise8). Son transfert est tenté dès la fin des années 1980, mais apparaît comme un échec : les sociétés en charge de son industrialisation – Spin-off2, puis Spin-off3 – « se passent le bébé ». Le transfert ne se réalisera pleinement qu’en 1999 avec la création de la spin-off Rocher Technologies par son dirigeant actuel, Yann. Voici comment ce dernier résume sa rencontre avec le langage Rocher :

« L’idée de créer [Rocher Technologies] est née en 1998. J’avais été approché […] par des actionnaires d’une société de services informatiques qui s’appelait [Spin-off3]. Elle était en quasi dépôt de bilan, en faillite, et les actionnaires cherchaient un repreneur, un manager pour redresser la société. C’était une des premières start-ups de l’INRIA, qui avait pas mal d’activités et notamment avait commencé à s’intéresser à la programmation de systèmes embarqués sur la base de questions qui lui étaient posées par deux clients qui étaient [Entreprise4] et [Entreprise5] pour le programme Rafale, et qui lui avaient dit : “on a des problèmes pour programmer nos systèmes embarqués, vous êtes un peu spécialistes en simulations et méthodes formelles, on a trouvé des technologies de type académique à l’INRIA” – le langage [Rocher]. […] Donc je suis tombé en arrêt en 1998 devant cette problématique. »

17La solution trouvée consiste à couper Spin-off3 en deux, en essaimant l’activité liée à la programmation de systèmes embarqués. C’est ainsi qu’en novembre 1999 est fondée Rocher Technologies : « une start-up assez originale [qui a] d’emblée deux clients identifiés : [Entreprise4 et Entreprise5] ». L’objectif est le suivant :

« Développer et industrialiser […] un environnement graphique de modélisation qui fournit des outils de vérification formelle et de génération automatique de code compact et rapide pour le développement de composants électroniques produits à grande échelle et de systèmes temps-réel embarqués critiques. »

18Afin de répondre à cet objectif, la jeune société recourt à trois « transferts de technologies ». Il s’agit de mobiliser des « bouts de solutions » technologiques disponibles dans la recherche publique et privée et de les « regrouper […] pour faire quelque chose d’industriel ». Le premier transfert est celui du langage Rocher : dès sa création, la société achète une licence des outils qui avaient été développés par l’équipe de Labo1. Deux ans plus tard, Michel et une partie de son équipe rejoignent l’entreprise. Ainsi, en 2001, la jeune pousse a une équipe, un outil et quelques clients. Son outil, basé sur le langage Rocher, est « capable de faire et du logiciel et du matériel ». Ses clients, sans surprise, sont des sociétés comme Entreprise4, qui dispose de 33 licences et utilise Rocher pour le développement du logiciel de commande de vol de l’avion Rafale ; Entreprise5, pour le développement de protocoles de commerce électronique ; ou encore une autre entreprise opérant dans le secteur du hardware qui se sert de Rocher pour la conception de processeurs de signal numérique pour téléphones mobiles. Qu’y a-t-il de commun entre le logiciel de commande de vol d’un avion et les circuits pour téléphones mobiles ? « Les maths, le cœur mathématique », selon Michel. La technologie est « polymorphe » : elle se prête à de multiples utilisations tout en restant la même. Toutefois, l’hybridité de Rocher place la société qui le commercialise dans une « situation délicate » :

« On avait un produit qui attaquait à la fois le marché hardware et le marché software. Sur le marché hardware, on était tout seul, c’était bon. Sur le marché software, on était concurrent de [Surcod] : direct, frontal. Sauf que [Surcod] était déjà établi. […] Donc on avait deux fers au feu […]. Et puis on commençait à avoir des doutes sur notre stratégie qui était effectivement d’aller voir des clients en leur disant : “on a un machin qui sait tout faire”. Le client ne croit pas à ça. […] Et là, coup de bol, la crise des telecom. […] [Entreprise3] part en morceaux et nous vend [Surcod] pour une bouchée de pain. […] Donc hop, on achète la boîte, on abandonne complètement [Rocher]-software […], on fait [Rocher] uniquement hardware et [Surcod] software avec l’équipe existante. »

19Ce deuxième transfert de technologie a lieu à la fin de l’année 2001. Il s’agit d’un transfert particulier, car il consiste en l’achat d’un produit : Rocher Technologies rachète à Entreprise3 les actifs de Surcod, c’est-à-dire sa licence, mais aussi ses employés et ses clients. Alors que l’équipe de R&D de la jeune société se demande « comment unifier tout ça », Surcod devient le produit phare de Rocher Technologies. En 2002, la société compte déjà plus de 200 licences vendues ; des grands comptes, parmi lesquels Entreprise2, ont rejoint la liste de ses clients.

20Deux domaines d’activité se dégagent alors clairement : celui des logiciels critiques et celui des composants électroniques. Ils ont le point commun suivant : des coûts de vérification très élevés, d’où l’importance d’outils de développement fiables qui permettent de générer du code qui est correct par construction (pour les composants électroniques, « c’est le coût d’un dysfonctionnement sur le terrain qui est évidemment critique : si un bug se manifeste sur le principal composant électronique une fois qu’ont été vendus plusieurs millions de téléphones portables, le coût de remplacement est monstrueux »). Ce point commun ne parvient toutefois pas à résorber les différences qui séparent ces deux domaines d’application et qui défient l’unicité de la technologie, en dépit de son « polymorphisme » :

« La technologie se sépare en deux, pour de vraies bonnes raisons : parce que les marchés sont différents. On comprend – on savait, mais là on met en œuvre – le fait que ce n’est pas la technique qui dicte, c’est les marchés… Et puis les marchés se séparent en deux et donc on fait une filiale hardware et une filiale software. »

21La filiale hardware ne vivra que quelques années. Ne concernant que quelques clients et restant « relativement confidentielle », cette activité demeure peu visible, surtout aux côtés de Surcod qui accumule de nouveaux clients. Aujourd’hui, la filiale hardware est fermée et sa technologie est désormais exploitée par une société américaine. Par souci de simplicité, nous nous focalisons donc exclusivement sur Surcod dans ce qui suit.

22Enfin, un troisième transfert a lieu en 2006, lorsque Rocher Technologies rachète à Entreprise5 le produit Dessin. Dessin est un outil de développement d’applications graphiques – une sorte de « super Powerpoint » – qu’Entreprise5 utilisait en interne, notamment pour la conception du cockpit d’un avion. Il s’agit là d’un transfert encore différent : le produit n’est accompagné dans son déplacement d’une entreprise à l’autre ni par ses clients (puisqu’il n’avait d’autre client que son concepteur), ni par les employés qui y étaient liés (seulement deux personnes sont recrutées par Rocher Technologies). Ce transfert s’inscrit dans une « démarche intellectuelle » de constitution de l’offre de Rocher Technologies qu’Yann résume ainsi : « J’ai des applications des logiciels critiques qu’on va trouver dans l’aéronautique, dans les trains, dans l’automobile, dans le nucléaire, dans la chimie […] et pour ça j’ai besoin d’une suite d’outils pour faire de la logique, pour faire du calcul et pour faire du graphique. »

23L’offre est progressivement étendue du secteur de l’aéronautique et de la défense vers les domaines ferroviaire, nucléaire et automobile, chaque élargissement déclenchant l’apparition de nouveaux besoins. Par exemple, en 2007 Rocher Technologies introduit la version 6.0 de Surcod, qui permet notamment de combiner la modélisation à base de flots de données (pour laquelle Cristal était adapté) avec celle à base d’événements discrets (pour laquelle Rocher était adapté), cette deuxième étant prépondérante dans le secteur de l’automobile et des transports. Les deux langages synchrones se trouvent ainsi, enfin, intégrés dans un seul produit. Notons que Rocher Technologies continue encore aujourd’hui ses relations avec la recherche publique, notamment à travers les pôles de compétitivité ou les projets européens. Munie d’une « shopping list » de ses clients, elle garde « un radar qui tourne sur ce qui se passe dans la recherche publique », pour dénicher ses « pépites » et « piocher » dans ses résultats.

Le rôle des spin-offs dans les collectifs d’exploration

24L’histoire que nous avons retracée ci-dessus est celle de deux explorations qui s’organisent autour des langages Rocher et Cristal. Elles ont des configurations similaires. Les collectifs exploratoires sont composés d’équipes académiques, d’entreprises établies et de jeunes sociétés technologiques – trois pôles entre lesquels circulent diverses entités : des documents et des artéfacts (fichiers, bouts de langages, outils, articles scientifiques, etc.), des personnes (doctorants, employés, équipes de recherche), des droits (de propriété et d’utilisation), de l’argent [Larédo & Mustar, 1996].

25Ces déplacements n’affectent pas de la même manière les réseaux qu’ils composent. Par exemple, le déplacement de RocherV3 de Labo1 vers Entreprise7 étend son réseau tout en augmentant le degré d’incertitude : Rocher devient V4 et parle désormais au logiciel et au matériel, se frayant ainsi un chemin dans le monde du hardware ; alors qu’il était sur le point d’être commercialisé, il revient dans un régime d’exploration et son industrialisation se voit repoussée. En revanche, lorsque RocherV7 passe de Labo1 à Rocher Technologies, accompagné d’une grande partie de l’équipe qui lui a donné naissance, c’est « dans un but de redévelopper tout ça dans une logique de transfert industriel, dans une logique de création d’un produit industriel ». Les incertitudes et problèmes se trouvent désormais circonscrits au sein de la jeune société ; l’objectif est « l’intégration ». Rocher devient de plus en plus certain, unique, stable. Ses rencontres avec de nouveaux utilisateurs ou partenaires ne peuvent plus (ou du moins ne doivent plus) bouleverser ni son identité, ni son réseau.

26Le transfert peut alors être défini comme un déplacement particulier qui marque le passage de réseaux émergents, dans lesquels « identités, intérêts et compétences sont le résultat de traductions provisoires et expérimentales », à des réseaux consolidés, où « l’action est programmable, les identités et les compétences sont stabilisées et fortement semblables et/ou complémentaires » [Callon, 1999, pp. 41, 44]. On observe, dans les cas de Comprix et de Rocher Technologies, tout le travail qui prépare le transfert – un travail d’exploration qui ne cesse de générer de nouvelles connexions, tout en en coupant d’autres. Mais le transfert est aussi le point de départ d’un travail de consolidation – ou d’exploitation – qui vise à étendre le réseau de l’innovation, devenue produit, tout en limitant les bouleversements que cette extension génère. Cette condition de non remise en cause est capitale pour le succès de l’innovation. En témoigne l’échec de l’industrialisation de Rocher V3, que Michel résume ainsi : « Quand [Spin-off2] a eu [Rocher] V4, [son dirigeant] m’a dit : “Ce n’est pas possible, on a investi dans V3 et tu dis qu’il y a V4 qui est beaucoup mieux !” […] [Spin-off2] a fini par laisser tomber, ce qui était assez normal […]. »

27Le rôle capital que jouent les spin-offs dans la consolidation des réseaux émergents auxquels donne lieu le travail des collectifs d’exploration apparaît clairement dans le cas de Rocher Technologies. Son fondateur explique ainsi la création de l’entreprise :

« Ce n’est pas un processus dans lequel un chercheur a une idée, essaie de la valider contre le marché, crée une société, lève des fonds, etc., etc. Ce n’est pas du tout un projet industriel linéaire de la recherche vers l’industrie. C’est en gros exactement le contraire ».

28À l’encontre du « mécanisme habituel : j’ai un truc, qu’est-ce que j’en fais ?, je le valorise, je le mets où ? », sa démarche a consisté à « partir du besoin pour agréger quelque chose, pour agréger des réponses à des besoins clients »3. Mais si le besoin est déjà là (chose que tout entrepreneur soutiendrait avec ferveur) ; si, comme dans le cas de Rocher Technologies, une demande existe déjà, puisqu’avant même sa création la start-up a déjà deux clients (configuration bien plus rare) ; quel est alors le rôle des spin-offs ? Les utilisateurs pilotes du langage Rocher (Entreprise4 et Entreprise5) l’explicitent lorsqu’ils « disent à [Spin-off3] : “[Rocher] est un outil académique ; moi, pour un programme qui va durer trente ans [le programme Rafale], je ne peux rien en faire ; j’ai besoin d’un partenaire industriel qui industrialise” ».

29Que signifie « industrialiser » ? Comme nous l’avons vu, une première tentative d’industrialisation du langage Rocher a lieu à la fin des années 1980, en coopération avec Entreprise6. Elle consiste en : « un nettoyage du code du compilateur, des portages sur diverses stations de travail, des tests intensifs, et une refonte de la documentation ». Elle procède par des rencontres avec les industriels : d’abord les « “pseudo-industriels” que l’on a comme interlocuteurs » dans le monde de la recherche, puis les « industriels réels » qui ont le « vrai problème de l’opérationnel qui a à exécuter une chose précise dans un temps fini ». Industrialiser un outil académique, c’est « en faire quelque chose […] qu’on peut mettre entre toutes les mains, où il ne faut pas avoir fait une thèse pour utiliser le produit ». L’industrialisation se définit donc comme l’adaptation d’un artéfact technique à de nouveaux utilisateurs dont le nombre est toujours plus grand et les compétences requises toujours moindres. Pour l’expliquer, Yann propose une métaphore automobile :

« Les gens achètent des voitures peintes, ils n’achètent pas des moteurs, bruts. Les chercheurs font des moteurs, pas mauvais ; autour ils foutent des carrosseries absolument ignobles et n’ont même pas idée qu’il faut les peindre. […] Si j’avais essayé de vendre les technos INRIA à un utilisateur chez Boeing […], je me serais fait sortir de la pièce. Ils auraient dit : “c’est un academic product, dégagez”. »

30L’industrialisation se nourrit de beaucoup d’argent : « faire un moteur, ça coûte 1 ; faire la carrosserie, ça coûte 3 ; la peindre, ça coûte 10 ». Dans le cas de Rocher Technologies, « l’accès à la techno [n]’a pratiquement rien coûté ; par contre, le nettoyage de la techno, le packaging, etc. ça coûte très cher », d’autant plus qu’il ne s’agit pas du simple ajout d’une couche, mais de la transformation du produit dans son ensemble, y compris la technologie de base :

« [Le marketing, le packaging] parfois a des impacts assez profonds sur le cœur, […] l’architecture du cœur des produits [doit] changer. Parce que si on doit pouvoir générer plusieurs adaptations ou customisations, il ne faut pas organiser les développements qu’on avait pensés au départ, la modularité n’est pas la même, et re-modulariser un truc qui n’est pas modulaire, c’est vachement compliqué. »

31Voici donc ce que fait une spin-off comme Rocher Technologies : elle transfère, mais surtout elle adapte, afin de réduire les exigences que la technologie pose sur l’utilisateur et d’étendre ainsi le spectre de ceux qui pourraient revêtir ce rôle, au-delà des « pseudo-industriels ». L’élargissement du réseau sous contrainte de non remise en cause – c’est-à-dire, sa consolidation – s’appuie sur un produit aux caractéristiques particulières : un artéfact technique qui est capable de circulation, mais d’une circulation fluide, sans heurts majeurs. Le passage à l’exploitation pose ainsi une exigence forte sur la technologie qui se trouve transférée : elle doit désormais devenir un outil industriel, un produit. Il reste à voir comment Rocher Technologies parvient à gérer le fin réglage entre exploration et exploitation en étendant le réseau de la technologie innovante qu’elle commercialise sans pour autant remettre en cause la stabilité des entités qui circulent au sein de lui.

ETENDRE DES RESEAUX CONSOLIDES

Un produit standardisé et modulaire

32La consolidation du réseau de Rocher Technologies – qui, une dizaine d’années après la création de l’entreprise, compte 130 employés, une centaine de clients et une multitude de partenaires technologiques et commerciaux4 – s’appuie sur la standardisation de son produit. Surcod arrive à ses utilisateurs sous la forme de « CD-rom dans une boîte en carton ». Son utilisation suppose un ensemble de compétences que la société développe chez l’utilisateur au cours d’une formation, d’une durée moyenne de cinq jours. Ce service peut être complété par une formation de deux ou trois jours pendant lesquels les consultants de Rocher Technologies travaillent avec l’utilisateur sur la base d’un premier projet que celui-ci a fait avec Surcod afin d’optimiser la performance de l’outil pour le type d’applications envisagées. Jusqu’ici, c’est l’utilisateur qui s’adapte au produit ; c’est le prix à payer pour un produit standardisé. Comme l’explique le dirigeant de la société, « il n’y a pas de customisation : c’est un outil de développement. Vous faites un modèle ou une application, vous appuyez sur un bouton, ça génère du code, il n’y a rien à customiser dans le produit. »

33Les adaptations du produit au client se font « à la marge », à travers son intégration dans un cycle de développement et un environnement d’utilisation particuliers. Surcod génère du code ; or, ce code doit correspondre à un ensemble d’exigences, définies en amont, et doit pouvoir être vérifié et intégré, en aval. Il s’insère dans un flux de travail qui fait intervenir d’autres acteurs – architectes, codeurs, vérifieurs – qui sont eux-mêmes équipés d’outils avec lesquels Surcod doit cohabiter, communiquer, s’interfacer. La « singularisation » [Callon & Muniesa, 2005] du produit est un exercice pratique et matériel, car le monde de l’utilisateur est déjà peuplé d’une multitude d’autres outils qui peuvent montrer une certaine résistance à la bonne entente avec les nouveaux venus. Dans le cas de Surcod, ce type de conflit potentiel est pris en compte en amont, intégré dans le produit, avec la même logique de standardisation qui passe ici par des « passerelles », c’est-à-dire des modules standards permettant le « couplage » de Surcod avec d’autres outils, réalisés par d’autres éditeurs. La singularisation du produit est ainsi réglée au préalable, grâce à sa forme modulaire.

Les partenaires technologiques : complémentarités et bénéfices

34Quels sont les outils avec lesquels le produit de Rocher Technologies cohabite ? Ce produit permet de passer automatiquement et de manière sûre d’un ensemble d’exigences (qui définissent, par exemple, le niveau que la pression dans la cabine d’un avion ne doit pas dépasser) à la spécification d’un logiciel et à la génération du code correspondant. Pour cela, Surcod doit d’abord pouvoir lire les exigences de départ. Un de ces modules s’occupe donc d’importer et de traiter les exigences, qui sont elles-mêmes spécifiées à l’aide d’outils particuliers. Ce module est le fruit d’un partenariat « OEM »5 dans le cadre duquel un outil dédié à la gestion des exigences, fabriqué par une autre société, est mis aux couleurs de Surcod et intégré en lui. Nous reviendrons sur ce partenariat.

35À partir de ces exigences, un modèle est construit et converti automatiquement en lignes de code. Le code ainsi produit doit lui-même pouvoir communiquer avec les entités qu’il rencontrera tout au long de sa trajectoire désormais indépendante. Par exemple, le code est destiné à être exécuté sur un microprocesseur qui est équipé d’un système d’exploitation temps réel, par lequel il devra se faire comprendre. Cette compatibilité peut être assurée par ce qu’on appelle des « enveloppes », mais elle peut aussi nécessiter un partenariat technologique entre Rocher Technologies et les fabricants des systèmes d’exploitation en question.

36Si le code généré par Surcod peut circuler et embarquer sur un avion ou un train, c’est parce qu’il est d’emblée certifié : il est « correct par construction », c’est-à-dire qu’il correspond fidèlement au modèle à partir duquel il a été généré. Mais comment s’assurer que le modèle lui-même est correct ? Plusieurs modules de vérification et de validation permettent ce test dès la phase de conception. Là encore, des modules peuvent cacher des collaborations : l’outil de vérification de Surcod, par exemple, est le produit d’un autre partenariat OEM.

37Sans aller plus loin dans la reconstitution de la liste des modules de Surcod, on peut noter que le fonctionnement du produit implique celui d’un réseau, composé d’autres outils, avec lesquels Surcod cohabite dans le monde de son utilisateur, et donc d’autres entreprises, qui fabriquent ces outils. « Interfacer [Surcod] au reste du monde » peut impliquer la mise en œuvre de partenariats. Certes, cet interfaçage pourrait être réalisé ad hoc par les clients, ou en interne par Rocher Technologies, mais il souffrirait alors d’un problème de continuité, car les outils évoluent. L’avantage d’un partenariat est qu’il permet d’échanger les licences, les outils et les connaissances tacites qui leur sont associées, tout en restant une modalité d’intégration relativement lâche par rapport à l’acquisition ou au développement en interne, car « si une [passerelle] disparaît, ça crée un manque, mais ce n’est pas tragique ».

38Nous illustrons ce type de partenariat par l’exemple de la collaboration entre Rocher Technologies et la société Rifet autour du module de Surcod qui est dédié à la gestion des exigences. Il s’agit d’un accord de type OEM : « [Rocher Technologies] achète [le produit de Rifet], l’intègre complètement et le revend sous [sa] marque ».

39Rifet propose des solutions logicielles pour le développement d’applications embarquées dans des domaines comme l’aéronautique, la défense, les transports ou l’automobile. Une de ces solutions, nommée Verif, concerne la gestion des exigences. Comme nous l’avons mentionné ci-dessus, les exigences qui sont définies lors de la conception d’un composant, sont progressivement traduites, depuis le cahier des charges jusqu’à la spécification logicielle. Le produit Verif répond au problème de la « traçabilité » de ces exigences : c’est « un outil qui est capable d’aller chercher les exigences et toutes les infos dans tous les outils utilisés sur le cycle de développement et […] de vous donner la visibilité de ce qui est bien couvert ou non ». Pour cela, Verif doit pouvoir communiquer avec ces autres outils, parmi lesquels se trouve Surcod. Les outils de Rifet et de Rocher Technologies se trouvent « ensemble chez les clients » et « il va bien falloir [qu’ils] se parlent ». Or, afin de rendre cette communication possible, tout un travail d’association sera nécessaire.

40Tout d’abord, les deux entreprises rechignent justement à se parler, du fait de la concurrence qu’elles ressentent entre elles : en effet, les outils qu’elles commercialisent sont basés sur des langages différents (Rifet exploite un autre langage synchrone qui a vu le jour dans les années 1980 aux côtés de Rocher et Cristal) et peuvent avoir une utilisation similaire. Un premier pas vers le partenariat consiste donc à « [se dire] que les outils [sont] complémentaires ». Rocher Technologies met alors des licences Surcod à disposition des équipes de Rifet, pour que ces dernières puissent construire l’interfaçage, avec son aide. La personne responsable de ce projet chez Rifet explique pourquoi celui-ci se transforme en partenariat :

« […] ensuite effectivement on s’est rendu compte […] qu’au-delà de dire : “on s’interface à Verif”, comme eux avaient ce genre de besoin […] de façon générique […], un modèle d’intégration de notre outil dans leur offre pouvait être intéressant à la fois pour eux (c’est eux qui vendent et donc ils ont une partie du revenu qui est pour eux) et pour nous aussi. »

41Il faudra deux ans de discussion et de développement pour arriver aux premières « versions montrables au client et montrées au client ». Pour éviter une concurrence directe entre les deux entreprises, il est nécessaire de « positionner les deux outils ». L’idée est de rattacher Verif à Surcod en le détachant des autres outils avec lesquels il s’interface. Cela passe par le développement d’une nouvelle entité : un Verif « léger », en termes de prix (plus de deux fois moins cher) et de possibilités de communication (il n’a pas toutes les interfaces du produit original de Rifet). Cet outil est « complètement coloré Rocher » et ne peut pas être lancé sans Surcod : « l’utilisateur de [Surcod], pour assurer la traçabilité dans son modèle Surcod, il utilise le [module de Surcod basé sur Verif]. S’il veut assurer la traçabilité avec les autres, il utilise [Verif]. »

42Il est intéressant de noter comment la complémentarité entre les technologies des deux entreprises est dans ce cas construite, aussi bien par les caractéristiques techniques du produit que par le discours qui l’accompagne. Au départ, Verif et Surcod ne sont complémentaires que dans la mesure où ils cohabitent chez les mêmes clients. Cette cohabitation ne déclenche pas automatiquement un partenariat. D’abord, l’utilisateur peut lui-même faire parler les deux outils. Par exemple, un client commun de Rifet et de Rocher Technologies avait développé une interface qui « [répondait] à son besoin ponctuel à ce moment-là ». De plus, « rentrer dans un produit, c’est plus compliqué à gérer, donc ça nécessite un niveau de business potentiel plus élevé ». Le point de départ du partenariat consiste donc à déclarer une complémentarité des outils, pour ensuite les rendre effectivement complémentaires. Cela passe par une série de repositionnements, d’ordre narratif (« il a fallu travailler sur le discours corporate : pourquoi on est complémentaire et on collabore ») et technique (détacher Verif de certaines entités et l’attacher à d’autres). La complémentarité est une affaire de réglage et de négociation :

« Il a fallu discuter des niveaux de royalties, des répartitions de compte et autres, d’aborder ensemble ou séparément les comptes, d’éviter que les outils créent des concurrences qui font qu’on perd beaucoup de temps à aborder un compte et lui expliquer pourquoi il faut acheter tel outil. On a dû travailler là-dessus. »

43Ce travail d’association génère une série d’effets, au-delà de la construction d’une complémentarité entre les deux outils. Rocher Technologies et Rifet « attendent beaucoup de ce partenariat » dont ils ne vont cesser de scruter les résultats. Un premier résultat réside dans l’entrée de la collaboration en phase de « livraison » : de l’exploration des possibilités de couplage, le partenariat bascule ainsi dans une période d’exploitation dans laquelle ses fruits sont recueillis, pesés et engrangés. Surcod et Verif suivent leurs « feuilles de route » (roadmaps), alimentées par des « demandes qui arrivent [des] utilisateurs » et ponctuées par « des évolutions, quelques corrections, comme tout outil logiciel, et puis une mise à niveau de tout ça ». À la stabilisation des outils correspond celle des relations :

« On est passé d’une situation où on ne se parlait pas et c’était très conflictuel à une situation où on s’invite, on fait des séminaires ensemble, on collabore sur les outils etc., et on se référence mutuellement ou des fois on va même ensemble chez des comptes voir les acheteurs ou les gens des projets. »

44Notre interlocuteur chez Rifet situe les « bénéfices » de ce partenariat à trois niveaux. Premièrement, au « niveau corporate » – celui de l’image de l’entreprise – « ça augmente notre crédibilité […] parce que finalement […] Rocher a une très bonne image sur ce secteur-là et donc le fait qu’ils passent par nous pour cette brique-là, ça monte notre visibilité et notre crédibilité ». Un deuxième aspect concerne les retombées financières du partenariat, car « un des critères déterminants, c’est aussi que ça ramène de l’argent à l’éditeur. Ça, c’est en train de se mettre en place, ça devrait fonctionner, on espère que ce sera un des axes forts, le fait que ça ramène de l’argent à eux et à nous. » Troisièmement, Rifet a « dû travailler sur la qualité » : « comme ils ont des contraintes de qualité assez élevées, ça nous oblige, nous, à nous maintenir à ce niveau de qualité élevé. Ça met une certaine pression sur le niveau de sortie du produit, ce qui est plutôt bénéfique. »

45On voit que le partenariat produit une multitude de résultats, qui vont de l’introduction d’un nouveau produit sur le marché à l’amélioration de l’image des partenaires, en passant par la requalification de leurs outils. L’objectif de cette illustration n’est pas de filer la description de bénéfices idiosyncratiques pour en mener la liste jusqu’à l’exhaustivité, mais de souligner qu’en circulant dans le réseau désormais bien solide qu’est le sien, Surcod continue à affecter les nouveaux acteurs qu’il recrute et à se voir affecté par eux. Certes, ces effets n’ont plus grand-chose à voir avec les bouleversements que nous observions au sein des collectifs exploratoires (décrits dans le chapitre 1 et dans la première partie du présent chapitre) : ils sont bien plus locaux, prévisibles, triviaux. Ils n’en sont pas pour autant moins présents et témoignent du travail d’association que les spin-offs et leurs partenaires continuent à mener au sein de réseaux consolidés.

Les clients : évaluations du produit

46Qui sont les clients de Rocher Technologies ? Ils se trouvent principalement dans le secteur aéronautique (rappelons qu’un des ancêtres de Surcod est un outil développé par Entreprise2, un constructeur d’avions). Le produit se présente comme un « menu », une offre « découpée en rondelles » : il y a une base – le module central qui permet de construire le modèle (dont les inputs sont les exigences et l’output est un code certifié) – qu’il faut acheter dans tous les cas, puis le client choisit les modules dont il a besoin, ceux-ci pouvant être achetés séparément. Le lien entre les différents modules se fait non pas au niveau de l’utilisateur particulier, mais à celui du réseau que mobilise la construction d’un avion. Par exemple, « certains […] clients n’utilisent le produit que pour faire des spécifications, donc ils n’ont pas besoin […] du générateur de code, [qui] va être acheté par leurs sous-traitants ». Un utilisateur final, comme Entreprise2, achète certains modules, car il est en charge de la conception. Des sous-traitants, comme Entreprise5, achètent d’autres modules, car ils ont la responsabilité de la réalisation. Des sociétés de services, à qui est déléguée une partie des développements logiciels, achètent, elles aussi, des modules particuliers. C’est ce réseau d’utilisateurs qui est le client de Rocher Technologies.

47Que fait Surcod dans ce réseau ? Il le coordonne et le consolide : il met en forme les lignes qui relient ses points, il standardise les interfaces de communication entre ses membres, il unifie les intermédiaires (spécifications, code) qui circulent en son sein. C’est ce que met en avant un utilisateur de [Surcod] interrogé sur les bénéfices qu’il retire du produit : « Quand nos clients nous fournissent les spécifications en format [Surcod], la correspondance entre une modification dans les spécifications et le code C généré par [Surcod] se fait de manière presqu’instantanée, ce qui rend nos interactions avec nos clients très efficaces. »

48Cet extrait souligne deux composantes de la valeur qu’a Surcod pour ses clients. Elles ont toutes les deux trait à la standardisation des intermédiaires qui circulent au sein du vaste réseau que représente la fabrication d’un avion. La première est relative à la certification : le code que Surcod permet de générer est correct-par-construction et donc automatiquement qualifié par la norme qui s’applique aux logiciels critiques en avionique. Plus besoin de certifier le code en démontrant, a posteriori, sa fiabilité ; l’adhésion des organismes de certification est assurée, a priori, par Surcod et le langage de programmation synchrone et fiable sur lequel il repose. La deuxième composante concerne la modularité : les interactions entre les différents acteurs qui interviennent dans la production de ce code (donneurs d’ordre et sous-traitants) sont réglées, ex ante, à travers celles entre les différents modules qu’ils utilisent.

49Les qualités de Surcod, désormais solidement établies dans le secteur de l’aéronautique, sont mises à l’épreuve lorsque Rocher Technologie tente d’étendre son offre vers de nouveaux secteurs. Pour illustrer cette dynamique, nous décrivons l’association de Surcod avec un nouveau client dans le domaine du transport ferroviaire. Il s’agit de Portance, division d’un grand groupe spécialisée dans les systèmes de transport.

50Lorsque les employés de Portance, chargés de trouver des technologies susceptibles d’améliorer leurs méthodes d’ingénierie informatique, rencontrent Surcod, ils voient avant tout en lui un outil de « développement dirigé par des modèles ». Portance procède à une première « évaluation » qui a pour objectif d’estimer si « cette méthode convient à [ses] besoins et à ses organismes de certification ». Le projet pilote dans le cadre duquel l’évaluation a lieu concerne le développement de compteurs d’essieux (des dispositifs permettant de détecter la présence de circulation sur une portion de voie). Son résultat est positif : « il y aura un composant écrit complètement en [Surcod] qui sera dans le nouveau compteurs d’essieux ». Voyons comment ce résultat est produit.

51Une première étape consiste à placer le produit dans son nouvel environnement d’utilisation. Cet environnement est d’abord celui d’un projet : le développement d’un compteur d’essieux. Un modèle Surcod remplace, dans un système de compteur d’essieux existant, une partie du logiciel qui était jusqu’ici programmé en C++. L’environnement d’utilisation est aussi celui d’un workflow : dans ce cas, un processus d’utilisation dans lequel des exigences sont définies, puis un logiciel est spécifié par l’intermédiaire d’un modèle composé de diagrammes, enfin du code est généré et compilé, la vérification et la validation du développement se faisant de manière automatique et en amont, sur le modèle lui-même. Situé dans ce flux d’opérations, le produit peut être qualifié et évalué. Qu’apporte-t-il à ses utilisateurs ? Ses caractéristiques justifient-elles l’investissement que nécessite son acquisition ?

52Pour répondre à ces questions, Portance se livre à l’évaluation de Surcod, en explicitant ses avantages et bénéfices. Cette évaluation prend différentes formes ; nous en présentons trois. La première se produit lors de notre entretien avec l’employé de Portance en charge du partenariat avec Rocher Technologie. Selon lui, l’apport (« benefit ») principal de ce partenariat réside dans le fait que la société Portance, qui était habituée à tout développer en interne, a appris qu’il « n’est pas nécessaire de construire tous ses outils toute seule », qu’elle peut « acheter des outils sur étagère et les utiliser pour des applications sûres ». En effet, Portance avait développé un outil similaire à Surcod qui permettait de faire du développement basé sur des modèles, mais seulement pour un produit particulier (les systèmes d’enclenchement). Or, explique notre interlocuteur, construire un outil en interne coûte beaucoup plus cher et ne permet pas de bénéficier des « synergies d’une application plus commune ».

53Une deuxième forme d’évaluation a lieu dans un article dédié au développement dirigé par les modèles que deux employés de Portance rédigent et soumettent à une revue. Ils détaillent plusieurs avantages (« advantages ») de Surcod : par exemple, il permet la séparation entre les « parties fonctionnelles, logiques du software » et les « plateformes hardware spécifiques » et il donne la possibilité d’effectuer une vérification dès les premières phases du processus de développement. Il a aussi quelques faiblesses : par exemple, un niveau d’abstraction relativement bas et des problèmes liés à l’intégration de modèles Surcod dans des environnements qui ne sont pas basés sur le paradigme synchrone. Au total, les auteurs de cet article concluent que leur expérience de la modélisation en Surcod et leurs résultats sont « positifs ». Le point important, à leur avis, est qu’avec le « développement dirigé par les modèles », et avec Surcod en particulier, « les phases de conception et d’implémentation sont combinées dans un seul pas de processus », ce qui améliore « la productivité du développement logiciel sur le moyen et long terme ».

54La troisième forme d’évaluation que nous évoquons ici consiste en un rapport qui a été rédigé par le département central de R&D de Portance et dont les principaux résultats sont présentés lors d’une « conférence utilisateurs » organisée par Rocher Technologies. Le rapport retient deux « critères d’évaluation principaux » : « l’intelligibilité de l’architecture » et « la testabilité ». Chaque critère est composé de trois sous-critères, ces derniers étant eux-mêmes « sous-divisés en aspects ». L’évaluation consiste à noter chacun de ces aspects, suivant une échelle de « classement relatif » qui compare un processus de développement basé sur Surcod et un « processus basé sur le langage de programmation C », en le positionnant sur un des sept niveaux définis (+++ percée, ++ force, + amélioration, 0 égal, - dégradation, -- faiblesse, --- difficulté). La valeur de Surcod ainsi calculée apparaît donc sous la forme suivante : « 2 +++/ 8 ++/ 10 +/ 4 ”0”/ 1 -/ 1 --/ 1 ---/ 1 ? », pour son architecture, et « 1 +++/ 2 ++ /9 + /4 ”0” / 4 - / 2 -- / 3 ? », pour sa testabilité. Cette suite de chiffres soutient la conclusion suivante : « Dans l’ensemble, la comparaison de [Surcod] avec le développement logiciel conventionnel lui est favorable. Toutefois, ses points forts sont la construction et le design, et moins la testabilité. »

55En dépit de leurs différences, ces trois évaluations procèdent d’une démarche commune. D’abord, Surcod est placé dans une catégorie : celle des produits « sur étagère » (dans l’entretien d’évaluation) ou celle des outils de « développement dirigé par les modèles » (dans l’article et dans le rapport d’évaluation). Cette opération n’a rien d’évident : en effet, jusqu’ici Surcod nous était apparu avant tout comme un outil de production de code certifié. Ainsi, même dans un réseau fortement consolidé, comme celui de ce produit, une multiplicité ontologique peut-elle subsister et se manifester lorsque le réseau s’étend (ici, en franchissant une frontière sectorielle). L’opération de dénomination n’est pas neutre quant à ses conséquences, puisqu’elle délimite les contours des mondes dans lesquels l’outil est positionné et donc les entités avec lesquelles il sera comparé : il peut s’agir de l’outil interne de Portance pour les systèmes d’enclenchement (dans l’entretien d’évaluation) ou des méthodes de développement « conventionnelles » qui utilisent le langage C (dans l’article et dans le rapport d’évaluation). Les entités impliquées dans ces comparaisons sont ainsi dotées de qualités relatives (comme le coût, la qualité du code, la possibilité d’intégration, la maturité) et classées. Ce positionnement permet d’attribuer à Surcod une valeur numérique, comme la série de chiffres que propose le rapport d’évaluation (ces chiffres pourraient être agrégés en une note unique qui serait ici positive : 0,52 sur une échelle de -3 à +3, d’après nos calculs).

56On voit à travers ces exemples que l’évaluation mobilise des échelles différentes – nominales, ordinales et numériques [Guyer, 2004] – et procède par associations. Elle recourt aussi à des « principes d’évaluation » [Stark, 2009] hétérogènes dans lesquels se mêlent la qualité du code, le niveau d’abstraction du modèle, les coûts et la productivité, la modernité (par exemple, les méthodes de développement dirigées par les modèles sont dites « modernes », par opposition à celles qui sont « conventionnelles »), « l’esprit » des personnes, etc. Elle se déploie dans des configurations aussi variées que l’exercice très formel auquel se livre le rapport rédigé par le département de R&D de Portance et les témoignages de clients que Rocher Technologies recueille et rend publics lors de séminaires, sur son site internet ou dans des communiqués de presse. Le dernier chapitre de cet ouvrage reviendra sur ces arrangements (au sens d’agencements et d’accords amiables) en étudiant le jeu entre les différentes échelles de l’évaluation et en traquant le moment où la valeur, intégrant des unités monétaires, se transforme en prix – question qu’on ne peut pas aborder ici.

57Interrogeons-nous, pour conclure, sur les évolutions que ces évaluations génèrent. Tout d’abord, elles ont un impact direct sur la collaboration entre les deux sociétés, puisqu’elles justifient la décision de Portance de « continuer ses activités concernant le développement dirigé par les modèles en général, et [Surcod] en particulier [avec l’intention d’] utiliser [Surcod] pour le développement d’un logiciel pour un système de commande de trains ». Il faut souligner que l’évaluation n’est pas située dans un moment suspendu de jugement pur mais dans une situation, dans un cours d’action, qui la nourrit et dont elle se nourrit en retour. Les entités auxquelles elle s’applique n’en sortent pas intactes : elles sont manipulées, au sens propre du terme, dans le cadre du projet pilote qui, à travers l’identification de bugs, transforme Surcod. Comme l’explique notre interlocuteur chez Portance : « On est en contact assez proche et de temps en temps j’ai l’impression qu’ils finiront par nous détester parce qu’on dit : “Ok, ici il y a un bug, et on a besoin de ceci, et cela doit être réparé, et…” »

58Toutefois, les évolutions que nourrit l’évaluation de Surcod par Portance restent limitées, contrôlables, marginales. On est loin des bouleversements que générait l’évaluation du logiciel Médiation par les clients pilotes et les futurs investisseurs de Comprix (chapitre 1). On est loin aussi du temps où la rencontre de Rocher avec des alliés dans un nouveau secteur (le hardware) ébranlait sa structure – aussi bien celle du langage que celle du réseau. Tout l’art de Rocher Technologies consiste désormais à maintenir le fin réglage de la tension entre la nécessaire adaptation de Surcod à des utilisateurs de plus en plus nombreux et le principe de non remise en cause qui règne dans les réseaux consolidés.

CONCLUSION

59Si l’entrepreneuriat est un processus d’exploration collective, le maintien de l’entreprise à laquelle il donne naissance nécessite de se détacher des utilisateurs pilotes [Mustar, 1994], de consolider et étendre les réseaux émergents qu’il construit [Callon, 1999]. La stabilisation de ces réseaux de plus en plus larges passe par la transformation d’un artéfact technique en un produit capable de circuler et d’intéresser des acteurs de plus en plus nombreux, en posant sur les compétences de ceux-ci des exigences toujours moindres. Cette circulation fluide a pour contrepartie une condition de non remise en cause : un produit doit être robuste ; la sensibilité de son « technogramme » à son « sociogramme » [Latour, 2005 [1989]] doit être réduite au minimum ; son identité doit rester stable en dépit de l’augmentation du nombre d’acteurs qu’il agrège.

60L’étude des cas de Comprix et de Rocher Technologies apporte un éclairage sur le rôle que jouent les spin-offs académiques dans les réseaux qu’elles intègrent et qu’elles contribuent à construire. Leur rôle, proposons-nous, consiste à explorer et à consolider des réseaux émergents. Cette description permet d’éviter les écueils que comporte une conceptualisation des spin-offs comme instruments d’un transfert entre science et marché. En effet, des acteurs « marchands » sont souvent présents bien avant que le « transfert » ne s’engage ; inversement, les entreprises issues de la recherche publique gardent des liens forts avec la « science » bien après leur création [Mustar, 1997]. Le travail que réalisent les spin-offs (et le principal défi auquel elles se voient confrontées) réside dans la consolidation des réseaux techno-économiques [Callon, 1991; Larédo & Mustar, 1996] qu’elles font émerger.

61La présentation des collaborations de Rocher Technologies avec un partenaire technologique et un client soulève aussi deux questions. La première procède de l’observation des effets que génère le produit au fur et à mesure de sa circulation. L’extension d’un réseau, même consolidé, n’est possible qu’au prix d’un travail d’association dans lequel s’engagent la spin-off et ses partenaires (comme Rocher Technologie et son partenaire technologique Rifet) et qui affecte les acteurs qu’il implique : les alliés pénètrent dans de nouveaux domaines, leurs produits s’en trouvent reconfigurés, de nouveaux artéfacts techniques voient le jour. Comment saisir ces effets, sans pour autant se limiter à des configurations inter-organisationnelles particulières, approchées à travers des études de cas ? Les chapitre 3 et 4 abordent cette question et proposent une analyse quantitative qui embrasse un grand nombre de partenariats avec des spin-offs académiques et qui en décrit les formes et les résultats. Une deuxième question concerne le lien entre la mesure de ces résultats et la conduite des activités collaboratives qui leur donnent naissance. Comme Portance dans le cas étudié ici, les entreprises impliquées dans des collaborations avec des spin-offs se livrent à un travail d’évaluation continu : elles qualifient les entités qu’elles échangent, pèsent leurs avantages et leurs faiblesses, chiffrent les bénéfices escomptés et enregistrés. Les chapitres 5 et 6 abordent cette deuxième question à travers l’étude des processus et dispositifs de valuation.