Contribution à la réflexion sur le développement logiciel

Contribution à la réflexion sur le

développement logiciel à l’INRIA

Rapport et recommandations

Eric GAUTRIN Bernard MARTIN

Décembre 2002

INRIA 2002 2/40 DirDRI

Remerciements

Pour réaliser cette mission, il était essentiel d’aller à la rencontre des différents acteurs que sont les directeurs des unités de recherche, la direction des ressources humaines, les projets de recherche, les structures de support aux développements, ... Nous tenons à remercier chaque personne nous ayant consacrée du temps pour nous apporter son point de vue sur le développement logiciel à l’INRIA.

Nous tenons également à remercier Gérard Giraudon pour nous avoir offert l’opportunité de mener cette mission et ainsi de contribuer à la réflexion sur le développement logiciel à l’INRIA.


1. INTRODUCTION......................................................................................................................... 6

2. LE DEVELOPPEMENT LOGICIEL DANS LES PROJETS DE RECHERCHE................. 8 2.1. MOTIVATIONS.......................................................................................................................... 8

2.1.1. Valider une idée ou une théorie....................................................................................... 9 2.1.2. Trouver de nouvelles problématiques, faire germer des idées ........................................ 9 2.1.3. Réutiliser des résultats, pouvoir adresser de nouvelles classes de problèmes.............. 10 2.1.4. Diffuser des résultats..................................................................................................... 10 2.1.5. Créer une start-up ......................................................................................................... 11 2.1.6. Se faire évaluer à l’INRIA ............................................................................................. 11

2.2. PROCESSUS DE DEVELOPPEMENT LOGICIEL .......................................................................... 11 2.2.1. Produit de recherche ..................................................................................................... 11 2.2.2. Types de développements .............................................................................................. 12 2.2.3. Diffusion, transfert et valorisation ................................................................................ 13 2.2.4. Stratégie de développement logiciel .............................................................................. 14

2.3. ENVIRONNEMENTS DE DEVELOPPEMENT LOGICIEL............................................................... 14 3. LES METIERS DU DEVELOPPEMENT LOGICIEL........................................................... 17

3.1. LES DIFFERENTES FONCTIONS ............................................................................................... 17 3.2. LES CATEGORIES DE PERSONNEL........................................................................................... 18 3.3. ACTIVITES DE DEVELOPPEMENT ET CARRIERES .................................................................... 22

3.3.1. Carrières des ingénieurs permanents............................................................................ 22 3.4. FORMATION ........................................................................................................................... 25

4. LA DIVERSITE DES BESOINS ET ATTENTES................................................................... 26 4.1. MOYENS HUMAINS ................................................................................................................ 26 4.2. ORGANISATION...................................................................................................................... 27

4.2.1. Plates formes technologiques ........................................................................................ 27 4.2.2. Fédération de développement logiciel........................................................................... 27 4.2.3. Structures de support au développement logiciel.......................................................... 28

4.3. ENVIRONNEMENTS DE DEVELOPPEMENT LOGICIEL............................................................... 28 5. PRINCIPALES RECOMMANDATIONS................................................................................ 30


1. Introduction

Le plan stratégique 1999-20031, met l’accent sur le rôle du logiciel qui « est partout », et où « derrière les innovations technologiques se posent des questions de recherche ». Le développement et la diffusion de logiciels y sont considérés comme un enjeu très important pour l’institut.

Dans cette perspective, l’institut a décidé de renforcer sa politique en matière de développement logiciel et de s’en donner les moyens. Une première note sur l’organisation du développement logiciel a été diffusée en septembre 20012 et présente les lignes directrices d’un nouveau schéma d’organisation du développement logiciel.

Le présent rapport et les recommandations réalisés à la demande du directeur du développement et des relations industrielles3 s’inscrivent dans ce contexte et s’attachent plus particulièrement :

• Aux métiers de l’ingénierie de développement logiciel et aux problèmes de formation associés.

• Aux domaines où la coordination doit être source d’une efficacité accrue (communication, formation, méthodologie, politique d’achat, …) et de l’organisation de cette coordination.

• Aux types de services correspondant aux attentes des équipes de recherche, éventuellement déclinées selon les problématiques scientifiques et technologiques des équipes.

Pour mener à bien cette mission nous avons rencontré des chercheurs de 4 à 5 projets dans chacune des unités de recherche (cf. Annexe I), des directeurs d’unités de recherche, les équipes de développement de Nancy, Rennes et Sophia et organisé 3 réunions à Paris4 avec les responsables de chacune de ces équipes ou de celles en cours de constitution.

Quelques remarques préliminaires :

• Nous nous plaçons exclusivement dans le cadre de développements effectués au sein des projets de recherche. L’idée d’une structure « INRIA Software Distribution » pour l’intégration, le test, le support et la diffusion de certains logiciels à l’exemple de ce qui est fait par l’université de Berkeley avec BSD a été soulevée par certains chercheurs5. Une telle structure qui se situerait en dehors des projets de recherche a déjà été évoquée antérieurement mais non retenue. C’est bien évidemment une hypothèse dont les implications sont importantes en terme d’objectifs et d’organisation des équipes de développement, mais l’étudier n’entre pas dans le cadre de la mission confiée. Cela signifie en particulier dans le cas présent que le développement est piloté par la recherche.

• Les développements de logiciel sont technologiques et assez éloignés de produits industriels plus orientés vers la prise en compte des besoins des « clients ». L’élaboration de produits à partir de ces développements sera réalisée soit par des start-up issues des équipes de recherche, soit par des industriels en collaboration ou non avec les équipes de recherche. Le développement de « produits » en logiciels libres comme Scilab ou dans le cadre de

1 http://www.inria.fr/inria/strategie/pdf/strategie.fr.pdf 2 http://www.inria.fr/DR:/dirdri/developpement/logiciel/developpement-logiciel.pdf 3 Voir Annexe 4 : lettre de mission confiée à Eric Gautrin et Bernard Martin 4 http://www.inria.fr/DR:/dirdri/developpement/index.html 5 Notamment Paul Le Guernic


consortium comme ObjectWeb modifie un peu ce schéma dans la mesure où il peut conduire à une plus forte implication de l’INRIA dans l’élaboration et la distribution d’un produit.

• Les rencontres avec les projets de recherche ont montré que le développement de logiciel6 était considéré par la majorité d’entre eux comme un élément clé dans leur activité de recherche. Rappelons que plusieurs projets de recherche ont lourdement investi dans des initiatives autour du développement de logiciels, qu’il s’agisse de la diffusion du CDROM des logiciels libres, de la diffusion de CAML, de la contribution de membres du projet OPERA au W3C, etc. Les chercheurs rencontrés (pour la plupart chefs de projet) ont souvent la perception que cette activité est peu valorisée par les instances décisionnaires de l’institut et la mission a été perçue comme une démarche positive dans le sens d’un changement d’attitude à cet égard. Des résultats concrets sont attendus en termes de moyens et de politique scientifique. Bien sûr, il reste la question ouverte du « comment » faire une évaluation des logiciels au même titre que les publications.

• Il nous a été reproché par certains projets de recherche de restreindre le développement à celui du logiciel et de ne pas prendre en compte la totalité des développements matériels et logiciels menés par l’institut, et en particulier dans le domaine de la robotique. Ces remarques nous ont conduits à dépasser le cadre initialement fixé, tout en nous intéressant en priorité aux questions liées au développement logiciel.

• La situation du développement logiciel est très diverse au sein de l’INRIA entre les différentes unités de recherche, les différents thèmes de recherche, etc. (Annexe 3). Il en va de même de la qualité et de la quantité des logiciels produits. Un des choix importants en terme de politique est de savoir si l’on souhaite homogénéiser la production globale de l’INRIA par la mise à disposition de moyens aux projets peu impliqués dans le développement ou à l’opposé le renforcement des équipes les plus impliquées ?

• Au cours de cette mission nous avons rencontré 27 projets de recherche, les personnels des structures de développement ASCII, SèDRE ou DREAM, les directeurs des unités de recherche de Grenoble, Rennes, Sophia et Rocquencourt et Paul Le Guernic au titre de membre du bureau exécutif du RNTL. L’établissement des listes de projets rencontrés dans chacune des unités de recherche a été fait en concertation avec son directeur.

6 pour certains projets, le développement logiciel s’inscrit aussi dans la mise en œuvre de plates-formes matérielles expérimentales notamment pour la robotique ou les environnements de réalité virtuelle, plates-formes qui ont des problématiques spécifiques.


2. Le développement logiciel dans les projets de recherche

L’entité de base de l’activité scientifique est le projet de recherche, et c’est à ce niveau que se définissent concrètement les politiques de développement et l’articulation entre développement et recherche scientifique. La compréhension des motivations et des pratiques des projets de recherche est donc essentielle. Dans cet esprit, nous avons rencontré dans chacune des unités de recherche des chefs de projet et des chercheurs impliqués, ou souhaitant s’impliquer dans des activités de développement

Nous avons orienté chacun de nos entretiens autour de 3 axes :

• Quelles sont leurs motivations pour faire du développement ?

• Comment ce développement est-il réalisé et par qui ?

• Qu’attendent-ils de l’institut en terme de moyens ?

2.1. Motivations

Notre première idée était de dégager quelques profils types corrélés au thème scientifique, au domaine de recherche, .... Cependant, les raisons pour lesquelles un chercheur, et par extension le projet de recherche7 s’implique dans une activité de développement, sont très diverses et dépendent de multiples facteurs :

• sa conception du métier de chercheur,

• sa perception du lien entre développement et recherche scientifique,

• son domaine de recherche,

• sa perception de son environnement académique et industriel,

• les pratiques de sa communauté de recherche,

• sa stratégie à moyen terme,

• …

Si des chercheurs de thèmes différents partagent les mêmes raisons pour s’impliquer dans le développement, à l’opposé d’autres, proches scientifiquement, ne partagent pas la même position. Par exemple,

• l’un capitalisera tous les développements au sein d’une plate-forme logicielle, un autre dans le même domaine scientifique développera uniquement pour valider des résultats en vue d’une publication ;

• l’un cherchera à diffuser uniquement dans le monde académique, un autre visera une diffusion dans le monde industriel, ou encore aura comme objectif la création d’une start-up.

7 la plupart des chercheurs rencontrés sont chef de projet ou chercheur « senior ». Il est indéniable qu’ils ont un rôle déterminant sur les orientations et la stratégie du projet vis-à-vis du développement


Partant de ce constat, nous nous limitons à ne présenter que les raisons mises en avant par les projets de recherche, tout en les classant par grandes catégories, et en citant les différentes positions.

2.1.1. Valider une idée ou une théorie

Les projets de recherche rencontrés sont tous impliqués dans des activités de développement logiciel. La première des raisons mises en avant est la validation d’une idée ou d’une théorie, mais est nuancée selon les chercheurs :

• pour obtenir des résultats, éventuellement en vue d’une publication,

« Peut-on spécifier de nouveaux protocoles sans les réaliser, sans en évaluer les performances ? »

• l’informatique est à la croisée des chemins entre pratique et théorie et il n’y a pas de recherche en informatique sans développement, sans implémentation,

« Peut-on faire de la recherche sur un langage de programmation sans en écrire le compilateur/interpréteur associé? »

• lorsque l’objectif du projet de recherche est d’adresser des problèmes réels posés par des acteurs économiques, industriels, académiques, une implémentation est nécessaire pour les convaincre, spécialement s’ils ne sont pas du domaine informatique. Dans ce contexte, la démonstration théorique ne suffit pas; la publication d’articles dans des journaux ne saurait à elle seule susciter l’intérêt des acteurs visés essentiellement motivés par l’utilisation pratique de ces résultats. Dans ces cas, l’outil doit être bien conçu pour son appropriation par les utilisateurs (d’où des contraintes fortes sur la qualité, l’ergonomie de l’interface),

• si le cadre théorique est insuffisant pour démontrer formellement l’idée, par exemple des travaux sur des problèmes NP-complets, une implémentation permet de montrer des résultats possibles dans des cas particuliers.

2.1.2. Trouver de nouvelles problématiques, faire germer des idées

Pour de nombreux projets de recherche, l’activité de développement met en évidence de nouvelles problématiques, fait germer de nouvelles idées.

• L’application de l’informatique à d’autres domaines permet de traiter des besoins réels posant de nouveaux problèmes, futurs objets de recherche. Mais il faut nécessairement développer des environnements utilisables par exemple par les physiciens8 ou par les biologistes9 pour résoudre leurs problèmes.

• L’implémentation révèle des problèmes non prévus ou sous-estimés théoriquement. Plusieurs projets nous ont cité l’exemple d’un travail théorique repris suite à une implémentation : des fonctionnalités jugées simples s’avèrent plus complexes, l’introduction d’une nouvelle fonctionnalité a des effets de bord non prévus.

• L’implémentation fait germer de nouvelles idées, détecter des cas non prévus.

8 Exemple des projets MACS et COPRIN 9 Avec le développement de la plate-forme Geno* à laquelle contribue le projet HELIX


2.1.3. Réutiliser des résultats, pouvoir adresser de nouvelles classes de problèmes.

La plupart des chercheurs rencontrés se préoccupent de capitaliser les travaux de développement logiciel réalisés par des chercheurs, des doctorants, des ingénieurs ou encore des stagiaires. Ils constatent une perte du travail trop fréquente après le départ du doctorant ou du stagiaire. Au-delà de la méthode et des besoins, plusieurs motivations sont avancées:

• Reprendre plus tard un travail pour le compléter par une nouvelle fonctionnalité, modifier l’algorithme implémenté ou ses paramètres d’exécution, et éviter ainsi de refaire plusieurs fois la même chose.

• Adresser des nouvelles classes de problèmes de recherche plus compliquées, et pousser plus loin la recherche. Cette démarche mène généralement au développement d’une plate-forme, d’un plug-in ou d’une bibliothèque. Point commun entre ces projets, le développement est pleinement inscrit dans la stratégie à moyen terme du projet10.

2.1.4. Diffuser des résultats

La diffusion de logiciels est largement utilisée à l’INRIA, et le site Web national11 (voir également l’annexe 3) affiche près d’une centaine de logiciels dont les pages sont les plus visitées avec celles des rapports scientifiques. Cet objectif de diffusion est un enjeu très important pour l'INRIA et inscrit dans son plan stratégique.

Plusieurs motivations poussent les projets de recherche à diffuser leurs logiciels :

• Indiscutablement, un moyen très efficace de diffusion des résultats de travaux de recherche. Certains chercheurs12 considèrent une diffusion d’un bon logiciel plus importante pour la notoriété scientifique que la publication d’articles.

• Dans certains domaines13, le développement joue un rôle important dans l’activité scientifique et éditoriale, il est demandé la mise à disposition des algorithmes publiés sur un site Web à des fins d’évaluation. Cette pratique se rapproche des processus d’évaluation d’autres disciplines scientifiques où une expérience doit être reproduite dans plusieurs laboratoires indépendants pour être validée.

• Une évaluation par sa communauté scientifique. La participation à des campagnes d’évaluations de méthodes ou technologies sur des jeux de tests imposés est une pratique se développant.

• Une contribution aux travaux de sa communauté scientifique en apportant sa pierre à l’édifice.

• Une contribution aux activités de standardisation par l’implémentation de spécifications.

• Une confrontation à des problèmes réels apportée par la diffusion dans le monde industriel.

Certains projets de recherche14 identifient des freins à la diffusion. Leur activité de recherche n’adresse qu’une partie d’un produit complet, qu’un maillon d’une chaîne, et ils ne peuvent pas consacrer suffisamment d’énergie à développer un produit complet ou une chaîne. Une alternative

10 C’est par exemple la démarche suivie par le projet SIAMES avec la plate-forme Open Mask. 11 http://www.inria.fr/valorisation/logiciels 12 Le succès de Scilab est un élément important pour la notoriété des travaux de l’équipe METALAU, et l’on pourrait bien évidemment citer bien d’autres exemples. 13 Comme celui du projet EPIDAURE. 14 Comme les projets ARLES et MACS


envisagée ou envisageable est de développer des plug-ins, mais impose une plate-forme d’accueil ouverte.

2.1.5. Créer une start-up

Pour certains projets, la création à terme d’une start-up est une motivation forte les conduisant à adopter une réelle stratégie de développement, même si la start-up vend du logiciel mais aussi du savoir faire et de l’expertise15. Il est également souligné l’importance des relations contractuelles avec les industriels, en amont à la création, pour adresser des problèmes réels et identifier un marché potentiel.

2.1.6. Se faire évaluer à l’INRIA

Si les chercheurs perçoivent très clairement le développement logiciel comme un « plus » dans l’évaluation de leur projet, par le biais du rapport d’activité ou lors de l’évaluation, ils s’interrogent sur le rôle du développement dans leur carrière. Ils considèrent être essentiellement évalués sur des critères de publications, sans réelle prise en compte des activités de développement.

Certains chefs de projet considèrent qu’un bon logiciel équivaut à une publication dans une revue de renom. Ils estiment les logiciels comme critère évaluation des chercheurs au même titre que les publications. La prise en considération n’est en revanche pas évidente : comment évaluer la qualité scientifique d’un logiciel, son succès et sa reconnaissance dans sa communauté scientifique au niveau international, la contribution de tel chercheur à une œuvre le plus souvent collective ?

• Lors des dépôts de logiciel à l’APP16, la répartition des contributions personnelles sur des critères pouvant faire l’objet de débats montre la difficulté de l’exercice.

• L’analyse des motivations pour l’activité de développement montre qu’elle s’inscrit pour beaucoup de chercheurs dans leur démarche scientifique. La question de son évaluation ne se pose alors pas, puisque le développement va appuyer une publication et/ou en être à l’origine.

• A contrario, la question de l’évaluation reste entière pour les projets où le développement est uniquement un moyen pour diffuser, valoriser et transférer leurs résultats. L’absence de critères conduit certains à un sentiment de perte de temps, d’où une tendance à sous-traiter le développement à des ingénieurs.

2.2. Processus de développement logiciel

Avant d’aborder les processus de développement logiciel pratiqués à l’INRIA nous nous attachons à préciser quelques notions déjà définies dans le rapport « Développement de logiciels à l’INRIA, Objectifs et organisation » de Gérard Giraudon.

2.2.1. Produit de recherche

Le développement logiciel à l’INRIA s’inscrit dans un contexte de recherche scientifique. Il se différencie du développement réalisé dans un contexte industriel par ses objectifs et ses motivations :

• Pour un produit de recherche, la validation d’une théorie ou la diffusion d’une technologie novatrice est au cœur des préoccupations.

15 C’est le cas du projet CAPS qui est en cours de création d’une start-up 16 Agence pour la Protection des Programmes


• Pour un produit industriel, la motivation essentielle est de le vendre, d’où la prise en compte des besoins des utilisateurs finaux, le positionnement du produit sur un créneau et sa disponibilité au plus vite sur le marché.

Ces motivations et objectifs différents ont des conséquences sur les développements et leurs transferts :

• Le cycle de vie d’un produit de recherche avant diffusion peut représenter plusieurs années. Au sein de l’INRIA, des cycles de vie dépassant la dizaine d’années sont fréquents17 d’où une différence importante par rapport aux produits industriels où raccourcir le « time to market » est recherché. Cette différence est une force de l’INRIA qui peut prendre le risque d’entamer et de poursuivre des développements qui n’aboutiront pas nécessairement.

• Les efforts de développement ne portent pas sur les mêmes parties ; plus sur la technologie dans le cas d’un produit de recherche.

• Le passage d’un produit de recherche à un produit industriel n’est pas immédiat. Nombreux sont les résultats de recherche issus de l’INRIA complètement repris par les industriels pour obtenir un produit conforme aux besoins du marché visé.

