dossier :
Conduite de projet
Rentabilité des projets informatiques
Catherine Leloup
Ingénieur Conseil
On observe depuis quelques années,
une volonté de mieux maîtriser la ren-
tabilité des projets,tant lors de la déci-
sion d’investissement que pendant la
conduite du projet ou à l’issue de sa
réalisation, puisqu’en 2005, 60 % des
entreprises effectuent une étude de
rentabilité en préalable au lancement
d’un projet, … même si seulement
25 % d’entre elles évaluent la rentabi-
lité obtenue à l’issue de la réalisation
du projet.
Ce qui semble révéler une maturité
plus grande et une réelle volonté de
comprendre l’impact de l’informa-
tique sur la performance de l’entre-
prise et la valorisation des investisse-
• La revue n° 80 - Septembre 2005
ments effectués. La variété sans
cesse croissante des applications
informatiques est sans doute un
point positif pour développer ces
pratiques. En effet, les projets visant
l’aide à la décision, l’échange ou le
partage d’informations, la capitalisa-
tion de savoir ou de savoir-faire sont,
par rapport aux projets plus tradi-
tionnels d’automatisation, plus inti-
mement liés au fonctionnement de
l’entreprise ainsi qu’aux moyens mis
en œuvre pour réaliser la stratégie
de l’entreprise. Et comme dans
4
beaucoup de domaines, plus on
pratique l’analyse de rentabilité,
mieux on la maîtrise.
1. Nature de la rentabilité
Analyser la rentabilité, c’est avant
tout rapporter des dépenses à des
gains et ce sous la forme la plus
naturelle possible, c’est-à-dire en
termes de flux de trésorerie nette,
donc d’impact sur le compte d’ex-
ploitation de l’entreprise.
Le terme projet concerne toute évolu-
tion du système d’information requé-
rant une décision d’investissement
informatique. Y compris en interne à
une DSI. Il peut s’agir aussi bien :
• d’une application nouvelle quelle
qu’en soit la nature : gestion de
connaissances, workflow, applica-
tion métier, application interne à
la DSI comme la gestion d’un
centre d’appels, etc. ;
• de la rationalisation d’un exis-
tant : migration de plate-forme
matérielle ou logicielle, refonte
logicielle, mutualisation de res-
sources logicielles ou applica-
tives , etc. ;
• de projets internes DSI mais
structurants pour l’entreprise :
gestion d’annuaire par exemple,
gestion centralisée des habilita-
tions, etc. ;
• de projets « partenaires » : extra-
net, EDI, etc.
La rentabilité s’évalue en comparant
des situations possibles futures et en
les analysant au niveau des coûts
générés et des bénéfices escomptés.
Le calcul des coûts n’est pas indé-
pendant de l’infrastructure informa-
tique existante – par exemple, selon
qu’il faut acquérir des matériels et
logiciels ou qu’il suffit d’obtenir une
extension de licences logicielles – ni
des applications opérationnelles –
en particulier lorsqu’il s’agit de les
intégrer ou de les interfacer avec le
futur système. Au niveau des béné-
fices attendus également, l’environ-
nement de l’entreprise joue :
méthodes de travail, motivation des
personnels, gestion du changement,
évolution requise des compétences
notamment. Deux projets iden-
tiques n’auront pas le même impact
dans deux entreprises distinctes.
2. La démarche d’analyse
de rentabilité
2.1. Les objectifs
Les objectifs de l’analyse de la rentabi-
lité d’un projet visent à comparer les
coûts supportés et les avantages
apportés. Il y a toujours deux alterna-
tives possibles au moins : faire le projet
ou non. Néanmoins, dans l’option de
réaliser le projet, il y a souvent de mul-
tiples alternatives reposant sur des
scenarii de solutions ou de mise en
œuvre, qui doivent toutes être étu-
diées de façon à permettre le choix de
la meilleure solution possible. C’est
donc en comparant des situations
futures entre elles que l’on peut
mesurer la rentabilité attendue, voire
comparer éventuellement les projets
entre eux. En outre, l’étude de rentabi-
lité permet de définir une feuille de
route du projet (délais, conditions,
risques, etc.) et donc de piloter sa réa-
lisation en toute connaissance de
cause.
2.2. Le périmètre concerné
Il résulte des multiples dimensions
d’un projet ou d’un système exis-
tant, comme indiqué ci-après :
(voir figure 1)

Niveau de maturité
Évolution
Processus
Projet /
Système informatique
Compétences
Valorisation
Conduite du changement
Figure 1 – Les dimensions d’un projet ou système informatique.
En effet, la rentabilité d’un projet
dépend très largement de son
contexte d’utilisation, dans la mesure
où les bénéfices apportés se situent
le plus souvent hors du périmètre de
la DSI. Par exemple, mettre en place
un intranet d’entreprise n’a poten-
tiellement aucun gain possible au
niveau de la DSI, sauf pour la part
marginale relative à ses propres
employés, en tant que personnel de
l’entreprise.
Évaluer la rentabilité passe donc au
préalable par la définition des évolu-
tions de chacune des dimensions, en
particulier :
• Processus : la dématérialisation
d’informations induit des boule-
versements des processus exis-
tants. Ainsi, la dématérialisation
des titres a totalement modifié
le travail des back-offices ban-
caires, tout comme plus récem-
ment le traitement de l’image
chèque électronique. La mise en
œuvre d’un annuaire centralisé
va rejaillir de manière significative
sur les processus de gestion des
utilisateurs et des autorisations
d’accès par une DSI.
• Environnement existant : selon
l’ouverture du système d’informa-
tion et des applications existantes
et les besoins d’interface ou d’in-
Conduite de projet dossier
Intégration
Développements
Environnement
informatique
existant
Organisation :
– Ressources
– Activités
Efficacité
Réactivité
tégration avec un nouveau projet
informatique, l’impact sur l’exis-
tant peut être quasi-nul – lorsqu’il
s’agit d’une simple juxtaposition
d’application – ou au contraire
très profond et aller jusqu’à la sup-
pression de toute ou partie d’ap-
plications existantes. Ainsi, la mise
en œuvre d’un CRM – Gestion de
la relation client – rend souvent
caduques des applications pré-
existantes comme la gestion des
portefeuilles commerciaux ou des
réclamations clientèle.
• Compétences : la mise en œuvre
d’un projet s’accompagne sou-
vent d’un accroissement des
compétences, facteur clé de la
rentabilité. Ainsi, lors de la mise
en œuvre d’une gestion de cata-
logue de produits industriels, les
rédacteurs qui préalablement
raisonnaient « forme du docu-
ment final » vont devoir réfléchir
en termes de gestion de contenu ;
ainsi, au lieu d’écrire « 12 A » en
gras, car c’est une caractéristique
technique, ils devront penser
« insérer une caractéristique
technique, de type ampérage »
puisque l’application se chargera
d’importer la bonne donnée au
moment de la publication du
catalogue en lui appliquant la
forme définie par la charte gra-
phique, fonction du média de
communication – papier, inter-
net, wap, etc.
• Organisation : sauf en cas d’au-
tomatisation pure, il est rare
que l’organisation en place
avant le projet perdure en l’état.
Lorsqu’il s’agit de nouvelles
technologies, en tirer la quintes-
sence – et donc la rentabilité –
suppose de revoir les méthodes
de travail et les ressources. Ne
serait-ce que parce que cer-
taines tâches disparaissent,
d’autres évoluent, d’autres
encore sont ajoutées. L’exemple
de la gestion électronique de
documents est assez flagrant :
les charges de recherche d’in-
formation sont réduites à zéro
ou à peu près, alors que celles
d’entrée des documents –
numérisation, indexation – sont
sensiblement alourdies et la
rentabilité est alors directement
fonction du taux d’utilisation
des documents concernés.
Il faut donc avoir défini, au moins à
grande maille, comment le système
va fonctionner avant de réaliser
l’étude de rentabilité. C’est en tout
état de cause le rôle de l’étude préa-
lable qui détermine les enjeux, les
risques, les points forts et faibles du
projet. C’est aussi à ce moment-là
qu’il faut étudier la rentabilité du
projet.
2.3. Les principes de l’étude
de rentabilité
Ce sont les suivants :
• définir les alternatives possibles,
• calculer les coûts complets,
• définir et argumenter les hypo-
• La revue n° 80 - Septembre 2005
thèses de gains,
• estimer les gains,
• utiliser des méthodes éprou-
vées de calcul de rentabilité,
• évaluer la sensibilité de la renta-
bilité aux hypothèses de gains,
• évaluer les risques,
• optimiser la rentabilité,
• mesurer la rentabilité effective.
L’étude de rentabilité compare tou-
jours des situations futures définies
selon les composantes du projet. De
5
 dossier :Conduite de projet
ce fait, la transparence est de mise
en ce qui concerne les hypothèses
de gains ; celles-ci doivent être
étayées par des éléments factuels –
des chiffres – dont la collecte est
souvent relativement lourde. Mais,
c’est à ce prix, que l’étude peut être
crédible.
2.3.1. Analyse des coûts
Le principe général est de raisonner
en coût complet. Il faut donc
prendre en compte l’ensemble des
coûts afférents au projet, en distin-
guant investissement, fonctionne-
ment, amortissements. Ces coûts
comprennent :
• les coûts non récurrents : les
matériels, logiciels, prestations
de toutes natures et les charges
internes valorisées – salaires et
charges – tant pour les coûts
informatiques – formation, déve-
loppement, tests, gestion de pro-
jet, etc. – que ceux supportés par
la maîtrise d’ouvrage – gestion
de projet, formation, accompa-
gnement des utilisateurs, reprise
d’existant éventuelle, etc. ;
• les coûts récurrents de fonction-
nement : administration, exploi-
tation, maintenance, support et
accompagnement.
Il convient de préciser aussi les
sources des données : contrôle de
gestion, DSI, maîtrise d’ouvrage. Tous
ces coûts doivent aussi pouvoir être
expliqués et justifiés. Les travers clas-
siques en la matière sont :
• la sous-estimation des charges
de travail des maîtrises d’ouvrage
pour les aspects relatifs aux évo-
lutions des processus, au
déploiement, aux formations et
• La revue n° 80 - Septembre 2005
à l’accompagnement des utilisa-
teurs,
• de manière générale, une sous-
estimation fréquente des
charges internes à l’entreprise,
• la non-prise en compte des aléas
– techniques ou technologiques
en particulier – par les maîtrises
d’œuvre,
• des calendriers de réalisation
des projets souvent trop serrés,
qui minimisent notamment tous
les coûts de fonctionnement et
6
lissent les coûts d’investisse-
ments.
Les projets informatiques ont pour
particularité de demander en géné-
ral un investissement massif en
début de projet, et une pratique
répandue, mais fort contestable, est
trop souvent de vouloir les étaler
dans le temps, ce qui ne se fait qu’au
détriment des gains.
2.3.2. Sources de gains et valeur
Globalement les sources de gains
sont de trois natures :
• Action sur les processus : l’optimi-
sation des processus se traduit
par des gains de productivité ou
d’efficacité. Ces gains sont en
grande majorité des gains de
personnel. Certes, pour beau-
coup de dirigeants, il y a loin de
l’évaluation des gains à leur réa-
lisation effective. Mais c’est bien
l’enjeu de la conduite de projet
que de garder constamment à
l’esprit les conditions de réalisa-
tion effective de ces gains. Si sur
un processus donné, on réduit
les charges de travail de 20 %, il
est indispensable de revoir la
répartition des tâches des diffé-
rents intervenants, les circuits
d’information, les responsabili-
tés de chacun pour que le pro-
cessus soit réellement optimisé.
Les critères d’optimisation sont
toujours un peu les mêmes :
paralléliser les tâches, éviter les
goulets d’étranglement, respon-
sabiliser les personnels, accroître
les niveaux de compétence,
rendre les processus transpa-
rents et communiquer. Il est vrai
que la sous-estimation de ces
travaux, souvent du fait des maî-
trises d’ouvrage, ont par le passé
conduit à trop rarement réaliser
ces gains.
• Action sur les coûts : c’est le plus
souvent la réduction des coûts –
d’achats, de production d’infor-
mations, de support aux clients,
etc. – qui sont dûs au projet ou à
l’application. Ces gains sont
notamment visibles dans tous
les projets de rationalisation
d’un existant informatique.
Ainsi, la mise en place d’un
annuaire centralisé, la migration
d’une application obsolète vers
un nouvel environnement, la
mutualisation d’outils, par
exemple, sont générateurs de
gains significatifs en exploita-
tion et maintenance.
• Action sur la valeur : il s’agit des
actions sur la valeur de l’entre-
prise, selon trois axes : augmen-
tation du chiffre d’affaires, aug-
mentation de la valeur ajoutée,
augmentation de la valeur bour-
sière. Ainsi, la mise en place
d’une base de connaissances
dans un département de R&D
doit logiquement apporter des
gains sur l’innovation – traduite
en dépôt de brevets par
exemple.
Les difficultés de calcul des gains
sont multiples. Trois points méritent
une vigilance particulière :
• L’expression des gains selon des
indicateurs fiables. Puisqu’on
compare des situations futures, il
convient de disposer d’une base
d’indicateurs reconnus : par
exemple, la charge de travail
pour effectuer telle ou telle
tâche ou le coût unitaire de telle
opération. Ces indicateurs
dépendent du projet étudié,
mais aussi de l’entreprise. Ainsi,
les délais de réponse à une
demande client n’ont pas les
mêmes enjeux pour une banque
que pour une compagnie d’as-
sistance internationale, qui gère
le plus souvent des situations de
crise. La difficulté consiste avant
tout à rapprocher ces indica-
teurs des critères de performance
de l’entreprise et à démontrer le
lien entre système informatique
et évolution de ces indicateurs.
• Le périmètre à prendre en
compte : il faut se garder de
comptabiliser les mêmes gains
sous plusieurs formes. Ainsi
l’évolution de la productivité du
personnel commercial peut se
traduire soit en gain de produc-
tivité soit en augmentation des
ventes – le temps ainsi gagné
étant réutilisé pour vendre
davantage. Il est toujours préfé-
rable de présenter les gains sous
la forme d’accroissement de
valeur plutôt que de gains de
productivité, même s’il ne faut
pas oublier de préciser les condi-

