En matière de budgets
des projets informatiques on rencontre assez souvent des évaluations prévisionnelles
fantaisistes qui s’avérent ensuite très éloignées des coûts effectivement constatés.
Trois exemples permettant de comprendre ce type de situation et les
conséquences qu’elle peut avoir :
·
Dans une
collectivité locale une longue discussion a eu lieu sur le budget du projet
de gestion de l’aide sociale mais très vite on s’aperçoit que ce chiffrage est
gravement sous-évalué car il ne comprend que le marché de réalisation par un
sous-traitant mais ignore complétement les coûts du personnel informatique de
la collectivité locale qui intervient sur le projet. Or ces montants sont
supérieurs à ceux du projet. On s’aperçoit alors que le coût réel du projet est
anormalement élevé. Manifestement la solution choisie n’était pas la bonne.
·
Dans une
entreprise industrielle on prend bien en compte dans le budget du projet le
coût correspondant aux informaticiens mais les utilisateurs participants au
projet et notamment la Maitrise d’Ouvrage ne sont pas pris en compte. Or ceux-ci
assurent une partie importante du travail de spécifications et des tests. Ces
dépenses sont ignorées pour la simple raison que ces personnes n’enregistrement
pas leurs temps de travail sur le projet.
·
Dans le cadre d’un grand projet de développement d’un service en ligne
fourni aux clients on a bien pris en compte les coûts de développement mais le
budget du projet ignore le coût du matériel et des logiciels qui seront
nécessaires. Or ils représentent les trois-quarts du total des dépenses du
projet. Il est évident que c’est une sous-évaluation grave du coût global du
projet. Elle est justifiée par l’idée que ce matériel est déjà en grande partie
utilisé par d’autres applications.
La sous-évaluation est fréquente
Comme on le voit
il existe une tendance très nette à sous-évaluer le coût des projets. Ce ne
sont pas des sous-estimations de tel ou tel poste mais carrément l’oubli de
postes fondamentaux du budget d’un projet : le matériel, le personnel
informatique de l’entreprise, la charge de travail des utilisateurs,
l’encadrement,...
A cela s’ajoute
la tendance naturelle à sous-évaluer systématiquement certaines rubriques comme
le volume de la charge d’études, le montant des charges sociales, les frais de
locaux et de matériels (dont les PC des développeurs), les quotes-parts de
direction, .... Ceci explique que les coûts des projets informatiques sont très
souvent sous-évalués.
Des visions différentes
Ces différentes
situations sont fréquemment dues à la faiblesse des méthodes d’estimation des
budgets informatiques. Elles sont en grande partie liées au fait que les parties
prenantes concernées ont des visions du projet informatique assez différentes par :
·
Les informaticiens
et notamment les programmeurs et les analystes s’intéressent tout
particulièrement à l’estimation de la charge de travail nécessaire pour mener à
bien la réalisation de l’application. Ils savent d’expérience que l’estimation du
volume du travail de programmation est soumise à des aléas importants. Ils sont
encore plus évasifs sur la charge de travail représenté par la conception, les
tests, le pilotage du projet,… La notion de coût complet du projet est assez
éloignée de leurs préoccupations.
·
Les
utilisateurs concernés par le projet et leur hiérarchie sont assez éloignés
des problèmes budgétaires. La connaissance de ce coût n’est pas leur
préoccupation première. Il est toujours difficile de les motiver pour
s’orienter vers une solution moins coûteuse qu’une autre. Par contre ils sont
particulièrement motivés par la définition des fonctions qui seront mises en
œuvre par la future application.
·
Le maitre
d’ouvrage est particulièrement intéressé par le niveau global du budget du
projet. Il doit ensuite défendre le budget auprès des différents décideurs.
Pour cela il a besoin de comprendre le contenu de chaque poste et il veut
s’assurer que celui-ci a été convenablement estimé et qu’aucune dépense
importante n’a été oubliée. Il est en particulier concerné par l’estimation de la
charge de travail qui sera demandée par les utilisateurs notamment lors de
l’analyse fonctionnelle et des tests.
·
Le
décideur ou les décideurs de l’entreprise sont directement concernés par le
budget du projet. Pour cela ils souhaitent avoir une vision complète de
l’opération. Il attend d’avoir un coût complet de l’investissement à effectuer,
y compris celui des matériels nécessaires. S’il est nécessaire de faire évoluer
les configurations existantes ils demandent que ceci leur est indiqué et que montants
nécessaires soient chiffrés. Ils veulent connaître les coûts supplémentaires qu’il
sera nécessaire de décaisser mais aussi qu’on leur précise le coût complet de
la configuration nécessaire y compris les PC, le réseau,… Si les équipements
sont mutualisés ([1])
ils demandent que la quote-part de ces charges s’imputant au projet soit
évalués.
Comme on le voit ces
différents points de vue sont assez divergents. Ils ont des visions du projet assez
éloignées et ceci se traduit fort logiquement par des chiffrages assez éloignés
les uns les autres.
Quatre approches différentes
A cela s’ajoute
le fait que les méthodes de chiffrages sont elles-mêmes différentes selon les
méthodes comptables utilisées par l’entreprise. Différentes approches sont
envisageables :
·
Comptabilité
générale. Dans ce cas on comprend l’ensemble de tout ce que coûtera le
projet. C’est un coût complet. La seule difficulté de cette approche est le
fait qu’un projet n’est pas une nature de dépenses. Dans ce cas on va s’efforcer
d’établir le compte de résultats analyse les charges par nature ([2]).
Pour arriver à distinguer les charges d’un projet il est nécessaire de disposer
d’un code d’opération donc de disposer d’une comptabilité analytique.
·
Comptabilité
analytique. Les coûts des projets sont calculés en faisant la somme du
produit des quantités d’unité d’œuvre par leur coût unitaire. Ainsi les coûts
des développements sont calculés sur la base du nombre de jours-hommes
nécessaire multipliés par le taux de journée standard. C’est l’approche la plus
fréquente. Mais souvent ces coûts sont sous-évalués car ils ne comprennent pas
le montant des achats d’équipement et de logiciels ou les amortissements correspondants,
les quotes-parts de direction, la charge de travail des utilisateurs,….
·
Contrôle
de gestion. Si le système comptable ne dispose pas d’une comptabilité
analytique il est possible de suivre les coûts du projet en les isolants à
l’aide d’un centre de frais spécifique. Ce peut aussi être un sous-centre de
frais du centre de frais de l’informatique. Il existe pour y arriver deux
difficultés : plusieurs centres de frais peuvent concourir à la
réalisation du même projet ([3]).
Il faut alors effectuer un retraitement des charges. En contrôle de gestion,
très souvent, on prend en compte les achats de matériels et de logiciels et on
ignore souvent leurs amortissements ([4]).
·
Refacturation.
On commence par identifier l’ensemble des prestations fournies au profit du
projet. Sur cette base on évalue les volumes d’activité fournis par les
différents centres de frais aux projets puis ces montants sont valorisés sur la
base d’un barème négocié. Dans ce contexte il est toujours délicat de fixer le
niveau des prix de ces prestations. Ils sont parfois négociés mais très souvent
ils sont imposés. Ceci ne peut qu’amener des critiques et des contestations.
Comme on le voit
ce sont quatre approches assez différentes et qui donnent parfois le sentiment
d’être face à une véritable Tour de Babel comptable. Chacun arrive avec ses
chiffres. Ils sont différents les uns des autres et impossible à comparer.
L’absence de règles claires
Ces difficultés
sont en grande partie dues à l’inadaptation des méthodes comptables à la notion
de projet. Mais cette difficulté n’est pas propre à l’informatique. Tous les
projets sont confrontés à cette même difficulté. Ceci est dû au fait que la
notion de projet n’a jamais été pris en compte lorsque de la conception de la
plupart des systèmes comptables. La plupart des projets sont pluriannuels or
les comptabilités sont annuels. De plus les projets regroupent des personnes se
trouvant dans de nombreux départements. Enfin une partie de leurs dépenses sont
des sous-traitances et des achats.
Ceci fait que
lorsqu’une entreprise doit gérer un grand projet, comme par exemple la création
d’une nouvelle usine, elle a tendance à créer une entité juridique spécifique qui
va prendre en charge l’ensemble de l’opération. Pour un projet informatique de
taille moyenne on ne va pas créer une société ou un GIE mais on va s’efforcer de
trouver une solution comptable adaptée.
La notion de
projet n’est pas un concept comptable. Ce n’est pas une nature de dépenses
comme les achats ou les frais de personnel. Ce n’est pas plus une division de
l’entreprise qui peut être identifiée par un code de centre de frais. De plus
un projet informatique va généralement couvrir plusieurs exercices. Il est bien
sûr toujours possible de reprendre les cumuls de chaque année à l’aide d’un tableur
et de les agréger. C’est envisageable mais ce pas très pratique à mettre en
œuvre et encore moins à lire.
Enfin il est
nécessaire d’être très attentif à prendre en compte certain postes et la
manière dont on les prend en compte. Ceci concerne particulièrement quatre
types de charges :
·
Les quotes-parts de frais généraux comme les
coûts des locaux, les dépenses de gestion des ressources humaines et de
direction,…. Selon les entreprises elles représentent entre 10 et 20 % des
dépenses. Faut-il les prendre en compte dans le coût du projet et de quelle
manière on doit le faire ? N’est-il pas préférable de les ignorer ?
·
Les matériels et les logiciels associés sont-ils
pris en compte dans le budget du projet sous forme des valeurs d’achats ou bien
est-il préférable de prendre en compte leurs amortissements ? On peut
aussi les ignorer. Dans ce cas le coût du projet est apparemment massivement
réduit. Mais, est-ce bien la réalité ?
·
Comment prendre en compte l’ensemble des coûts
mutualisés comme les réseaux, les postes de travail, les logiciels
applicatifs,… Faut-il les prendre en compte et de quelle manière ? N’est-il
pas préférable de les ignorer ?
·
Dans tout projet il y a des impondérables qui
peuvent se traduire par des dérives significatives des coûts. Faut-il
provisionner ces imprévus et à quelle hauteur ?
Pour
répondre à ces différentes questions il est nécessaire de fixer un certain
nombre de règles. Pour les déterminer il est nécessaire d’avoir une réflexion
sur le calcul du coût des projets informatique : quels montants prendre en
compte et sous-quelle forme ? C’est un choix délicat : est-ce qu’on
s’intéresse aux seules dépenses décaissées dans le cadre du projet ou bien
cherche-t-on à évaluer le coût complet du projet ? L’écart peut être du
simple au double, voire plus.
Définir ce qui rentre dans le coût du
projet
Pour aider les
responsables du projet il est nécessaire de définir un plan de comptes définissant
la manière de calculer le montant des investissements informatiques. Il
comprend les rubriques suivantes :
- Les matériels. Ceux-ci se composent :
·
les postes de travail : les PC mais aussi
les tablettes. Faut-il aussi prendre en compte les smartphones ?
·
l’ensemble des équipements permettant le
fonctionnement des réseaux locaux : câblages, routeurs, commutateurs, armoires
technique, boîtiers Wifi, firewall, …
·
les serveurs. Ce peuvent être des PC, des fermes
de PC, des serveurs sous Unix-Linux, des mini-ordinateurs sous OS/400, des mainframes,…
·
les systèmes de stockage sur disque type SAN ou
NAS (on se rappellera qu’une partie des stockages de données se font sur les
serveurs).
·
les locaux techniques,
·
les équipements de climatisation,
·
les systèmes d’alimentation électrique et le cas
échéant les systèmes de secours,
Souvent
ces équipements sont préexistants. Dans le cadre du projet il est souvent nécessaire
de renforcer ou de compléter ce parc. Faut-il seulement prendre en compte ces
coûts supplémentaires ou bien est-il nécessaire de calculer le coût complet de
la configuration ? Le projet ne va utiliser qu’une partie de ces
ressources. Comment estimer la part qui doit être affectée au projet ?
- Les logiciels. Ils comprennent :
·
les études générales notamment l’expression des
besoins, le dossier d’investissement, l’analyse fonctionnel,
·
le pilotage des projets,
·
les achats de logiciels systèmes, des bases de
données, des moniteurs transactionnels, des serveurs d’applications, des interfaces
utilisateur,... liés au projet,
·
les achats des progiciels notamment d’ERP,
·
les développements spécifiques, la documentation
technique et les tests informatiques,
·
le paramétrage de progiciels,
·
l’intégration sur un site pilote.
Comme
on le voit les coûts des logiciels vont bien au-delà des seules dépenses de
réalisation. Dans ces conditions est-ce qu’il faut prendre en compte les
montants induits par le travail de la maîtrise d’ouvrage et des utilisateurs ?
De plus en plus souvent ils assurent, en tout ou partie, les études amonts
comme l’expression des besoins et l’analyse fonctionnelle. Comment valoriser
ces travaux ? Comment suivre la charge de travail correspondant ?
- Les tests et les frais de démarrage.
Ils comprennent :
·
les tests utilisateurs et les tests d'intégration,
·
les plateformes de tests mises à la disposition
des informaticiens et des utilisateurs,
·
les actions de formation des informaticiens préalables
à la réalisation, notamment lorsque on met en œuvre des nouvelles technologies,
·
les actions de formation des utilisateurs
nécessaire pour mettre en œuvre la nouvelle application,
·
la documentation utilisateur : rédaction,
mise en page et édition.
·
les travaux de reprise de bases de données et de
fichiers,
·
les travaux de saisie complémentaires,
·
les opérations faites en double,
·
l’assistance technique,
·
le monitorat,
·
...
Ce
sont de nombreuses dépenses dont certaines sont d’un faible montant mais dont
le total fini par être conséquent. Il est important de ne pas les oublier.
Ce plan de comptes
est assez large. Son objectif est de calculer le coût complet du projet. Mais,
souvent le domaine pris en compte est plus restreint car on ne s’intéresse qu’à
une partie des coûts. En effet, on observe dans ce domaine de grandes
différences d’une entreprise à l’autre. Pour rendre les évaluations du coût des
projets comparables il serait souhaitable d’avoir un plan de comptes des
investissements informatiques standard mais, dans la plupart des entreprises,
on est encore assez loin ([5]).
Mettre en place une méthode de calcul des
devis de projet
Une fois le plan
de comptes établi il est nécessaire de disposer d’une méthode de calcul des
devis des projets qui identifie les différentes rubriques qui vont servir de
base au calcul. Il existe différentes méthodes de calcul. Ensuite on va s’attacher
à définir les indicateurs de mesure de l’activité. Ceux-ci vont ensuite être
valorisés à l’aide de coûts unitaires.
Le choix des
rubriques possibles est très important. Ce peut être des natures de dépenses
comme l’achat d’un progiciel ou un contrat de sous-traitance. Mais c’est aussi des
centres de frais comme l’activité d’études. Il est important de veiller à
définir les rubriques les plus facile à estimer et sur lesquelles l’erreur possible
est faible.
Pour cela la
mesure de l’activité doit se faire à l’aide d’unités d'œuvre simples. Si ces
indicateurs sont difficiles à estimer on aura du mal à estimer le budget. On va
par exemple estimer : le nombre des postes de travail des utilisateurs, la
quantité de mois-hommes de conception ou de réalisation, le nombre de mètres
carrés des bureaux,.... Ce sont tous des indicateurs faciles à mesurer.
Pour valoriser ces
volumes d’activité il est nécessaire d’établir un barème standard par type de
prestations fournies comme par exemple : le coût d’un jour-homme ou le montant
de la location mensuel d’un poste de travail.
Une fois que le
total des dépenses a été calculé il ne faut pas oublier d’ajouter la prise en
compte des frais généraux et des imprévus. Les frais généraux sont toutes les
dépenses de structure qui seront imposées au projet. Les imprévus sont des
dépenses qu’il est difficile de qu’il est difficile de prévoir au début du
projet mais qui peuvent survenir au cours des opérations.
Cette méthode se
traduit par une feuille de calcul qui peut être traitée par un tableur. C’est
une grille stockant le barème des coûts unitaires des différentes prestations.
On saisit les quantités de ressources qui sont nécessaires et il est alors
possible d’immédiatement consulter le montant de budget du projet.
Mettre en place un outil de suivi des
dépenses des projets
Il est ensuite nécessaire de s’assurer la qualité des
prévisions de coût effectuées. Pour cela on va mettre en place un suivi des
dépenses par projet. C’est un outil indispensable pour piloter les projets et s’assurer
du coût final du projet. Il permet de s'assurer du respect des budgets et ainsi
d’améliorer la méthode d’établissement des prévisions.
Il est, pour cela, nécessaire de rapprocher périodiquement
la réalité des dépenses constatées, le budget du projet et le degré
d’avancement du projet. Ces comparaisons se font généralement à des moments
clés du projet :
·
à la fin de l'analyse fonctionnelle. On a à ce
moment une idée assez précise de ce qu’il sera nécessaire de développer et donc
d’affiner le budget du projet.
·
à la fin de la programmation juste avant que
commence les tests utilisateurs. Eventuellement un point peut être effectué à
mi-parcours de cette étape.
·
au moment du démarrage effectif de
l’application.
Généralement, à la suite de cette analyse, on peut
vouloir mettre à jour le budget du projet. L’expérience montre qu’on n’a aucun
intérêt à multiplier le nombre de "réactualisations" du budget car cela
représente un gros travail et les variations d’une période sur l’autre ne sont
pas toujours significatives.
Par contre il est toujours possible de faire une
estimation globale du budget du projet en prenant le montant global des dépenses
réelles effectivement constatées et une estimation de l’avancement du projet.
Cette évaluation globale est un peu sommaire mais l’expérience montre que c’est
un chiffrage intéressant
Mais ce calcul ne remplacera jamais la comparaison
des dépenses constatées par rapport au budget de la baseline. On obtient ainsi un
ratio de consommation du budget. C’est l’indicateur clé demandé par le
management. Il va comparer ce pourcentage à celui d’avancement du projet pour
globalement estimé la dérive probable du budget. Ainsi si on a fait le tiers du
projet et qu’on a dépensé la moitié du budget il est assez probable que la
dépense finale sera de l’ordre de 150 % du budget initial.
Pour améliorer la qualité des prévisions effectuées
il est fortement conseillé d’auditer régulièrement les budgets de différents
projets en cours ou terminés afin de détecter, le cas échéant, d’éventuelles sous-évaluations
systématiques. Ce type de contrôle devrait faire partie des contrôles réguliers
effectués par les auditeurs internes et les commissaires aux comptes. En effet
les dépenses effectués sur des projets non-terminés doivent être comptabilisées
en fin d’année dans une rubrique « projets en cours » et devraient
être contrôlés. Je ne suis pas sûr que ce type de contrôle soit systématiquement
effectués. Dans ces conditions il est assez logique de découvrir régulièrement
des dérives.
Faut-il immobiliser les projets ?
Fréquemment on
s’interroge sur la nécessité de mettre en immobilisation le montant des études
informatiques. Sur ce sujet les avis sont très tranchés. Il y a ceux qui sont
contre et considèrent que ces dépenses sont des charges de l’exercice et
d’autres qui pensent qu’au contraire comme ces montants sont très importants et
qu’il est souhaitable de les étaler sur plusieurs exercices. C’est un débat qui
revient régulièrement. Il est dû à une confusion entre les notions d’immobilisation
et celle d’investissement.
L’intégralité des
dépenses d’un projet informatique sont des investissements. Par contre seulement
une partie de ces dépenses est immobilisée, c’est-à-dire inscrite à l’actif du
bilan des entreprises. Ces montants sont déterminés en fonction de la
réglementation fiscale des entreprises et la politique financière des entreprises.
La situation est
un peu différente selon la nature des dépenses. Les achats de matériel et les
logiciels associés sont normalement amortis sur sa durée probable d’utilisation
(en théorie 3 ans mais en pratique 5 ans). Les achats de progiciels sont
amortis sur une durée d’utilisation estimée comme raisonnable. Mais beaucoup
d’entreprises préfèrent les passer en charge de l’exercice. Le débat est plus
tranché en ce qui concerne les études. Contrairement à ce qui est souvent dit le
fisc autorise l’amortissement des études en appliquant une curieuse
règle : les dépenses de réalisation, qu’elles soient faites en interne ou
en externe, peuvent être amorties. Par contre les travaux de conception sont considérés
comme des charges de l’exercice ([6]).
En guise de conclusion
L’investissement
informatique représente entre 20 % et 35 % des investissements faits par les entreprises.
Dans certaines branches d’activité le ratio s’élève à 50 % comme dans la
banque, l’assurance, le commerce électronique,… Il est donc important d’arriver
à maitriser les budgets des projets informatiques de façon à garantir leur
rentabilité. Or, trop souvent on constate des dérives importantes qui réduisent
d’autant la rentabilité réelle des projets. L’observation montre que 43 % des
projets dérivent. C’est beaucoup. Plus les projets sont importants plus le
risque de dérive est important : 52 % des projets dépassant un million de
dollars dérives ([7]).
Plus la dérive est importante plus la rentabilité du projet est compromise. Il
est pour cette raison vital de mieux maîtriser le budget des projets.
[1]
- Equipements mutualisés : ce sont les serveurs, les mainframes, les postes
de travail, les imprimantes, le réseau, les routeurs, les systèmes disque,…
utilisés conjointement par différentes applications ou différents utilisateurs.
[2]
- Les charges du compte de résultat sont classées par nature : charges de
personnel, cotisations sociales, achats, services extérieurs, charges
financières, impôts et taxes, autres charges de gestion, dotation aux
amortissements
[3]
- Si plusieurs centres de frais contribuent au même projet cela veut dire que
dans chaque centre de frais on doit ouvrir un sous-centre de frais
correspondant à chaque projet. Cela risque d’être lourd.
[4]
- Dans de nombreux systèmes de contrôle de gestion on s’attache à suivre les
achats et on ignore les amortissements or dans une comptabilité en coût complet
il est nécessaire de prendre en compte les amortissements de ces équipements.
Il est possible de corriger cela par la refacturation de l’usage de ces différents
équipements.
[5]
- Le Cigref et l’AFAI ont mis au point en 2005 un document de référence :
« Plan de comptes informatique ». Il n’a pas rencontré l’écho que ces
initiateurs avaient souhaités.
[6]
- Un avis très ancien du Conseil national de la comptabilité du 29 avril 1987, et
souvent ignoré, règle ce problème. L'ensemble des frais de développement et de
réalisation, de pilotage de la réalisation, de tests et la documentation sont
amortissables. Par contre les coûts de conception allant de l'expression des
besoins jusqu'au cahier des charges sont exclues des montants immobilisés et
donc des amortissements. Ces montants représentent en moyenne entre 15 et 25 %
du budget des projets. De même les frais de formation et de démarrage doivent
être passés en charge de l'exercice.
[7]
- Chiffres du Standish Group. Cet organisme considère que les gros projets font
plus d’un million de dollars en études.
Aucun commentaire:
Enregistrer un commentaire