2.2.2. Types de développements

Plusieurs types de développements logiciels sont faits par les projets de recherche. Dans son document, Gérard Giraudon identifiait les programmes, les logiciels, et les bibliothèques. Lors de nos rencontres avec les projets de recherche, les plates-formes prennent de l’ampleur au sein de l’INRIA.

• Programme de validation d’une idée ou d’une théorie : l’objectif recherché est l’implémentation d’une théorie ou d’une idée pour la valider, pour en démontrer la faisabilité ou l’évaluer, généralement en vue d’une publication scientifique. Par conséquent, les efforts de développement portent essentiellement sur le codage de la technologie, sur son prototypage. Un programme est sujet à évolution de tout nouvel apport théorique. La qualité de la programmation est très variable : si certains projets de recherche se donnent quelques règles de programmation pour le codage d’un programme de validation (quand la stratégie du projet est de diffuser ou de capitaliser par la suite), d’autres projets de recherche ne s’imposent aucune règle (d’où des difficultés de réutilisation, capitalisation et diffusion).

• Logiciel diffusable : il se différencie d’un programme par plusieurs aspects :

- la « robustification » du code pour avoir une meilleure qualité, une architecture cohérente, une prise en compte des standards, etc.

- un ensemble d’ajouts nécessaires pour la diffusion : documentations, tutoriaux, démonstrations, interface conviviale adaptée aux utilisateurs visés, paquetage, … Ces ajouts seront plus ou moins importants selon que la cible de diffusion est l’environnement proche de son ou de ses auteurs (environnement qui peut être très étroit), un cercle académique, des laboratoires industriels ou unités opérationnelles d’entreprises, ou encore la création d’une start-up.

- l’ouverture et le portage sur différents systèmes d’exploitation.

• Bibliothèque : l’objectif recherché est de capitaliser au sein d’une bibliothèque un ensemble de programmes/logiciels (ou composants) dans un objectif d’accumulation du savoir-faire du projet, de réutilisation future ou de diffusion. Le développement d’une bibliothèque a plusieurs conséquences sur le développement : définition des interfaces des différents

17 C’est le cas de logiciels comme Scilab, CAML, Signal, etc.


composants, formats des données, respect de standards pour la réutilisation, qualité du code, documentations, ….

• Plate-forme : une plate-forme est un environnement de développement et d’exécution d’une classe d’applications (réalité virtuelle, calcul intensif, robotique, réseau, applications synchrones, …).

- Si les plates-formes comportent toutes une couche logicielle, nombreuses sont celles ayant une partie matérielle importante ; cette partie matérielle étant objet de recherche (cas de la robotique), ou apportant les moyens de poursuivre des recherches (cas de la réalité virtuelle).

- Une plate-forme, à l’instar d’une bibliothèque, capitalise le savoir-faire du projet, favorise la réutilisation des programmes développés, et comme tout environnement de développement comporte des outils variés (par exemple, un éditeur de schémas, un simulateur, un afficheur de résultats, etc.). La construction d’une plate-forme nécessite en amont une réflexion sur l’architecture, le format des données d’échange, les interfaces entre les modules, la définition d’une API, la définition de règles de développement.

- Une plate-forme est également un moyen de fédérer des développements effectués par différentes équipes (consortiums, projets européens, …), ou d’y intégrer des développements réalisés par ailleurs. La construction d’une plate-forme ouverte nécessite le respect des standards et des normes.

- La construction d’une plate forme est un travail de plusieurs années, au minimum de 4 à 5 années, voir plus dans les cas d’utilisation ou de construction de plates-formes matérielles où l’ordre de grandeur peut atteindre la dizaine d’années.

2.2.3. Diffusion, transfert et valorisation

La diffusion de logiciels, le transfert et la valorisation de logiciels ont été largement abordés dans de nombreux documents. De nos entretiens avec les projets de recherche, il ressort deux dimensions : le public visé par la diffusion ou le transfert, les services rendus aux utilisateurs.

Les publics visés :

• Diffusion dans un premier cercle : ce premier cercle est très étroit et bien identifié, du projet de recherche aux scientifiques avec lesquels l’auteur (ou les auteurs) entretient des relations scientifiques étroites. Le but est de partager, de capitaliser le savoir-faire pour générer de nouvelles connaissances.

• Diffusion dans le cercle académique: ce cercle est relativement bien délimité. Plusieurs objectifs recherchés sont :

- La publication de résultats de recherche,

- L’évaluation par ses pairs, et la recherche d’une notoriété scientifique,

- La participation à la vie d’une communauté.

• Diffusion élargie : cette diffusion va d’une mise à disposition à une large communauté académique, aux industriels, à « monsieur tout le monde ». Si le projet de recherche ne connaît pas a priori le public utilisateur, il ne cherche pas nécessairement à le connaître a posteriori : profils types, nombre, …

• Transfert et valorisation : le transfert ou la valorisation est une relation bipoint : un projet de recherche et une institution. Cette relation prend différentes formes : contrat, partenariat, consortium. L’ouverture d’une plate-forme sur l’extérieur, particulièrement lorsqu’elle


s’appuie sur des équipements coûteux comme la réalité virtuelle, les grappes de PCs, est également un cas de relation bipoint (et même si ces relations sont dupliquées).

Lors d’une diffusion ou d’un transfert, différents niveaux de services sont rendus aux utilisateurs :

• Aucun service : la seule action consiste en la mise à disposition d’un téléchargement. Aucun service n’est assuré par le projet de recherche. La question se pose de l’intérêt de maintenir une telle diffusion après quelques mois. Des projets affirment n’offrir aucun service faute de moyens mis à disposition.

• Prise en compte des retours des utilisateurs : dans cette catégorie, nous classons essentiellement la correction de bugs signalés par les utilisateurs, et la fourniture des correctifs ou des versions mineures qui s’ensuivent.

• Annonce du plan de développement : l’annonce du plan de développement comporte deux facettes : les futures fonctionnalités intégrées, et les délais de mise à disposition des versions. Cette pratique répandue dans le monde du logiciel libre, est un gage pour les utilisateurs d’un produit en évolution. Elle suppose le respect des délais annoncés par le projet de recherche.

• Support de premier niveau aux utilisateurs : ce service comprend la résolution des problèmes de configuration, d’installation sur une plate-forme rencontrés par les utilisateurs.

• Apport d’expertise, aide à l’utilisation : ce service accompagne une opération de transfert ou de valorisation. Dans d’autres cas de diffusion, il présente l’intérêt de traiter des problèmes réalistes, d’enrichir le savoir-faire du projet de recherche, ….

2.2.4. Stratégie de développement logiciel

Certains projets de recherche affichent une stratégie clairement définie sur le type de développement, le public visé pour une diffusion ou un transfert, et les services associés à cette diffusion ou à ce transfert. Par exemple, une diffusion restreinte d’un logiciel à un cercle académique avec correction de bogues, une diffusion d’une bibliothèque uniquement vers des éditeurs de logiciels sans service associé, …

Cette stratégie se construit sur les expériences passées du projet de recherche en particulier ses relations industrielles, et sur son potentiel de développement. Si une stratégie évolue dans le temps (passage d’un public visé à un autre), la valorisation et l’ouverture de plates-formes avec fort investissement sont des objectifs recherchés dès le départ.

Allant de pair avec une stratégie claire, l’organisation du développement logiciel est également définie : choix des outils, rôle des différentes personnes intervenant dans le processus de développement, …

Inversement, si les objectifs ne sont pas clairement identifiés (type de développement, public visé, services associés), les implications sur l’organisation à mettre en œuvre ne sont pas pleinement appréhendées.

2.3. Environnements de développement logiciel

De nombreux outils élaborés sont à disposition des projets de recherche :

• Environnements UML : Objecteering, Rose, Visio, ArgoUml, Dia, Poseidon, …

• Environnements de développement intégrés : Workshop, Forte for Java, Visual C++, ISE (Eiffel), XmlSpy, Visual Studio, JBuilder, .net, KDevelop, Visual Basic, …


• Gestion de versions : CVS, PRCS, …

• Vérification – Test : PurifyPlus, dmalloc, efence, njamd, …

• Extracteurs de documentation : Doc++, Doxygen, Javadoc, LSD, dot, …

• Suivi de bugs : gnats, bugzilla, …

• Navigateur de sources : lxr, …

• …

Hormis quelques recommandations d’outils dans certaines URs, il n’existe à l’INRIA ni outils communs, ni recommandations nationales, ni règles de développement communautaires. Les projets de recherche utilisent majoritairement Emacs (avec un mode adapté) comme environnement de développement intégré, CVS comme outil de gestion de version, et Latex pour réaliser la documentation. Les outils les plus élaborés sont globalement peu utilisés18, voire considérés comme trop contraignants ou inutiles par certains.

Le développement de logiciels se fait très majoritairement dans des environnements UNIX et les environnements Windows sont très souvent ignorés.

Il n’y a peu ou pas de synergie entre les projets de cultures différentes : informatique, automatique, mathématiques. Les projets de recherche dans lesquels les chercheurs ne sont pas informaticiens de formation19, ne bénéficient d’aucun support en interne sur les environnements de développement ou d’expertise dans certains domaines de l’informatique, et doivent le plus souvent recruter des compétences extérieures (ingénieurs experts par exemple).

Dans de telles conditions, la « qualité » des différents développements est très inégale20, le coût d’intégration d’un nouveau développeur est élevé et à la charge du projet de recherche. Cette situation est considérée comme non satisfaisante.

Plusieurs éléments devraient faire évoluer cette situation :

• Le développement coopératif (consortiums, projets européens, …) et la diffusion de logiciels libres ont conduit plusieurs projets à adopter de nouvelles pratiques : règles de programmation, serveurs avec une base CVS accessible de l’extérieur, mailing list, forums, etc. et plus récemment environnements de type Source Forge.

• Les structures de support au développement logiciel mises en place dans les URs participent à l’évolution de cette situation. L’enquête réalisée sur Rennes début septembre 2002, montre une évolution par rapport à la photographie réalisée en janvier 1999 :

- une légère augmentation de l'utilisation des environnements UML,

- une progression de Visual C++ corrélée aux développements réalisés sous Windows,

- une très nette augmentation de l’utilisation des extracteurs de documentation (14 projets sur les 16 ayant répondu).

une très nette augmentation de l'utilisation de CVS (11 projets l'utilisent dont 8 très régulièrement).

18 Une enquête plus fine menée sur l’UR de Rennes fait apparaître une utilisation régulière d’environnements de développements intégrés par 5 projets sur les 16 ayant répondu 19 cas de projets comme MATHFI 20 A titre d’exemple, aucun contrôle n’est effectué sur les logiciels diffusés sur le site WEB de l’INRIA, sur la qualité de la programmation, de la documentation, de la convivialité, de la facilité de maintenance, …


3. Les métiers du développement logiciel

Dans le secteur industriel, il y a schématiquement une seule catégorie de personnel : les ingénieurs de R&D, le plus souvent diplômés d’une école d’ingénieur ou de l’université. A l’INRIA, les catégories de personnels impliqués dans le développement sont définies plus par leur statut que par leur fonction. Après avoir identifié les principales fonctions à remplir, nous indiquons ceux qui les assument. Puis nous abordons les questions liées aux recrutements et motivations d’ingénieurs permanents, et enfin les aspects de formation.

3.1. Les différentes fonctions

Pour mener à bien les stratégies de développement, différentes fonctions « développement » de compétences et missions différentes sont à couvrir. Nous avons ainsi identifié 9 fonctions21, retrouvées pour la plupart dans l’industrie du développement logiciel.

Développeur expert scientifique : il implémente une idée ou une théorie issue de travaux de recherche en forte interaction avec le concepteur de cette théorie (si ce n’est lui-même, comme dans la plupart du temps). Il est un expert du domaine scientifique concerné et possède une forte compétence en algorithmique.

Développeur expert technique : il possède une expérience de développement d’applications et une expertise reconnue dans un ou plusieurs domaines techniques : protocoles de communication, technologies du Web, visualisation graphique, etc. Son expertise peut le conduire à participer à des organismes de standardisation et à des développements dans le cadre de ces organismes (IETF, W3C, OMG, ISO, etc.)

Développeur d’applications : il apporte des compétences générales en informatique comme le portage d’une application, le développement d’une interface utilisateur, l’écriture de la documentation, l’écriture d’un code de bonne qualité. Différent du développeur expert scientifique ou technique, il ne connaît pas forcément, et n’a pas nécessairement besoin de connaître, la technologie sous-jacente au développement.

Chef de projet : il intervient essentiellement pour la construction d’un logiciel conséquent, d’une bibliothèque, ou d’une plate-forme. Il assure la conduite (priorité des développements à réaliser), la coordination et le suivi des moyens correspondants, définit les règles de qualité logiciel et conduit la diffusion/transfert de la plate-forme. Le chef de projet est responsable des décisions relatives à la gestion des versions.

Architecte : il conçoit l’architecture d’un progiciel ou d’une plate-forme, définit les formats des données d’échange et les interfaces entre les différents modules, ... L’architecte intervient le plus souvent lors de la phase de conception mais aussi, compte-tenu de la durée des cycles de vie, pour restructurer un développement déjà diffusé22.

Intégrateur : il intègre le nouveau composant (fonctionnalité) dans une bibliothèque ou une plate-forme en respectant les formats des données d’échange et les interfaces définis par l’architecte. Il est responsable de la qualité du code, des tests et de la cohérence architecturale de l’ensemble.

21 Une même personne peut assurer plusieurs fonctions. 22 A titre d’exemple, des progiciels comme CAML et SynDEx ont été complètement réécrits plusieurs fois.


Chargé de promotion : il assure les activités de promotion d’une plate-forme accessible depuis l’extérieur. Il suit les partenariats et assiste les partenaires dans l’utilisation de la plate-forme. Son activité est comparable à celle de l’avant-vente dans l’industrie, et implique une bonne compétence technique du « produit » et la compréhension des besoins des utilisateurs (les clients).

Administrateur : il assure pour la plate forme dont il a la charge, l’ouverture sur l’extérieur, la maintenance, l’exploitation et son évolution. Cette activité recoupe certaines des activités assurées par les services informatiques.

Ingénieur support : il assure l’évaluation de méthodes et d’outils, l’élaboration de recommandations de méthodes d’outils, la diffusion de connaissances et de formations, l’apport de conseils et d’expertise. Ses missions23 sont transversales aux équipes de développement des projets de recherche.

Le tableau suivant fait le lien entre ces fonctions et les types de développement.

Programme de validation

Logiciel diffusable

Bibliothèque

Plate-forme

Développeur expert scientifique * * * *

Développeur expert technologique * * *

Développeur d’applications * * *

Chef de projet *

Architecte * * *

Intégrateur * *

Chargé de promotion *

Administrateur *

Ingénieur support * * * *

3.2. Les catégories de personnel

A l’INRIA, de nombreuses catégories de personnes sont impliquées dans des activités de développement logiciel :

• chercheurs et enseignants/chercheurs,

• doctorants,

• ingénieurs permanents,

• ingénieurs experts,

• ingénieurs sur postes d’accueil,

23 analogues à celles des fonctions de qualité/méthode logiciel dans le milieu industriel.


• stagiaires.

Le tableau suivant donne une photographie au 1er septembre 2002, du nombre d’ingénieurs en équivalent plein temps pour chacune des catégories d’ingénieurs.

Ingénieurs permanents

Ingénieurs experts

Ingénieurs sur postes d’accueil24 Total

Ingénieurs associés

Ingénieurs ODL

Ingénieurs spécialistes

Grenoble 7,5 22,6 10,0 2,7 1,7 44,5

Nancy 5 12,7 9,3 1,3 2,2 30,5

Rennes 11,4 31,7 11,4 1,0 0,7 56,2

Rocquencourt 2 25,3 10,0 2,8 1,0 41,1

Sophia 5,5 15,7 8,8 2,8 2,3 35,1

Futur 0 0 1,8 0 0 1,8

Siège 0,6 31,225 3,0 0 2,0 36,2

Total 32 139,2 54,3 10,6 9,9 246

Les chiffres ingénieurs experts et ingénieurs sur postes d’accueil nous ont été communiqués par la DRH. Plus précisément, ils représentent les équivalents temps plein connus au 1er septembre 2002, et n’intègrent pas les recrutements ou prolongations de contrats non connus à cette date. Par ailleurs, si les postes d’ingénieurs experts ou d’ingénieurs sur postes d’accueil concernent la plupart du temps des ingénieurs de développement, ils peuvent aussi de façon marginale être affectés à des gestionnaires de contrats, des assistantes de projet, etc. ; situations non reflétées dans le tableau précédent.

Les chiffres ingénieurs permanents proviennent de notre connaissance de terrain et sont à prendre comme une borne minimale26. De plus, ils intègrent pour les URs de Grenoble, Nancy et Rennes des agents non INRIA (universitaires, CNRS, …).

24 Pour les postes d’accueil, nous discernons les ingénieurs spécialistes, les ingénieurs ODL et les ingénieurs associés. 25 Ces chiffres intègrent les ingénieurs des actions nationales de R&D, dont le W3C. 26 Par exemple, nous n’avons pas été en mesure d’apprécier la situation sur l’UR de Rocquencourt et nous n’avons pas de visibilité des missions effectuées par les ingénieurs en poste INRIA à Infobiogen.


Le rôle joué par chacune des catégories de personnels dans le cycle de développement est par contre plus diffus. Le tableau suivant met en correspondance les fonctions développement avec les catégories. Faute de données chiffrées, ce tableau donne les tendances ressenties au cours de nos entretiens.

Chercheur Doctorant Ingénieur

permanent Ingénieur

expert Ingénieur sur poste d’accueil

Stagiaire

Développeur expert

scientifique *** *** ** **

Développeur expert

technologique ** ** ** *** *

Développeur d’applications ** *** *** ***

Chef de projet ** *

Architecte ** * *

Intégrateur ** ** **

Chargé de promotion ** * *

Administrateur ** * *

Ingénieur support * ***

*** : très souvent ** : souvent * : dans quelques cas

Une première analyse de ce tableau montre que :

• les activités de développement logiciel sont bien identifiées pour les doctorants, ingénieurs sur postes d’accueil et stagiaires,

• les activités de développement logiciel se recouvrent entre chercheurs, ingénieurs permanents et ingénieurs experts,

• la fonction de développeur d’applications est quant à elle fréquemment couverte par les ingénieurs permanents, les ingénieurs experts, les ingénieurs sur postes d’accueil et les stagiaires.

Nous complétons cette première analyse par plusieurs remarques.

Chercheur/enseignant chercheur

• L’activité principale en développement logiciel d’un chercheur est développeur expert scientifique.

• Lorsque la stratégie du projet de recherche conduit à développer une plate-forme ou une bibliothèque, un chercheur (ou un collège de chercheurs) du projet assure les fonctions de chef de projet et d’architecte (fonction plus rarement assurée par un ingénieur permanent). Certains


chercheurs souhaitent voir remplir ces fonctions soit par un ingénieur permanent, soit par un ingénieur expert ou un ingénieur spécialiste (certains chercheurs n’envisageant que cette dernière solution).

• L’activité de promotion est essentiellement faite par les chercheurs. Nombreux sont ceux qui aimeraient ne pas assurer une fonction estimée leur prendre beaucoup de temps et ne pas correspondre à leurs compétences.

• Les chercheurs sont quasi unanimes à ne pas souhaiter s’impliquer dans des fonctions de développeurs expert technologique ou d’applications. L’argument le plus fréquemment avancé, tout en reconnaissant l’utilité de cette partie du développement pour une diffusion, est qu’elle consomme de temps d’un chercheur sans qu’il présente de compétence particulière pour cette tâche.

