mercredi 4 mars 2015

Estimer correctement le coût des projets informatiques


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: