La conduite

de l'innovation
Enjeux et bonnes pratiques en matière de R&D Logicielle
 Avant propos
Chers adhérents, Chers amis,

Ce Livre Blanc, 4e exercice du genre pour notre association, est consacré à

la Recherche et Développement des éditeurs de logiciels. Ce n’est donc
sûrement pas un hasard s’il est, plus que jamais auparavant, le fruit d’un travail
très collaboratif des membres de la Commission R&D de l’AFDEL, Commission
animée avec un volontarisme exemplaire par Daniel Cohen-Zardi, fondateur et
dirigeant de Softfluent. Je le remercie, ainsi que l’ensemble des contributeurs,
pour le temps et l’énergie consacrés à produire cette vision prospective du
cœur de notre métier.

Ce Livre Blanc ne constitue pas une quelconque position monolithique ou

officielle. Plus que le reflet des positions AFDEL sur la R&D logicielle, ce Livre
Patrick Bertrand Blanc est celui des contributeurs, éditeurs ou partenaires des éditeurs (voir
Président AFDEL page 86), qui ont bien voulu partager leur spécialité et leur vision de ce métier.
Il trace des perspectives, propose des solutions et peut-être même ouvre
certains débats…

Nos entreprises consacrent en moyenne 30% de leurs ressources à la R&D,

une moyenne bien au dessus des entreprises du Cac 40, y compris des plus
industrielles d’entre elles. Car être au cœur de l’innovation, c’est évidemment
développer constamment de nouveaux produits, mais c’est aussi s’adapter
sans cesse aux ruptures de modèles et d’environnement qui marquent
l’évolution de l’industrie IT.

Nos entreprises doivent ainsi faire preuve d’agilité et d’une formidable capacité
d’adaptation pour demeurer innovantes ! Il fallait faire le point sur les méthodes
et modèles qui peuvent permettre à nos entreprises de grandir mieux et plus
vite , en rationnalisant davantage la gouvernance de leur R&D. Sans oublier
bien sûr la dimension humaine et économique de ces processus coûteux et
risqués qu’implique le développement de logiciel.

Ainsi, s’il est évident que la forte verticalisation de notre industrie peut parfois
être un frein à l’externalisation de nos développements, le développement à
l’international et les réalités économiques actuelles constituent en revanche des
leviers pour le développement de l’offshore.

Il est important d'aborder ce sujet en professionnels et ce document donne

la parole à un contributeur dont le métier est justement d’aider ceux qui le
souhaitent franchir le pas de l’offshore.

Mais il nous faut également aborder ce sujet en citoyens responsables et

souhaiter ardemment que notre pays conserve les compétences qui font sa
réputation de par le monde, comme en témoignait l’octroi en 2008 du Prix
Turing à l’un de nos compatriotes, Joseph Sifakis.

3
 D’aucuns disent que notre pays est devenu un « paradis fiscal » pour la R&D,