Doctorant

• Il est essentiellement demandé à un doctorant de réaliser le logiciel de validation de sa thèse. Pour beaucoup de chercheurs, couvrir d’autres fonctions liées aux développements serait pénalisant pour la thèse.

• La majorité des chercheurs rencontrés considèrent le code produit par les doctorants comme non intégrable directement dans les produits diffusés par le projet de recherche. En règle générale, ce code est repris sous le contrôle des permanents pour l’améliorer, le documenter, le tester.

Ingénieur permanent

• Les fonctions actuelles des ingénieurs permanents sont très nombreuses, et de fait, cette catégorie couvre l’ensemble du spectre des fonctions liées aux développements. Cette situation est aussi due à la diversité des profils des ingénieurs permanents.

• S’ils sont positionnés sur des fonctions de chef de projet ou d’architecte, généralement, ils n’en assurent pas la complète responsabilité. Celle-ci est partagée collégialement avec des chercheurs.

• Sur les plates-formes du projet, la fonction d’administrateur leur est généralement dévolue.

• Les chercheurs perçoivent mal leur positionnement par rapport aux ingénieurs sur CDD : font-ils le même travail ? ont-ils une fonction d’encadrement ? quelles sont leurs spécificités ?

• Le cloisonnement des projets de recherche est perçu négativement par la plupart des ingénieurs de développement. Ils souhaitent confronter leurs expériences, leurs expertises et les problèmes rencontrés.

• Ils sont totalement intégrés dans des structures de support aux développement comme à Nancy et Sophia, ou partiellement comme dans les autres unités de recherche.

Ingénieur expert

• Les ingénieurs experts font surtout du développement. Les activités précises dépendent essentiellement de la nature du travail à réaliser, et par conséquent du niveau de recrutement qui va de BAC + 5 à un niveau doctorat.

• La fonction d’administrateur est confiée à un ingénieur expert en l’absence d’ingénieur permanent dans l’environnement du projet.

Ingénieur sur poste d’accueil


• Les ingénieurs sur postes d’accueil, exception faite des ingénieurs spécialistes, sont plutôt positionnés sur des fonctions de développeurs d’applications.

• L’arrivée des ingénieurs sur postes d’accueil est unanimement appréciée. Si pour certains projets, il s’agit d’une force d’appoint, pour d’autres, ils représentent l’opportunité d’un développement non entrepris sans cet appui. Ces postes sont considérés comme des acquis par les projets qui ne perçoivent pas le contexte d’une mesure éventuellement non renouvelée par le ministère.

Stagiaires

• Comme les ingénieurs sur postes d’accueil, ils sont positionnés sur des fonctions de développeurs d’applications. Par contre, les durées généralement courtes de leurs stages, leurs niveaux de compétences en développement, ne permettent pas d’envisager des développements longs ou complexes.

3.3. Activités de développement et carrières

Nous consacrons l’essentiel de ce paragraphe à la carrière des ingénieurs permanents et à l’attractivité des postes. En effet, dans le chapitre 2, nous avons déjà abordé l’impact des activités de développement sur les carrières des chercheurs, et les interrogations de ces derniers. Par ailleurs, pour les ingénieurs sur CDD (ingénieurs experts, ingénieurs sur postes d’accueil), leurs carrières se font par définition en dehors de l’INRIA. Leur passage à l’institut est une première expérience de travail, et l’occasion d’acquérir et/ou valoriser une expérience dans un domaine de haute technologie27.

3.3.1. Carrières des ingénieurs permanents

Lors de nos rencontres avec les chercheurs, des préoccupations sur la carrière des ingénieurs permanents sont remontées sous forme de questions ou d’assertions :

• Compétitivité financière par rapport au privé,

• Attractivité des meilleurs,

• Manque de perspectives de carrière,

• Motivations tout au long de la carrière.

Dans la suite, nous apportons des éléments de réponse tendant à montrer que la situation n’est pas sombre, même si certains de nos interlocuteurs l’estiment ainsi. Notre première réflexion est de discerner la carrière administrative des ingénieurs permanents de la reconnaissance de leur carrière fonctionnelle qu’ils peuvent poursuivre à l’INRIA.

Niveau de recrutement

La logique des carrières administratives des ITA devrait conduire à recruter les ingénieurs de développement dans le corps des ingénieurs d’étude pour leur offrir une perspective de progression. Il n’en est rien, et l’INRIA recrute des ingénieurs de développement le plus souvent dans le corps des ingénieurs de recherche. En effet, faire du développement dans un projet de recherche demande un haut niveau de qualification en informatique et un potentiel de prises de responsabilités

27 Pour les ingénieurs sur postes d’accueil, l’INRIA s’est engagé à des actions de formations au développement, formations pour lesquelles les structures de support aux développements peuvent jouer un rôle déterminant. A l’instar du travail fait par les URs de Rennes et Sophia, il nous apparaît judicieux de mettre en place un suivi de leurs travaux et des postes qu’ils obtiennent dans l’industrie.


équivalents à un niveau de formation BAC + 5 ou BAC +8 28. De plus, si l’INRIA souhaite confier aux ingénieurs permanents des missions d’encadrement d’ingénieurs sur CDD, nous recommandons de continuer à recruter dans le corps des ingénieurs de recherche.

Les missions liées à la fonction d’ingénieur support ne nécessitent pas un niveau de qualification comparable à celui des ingénieurs permanents développant au sein des projets de recherche. Pour exemples, les installations de logiciels, des évaluations de produits, des rédactions de documentations, sont des activités qui peuvent être confiées à un ingénieur d’étude recrutés sur un niveau BAC + 2 à BAC + 4. Par contre, les missions d’ingénieur support portant sur l’expertise, le conseil, des formations pointues sont à confier à des ingénieurs de recherche.

Attractivité financière

Nous avons réalisé une étude comparative des différences de salaires entre l’INRIA et le privé, en nous basant sur des données du Syntec Informatique et de l’hebdomadaire 01Net Informatique :

• Nous avons retenu 3 métiers types comme échantillonnage de la famille des métiers « Etudes et développements » : chef de projet et ingénieur études et développement (similaire à la fonction chef de projet, développeur expert technique de niveau IR), et analyste (similaire à la fonction développeur d’applications de niveau IE).

• Pour l’INRIA, les salaires bruts annuels incluent les primes (PPRS taux moyen et PFI niveau Programmeur Système d’Exploitation) :

- la fourchette minimale correspond au salaire brut d’un IR2 ou IE2 1er échelon,

- la fourchette maximale correspond au salaire brut d’un IR1 ou IE1 dernier échelon,

- la fourchette moyenne correspond au salaire brut d’un IR2 ou IE2 dernier échelon29.

Salaire brut annuel en K€

Fourchette minimale

Fourchette moyenne

Fourchette maximale

Chef de projet 43,7 51,2 58,6

Ingénieur études et développement 35,2 43,0 50,7

Ingénieur de recherche INRIA 31,8 47,7 53,4

Analyste 36,8 42,0 47,2

Ingénieur d’études INRIA 27,7 35,0 43,8

Si en début de carrière, la différence de salaire brut est de l’ordre 10 à 12 K€, elle diminue en fourchette moyenne et maximale, tout en sachant que l’écart entre le brut et le net est moindre dans

28 Le rapport du Syntec Informatique montre qu’en 2000 l’éventail du niveau d’étude des jeunes diplômés sans expérience professionnelle allait de Bac+2 au diplôme d’ingénieur d’une grande école ou d’un doctorat. La plus grande variété des métiers dans l’industrie est l’une des explications à cette situation. 29 Comme base moyenne pour les salaires ingénieurs fonctionnaires, nous avons considéré ce dernier échelon car un agent recruté en IE2 ou IR2 arrivera automatiquement à ce niveau de salaire à l’ancienneté.


la fonction publique que dans le privé. Les études du Syntec Informatique et de 01Net Informatique30 montrent, d’une part, quelques salaires exceptionnels sur les métiers retenus (jusqu’à 125 K€ pour le chef d’un projet très important) et d’autres fonctions comme responsable de domaine, responsable études et développement (fourchette maximale respectivement de 73,3 et 78,5 K€, salaires exceptionnels de l’ordre de 125 K€). L’équivalent de telles fonctions pourrait se trouver à l’INRIA comme responsable d’un consortium ou d’un GIE.

Motivations des candidats

Il y a une très nette tendance dans la recherche publique à sous-estimer les difficultés rencontrées par les ingénieurs de développement dans l’industrie et à prendre en compte uniquement les aspects financiers. Les EPST possèdent d’autres facteurs d’attractivité:

• Intérêt du travail, qualité de l’environnement : lors de concours pour des postes d’ingénieurs de développement, les candidats du secteur industriel avancent le plus souvent des arguments sur l’intérêt du travail, la qualité de l’environnement « high-tech ».

• Formation : la crainte d’une perte de compétences techniques en raison de contraintes/missions à court terme imposées par leur société, l’absence de formations dans certaines entreprises.

• Sécurité de l’emploi, service public : particulièrement sensible sur certaines périodes.

Nous nous sommes forgé cette opinion en participant à des jurys de recrutement et en échangeant avec d’autres membres de jury. Par exemple, sur un concours pour un poste d’ingénieur de développement CNRS en 2002, sur les 45 candidats ayant postulé, 11 candidats de bon niveau ont été admissibles et il n’y a eu aucune défection aux épreuves d’admission. Point complémentaire, la moitié des candidats admissibles avaient une bonne expérience dans le monde industriel.

Nous recommandons, lors des jurys de recrutement d’ingénieurs de développement, d’être très attentifs aux motivations des candidats. Par ailleurs, pour ses recrutements, l’INRIA s’appuie sur les emplois-types. Les ingénieurs de développement entrent dans la famille professionnelle « études et développement » de la BAP E. De notre point de vue, les emplois-types ne correspondent pas ni aux missions actuellement confiées, ni à celles que nous recommandons. Un travail est à mener avec la DRH pour disposer et afficher vers l’extérieur des profils types en adéquation avec les fonctions recherchées par l’INRIA.

Motivations pendant la carrière et mobilité

Si l’intérêt pour le travail et la qualité de l’environnement sont de fortes motivations, la reconnaissance et la valorisation du travail, d’une part, la reconnaissance de la fonction exercée, d’autre part, sont des facteurs de motivation importants. Quelques actions concrètes simples devraient être systématisées pour renforcer cette reconnaissance :

• Mention des activités des ingénieurs permanents dans les rapports d’activités,

• Participation des ingénieurs aux publications scientifiques,

• Incitation à publier des papiers techniques sur les développements,

• ….

Certains chercheurs partagent ce point de vue, et il est apparu comme point sensible de reconnaissance par la communauté scientifique lors de nos entrevues avec les équipes de support aux développements.

30 Le Syntec et 01Net s’appuient chacun sur les enquêtes de Hewitt Associates, cabinet américain spécialisé dans le recrutement.


Si la mobilité est également un facteur de motivation, nous constatons sa faiblesse chez les ingénieurs permanents que ce soit à l’extérieur ou à l’intérieur de l’INRIA.

• A l’extérieur : plusieurs ingénieurs permanents ont quitté l’INRIA pour s’investir dans une start-up, plus rarement dans l’industrie. Compte-tenu de la faible taille de l’institut la mobilité à l’extérieur est indispensable pour conserver une ouverture sur les nouvelles méthodes de développement. Force est de rappeler que les décrets Allègre sur l’innovation s’appliquent également aux ingénieurs permanents et leur offrent un cadre particulièrement favorable pour une mobilité vers l’industrie.

• A l’intérieur : même si la taille de l’établissement et sa focalisation sur la recherche limitent les changements de métier, il existe des possibilités de passage d’une fonction de développement à une autre, de changement de projets de recherche, de thématiques scientifiques. Autant de possibilités à encourager.

3.4. Formation

La formation à des méthodes, à des langages, à des outils est un enjeu important pour augmenter et améliorer la production de logiciels de qualité et favoriser la mise en place d’une « culture » du développement. La mise en place de formations initiales pour les nouveaux arrivants, l’organisation de séminaires, la participation à des conférences sont autant de moyens pour améliorer la situation actuelle. Nos entretiens ont montré une forte attente dans ce domaine.

Il n’y pas à notre connaissance de plan de formation sur le développement logiciel au niveau de l’institut ou des unités de recherche. Cependant, l’INRIA possède d’ores et déjà plusieurs atouts pour bâtir rapidement une offre de formations adaptées à ses besoins :

• De fortes compétences en interne chez les chercheurs et les ingénieurs permanents,

• Un fond de formations disponibles sur l’Intranet31,

• Des structures de support pouvant servir de relais pour dispenser les formations dans lesunités de recherche,

• La DRH poursuivant ses efforts pour mettre en place un plan de formation national.

Un recensement des formations disponibles doit nous permettre d’établir un premier catalogue, et d’identifier les axes à investir en regard de la « culture » de développement que l’INRIA souhaite mettre en place.

31 Voir http://www-interne.irisa.fr/atelier/documentations/ASCII/coursASCII.html

http://www-sop.inria.fr/semir/formation/DR:I/


4. La diversité des besoins et attentes

Les besoins et les attentes des projets de recherche sont bien évidemment fonction de leur expérience de développement logiciel et/ou matériel. Dans cette partie, nous incluons également les demandes et attentes exprimées par les responsables des services/cellules de support aux développements (demandes exprimées lors des réunions organisées avec eux dans le cadre de cette mission).

4.1. Moyens humains

La demande la plus forte est un renforcement du nombre des ingénieurs liés au développement logiciel. Lors de nos entretiens, nous avons recueilli des avis opposés sur le recrutement d’ingénieurs permanents :

• Pour les uns, le recrutement d’ingénieurs permanents est dangereux et risqué en raison d’une absence d’enjeu économique, d’une pérennisation sur plusieurs années de développements dont l’utilité reste à démontrer. Avec des ingénieurs permanents, les projets n’auraient plus besoin de se confronter aux industriels pour financer des ingénieurs sur CDD et les développements n’adresseraient pas des besoins réels.

• Pour d’autres, ce recrutement est indispensable pour le suivi des développements sur lesquels ces ingénieurs auront la mémoire du projet. C’est aussi un moyen d’échapper aux problèmes liés à la recherche de contrats et à l’embauche d’ingénieurs sur contrats à durée déterminée.

Globalement les projets de recherche demandent des ingénieurs possédant une bonne formation initiale en informatique, ayant tout à la fois une expertise reconnue dans plusieurs domaines scientifiques et une expérience significative dans le développement. Ils identifient des fonctions ou des missions à confier à des ingénieurs :

• Les activités de standardisation (IETF, …) demandant un effort important32 tant au niveau du développement d’une implémentation de référence que de la participation aux réunions internationales.

• La prise en charge de la promotion et du support des développements réalisés par les projets.

• Les développements de plates-formes ou de gros logiciels nécessitant au sein du projet de recherche des compétences de chefs de projet.

• L’apport d’expertise, de conseils, la dispense de formations internes.

Sur les catégories des ingénieurs contractuels, les chercheurs nous ont fait part de plusieurs attentes :

• Un allègement des procédures de recrutement et des délais plus courts. L’argument principal mis en avant est le risque de perdre de bons candidats, particulièrement dans les périodes de forte concurrence avec le monde industriel. De plus, la multiplicité des procédures de recrutement (ingénieurs experts, ingénieurs associés, ODL, ingénieurs spécialistes) est perçue comme une source de confusion.

32 Le projet PLANETE indique le succès d’une telle démarche pour le protocole UDLR.


• Des niveaux de rémunération compétitifs au niveau national ou international pour permettre le recrutement de compétences techniques pointues ou de fonctions importantes comme chef de projet, architecte.

• La possibilité de recruter un chef de projet sur une durée de 4 à 5 ans est demandée pour la direction de consortia. Les contrats d’ingénieurs spécialistes actuels sont considérés de trop courtes durées (2 à 3 ans) pour assurer ce type de fonction.

4.2. Organisation

4.2.1. Plates formes technologiques

Dans plusieurs unités de recherche, des projets de recherche utilisent des plates-formes technologiques : robotique, Cycab, réalité virtuelle, grappe de PCs, … Pour une utilisation optimale, ces plates formes nécessitent l’appui d’ingénieurs permanents développant ou ayant développé des compétences particulières, et assurant la pérennité des investissements.

L’éclatement géographique de ces compétences sur plusieurs sites pose de réels problèmes :

• Légitimement, se pose la question de la masse critique pour certains sites ne disposant le plus souvent que d’un seul ingénieur de recherche, situation fragilisée en cas de mobilité de l’ingénieur. Il n’est évidemment pas réaliste d’envisager une montée en puissance sur chacun des sites et des choix devront être faits :

- renforcement de la coopération entre sites (niveau projets de recherche et niveau ingénieurs) qui, si souhaitée, reste limitée. Un directeur d’UR préconise de s’attacher principalement à la coordination du développement entre les unités de recherche : plates-formes (Cycab, Clusters, Robotique, etc.), réseaux de compétence d’ingénieurs, formations, …

- concentration des moyens sur une ou deux unités de recherche,

- coopération accrue avec des partenaires comme le CNRS et l’université, ouverture à l’industrie,…

• Des choix technologiques différents sont pris d’un site à un autre. Pour exemple, les développements réalisés autour du Cycab, plate-forme matérielle et logicielle commune entre les unités de recherche, illustrent les difficultés rencontrées. Les développeurs rencontrés à Rennes, Grenoble, Sophia et Nancy, nous ont fait part de leurs difficultés à utiliser et développer des applications sur le Cycab. Les critiques concernent tout à la fois le matériel fourni par Robosoft et le logiciel développé conjointement par Robosoft et l’INRIA. Paradoxalement le choix de SynDEx est toujours contesté à l’intérieur de l ‘INRIA alors qu’il semble avoir définitivement été adopté par Robosoft. En dépit de ces critiques, des opérations de promotion du Cycab ont été lancées régionalement à Nancy et Sophia.

4.2.2. Fédération de développement logiciel

Des projets de recherche considèrent que des projets de développement d’envergure sont un moyen de fédérer plusieurs projets, d’assurer une plus grande visibilité aux développements réalisés isolément par les projets, de créer une dynamique. L’expérience de MODULEF est considérée comme importante et structurante.


4.2.3. Structures de support au développement logiciel

La plupart des chercheurs rencontrés sont favorables à la mise en place au niveau de l’UR d’une structure de support au développement logiciel qui privilégie les missions d’expertise, de formation, de coordination et d’animation de la communauté des développeurs, l’accompagnement des ingénieurs sur postes d’accueil, des thésards, etc., une veille technologique sur les outils, le partage d’expériences.

Cependant, dans plusieurs unités de recherche, l’idée de mettre en place une structure de développement a provoqué des réactions :

• Le syndrome du « service », et en particulier celui du service informatique, est très présent et il est craint que la mise en place d’une structure ne rende pas les services escomptés.

• La crainte d’un « pouvoir » des services sur les orientations scientifiques des projets de recherche par le biais de la mise en place d’un service de développement est aussi présente.

• Les structures matricielles avec un rattachement de l’ingénieur de développement à un service et à un projet de recherche sont mal comprises et jugées inefficaces.

• Si le rattachement des ingénieurs de développement à un service est parfois mal perçu, les chercheurs rencontrés réfutent le rattachement « à vie » à un projet et acceptent l’idée d’une organisation pour passer d’un projet à un autre.

Par ailleurs, nous avons organisé quelques réunions avec les responsables des structures de développements en place (ASCII à Rennes, Sèdre à Nancy, DREAM à Sophia) et les RMIs des URs de Rocquencourt et de Rhône Alpes. Il ressort de ces réunions un besoin de coordination nationale :

• Veille technologique, expertise au niveau national, organisation des formations,

• Communication et information,

• Mise en relation des ingénieurs : réseaux, audio-conférences entre les responsables,

• Budget autonome pour des acquisitions de certains produits logiciel au niveau national,

• Mise en place d’un animateur national

4.3. Environnements de développement logiciel

Lors de nos entretiens, nous avons recensé plusieurs types de demandes ou d’attentes :

• Formation : les demandes en formation couvrent l’initiation à un langage de programmation, l’expertise sur ce langage, l’utilisation d’outils ou d’environnements. Par ailleurs, les responsables des structures de support au développement ont fait ressortir la nécessité de partager entre les URs les formations dispensées.

• Méthodologie : il n’existe pas à l’INRIA de méthodologie de développement. Cependant, quelques projets sont demandeurs d’une telle méthodologie, sous réserve qu’elle ne soit pas trop contraignante et soit présentée sous forme de règles à adopter.

• Outils : la demande d’outils va de leur installation dans l’environnement du projet, à la recommandation d’outils associée à un support de second niveau. Une demande forte a été exprimée pour la mise à disposition d’environnements de gestion de versions (CVS, Source Forge) pour les besoins propres du projet ou des développements en partenariat.


• Expertise/conseil : beaucoup de projets de recherche sont demandeurs d’expertise et de conseil sur une technologie, sur la meilleure façon de s’organiser (exemple suivi des bogues lors d’une diffusion).

• Salle de portage : la disponibilité à l’INRIA d’une plate-forme de test pour la portabilité des logiciels est jugée importante et demandée par plusieurs projets de recherche. Les moyens informatiques ne supportent que les systèmes « standards » et refusent généralement d’assurer ce type de service.


5. Principales recommandations

Notre mission a mis en évidence des éléments caractéristiques du processus de développement logiciel dans l’institut :

• Les ingénieurs de développement sont principalement des ingénieurs sur contrat à durée déterminée (plus de 210). Les ingénieurs permanents représentent 13% du nombre total d’ingénieurs de développement.

• A l’exception des ingénieurs spécialistes et de quelques ingénieurs experts, la plupart des ingénieurs sur contrat à durée déterminée ont peu d’expérience préalable en développement logiciel, d’où un besoin important d’encadrement et de formation.

• Les fonctions de développement logiciel (ingénieur support, chef de projet, architecte, développeur expert technique, chargé de promotion) sont difficilement remplies par des ingénieurs qui resteront de 2 à 3 ans.

• A l’exception de quelques outils de base, il n’existe pas à l’INRIA d’environnements de développement logiciel communs, de méthodologie de développement commune. L’absence de mutualisation des moyens et des compétences a un coût important et qui croit avec la taille de l’institut et sa dispersion géographique.

• La coordination du développement logiciel est faible entre projets de recherche d’un même site, et pratiquement inexistante entre unités de recherche. Ce manque est particulièrement préjudiciable aux activités autour des plates-formes de même technologie : grappes de PCs, réalité virtuelle, Cycabs, ...

Sur la base de ces éléments, nous sommes convaincus que des progrès significatifs sur la qualité et la quantité des développements de logiciels sont possibles en améliorant l’organisation collective du développement, la formation et l’encadrement des développeurs, en proposant des règles et méthodes de développement.

Nous proposons de mettre en place une organisation collective à trois niveaux :

• Projets de recherche,

• Structures de support au développement logiciel propre à chaque unité de recherche,

• Coordination et animation nationale.

Nos recommandations principales vont principalement dans le sens de mettre en place cette organisation collective pour assurer efficacement la formation et l’encadrement, pour proposer des règles.


Recommandation 1 : Mettre en place des structures de support aux développements logiciels dans chaque unité de recherche

Lors de nos visites, de nombreux projets de recherche nous ont fait part de leurs attentes de supports communs aux développements logiciels dont les plus marquantes sont :

• Formations internes,

• Animation du réseau des développeurs,

• Tutorat logiciel,

• Expertise/veille sur les outils et les technologies,

• Recommandations d’outils et de méthodologies,

• Installations d’outils communs,

• Apport d’expériences pour la diffusion,

• Support technique à la valorisation des logiciels.

Nous recommandons de poursuivre au plus vite la mise en place et la consolidation des structures33 de support aux développements logiciels de chaque unité de recherche recentrées sur les missions listées précédemment. Ainsi, l’INRIA aura le plus fort impact global sur la qualité et la quantité des développements de logiciels par rapport au nombre raisonnable d’ingénieurs support affectés.

En effet, les effectifs des structures de support impliqués sur les missions recommandées n’ont pas vocation à être importants. Un noyau central minimum de 3 ingénieurs support34 par structures nous semble indispensable, l’optimum étant de 4 à 5 ingénieurs support. Ceci implique l’affectation ou le recrutement au minimum d’une dizaine d’ingénieurs support et au maximum d’une vingtaine.

De plus, les structures de support aux développements de logiciels doivent bénéficier de l’apport de compétences des ingénieurs permanents travaillant dans les projets de recherche. Sans aller jusqu’à recommander un rattachement hiérarchique aux structures de support, il nous apparaît nécessaire que chaque ingénieur de projet consacre une partie de son temps à des tâches communautaires de support (tutorat logiciel, dispenses de formations, apports d’expertise, …). Autre bénéfice de cette mesure, les ingénieurs de projet s’intègreront dans une communauté de développeurs.

Recommandation 2 : Mettre en place une coordination des structures de support avec une animation au niveau national.

Les réunions avec les responsables des structures ASCII, DREAM, Sèdre, et les responsables des moyens informatiques de Rocquencourt et de Montbonnot, ont mis en évidence, d’une part, un souhait de voir émerger une communauté de développeurs reconnue et visible, et d’autre part, un besoin de coordination nationale des structures de support. Plusieurs pistes de collaboration, d’échanges de compétences, de mutualisation ont été identifiées :

33 Si plusieurs chefs de projet se sont déclarés opposés à la mise en place de telles structures, un affichage clair des missions, des personnes impliquées et de leurs compétences est de nature à lever les craintes exprimées. 34 Au sein de ces structures, il n’est pas nécessaire d’avoir uniquement des ingénieurs support de niveau IR. De nombreuses tâches peuvent être prises en charge par des IE.


• Partage/dispense de formations entre unités de recherche,

• Partage des compétences sur des outils,

• Partage de documentations,

• Evaluation partagée d’outils.

Pour dynamiser et structurer ces échanges, favoriser les partages sources d’économie, nous préconisons de mettre en place dans les meilleurs délais, une fonction d’animateur national rattachée à la direction du développement et des relations industrielles. Cette fonction aura un rôle important dans la coordination et l’animation d’actions nationales comme celles faisant l’objet des deux recommandations à suivre, et peut englober d’autres missions comme par exemple :

• La reprise de la politique d’achats des outils de développement logiciel. Il nous apparaît logique de placer cette politique d’achats, actuellement sous la responsabilité des moyens informatiques, au plus près des experts représentés par les responsables des structures de support aux développements. Cette action doit faire l’objet d’une coordination préalable avec la DRSI.

• La mise en place et animation de réseaux transversaux d’ingénieurs ayant des compétences proches ou travaillant sur le même thème : réalité virtuelle, Cycab, grappes de PCs, … Dans ces réseaux pourront être impliqués des chercheurs.

• La coordination pour les besoins en développement logiciel avec les autres directions fonctionnelles. Par exemple, la mise en place d’une salle de portage souhaitée par des projets doit être coordonnée avec la DRSI pour son installation et son exploitation.

Recommandation 3 : Mettre en place les éléments de base d’un processus de développement logiciel cohérent au sein de l’institut

L’absence de règles communes est pénalisante car elle ne garantit pas un minimum de qualité pour les logiciels, bibliothèques et plates-formes développés par l’institut. Il ne s’agit pas d’imposer des règles qui ne seront jamais suivies, mais de dégager avec les projets de recherche un ensemble de bonnes pratiques et d’outils communs.

Des demandes insistantes venant des ministères et des industriels vont dans le sens d’une formalisation des processus de développement pour produire des logiciels de meilleure qualité. Une évolution dès aujourd’hui de nos pratiques permettra à l’institut de se préparer à ces futures contraintes.

Pour l’élaboration des règles communes, nous préconisons un groupe de travail national regroupant des représentants des différents acteurs du développements. La diffusion au sein de l’institut sera assurée par les structures de support au développement.

Recommandation 4 : Mettre en place un plan de formation aux techniques et méthodes de développement logiciel

La formation à des méthodes et des outils est un enjeu important pour augmenter et améliorer la production de logiciels de qualité, pour favoriser l’émergence d’une « culture » du développement. L’INRIA possède les atouts pour bâtir une offre de formations adaptée à ses besoins :


• de fortes compétences en interne chez les chercheurs et les ingénieurs permanents,

• un fond de formations disponibles sur l’Intranet,

• des structures de support dispensant des premières formations dans leur unité de recherche,

• la mise en place par la DRH d’un plan de formation national pour l’ensemble des personnels.

Un recensement des formations disponibles permettra d’établir un premier catalogue, et d’identifier les axes à investir en regard, d’une part, de la « culture » de développement retenue par l’INRIA, d’autre part, du potentiel de formations internes que pourront dispensées les structures de support.

Recommandation 5 : Définir des critères de mesure du « succès » d’un développement logiciel

L’affirmation « qu’un bon développement logiciel vaut une bonne publication » n’est pas contestable, mais se heurte aux questions d’évaluations d’un logiciel sur les plans scientifiques, de l’opportunité d’y affecter des moyens pour son développement, du succès de son impact. Il est nécessaire de répondre à ces questions pour progresser dans la reconnaissance, l’affectation de moyens, l’évaluation des activités de développement au sein de l’institut.

Nous proposons la mise en place rapide d’un groupe de travail sous la responsabilité des directions scientifiques et du développement et des relations industrielles pour la définition de critères permettant d’évaluer l’intérêt, l’impact et le succès d’un logiciel.