tions effectives de réalisation de
ces gains.
• Les hypothèses utilisées et leur
sensibilité : lorsqu’on effectue les
études de rentabilité, il faut s’ef-
forcer de chiffrer les « mieux »,
« plus vite », « plus fiable »,
« meilleure qualité ». Ainsi, si par
exemple, on souhaite réduire un
taux de réclamation, il faut pro-
bablement effectuer le calcul de
rentabilité en faisant varier ce
taux (de – 5 % à – 20 % par
exemple). Cet exercice est riche
d’enseignement, car il permet
de mieux comprendre sur quoi
repose la rentabilité. C’est aussi
une façon de présenter le projet
ou le système avec des objectifs
simples : « le projet est rentable
à 2 ans si le taux de réclamation
baisse de10 % », les 10 % deve-
nant alors l’objectif clé du projet.
2.3.3. Les risques
Tout projet informatique comporte
des risques informatiques bien sûr –
techniques et technologiques – mais
aussi relatifs à la mise en œuvre :
délai, refonte des processus, appro-
priation des outils par les utilisa-
teurs, évolution des postes et des
méthodes de travail. Il est fréquent
que les gains les plus importants
soient aussi ceux entachés d’un
maximum de risques. Ainsi, si on
décide par exemple de dématériali-
ser les échanges avec les clients –
dans une application de CRM – il est
indispensable que les utilisateurs
accordent pleine confiance aux
informations gérées dans le nou-
veau système. Si les pratiques ini-
tiales étaient de renseigner peu d’in-
formations dans le système d’infor-
mation et de conserver des dossiers
« personnels » sur support papier, le
risque du non-partage d’informa-
tions est réel. Au-delà de ce risque,
c’est le principe même de la mise en
commun des informations clients
par l’ensemble du personnel appelé
à communiquer avec lui qui est
remis en question. L’analyse des
risques éclaire bien souvent les
conditions effectives de réalisation
des gains et à ce titre, fait partie inté-
grante de l’étude de rentabilité.
Conduite de projet dossier
2.3.4. Calculs de rentabilité
Tous les calculs de rentabilité sont
fondés sur l’évolution du compte
d’exploitation de l’entreprise et
donc sur les flux nets de trésorerie,
c’est-à-dire, la différence entre les
gains et les coûts, majorés des inves-
tissements, le tout étant minoré des
impôts et taxes. De multiples indica-
teurs existent, qui résultent d’ap-
proches différentes :
• Le délai de recouvrement – pay-
back period – est le délai au-delà
duquel les gains dépassent les
coûts, c’est-à-dire que le flux net
de trésorerie est nul. C’est le
meilleur indicateur pour les pro-
jets informatiques, qui trop sou-
vent dérapent en délais et coûts.
• La valeur nette actualisée (VAN) :
c’est sur une période donnée, le
cumul des flux nets actualisé en
tenant compte d’un taux de l’ar-
gent. Ce chiffre indique la valeur
du système mis en place à l’hori-
zon donné. Une VAN négative
est la démonstration d’un projet
non rentable.
• Le taux interne de rentabilité :
c’est le taux qui rend nul la VAN,
soit le taux maximum auquel il
est possible d’emprunter pour
que le projet soit rentable. Ce
taux est très souvent très élevé
dans les projets informatiques,
mais pas très significatif, les
investissements s’effectuant
massivement au démarrage du
projet.
Toutefois, la rentabilité ne s’exprime
pas uniquement par un chiffre. Elle
traduit aussi les conditions de réali-
sation effective des gains, surtout
lorsqu’il s’agit de gains de personnel
– qui comptent souvent pour près
de 50 % des gains apportés par les
technologies –, conditions qui relè-
vent du management de l’entreprise
et pas des technologies en tant que
telles.
2.3.5. Optimisation de la rentabilité
Lors de l’étude de rentabilité – qui
s’effectue, pour les projets, au
moment de l’étude préalable – il est
fréquent que l’organisation même
du projet fournisse selon les
variantes possibles, des niveaux de
rentabilité différents. Par exemple, si
le projet suppose des gains en
matière d’accès à l’information et
qu’une reprise d’existant est néces-
saire, il est souhaitable que le sous-
projet de reprise d’existant soit initié
dès le démarrage du projet, afin que
lors du déploiement, ces gains puis-
sent effectivement être réalisés ; en
effet, si la reprise de l’existant est
effectuée après le déploiement des
outils, ces gains ne se feront que plus
tard, grevant ainsi la rentabilité du
projet. En matière de processus, dès
lors qu’une évolution est requise, la
stratégie du « big bang » est souvent
la plus rentable, surtout lorsqu’elle
exploite au mieux les apports des
technologies ; toutefois, ceci doit
être nuancé en fonction des change-
ments induits, notamment au niveau
des compétences et des transferts
de tâches. Ainsi, la lecture automa-
tique de formulaires sur support
papier dans une administration, si
elle apporte des gains évidents en
matière de saisie de données, a
comme impact de changer radicale-
ment le métier des personnels du
Service Courrier, lequel devient pro-
ducteur d’information et non plus
routeur de documents. Ce qui ne se
fait pas en un jour…
Optimiser la rentabilité, c’est donc
trouver le meilleur compromis pos-
sible entre un maximum de gains et
un minimum de risques. En pratique,
ces deux objectifs sont contradic-
toires. Néanmoins, l’optimisation de
la rentabilité doit être la préoccupa-
tion des responsables de projet, tant
au niveau de l’étude de rentabilité
qu’au niveau du pilotage du projet.
• La revue n° 80 - Septembre 2005
2.3.6. Mesurer la rentabilité effective
Une fois le projet déployé, la mesure
de la rentabilité effective, après une
courte période de quelques mois
pendant lesquels les ajustements
peuvent être possibles, est indispen-
sable. Elle est souvent riche d’ensei-
gnements, ne serait ce que pour
chiffrer des éléments difficiles à esti-
mer avant le projet ou pour mettre
en évidence des indicateurs de per-
formance additionnelle. Ainsi, il est
des éléments difficiles à mesurer, ce
7
 dossier :Conduite de projet