territoire qui il est vrai accueille de grands centres de R&D mondiaux des ténors
de notre industrie. Mais la réalité est plus prosaïque pour nos entreprises :
l’activité de développement de logiciels n’est que marginalement éligible au
Crédit Impôt Recherche et la moitié des nos entreprises n’en bénéficient pas.
Son déplafonnement a créé pour certains davantage d’effets d’aubaine que
d’incitations.
L’industrie du logiciel fait donc « avec » ou plutôt « sans », a contrario d’une
industrie aéronautique et spatiale qui concentre par exemple 60% des aides
publiques et ne représente que 5% de l’effort de R&D des ETI !
Notre industrie, qui est très majoritairement une industrie de PME, finance donc
sa R&D majoritairement sur la base de ses fonds propres…
C’est pourquoi nous attendons beaucoup des initiatives portées par le Fonds
Stratégique d’Investissement (FSI), dont la mission à l’égard des PME vient de
se voir renforcée par le Grand Emprunt. Nous attendons aussi beaucoup de
l’effort également porté par le Grand Emprunt sur l’innovation et des grands
chantiers prioritaires identifiés par la Commission Rocard-Juppé. C’est en effet
en se spécialisant sur les grands vecteurs d’innovation de demain que notre
pays conservera, ou améliorera, son rang au sein des nations innovantes. Et
chacun de ce s chantiers comporte évidemment une dimension IT et logicielle…
Bonne lecture à tous !
Patrick Bertrand
Président AFDEL
4 5
Avant propos
Passionné par le développement logiciel et ayant toujours travaillé dans ce
domaine, je suis intimement convaincu que ce métier est à la fois intéressant,
complexe et gratifiant. Intéressant parce qu’il nécessite de faire marcher son
intelligence, et qu’on ne peut jamais totalement se reposer sur ses acquis, la
technologie évoluant sans cesse.
Complexe parce qu’il convient d’intégrer ces possibilités technologiques au
service d’un besoin, qui évolue souvent sur un rythme et des dimensions
Daniel Cohen-Zardi orthogonales à la technologie. Gratifiant parce qu’il n’est pas un simple
Président de la processus d’ingénierie linéaire, la créativité jouant un rôle fondamental dans
commission R&D la différenciation obtenue, que ce soit sur la manière de répondre au besoin
AFDEL fonctionnel ou dans l’ergonomie proposé aux utilisateurs, sans parler de
Président Softfluent l’imagination dont il faut parfois faire preuve pour trouver certaines solutions
techniques.
Au-delà de la seule écriture d’un programme informatique, exercer le métier
d’éditeur de logiciels, et en particulier orienter les travaux de recherche et
développement d’une société dont c’est le modèle économique, répond
parfaitement aux trois attributs mentionnés ci-dessus. Il ne peut pas être de
bon responsable de recherche et développement chez un éditeur de logiciel
aujourd’hui sans que celui-ci s’intéresse de près aux évolutions du métier de
son secteur et sans que celui-ci dispose de capacités créatives fortes pour
imaginer les solutions de demain.
De plus, l’évolution des technologies s’accélérant, il n’est plus possible
d’innover en mode fermé en espérant trouver toutes les recettes du succès
soi-même. Plus que jamais, il faut observer ce qui se fait ailleurs ou dans des
secteurs similaires, étudier toutes les possibilités de partenariat qui peuvent
étendre la couverture de l’offre, et finalement concentrer son effort sur ce
qui fera sa différentiation sur son marché. Dans ces conditions, quoi de plus
important que d’échanger avec ses pairs – et parfois concurrents – sur les
enjeux de l’exercice de ce métier.
Lorsque l’AFDEL m’a demandé de lancer la commission Recherche et
Développement début 2008, j’ai immédiatement accepté de relever le défi,
car quoi de plus naturel pour l’association professionnelle du secteur que de
créer une commission dédiée à l’un des enjeux principaux du métier, celui de
constituer l’offre !
Mais pour être honnête, j’avais une petite appréhension à l’idée que les
départements de recherche et développement se montrent prêts à partager
leurs pratiques et échanger sur des sujets où règne un historique de
protectionnisme assez fort. Tout dirigeant qui a déjà essayé de lancer un audit
externe sur son département de recherche et développement sait de quoi je
parle et combien les cultures doivent encore évoluer.
 Sommaire
Pourtant, dès le lancement de la commission, un nombre significatif de
membres s’est mobilisé et les échanges se sont avérés rapidement intenses et
très fructueux. Finalement, ceux qui sont venus avaient compris qu’ils avaient
plus à gagner à partager qu’à se refermer sur eux-mêmes et l’exercice s’est
déroulé de manière extrêmement naturelle et enthousiaste.

D’un point de vue personnel, je reste convaincu que le responsable de

Recherche et Développement brillant n’hésitera pas à montrer son savoir-faire
et à ouvrir (en partie au moins) les portes de son département, non seulement Introduction 9
par fierté mais parce qu’il aura à cœur d’enrichir son propre savoir-faire et
de faire progresser son organisation de tous les retours qu’il pourra obtenir. Mesure de la performance 13
De plus, l’interaction elle-même est souvent source d’idées et de nouvelles
approches pour résoudre les enjeux auquel chacun est confronté. Ressources Humaines 21
C’est de ces interactions qu’est né ce livre blanc, qui tente le difficile exercice
Technologies 29
de consolider dans quelques dizaines de pages le concentré de plusieurs Méthodologies 35
centaines d’années d’expérience cumulées des différents participants à la
commission. Qualité logicielle 43
Cette première version en appellera probablement une seconde, à la fois parce Off shore 55
qu’elle aurait mérité plus de temps (mais tous les contributeurs - voir page 86 - Open Source 67
ont aussi un vrai métier à temps plein !), parce qu’elle suscitera des interactions
porteuses d’enrichissements, mais aussi parce que notre environnement Place du client dans la R&D 73
continue d’évoluer, et qu’il convient de s’adapter chaque jour à ces mutations.
Financement de l’innovation 79
En nourrissant l’espoir que ce livre blanc suscitera également des vocations
vers ce métier aux multiples facettes, je vous souhaite une excellente lecture.
Conclusion 83
Remerciements 86
Eléments de bibliographie 87
AFDEL 88
Daniel Cohen-Zardi
Président de la commission R&D AFDEL
SoftFluent 88
Président Softfluent

6 7
Introduction
 L’Association Française des Editeurs de Logiciels a été créée en 2005 afin de
fédérer les éditeurs de logiciels autour de leur métier et de mieux faire connaître
leurs enjeux. Le métier d’éditeur de logiciels est un métier vaste et complexe,
qui nécessite de réunir des compétences pluridisciplinaires, en matière de
technologie, de commerce, de marketing et comme toute entreprise, de
gestion.

Le métier d’éditeur de logiciels se distingue des métiers de services informatiques

par une composante fondamentale, l’investissement. En particulier, éditer un
logiciel, c’est prendre le pari de construire, avant même de l’avoir vendue, une
solution qui sera compétitive au moment de sa mise sur le marché et qui pourra
être rentabilisée par le nombre de clients qui l’achèteront.

De fait, gérer correctement l’effort de recherche et développement, aussi

bien dans sa composante de coût que de valeur, est le nerf de la guerre du
métier d’éditeur de logiciels. On comprend alors aisément qu’il ne s’agit pas
simplement d’apporter une réponse technique à un instant t à un besoin
identifié et bordé, mais également à anticiper l’avenir, voire à le dessiner.

Pour cette raison, la dimension de « Recherche et Développement » chez un

éditeur de logiciels doit procéder d’une réelle gestion de l’innovation. Cette
gestion comporte de nombreux enjeux, avec bien évidemment la maîtrise de
la technologie et de ses changements rapides, mais également la capacité à
connecter cette technologie aux besoins du marché, en privilégiant les axes qui
créent une valeur maximale, pour un coût maîtrisable.

Dans un contexte de plus en plus mondialisé, la lutte pour disposer des meilleures
compétences constitue l’un des leviers majeurs, mettant la problématique des
ressources humaines au cœur des enjeux des départements de Recherche et
Développement.

Rédigé sur la base de deux ans de réunions de la commission R&D de l’AFDEL,

créée début 2008, ce livre blanc a pour objectif de donner une première vue
synthétique du métier de la R&D logicielle et de ses différentes dimensions. Le
lecteur y trouvera les bonnes pratiques partagées par les experts du domaine
et l’ensemble des acteurs de la profession du marché.

10 11
Partie 1 :
Mesure de la
performance
 1. Mesure de la performance