Recommandation 6 : Privilégier l’affectation des ingénieurs permanents pour les projets de recherche sur des fonctions de développeur expert technique, de chef de projet, d’architecte et de promoteur.

Trois raisons principales nous poussent à émettre cette recommandation :

• Le besoin de renforcer le potentiel d’encadrement. Nombreux sont les projets de recherche accueillant simultanément plusieurs ingénieurs contractuels (jusqu’à une dizaine pour quelques projets), des stagiaires. L’encadrement, le suivi des travaux deviennent une tâche lourde souvent assurée par les chercheurs. Elle pourrait être déléguée à des ingénieurs permanents.

• L’accroissement du niveau d’expertise dans les technologies de développement. Cette expertise est nécessaire pour mener à bien des développements pointus et complexes au sein des projets.

• Des développements nécessitant de telles fonctions, mais avec des cycles dépassant les durées usuelles des contrats à durée déterminée. Des projets de recherche souhaitent recruter des ingénieurs contractuels sur de plus longues durées pour assurer ces fonctions, cependant, la DRH nous a confirmé l’impossibilité de satisfaire ces demandes.

L’affectation d’un ingénieur permanent à un (ou des) projet de recherche qui veut réaliser un logiciel, une bibliothèque ou une plate-forme, devra s’inscrire dans un processus d’évaluation de l’opportunité du travail à réaliser, suivie par des évaluations régulières du travail réalisé.


La mise en application de cette recommandation se concrétise par deux axes d’actions :

• Une évolution des métiers et des compétences des ingénieurs permanents de projets actuellement en postes. Cette évolution peut s’envisager à court terme, mais il est nécessaire d’accompagner cette évolution par un plan de formation portant sur des compétences comme la conduite de projets de développement logiciel, le management d’équipe, …

Des recrutements externes pour renforcer l’expertise technique, le potentiel d’encadrement, le suivi de projets de développement longs. Nous recommandons d’entamer cette politique de recrutement après avoir mis en place les structures de support au sein de chaque unité de recherche.

Recommandation 7 : Veiller à la qualité du recrutement des ingénieurs permanents, privilégier les profils ayant une forte compétence en informatique.

En privilégiant pour les ingénieurs permanents des fonctions où les missions d’encadrement, d’expertise sont centrales, les futurs recrutements doivent suivre quelques règles :

• S’assurer d’une forte compétence35 en informatique et en développement, avec éventuellement une double compétence dans un domaine applicatif ou technologique.

• Vérifier auprès de chaque candidat ses motivations sur l’intérêt du travail et sur la qualité de l’environnement, sa connaissance des impacts financiers.

• Recruter dans le corps des ingénieurs de recherche ou des ingénieurs d’études pour les fonctions d’ingénieurs support, dans le corps des ingénieurs de recherche pour les autres fonctions d’ingénieurs permanents.

Le référentiel métier est un outil essentiel pour l’affichage vers les candidats, la sélection des candidats et la définition des carrières. Les fiches métiers définies pour les ingénieurs de développement ne sont pas en adéquation avec les fonctions et missions préconisées pour les ingénieurs permanents. Un travail en collaboration avec la DRH sur ces fiches ou sur des profils types améliorera le recrutement.

35 Cette compétence favorise de plus la mobilité entre projets de développement et la reconnaissance.


ANNEXE I Liste des projets de recherche rencontrés

Au cours de cette mission nous avons rencontré 27 projets de recherche, les personnels des structures de développement ASCII, SèDRE ou DREAM, les directeurs des unités de recherche de Grenoble, Rennes, Sophia et Rocquencourt et Paul Le Guernic au titre de membre du bureau exécutif du RNTL. L‘établissement des listes de projets rencontrés dans chacune des unités de recherche a été fait en concertation avec le directeur de l’unité de recherche et le responsable du développement. La grande majorité des projets rencontrés sont fortement impliqués dans le développement logiciel et ont des préoccupations qui ne sont pas nécessairement celles de tous les projets de recherche

COMPOSE 2A

FUTUR36 SCALAPPLIX 4B

HELIX 3A APACHE 1A OPERA 3A

PLANETE 1B VASY 1C

GRENOBLE

IS2 4A MAIA 3A

SPACES 2B ECOO 3A

PROTHEO 2A NANCY

MIRO 2A ARMOR 1B

CAPS 1A VISTA 3B

RENNES

SIAMES 3B ARLES 1A

CRISTAL 2A GAMMA 4B MATHFI 4B

ROCQUENCOURT

MACS 4B ICARE 4A

COPRIN 2B EPIDAURE 3B ROBOTVIS 3B

SOPHIA

PRISME 2B

36 Nous avons également rencontré Pascal GUITTON qui est en cours de montage d'un projet devant se situer dans le 3B.


ANNEXE II Analyse des ODLs

Depuis 2001, 20 postes d’ODL ont été affectés, 10 postes en 2001 et 10 autres en 2002. Les projets rencontrés apprécient de façon très positive cette mise à disposition de moyens pour faire du développement. La ventilation des postes par thème montre que 65% d’entre eux ont été affectés aux thèmes 2 et 3 et 35% aux thèmes 1 et 4.

Figure 1 : ventilation des ODL par thèmes

Dévelop

pement Documenta

tion Tests Reprise du

code Packaging Portage Interfaces Gestion

site web PRISME X PLANETE X LOGICAL X X X SAMIE X X X X SIRAC X X X X X CRISTAL X X X SIAMES X X X COSI X X X X METALAU X X MIRO X X X

Sur la base des rapports d’activités des ODLs affectés en 200137, nous avons essayé d’analyser les types de développements qui étaient demandés par les projets. Il n’est bien évidemment pas possible de généraliser sur la base d’un si petit nombre de projets, mais on peut cependant noter une demande importante pour :

• améliorer la diffusion du logiciel : documentation, tutoriaux, site Web, packaging ;

• faire des développements spécifiques : interfaces graphiques, portage sur des plate-formes Windows, portage d’applications, etc.

37 http://www.inria.fr/valorisation/odl/index.fr.html


ANNEXE III Logiciels affichés et déposés

L’INRIA affiche sur son site Web national38 un peu plus d’une centaine de logiciels (121 en novembre 2002) et distribue un cédérom de logiciels libres.

Figure 2 : répartition des logiciels suivant les thèmes

38 http://www.inria.fr/valorisation/logiciels/alpha.fr.html


Figure 3 : répartition des logiciels suivant les unités de recherche

L’analyse de ces logiciels suivant les thèmes scientifiques (Figure 2) montre que ces logiciels sont moins présents dans le thème 4 que dans les autres thèmes et que la moitié d’entre eux sont produits par les unités de recherche de Rocquencourt et de Sophia. Il ne faut cependant pas tirer de conclusions trop hâtives de ces chiffres, car ces logiciels sont d’importance très inégale et ne représentent qu’une partie des logiciels développés par les projets de recherche.

L’institut recommande le dépôt à l’APP des logiciels qui sont commercialisés, distribués par l’institut ou utilisés par des tiers dans le cadre de contrats. Le nombre de dépôts reflète donc assez bien le niveau de production de ces logiciels dans chacune des unités de recherche et c’est ce nombre qui est retenu dans les indicateurs présentés chaque année par l’institut. Le chiffre de l’année 2002 est partiel et n’intègre pas nécessairement tous les dépôts effectués par les unités de recherche.


ANNEXE IV Lettre de mission confiée à Eric Gautrin

De G. Giraudon A : Eric Gautrin

Cher Eric,

La note sur l’organisation de développement logiciel à l’INRIA diffusée en septembre 200139 présente les lignes directrices du nouveau schéma d'organisation de l’INRIA concernant la problématique du développement de logiciels à l’institut.

Depuis la diffusion de cette note, les Unités de Recherche ont avancé sur la définition et parfois sur la mise en place d’entités dédiées au développement logiciel. Si les lignes directrices sont définies, il reste un grand nombre de questions ouvertes sur leur mise en œuvre locale et sur les éléments de méthodes pour l’émergence de plates-formes communes, sur l’identification et la promotion des métiers du développement et plus généralement sur le partage et l’échange d’informations afin que l’on puisse progresser collectivement et de la manière la plus efficace possible.

La direction du développement et des relations industrielles (DirDRI) qui s’est engagée à animer le réseau des services ou cellules de développement des Urs, a aujourd’hui à jouer un rôle particulier pour permettre cette réflexion collective.

Dans ce cadre et en accord avec Claude Labit, je vous confie une mission, de 6 mois, d'analyse et de conseil auprès de la DirDRI sur les dispositions qu'il conviendrait de prendre pour renforcer et mieux coordonner les actions de l'institut en matière de développement logiciel. La conclusion de cette mission se matérialisera par la fourniture d’un rapport. Vous travaillerez avec Bernard Martin, mon adjoint, sur les 3 axes suivants :

1. Les métiers de l’ingénierie de développement logiciel et les problèmes de formation associés,

2. Les domaines où la coordination doit être source d’une efficacité accrue (communication, formation, méthodologie, politique d’achat, ….) et l’organisation de cette coordination.

3. Les types de service correspondant aux attentes des équipes de recherche, éventuellement déclinés selon les problématiques scientifiques et technologiques de ces équipes.

Dans le cadre de cette mission, pour laquelle vous pourrez consacrer jusqu’à 20% de votre temps, vous serez amené à vous déplacer dans les Unités de Recherche et au Siège en particulier pour rencontrer la DRH sur les aspects métiers et formation. Vous prendrez contact également avec toute autre personne qui vous paraîtra utile de rencontrer pour recueillir avis et suggestions.

En vous remerciant pour votre aide, je vous adresse l'expression de mes sentiments très cordiaux,

Gérard Giraudon

Rocquencourt le 13 Février 2002

Copie : Comité de Direction,

39 http://dirdri.inria.fr/Interne/Developpement/developpement-INRIA.html

Documents

Contribution à la réflexion sur le développement logiciel