qu’on appelle dans la littérature les
gains « intangibles » : impact des
délais de réponse aux clients sur leur
fidélité, impact d’une fourniture d’in-
formations fiabilisée sur la prise de
décision, etc.
3. En conclusion
La littérature regorge de chiffres
alarmants montrant que 50 à 80 %
des projets d’introduction de nou-
velles technologies (E-business,
CRM, GED, KM, entre autres) sont des
échecs. Mais les motifs sont toujours
les mêmes :
• défaut d’alignement straté-
gique,
• trop faible implication du mana-
gement,
• ignorance des évolutions néces-
saires des processus,
• insuffisance d’accompagne-
ment du changement,
• absence d’indicateurs de perfor-
mance pertinents et de leur suivi.
L’informatique, c’est un peu comme
l’industrie cinématographique. Un
film a très gros budget peut parfai-
tement aboutir au pire navet. Cela
ne dépend pas du budget, mais
aussi et surtout de l’alchimie entre le
scénariste, le réalisateur et ses
équipes, et les acteurs.
Bibliographie
AFAI – Rentabilité des projets informa-
tiques : méthode, outils, cas pratiques.
Paris, 2004. Collection Pratiques
Professionnelles
Ghenassia Bruno, Fustec Alan : Votre
informatique est-elle rentable ? Paris,
Édition d’Organisation, 2004.
Peaucelle Jean-Louis. Informatique
rentable et mesure des gains. – Paris,
Hermès. 1997.