Pour illustrer la richesse et la complexité d’un département de « Recherche et
Développement », commençons par poser l’une des problématiques clé : la
mesure de la performance.
Il est assez facile de mesurer globalement la performance d’une entreprise,
voire de comparer certains départements de vente ou de gestion financière, à
l’aide de ratios du métier, à commencer par certains ratios financiers.
Dans le cas du département de « Recherche et Développement », cet exercice
est plus difficile, car s’il est aisé de mesurer les coûts, il est plus complexe de
mesurer la valeur produite.
Au final, la valeur qui compte est celle qui sera transformée commercialement,
mais cette transformation dépend de facteurs totalement en dehors de la
maîtrise du département de R&D, et mesurer la performance intrinsèque de ce
département n’est pas une mince affaire.
Pour résumer, un département de Recherche et Développement est performant
s’il est :
1. Aligné sur les attentes de son marché de façon à réaliser des produits
vendables,
2. Productif dans la quantité de ce qu’il réalise par rapport à l’effort consenti,
3. Prévisible pour livrer ses solutions au marché selon un calendrier
maîtrisable,
4. Performant dans la qualité de ce qui est réalisé et mis sur le marché.
A. Evaluation de l’alignement
Le bon alignement de ce qui est produit sur les attentes est sans aucun doute
l’un des facteurs fondamentaux de performance d’une R&D.
14
Sur le schéma théorique qui précède, l’équipe de R&D numéro 3, même si
elle produit moins en quantité (longueur de la flèche), produira plus de valeur
pour l’entreprise car elle est plus alignée sur les besoins du marché (longueur
projetée sur l’axe de valeur).
L’alignement est probablement l’élément le plus difficile à mesurer, car il n’est
pas toujours facile de mesurer l’effort improductif. Pourtant il est fréquent de
constater des axes de travail des équipes techniques, où l’on s’aperçoit que
le coût est démesuré en regard de la valeur monétisable, sans compter le
développement d’éléments techniques dont la valeur est parfois discutable.
Cet élément est aussi potentiellement controversé. En effet, certains
responsables R&D ont encore aujourd’hui tendance à ne pas prendre de rôle
de responsabilité vis-à-vis de cet alignement, en se positionnant en tant que
ressource de développement au service de l’équipe marketing ou commerciale,
qui fournit les spécifications de ce qui est à réaliser.
Si une telle position peut se comprendre, voire se justifier sur certains types de
métier, elle a au minimum deux conséquences :
• Positionner l’équipe de R&D en seule attente de spécifications de la
part d’une autre équipe de l’éditeur ne permet pas de tirer parti des
compétences de la R&D pour concevoir l’application et effectuer des
arbitrages cruciaux. C’est en général l’équipe d’ingénieurs qui peut se
rendre compte de la difficulté de réalisation de telle ou telle fonctionnalité,
et d’imaginer les solutions qui présentent le meilleur rapport valeur/
coût. Avec un tel positionnement, l’équipe de R&D ne prendra pas plus
de valeur qu’une équipe de développement d’une société de services
potentiellement délocalisable.
• Innover dans les solutions logicielles procède souvent d’un subtil mariage
entre la bonne compréhension technique de ce que la technologie
permet et une connaissance pointue d’un marché ou d’un besoin. Seul
un processus collaboratif fort et imbriqué permet de faire émerger de
nouvelles solutions différenciatrices, alors qu’un processus descendant
permettra essentiellement de réaliser des applications bordées à faible
niveau d’innovation.
Pour certains types de logiciels ou de progiciels, pour lesquels l’innovation est
modérée et le périmètre fonctionnel relativement direct et nécessitant surtout
le travail détaillé d’un expert métier, l’approche classique et historique de
séparation peut fonctionner et ces deux points ne sont pas forcément gênants.
Notre conviction est cependant que les innovations qui permettent de
bousculer un marché et de créer de la différenciation proviennent d’un modèle
où le processus de conception des produits est collaboratif entre les équipes
de R&D et la direction produit. Ce processus prend des formes diverses suivant
la taille de l’éditeur, en particulier l’existence ou non de postes de direction
produit dédiés.
L’industrie logicielle voit d’ailleurs se développer les méthodes agiles, dont l’un
des piliers repose sur la mise en place d’un processus fortement collaboratif
15
 entre l’équipe de développement est la direction produit. Nous y reviendrons Le deuxième indicateur suivi est la vélocité, qui mesure le nombre de points
dans la partie méthodologie. réalisés par itération, conformément à l’exemple ci-dessous.

Vu d’une direction générale, l’alignement peut s’évaluer par une analyse des Vélocité
(nombre de points réalisés par itération)
rapports entre les différents départements de la société. Une analyse externe
11
peut par exemple permettre d’évaluer les pratiques de l’éditeur par rapport à 10
9
ce qui peut être fait ailleurs. 8
7

Points
6
5
4

B. Productivité 3
2
1
0
1 2 3 4 5
En supposant que l’on développe les produits adaptés au marché que l’on Itérations

vise, comment savoir si l’équipe de développement produit le code à la bonne

vitesse ? Chaque développement étant par nature unique, il est toujours difficile
d’établir des comparaisons. La littérature abonde en ce sens, avec notamment
le célèbre ouvrage « The mythical man-month » (le mythe du mois-homme), et
la solution universelle et absolue n’existe pas réellement.
Néanmoins, il est possible de mesurer la dynamique de productivité et de
piloter son suivi. Dans les méthodes traditionnelles, les logiciels à développer
sont spécifiés de manière assez détaillée. Mustapha Derras, de Berger/Levrault
a réalisé un travail important de synthèse des différents modèles comme les
méthodes des points de fonction ou le modèle Cocomo, en rassemblant
notamment bon nombre des liens que nous proposons également en annexe
de ce livre blanc.
Dans les deux cas, ces indicateurs n’ont pas de valeur « absolue », qui
permettrait une comparaison d’un éditeur à un autre, puisque les points sont
évalués par l’équipe de développement en accord avec le produit.
Cependant, cela permet une évaluation relative dans un contexte donné et de
suivre l’évolution de l’équipe dans le temps.
Une intervention externe à un instant t peut permettre au besoin de comparer
avec d’autres vécus client, quitte à recroiser les chiffres avec d’autres métriques
classiques (nombre de lignes de code, nombre de points de fonction, nombre
de tables de base de données) et donc de positionner l’échelle d’évaluation de
la société.

Mais indéniablement, une tendance aux méthodes agiles semble se développer

