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

Contribution à la réflexion sur le développement logiciel à l INRIA Rapport et recommandations Eric GAUTRIN Bernard MARTIN Décembre 2002

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. INRIA 2002 2/40 DirDRI

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 INRIA 2002 3/40 DirDRI

1. Introduction Le plan stratégique 1999-2003 1, 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 2001 2 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 industrielles 3 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 à Paris 4 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 chercheurs 5. 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 INRIA 2002 4/38 DirDRI

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 logiciel 6 é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. INRIA 2002 5/38 DirDRI

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 recherche 7 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 INRIA 2002 6/38 DirDRI

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 physiciens 8 ou par les biologistes 9 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 INRIA 2002 7/38 DirDRI

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 projet 10. 2.1.4. Diffuser des résultats La diffusion de logiciels est largement utilisée à l INRIA, et le site Web national 11 (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 chercheurs 12 considèrent une diffusion d un bon logiciel plus importante pour la notoriété scientifique que la publication d articles. Dans certains domaines 13, 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 recherche 14 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 INRIA 2002 8/38 DirDRI

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 expertise 15. 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 APP 16, 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 INRIA 2002 9/38 DirDRI

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équents 17 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. INRIA 2002 10/38 DirDRI

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 INRIA 2002 11/38 DirDRI

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, INRIA 2002 12/38 DirDRI

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és 18, 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 formation 19, 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égale 20, 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, INRIA 2002 13/38 DirDRI

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 fonctions 21, 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 plateforme 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. INRIA 2002 14/37 DirDRI

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 missions 23 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. INRIA 2002 15/37 DirDRI

stagiaires. Le tableau suivant donne une photographie au 1 er 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 accueil 24 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,2 25 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 1 er 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 minimale 26. 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. INRIA 2002 16/37 DirDRI

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 INRIA 2002 17/37 DirDRI

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 : fontils 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 INRIA 2002 18/37 DirDRI

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 technologie 27. 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. INRIA 2002 19/37 DirDRI

é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 1 er é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 échelon 29. 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 Ingénieur de recherche INRIA 35,2 43,0 50,7 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é. INRIA 2002 20/37 DirDRI

la fonction publique que dans le privé. Les études du Syntec Informatique et de 01Net Informatique 30 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. INRIA 2002 21/37 DirDRI