LES OUVRAGES PARUS

■ La rentabilité des projets informatiques

L’étude de la rentabilité des projets informatiques, c’est un piège : « si on ne le fait pas, on vous le reproche ; et si on le fait,
personne n’y croit. » Voilà le décor planté. Pourtant, cela n’est pas si difficile. Pour une direction générale ou un DSI, le pilotage
des projets par leur retour sur investissement devrait être la règle. Force est de constater que ce n’est que trop rarement le cas,
au mépris des saines règles de l’IT Governance.
Réhabiliter de saines pratiques en matière d’analyse de rentabilité, détailler une méthodologie, fournir des points de repère, illus-
trer la démarche par des cas concrets, et surtout mettre en filigrane de tout projet les critères de sa rentabilité pour établir des
jalons, mesurer les points de contrôle, et décider au cours de la vie du projet, s’il passe l’examen de la décision, de continuer, de
réorienter ou d’arrêter le projet sont les objectifs de cet ouvrage. Ambitieux, probablement, mais utile sans doute.

■ Le livre blanc sur l’enquête ERP

À l’occasion du séminaire du 18 janvier 2005, l’AFAI publiera un livre blanc qui résulte de l’enquête menée par ASK Conseil sur
les bonnes pratiques observées en matière de mise en place d’ERP. Cette enquête a permis de mettre en évidence des typo-
logies de comportement entre Groupes d’origine diverses (USA, UK, RFA, FR) sur deux grands ERP du marché, SAP et ORACLE.
Les auteurs en ont dégagé une voie de progrès concrétisée par un modèle de maturité pour réussir la transformation de l’en-
treprise en alignant la performance à la stratégie ERP.
• La revue n° 80 - Septembre 2005

LES OUVRAGES À PARAÎTRE

■ Le support client

L’ouvrage qui sortira au dernier semestre 2005 est destiné à mettre en exergue le rôle déterminant de la fonction support dans le
pilotage de la performance de l’informatique. En effet, les travaux sur le thème de la performance se polarisent sur les projets là où
les budgets sont de plus en plus absorbés par les tâches récurrentes. Cet ouvrage permettra de :
– comprendre le rôle central du support dans une approche de gouvernance basée sur IT Scorecard ;
– réussir la greffe d’un contrat externalisé dans les processus internes et auprès des acteurs concernés ;
– passer en revue les méthodes (ITIL, CoBIT) et se situer vis-à-vis des bonnes pratiques (modèle de maturité, modèle d’évolution).

Son résultat sera une boîte à outils recensant les principales pratiques, les pistes possibles d’amélioration et les interrogations
ouvertes.