ces dernières années, et, dans le cadre de la commission, la société Valtech C. Prévisibilité
est venue présenter sa manière les mettre en œuvre ainsi que les indicateurs
de suivis associés. En introduction à ce paragraphe, illustrons l’enjeu de prédictibilité par quelques
chiffres intéressants partagés par Matthieu Hug de RunMyProcess : 58% des
L’équipe évalue la complexité des développements en « points » avec une logiciels achetés ne sont jamais mis en production, seulement 13% des projets
échelle de complexité allant de 1 à 7 et dont la valeur en points est basée sur informatiques sont livrés dans les délais et 30% des projets sont arrêtés.
une suite de Fibonacci obtenue en additionnant les éléments précédents (1, 2,
3, 5, 8, 13, 21, 34). C’est dire s’il est loin d’être négligeable d’arriver à une situation de maîtrise qui
permette de prévoir et de piloter.
Les fonctionnalités sont définies et ajustée par itération (« product backlog »)
et évaluées selon ce système de points. On mesure alors la productivité en Selon la méthode évoquée ci-dessus, Valtech intègre des indicateurs de
nombre de jour-homme pour réaliser un point. prédictibilité de l’équipe, en évaluant le pourcentage réalisé de chaque itération
par rapport à ce qui est prévu en début d’itération.
Productivité
(nombre de jours pour réaliser 1 point) Prédictibilité
(périmètre réalisé / périmètre prévu)
16
90%
14
80%
12
70%
Jour-homme

10 60%

8 50%

6 40%
30%
4
20%
2
10%
0
0%
1 2 3 4 5
1 2 3 4 5
Itérations
Itérations

16 17
 Au-delà de la vision itérative de la méthode proposée par Valtech, la capacité à • Nombre de développeurs / testeur
livrer des versions dans des calendriers maîtrisés est un élément important de • Nombre de développeurs / responsable de produit
la performance d’une R&D. • Répartition des ratios pilotage / conception / développement / test
• Taux de jours-hommes « productifs » (par rapport à des tâches «non
Il est fréquent, notamment lors de ruptures technologiques, de trouver des planifiées » telles que définies chez certains éditeurs)
équipes qui perdent la maîtrise du calendrier et des projets de R&D peuvent
prendre plusieurs mois voire des années de retard, avec des budgets qui Lorsque l’on audite une application ou un produit, il est toujours intéressant de
gonflent dans les mêmes proportions. regarder ces éléments pour avoir une idée de la volumétrie de celle-ci, et de
la mettre en regard de l’équipe qui l’a développée et de celle qui la maintient.
Il est donc indispensable de disposer de jalons réguliers comprenant des
livraisons de versions et des mises à jour de fonctionnalité afin d’éviter l’effet
tunnel de certains grands projets qui peuvent créer un énorme « trou » dans
les éléments « produits » par le département de R&D. Plusieurs des éditeurs de
la commission ont eu l’occasion d’être confrontés à des projets de ce type, la
perte de contrôle se traduisant par des dérapages financiers colossaux.

D. Qualité
La qualité des développements réalisés par l’équipe de R&D est bien
évidemment également un critère d’évaluation fondamental de la performance
du département.

En particulier pour les logiciels diffusés massivement, le coût de la non-qualité

peut exploser et aller jusqu’à tuer l’éditeur.

Ce point est tellement crucial qu’il fait l’objet d’un thème à part entière que nous
développons plus loin.

Notons en synthèse au niveau de ce thème que la qualité de ce qui est produit

et qui sera perçue par le client recouvre :

• Le taux de bogues constatés,

• La performance de l’application en conditions d’exploitation,
• La capacité de montée en charge lorsque le métier l’exige,
• La bonne exploitabilité de la solution,
• L’ergonomie et la facilité d’utilisation.

E. Exemples d’indicateurs de performance

Même si ces indicateurs doivent être interprétés avec une certaine prudence
en fonction du contexte de chaque éditeur, les indicateurs suivants peuvent
constituer des éléments à regarder :

• Nombre de lignes de code / mois

• Nombre de points de fonctions / mois
• Charge de maintenance / nombre de lignes de code
• Nombre de bogues ouvertes / nombre de lignes de code
• Délai et charge de correction d’une bogue
18 19
 R V E
E S E N T
R E R E
A D H

Association Française Des Editeurs de Logiciels

11-17 rue de l'Amiral Hamelin
75016 Paris
Tel : 01 49 53 05 89 - Fax : 01 45 62 01 12
info@afdel.fr - www.afdel.fr