Tenir le planning des projets informatiques

L’efficacité de la gestion de projet se mesure. Elle s’apprécie en grande partie par la capacité du chef de projet à tenir son planning. C’est un enjeu fondamental. Un planning bien conçu s’exécute sans peine et permet de mieux maîtriser le déroulement du projet. A contrario un planning mal conçu est difficile à tenir. Cela se traduit par un projet chaotique et finit par aboutir à des dérives significatives.

Une fois le planning établi il est nécessaire de s’attacher à le suivre. Au fur et à mesure de son déroulement il est nécessaire de détecter des écarts notamment entre les dates prévues et la date réelle. Ce suivi est un moyen efficace de pilotage des projets permettant de détecter d’éventuelles dérives et de réagir rapidement.

La gestion du planning est un outil de pilotage indispensable car il met à la disposition du chef de projet et du management un outil de suivi des opérations qui permet de détecter un éventuel dysfonctionnement. La crédibilité des informaticiens et notamment des chefs de projet se jouent sur leur capacité à établir et à gérer le planning des projets qui leur sont confiés.

Les conséquences de la complexité des projets

Vu de l’extérieur un projet peut paraître simple. Mais en réalité ce n’est jamais le cas. C’est toujours une opération complexe car de nombreux intervenants sont concernés, une grande variété d’activités est mise en œuvre, un nombre élevé de tâches sont effectuées et surtout le déroulement des opérations peut s’étaler sur des mois ou des années. Un projet de taille moyenne comprend des centaines, voire plusieurs milliers, d’événements significatifs. Très vite les intervenants sont noyés dans ces masses d’informations.

Une partie significative de ces événements est constituée par les débuts et les fins de tâches. Lorsque le nombre de tâches croit on passe de quelques centaines à des milliers de faits à gérer. La croissance du nombre de tâches est un facteur expliquant la complexité des projets. Plus la taille projet est importante plus la probabilité de dérive est élevée. Ceci explique la difficulté particulière ressentie à maîtriser les projets de grandes tailles.

Les analyses du Standish Group ([1]) montrent très clairement que les grands projets ([2]) sont particulièrement fragiles : plus d’un projet sur 3 échoue (38 %). C’est un chiffre très élevé surtout si on le compare au taux d’échec des petits projets qui n’est que de 4 %. A cela s’ajoutent le fait que la moitié des grands projets dérivent (52 %). En conséquence : seulement 10 % des grands projets arrivent dans les délais et avec le budget prévu alors que 76 % des petits projets réussissent à tenir la charge, le budget et le planning.

Petits et grands projets	Moyenne	Petits projets	Grands projets
Succès	39 %	76 %	10 %
Dérive	43 %	20 %	52 %
Echec	18 %	4 %	38 %

Taux de succès, de dérive et d’échec des petits et des grands projets

                                               Source : Chaos Manifesto 2013 : The Standish Group

Casser la complexité des projets

Pour la Standish Group il y existe deux solutions permettant de sortir de cette situation :

·       Casser les grands projets en une série de plus petits projets. L’idée est intéressante, faut-il encore que cela soit possible ! Or certaines applications, de par leur nature, ne peuvent pas être découpées en plusieurs projets. Cependant ce n’est pas la règle générale et il existe effectivement de grands projets qui peuvent être décomposés en phases.

·       Réduire la complexité fonctionnelle de ces applications en se concentrant sur les fonctions essentielles. L’idée est de repousser les options et les cas particuliers qui représentent 80 % du code mais ne répondent qu’à 20 % des utilisations. Il serait ainsi possible de réduire le volume de travail nécessaire et obtenir plus rapidement des applications opérationnelles.

Ces solutions sont intéressantes mais dans la pratique elles ne sont pas évidentes à mettre en œuvre. Ce n’est pas sans rappeler l’idée d’Alphonse Allais de mettre les villes à la campagne. Souvent les concepteurs n’ont pas le choix. Par exemple, la mise en place d’un ERP est un bloc et il est difficile de découper l’opération en tranches. De même il est difficile d’éliminer les cas particuliers d’une application car cela risque de la rendre difficilement utilisable. Les architectures intégrées poussent à avoir des projets de grande taille.

La bonne nouvelle est qu’il y a de moins en moins de projets de ce type car la plupart des grandes entreprises ont déjà mis en place leur ERP et aujourd’hui les projets portent surtout sur la migration d’une version à l’autre ou sur la généralisation d’un système à l’ensemble de l’entreprise, notamment en cas de rachat de nouvelles entreprises et de fusion au sein d’un même groupe de filiales. De plus la basse conjoncture observée depuis 2008 a énergiquement réduit le nombre des grands projets.

Faire simple n’est déjà pas si simple que ça

Il est certain que pour maîtriser les projets il est nécessaire de chercher à réduire leur complexité. Le nombre de solutions n’est pas infini. En fait il n’y en a que deux : soit réduire le nombre de fonctions et de sous-fonctions mises en œuvre, soit améliorer la technique de gestion de projet. Comme la première solution n’est pas réaliste, il reste la seconde. 

Pour y arriver on a pris l’habitude de regrouper un ensemble de tâches concourant au même résultat en étape encadrés par une date de début et une date de fin. Ce sont, par exemple, l’expression des besoins, l’analyse fonctionnelle, l’analyse détaillée, la définition de l’architecture technique, la programmation, les tests,…. Elle a représenté une innovation majeure dans la gestion de projet. Elle n’est pas spécifique à l’informatique. On la retrouve dans tous les projets : industriels, de recherche et développement, de travaux publics,… Les étapes portent des noms différents mais les concepts mis en œuvre sont les mêmes.

C’est une notion importante car elle permet de simplifier considérablement la gestion de projet. Au lieu de gérer des centaines, voire des milliers, de dates on ne gère que quelques étapes ou quelques dizaines avec, à chaque fois, la date de début et la date de fin ([3]). La gestion des étapes représente un progrès significatif. Autre avantage, l’existence des étapes est un moyen simple et rapide permettant de mesurer l’avancement du projet ([4]). Dans ces conditions un projet, même complexe commence à devenir maîtrisable.

Rôle du planning global

Sur cette base on établit un planning global. Généralement c’est un graphique de type Gantt avec en abscisse le temps, chaque étape étant représentée par un trait allant de sa date de début à sa date de fin. Le graphique à barre n’est pas la seule représentation possible. Il existe de nombreux types de graphiques comme par exemple un réseau (Pert), le schéma du type chemin de fer, une représentation en cercle, une représentation à base d’histogramme, un tableau en mode radar, ...

Le graphique de type Gantt a l’avantage d’être un document facile à lire et à comprendre. Il est généralement remis aux décideurs pour leur permettre de comprendre le déroulement des opérations. Il est ainsi possible de répondre à la plupart des questions habituelles : « où est-on ? », « quel est le retard moyen ? », « dans ces conditions quand est-ce que l’application sera effectivement opérationnelle ? »,…

Au départ ce schéma est un outil de communication. Mais, au cours de projets, son rôle évolue. Au fur et à mesure du déroulement du projet on note la date réelle des événements des projets. Il est ainsi possible de mesurer l’avancement du projet (4). Ceci fait que le planning devient un outil de pilotage du projet.

Mais il est possible d’aller plus loin. En rapprochant pour quelques dates clés les dates prévues et les dates réelles on est capable d’évaluer le retard moyen du projet ([5]). Le planning devient ainsi un outil d’alerte permettant de détecter des dérives significatives du projet.

Les illusions d’un planning détaillé

Très souvent on cherche à établir le planning global du projet à partir du planning détaillé décrivant l’ensemble des tâches à effectuer. Cela parait logique. Mais en pratique il est assez illusoire de vouloir identifier un ou deux ans à l’avance le détail de toutes les opérations qu’il sera nécessaire d’effectuer alors qu’on ne sait pas encore ce qu’il sera nécessaire de réaliser. Au départ on ignore tout sur le projet l’étape d’expression des besoins a justement pour but de connaître le périmètre fonctionnel et déterminer ce qu’il va être nécessaire de réaliser puis de tester.

En fait, il n’est pas possible de définir le détail des tâches de réalisation avant que l’analyse fonctionnelle soit terminée. Ensuite il est nécessaire de définir le détail des opérations de test généralement appelé le plan de tests. Mais ceci n’est possible qu’à partir du moment où une partie de l’application est en cours de réalisation. Dans ces conditions l’idée de définir dès le lancement du projet l’ensemble des tâches qui devront être effectuées est assez irréaliste.

Même si on était capable d’identifier toutes les tâches d’un projet et leur enchainement (enclenchement) le résultat serait un immense tableau ou un graphique qui ferait plusieurs pages ([6]) et qui ne serait pas très lisible. Le décideur à qui on remettrait ce type de document serait très vite perdu et il lui serait difficile d’avoir une vision d’ensemble du projet.

Par contre le planning détaillé est très utile pour pointer la réalisation des tâches : celles qui ont été effectuées, celles qui sont en cours et celles qui sont en attentes. Ces listes sont très utiles pour animer les réunions de l’équipe projet mais elles ne sont pas adaptées pour informer les décideurs de l’état du projet et ce qui reste encore à faire.

Pour répondre aux attentes du management la règle simple : on raisonne sur les étapes et on ignore le détail des tâches. Une étape est en cours ou elle est terminée. Une étape qui serait presque terminé mais pour laquelle on consomme encore des jours-homme est classée « en cours ». On considère qu’elle est terminée à partir du moment où il n’y a plus d’intervention imputée à cette étape.

Gérer les événements clés

Le pilotage d’un projet se fait à partir d’un ensemble de ses dates clés. Elles sont peu nombreuses. Dans le cadre d’un projet ce sont d’abord les dates de début et de fin d’étape mais ce sont aussi les dates de remise de documents importants, les réunions du comité de pilotage, la date de livraison d’un matériel ou d’un ensemble de logiciels, le moment où un système est opérationnel, … Parmi ces dates il y a des événements qui sont des points de passage obligé : ce sont les jalons. Ils vont permettre de suivre, nous l’avons vu, le rythme de progression du projet et le cas échéant mesurer le retard du projet.

L’objectif est d’avoir en moyenne un jalon tous les deux mois. Ainsi une étape qui dure 6 mois sera suivie à l’aide de quatre évènements clés : ses dates de début et de fin auxquelles on ajoute deux jalons intermédiaires. Par exemple la remise d’un document important ou une réunion d’orientation du comité de pilotage. Multiplier le nombre de dates clés n’améliore pas de manière significative le contrôle des opérations. Par contre il a tendance à alourdir ce suivi.

La baseline du projet repose sur le découpage du projet en phases, en étapes, en lots, en itérations ([7]), en run, … Il est ainsi possible de dégager une série de dates clés. C’est la base permettant ensuite de suivre l’évolution du projet et, éventuellement de détecter des retards.

Une fois que le planning est défini on dispose d’une métrique permettant de mesurer l’avancement du projet et de calculer son retard moyen. S’il n’existe pas il est délicat de suivre le projet.

Le rôle du journal de bord

Pour bien comprendre le déroulement du projet il est nécessaire d’avoir une trace des opérations effectuées. Or, les activités effectuées dans le cadre d’un projet changent régulièrement. Or, quelques semaines après qu’un événement soit survenu il est très difficile de se rappeler ce qui s’est exactement passé. Au bout de quelques mois, ce qui n’a pas été enregistré, est oublié.

Pour arriver à reconstituer ce qui s’est passé il est toujours possible de recourir aux comptes-rendus des réunions d’avancement ou des réunions de l’équipe projet ([8]). C’est notamment le cas si une partie des travaux est sous-traitée à une société de service. Ces réunions périodiques sont très utiles car elles permettront de constater qu’à un moment précis tel ensemble d’opérations est terminé et que les autres sont encore encours ou restent à lancer. C’est pratique mais ce n’est pas suffisant car dans ce type de document on ne note pas tout, ce qui fait que certaines événements clés peuvent avoir été oubliées.

Pour éviter cette situation il est souhaitable que le chef de projet prenne l’habitude de noter au jour le jour les événements significatifs qu’il observe : les incidents, les livraisons, les réunions, les problèmes apparus,…. Pour cela il est nécessaire qu’il mette en place un livre de bord du projet. Il est ainsi possible de suivre le détail des opérations et, le cas échéant, de voir apparaître les dérives. Faut-il encore que le chef de projet ait la discipline de noter tous les soirs avant de quitter son bureau les événements clés qui sont survenus au cours de la journée. Ce document peut être rédigé à l’aide d’un cahier mais la plupart du temps il est tenu grâce à un programme de traitement de texte.

Mesurer les décalages constatés sur le projet

Le suivi régulier des dates des événements clés est très utile. Il permet de comparer les dates prévues et les dates réelles. Le suivi de ces dates est très instructif et montre qu’il existe en matière de retard deux situations possibles :

·       Le décalage constant. On note au départ du projet un décalage de X jours (ou X semaines) et celui-ci reste le même pendant toute la durée du projet. Cela veut dire qu’on a pris du retard au début du projet mais qu’ensuite il se déroule normalement. On constate que la productivité de l’activité d’études (conception, programmation, tests) est bien celle qui été prévue.

·       Le décalage croissant. Plus le temps passe plus le retard augmente. On a, par exemple, au début du projet un retard de 10 jours mais 3 mois plus tard on est à 20 jours, … Chaque mois on perd trois jours. C’est une situation inquiétante. Cela veut dire que la productivité des études et de la réalisation est insuffisante où que le planning prévisionnel a été mal fait.

On peut espérer qu’à l’inverse que le retard diminue avec l’avancement du projet. Mais il ne faut pas rêver : « le temps perdu ne se rattrape guère » ([9]). Il est très rare que le retard constaté au début du projet soit ensuite rattrapé.

Pour piloter efficacement le projet il est nécessaire de mesurer régulièrement le retard moyen du projet et essayé d’évaluer la date probable de fin du projet.

Etre capable de réagir rapidement à toute dérive

Le suivi du planning est le dispositif central de la gestion des projets. Il est ainsi possible de détecter et de suivre d’éventuelles dérives des projets. Il permet d’alerter rapidement les décideurs d’une dégradation de la situation de sorte qu’il est possible de prendre rapidement les bonnes décisions. C’est la base d’une réelle réactivité.

L’idéal est d’arriver à réagir à toute dérive en moins de 48 heures, même à des incidents qui peuvent avoir de graves conséquences comme, par exemple, le fait qu’un collaborateur important du projet tombe gravement malade ou le constat de la défaillance soudaine d’un fournisseur. Ce délai est mesuré entre le moment où le problème survient et celui où la solution de remplacement est mise en place.

Souvent le délai de réaction est de l’ordre d’une semaine. C’est encore acceptable mais c’est un peu lent car entre temps il peut se passer de nombreux d’événements. Mais si la structure de pilotage du projet est lourde, avec de nombreux organes de décision ou de consultation il est difficile de réagir plus vite. Souvent cette complexité est due à celle de l’entreprise. Avant de faire quoique ce soit il faut consulter de nombreux organes et avoir l’avis de toutes les « huiles » possibles. Dans ce cas il est difficile d’améliorer la situation.

Lorsque la réaction prend plus d’une semaine on est face à un management de projet peu efficace. Ceci ne concerne pas seulement le chef de projet. En effet, très souvent la solution ne peut pas venir uniquement de la maîtrise d’œuvre ou du chef de projet mais relève plutôt du maître d’ouvrage ou du comité de pilotage. Les délais de réaction sont plus longs car la concertation prend toujours plus de temps. Comme on le voit le délai de réaction du projet à toute dérive de planning est un critère de bonne gestion.

Heureusement, grâce à une bonne organisation il est possible de réduire ces délais et de se rapprocher d’une réaction en 24 ou 48 heures. C’est l’idéal car cela évite que le projet prenne du retard.

  

---

[1] - Chaos Manifesto 2013, Standish Group. Ces études font référence en matière de gestion de projet informatique.

[2] - Selon le Standish Group, les grands projets ont des budgets en charge de développement supérieurs à un million de dollars, ce qui me parait être un seuil très élevé. Il me semble que le seuil est plutôt de l’ordre de 1.000 jours soit de l’ordre de 500.000 dollars.

[3] - De plus, si on s’y prend bien la date de fin d’une étape et la même que celle de début de l’étape suivante. C’est une réduction de moitié du nombre de dates à gérer.

[4] - Pour cela il suffit de compter le nombre d’étapes terminées, de les pondérer par la charge de chacune de ces étapes et de le rapporter au nombre total d’étapes à effectuer.

[5] - Par exemple la validation du cahier des charges était prévue pour le 12 avril. Elle a été terminée le 15 juin. Le projet a donc 2 mois de retard.

[6] - Le graphique Pert d’un projet de plusieurs milliers de tâches peut faire plusieurs mètres carrés.

[7] - Les itérations sont un des éléments clé des méthodes agiles. Elles reposent sur un découpage de la phase de conception réalisation en itérations qui ont une durée fixe et qui se terminent par la livraison d’une partie du code.

[8] - S’ils ont été rédigés !

[9] - Comme le chantait Barbara.

Evaluez correctement les gains liés à vos projets informatiques

Il existe au sein de la communauté informatique un important débat à propos des gains liés aux projets informatiques. Beaucoup de personnes s’interrogent sur la nature de ces gains et sur leur importance. Certains vont même plus loin et se demandent s’il existe effectivement des gains. En effet la plupart des gains n’apparaissent pas à l’informatique mais dans les comptes des départements où travaillent les utilisateurs. Si ces derniers ne sont capables de les évaluer ou ne veulent pas les mesurer on peut alors s’interroger sur leur matérialité.

Cette attitude est assez étonnante car tout le monde convient qu’il est nécessaire de mesurer les gains. L’ensemble des auteurs, des enseignants et des consultants sont unanimes en ce qui concerne le principe mais dans la pratique on constate des attitudes contrastées. Certains font valoir la difficulté de l’opération, d’autres mettent en avant le fait que ce ne peut être qu’une estimation car généralement le système comptable en place ne permet pas de les mesurer. Pour une minorité il est vain de chercher à estimer les gains car ils ne seraient pas mesurables.

Ces différentes attitudes expliquent le fait qu’aujourd’hui un grand nombre de projets ne disposent pas d’une étude de rentabilité digne de ce nom ([1]). Il n’existe pas de statistique sur le pourcentage de projets lancés sans disposer d’un bilan économique mais il ne doit pas dépasser 10 % et il est même peut-être encore plus bas. Ceci peut être toléré pour des petits projets mais ne l’est pas dans le cas des grands projets. Cette absence est une prise de risques importante. Comment expliquer cette attitude ? Est-ce que les entreprises sont d’accord pour investir plusieurs millions d’euros par an sans avoir de garantie d’avoir un retour significatif ?

La plupart du temps les gains liés à l’informatique sont massifs et évidents

Rassurons-nous l’informatique n’est pas le tonneau des Danaïdes. La plupart des projets informatiques dégagent de la valeur et certains permettent de dégager d’excellentes rentabilités. Cela fait plus de 60 ans que les entreprises font de l’informatique. On estime l’ensemble des investissements (matériels informatique et de télécommunication, logiciels, progiciels, développements spécifiques,..) à un montant de l’ordre de 2.200 à 2.300 milliards de dollars par an. En France il serait chaque année de l’ordre de 50 milliards d’euros. Il est difficile d’imaginer que les entreprises dépenseraient des sommes aussi importantes s’il n’y avait pas des contreparties significatives. Mais, rassurons-nous, les gains existent et ils sont massifs.

Cependant, pour les connaître il faut être capable de les mesurer. Dans un grand nombre d’entreprises on attend que les informaticiens les évaluent. Mais ils sont les plus mal placés pour le faire car l’essentiel des gains se font loin de chez eux, dans les services utilisateurs. En effet, les gains réalisés au sein de la direction informatique sont généralement faibles : matériels moins chères, baisse des coûts de maintenance, … La quasi-totalité des gains se font dans des unités. Or elles n’ont pas mis en place des outils et des méthodes capables de les mesurer. Il est certain que tant que les gains ne sont pas régulièrement mesurés, il est délicat de les estimer de manière prévisionnelle.

Deux cas parmi des milliers d’autres

Deux exemples parmi de nombreux autres permettent d’apprécier la nature et l’importance des gains liés aux projets :

-      L’élaboration des devis. Dans une entreprise d’ingéniéring une application de calcul de devis est utilisée depuis de nombreuses années. Elle est lourde et peu efficace. La saisie est complexe et longue. Seul des techniciens expérimentés arrivent à s’en servir. Les traitements se font toutes les nuits et il faut souvent plusieurs allers retours pour obtenir un devis présentable. Cela prend plusieurs jours.

Il est décidé de reconcevoir cette application. Elle repose sur trois innovations : la saisie est simplifiée, les calculs se font en temps réels et elle permet de calculer la marge prévisionnelle attendue du devis. De plus l’entreprise souhaite réduire le délai de fourniture d’un devis d’une semaine à seulement 2 heures. La charge de travail par devis qui est d’une demi-journée sera ramenée à 1 h de travail. Mais le véritable gain va consister à augmenter le taux de réussite des devis.

Effectivement, après deux ans de fonctionnement de la nouvelle application, on constate que le taux de réussite des devis est passé de 15 % à 25 %. Cela s’est traduit par une augmentation du chiffre d’affaires de 15 % par an au lieu des traditionnels 4 à 6 %. On est passé à un temps moyen de saisie de chaque devis à 1 h 15. De plus la marge nette de l’entreprise est passée en deux ans de 2 % à 6 %. L’objectif est maintenant d’arriver à 10 %. Mais, bien entendu ce gain n’est pas uniquement lié au système de devis.

-      Le suivi des incidents. L’entreprise produit des moteurs de camions et d’engins de travaux publics. Elle gère un parc important. Pendant longtemps on suivait les incidents grâce à des fiches suiveuses gérées par les ateliers centraux, les concessionnaires et certains gros clients. Une fois ces fiches remplies elles étaient centralisées au siège puis saisies. C’était lourd et surtout la base ainsi constituée était incomplète.

Aujourd’hui les moteurs sont dotés de systèmes électroniques notamment pour gérer la carburation et pour faciliter les tests lors des visites d’entretien. Un contrôleur enregistre en permanence les incidents qui peuvent survenir et ils sont stockés en mémoire. Lors des visites périodiques le mécanicien récupère ces informations sur son ordinateur de tests, les complète par ses observations et la liste des interventions effectuées puis l’ensemble est immédiatement envoyé pour mettre à jour la base de données centrale. Ces informations sont analysées en temps réel et un message est envoyé au mécanicien pour attirer son attention sur d’éventuelles fragilités, des réglages à effectuer, des pièces à remplacer de manière préventive,…

A terme on envisage de connecter le contrôleur sur un modem 3 G pour envoyer en temps réel les incidents et les relevés d’activité. Le but de ce système est de pouvoir détecter les fragilités avant que la panne survienne. Ceci doit permettre d’éviter des arrêts d’exploitation forts coûteux aux clients.

Mais elle doit aussi permettre de diminuer le coût de la maintenance en développant la maintenance préventive et éventuellement d’espacer les visites d’entretien. Cela va se traduire par une baisse du coût d’entretien de 20 %. C’est bien pour le client mais pour l’entreprise ce n’est pas un gain mais c’est au contraire une baisse de son chiffre d’affaires.

Mais ce n’est qu’une partie des gains. L’enjeu le plus important concerne la réduction du coût d’indisponibilité des équipements chez les clients. On estime globalement ce gain sur l’ensemble de tous les clients à plusieurs centaines de millions d’euros.

Ces nouveaux services auraient pu être facturés par les concessionnaires aux clients. Cela aurait remonté la rentabilité du projet mais cela aurait freiné leur rapide généralisation. Il a été décidé de ne pas le faire payer. Seule la mise à niveau du contrôleur est facturée ([2]).

Pour le fournisseur de moteur les gains directs liés au projet sont faibles. Par contre il offre un avantage concurrentiel important ([3]), une gestion plus efficace des pièces détachées et une meilleure planification des interventions des mécaniciens chargés de l’entretien de ces moteurs.

Si on ne compte que les seules baisses des coûts de l’entreprise le gain est faible mais si on prend en compte l’ensemble des gains y compris ceux réalisés par les clients le retour sur investissement est très élevé.
Pour profiter de ces gains l'entreprise a dans un premier temps proposer à ses clients des contrats d'entretien forfaitaires coûtant environ 20 % du tarif antérieur à charge pour elle de diminuer ses coûts et gagner la différence. Mais dans un deuxième temps elle est allé plus loin est à proposer de louer ces moteurs aux clients comprenant l'entretien des matériels. Ceci concerne notamment la rechange des moteurs qui permettent de donner une deuxième vie au camion où à l'engin. Elle a pu bénéficier des gains de maintenance ainsi obtenus.  

Rassurons-nous la plupart des projets informatiques sont rentables. Mais parmi toutes les opérations envisageables certaines ne le sont pas et doivent être évitées. C’est le rôle indispensable des études de rentabilité des projets.

Le remplacement d’applications existantes

Quand on s’intéresse aux gains permis par les projets il est nécessaire de distinguer le renouvellement des applications existantes et la création de nouveaux systèmes d’information. La logique économique n’est pas la même. En effet quand on remplace une application existante par une nouvelle il n’y a pas forcément de nouveaux gains. De même remplacer un camion en bout de course par un autre tout neuf ne se traduit pas forcement par des gains. Il est seulement nécessaire de le remplacer et on le fait. Il est probable qu’à l’origine, lorsqu’on a mis en place pour la première fois cette application, des gains ont pu être dégagés et tant qu’elle est utilisée elle permet d’en dégager. Mais, la plupart du temps, il est probable que le remplacement de l’ancienne application par une nouvelle ne dégage pas des gains supplémentaires.

Dans ce cas il est difficile de justifier ces nouveaux investissements par de nouveaux gains. Pour cette raison il est nécessaire d’amortir les applications de façon à dégager le cash-flow nécessaire pour les renouveler en fin de vie. Ceci n’est pas propre à l’informatique. Il en est de même si des camions ou des machines-outils il faut prévoir leur renouvellement au bout d’un certain nombre d’années. Leur coût de revient doit normalement comprendre des amortissements permettant de financer leur renouvellement périodique. Il en est de même pour les applications informatiques qui doivent être périodiquement réécrites et le cas échéant, être remplacée par une nouvelle.

Dans le cas du logiciel il faut savoir que le montant des amortissements sont importants et peuvent représenter 20 % à 30 % du coût de revient réel des applications opérationnelles. Cela veut dire que « l’oubli » de ces amortissements permet de réduire de manière significative le coût de revient apparent des applications. Mais cette baisse est illusoire car à terme il sera nécessaire remplacer cette application. Ainsi le coût informatique d’une facturation est de 5 euros par facture. Mais en négligeant les amortissements on peut afficher un coût de 3,50 à 4 euros. C’est agréable à court terme mais à long terme ce n’est pas une solution tenable.

Productivité ou efficacité ?

L’expérience montre qu’il existe une grande variété de gains. Il est donc difficile de tous les recenser. Cependant l’analyse d’un certain nombre d’applications montre qu’il existe deux grandes familles de gains : la productivité et l’efficacité. Ce n’est pas la même chose. Ce sont deux logiques différentes :

·       La productivité consiste à effectuer le même travail avec moins de ressources. C’est par exemple la possibilité de saisir une commande client en 10 minutes au lieu de 15 minutes avec l’ancien système. Dès les débuts de l’informatique on a constaté des gains de productivité massifs. Ils ont justifié les investissements informatiques pendant de nombreuses années. Aujourd’hui ils jouent un rôle moins important.

·       L'efficacité consiste à obtenir un résultat supérieur en employant les mêmes ressources. Ces gains se traduisent pas une augmentation du chiffres d’affaires, de la valeur ajoutée créée par l’entreprise, par une amélioration de sa marge brute et finalement pas une augmentation de sa marge nette. Les systèmes d’information comme le commerce électronique, l’exploitation de grandes bases de données à des fins de marketing ou des systèmes de suivi des clients type CRM sont des applications permettant d’améliorer le chiffre d’affaires et la marge de l’entreprise.

Depuis une dizaine d’années les gains d’efficacité sont devenus le moteur essentiel du développement des applications informatiques. L’expérience montre que les gains d’efficacité ont un potentiel de développement considérable. Ce sera probablement le facteur clé de croissance de l’informatique dans les années à venir.

Si on ne mesure pas l’impact des projets il est difficile d’apprécier leur rentabilité

Comme on le voit les gains liés aux projets sont importants et leur mesure est généralement simple à effectuer. Il est dans ces conditions assez étrange de constater que de nombreux intervenants partie-prenantes affirment qu’il est très difficile de les mesurer. Cette attitude s’explique, en grande partie, par le fait que les informaticiens sont assez mal placés pour les évaluer. Certains gains se font à l’informatique comme, par exemple, la baisse du coût de maintenance des matériels ou des logiciels ou bien la réduction des dépenses d’exploitation. Mais ce n’est qu’une faible partie des gains. L’essentiel des gains se font chez les utilisateurs. Ceci fait que seuls les responsables des métiers sont capables de les évaluer.

Mais, souvent, ils éprouvent une certaine difficulté à effectuer ce type d’évaluation. Ceci est fréquemment lié à leur prudence. Ils hésitent à s’engager sur un résultat prévisionnel quantifié alors qu’ils ignorent encore comment fonctionnera la future application et quelle sera son impact sur l’organisation en place. Mais très souvent on constate qu’ils ne sont pas capables de le faire car ils n’ont pas les compétences nécessaires pour effectuer cette évaluation. De plus ils sont souvent trop impliqués et ne disposent pas de la distance suffisante pour effectuer ce travail. Il est pour cela souhaitable de recourir à des hommes ayant suffisamment de recul. C’est le rôle de la maîtrise d’ouvrage et des sponsors qui ont la responsabilité ultime de mesurer la rentabilité des projets.

Mais, la plupart du temps ils n’ont pas les connaissances nécessaires pour effectuer ce type de chiffrage. Pour évaluer les coûts du projet ils font appel aux informaticiens mais ils ont ensuite la responsabilité délicate de mesurer l’impact du projet. Ce travail doit être assuré par l’encadrement des différentes fonctions assisté par le ou les contrôleurs de gestion de l’entreprise. Ils ont la responsabilité de faire participer l’ensemble des personnes concernées à cette évaluation et de valider ensuite les chiffres ainsi obtenus. C’est toute la difficulté de l’opération.

Que faire des projets qui dégagent une rentabilité insuffisante ?

Parmi toutes les idées de nouvelles applications certaines sont très rentables mais d’autres le sont moins et certaines risquent d’être de véritables puits sans fond. Il est fort probable qu’il existe des projets pour lesquels il n’y a aucun espoir de rentabilité et malgré tout il est impératif de faire. C’est notamment le cas des projets imposés par des changements de réglementation. Il est certain que l’administration à tendance à imposer des traitements et des développements parfois conséquents sans contrepartie. Le bon sens serait de lui facturer ces coûts ou de lui fournir les informations brutes à charge pour elle de les traiter. Mais ce n’est pas son approche et tant qu’une loi ne lui imposera pas une prise en charge de ces projets il y a peu de chance de dégager une quelconque rentabilité de ces projets.

Cependant il faut rester raisonnable : quel est le poids de ces projets dans le portefeuille global d’une entreprise ? Entre 5 et 10 %, parfois moins. Reste les 95 % applications qui sont des investissements. Ceux-ci doivent impérativement dégager une rentabilité. Les entreprises qui suivent la rentabilité de leurs projets ont fait deux constatations importantes :

·       Une grande disparité de la rentabilité des applications. A côté d’opérations très rentables on en trouve de nombreuses autres qui le sont moins. La même application peut être très rentable dans une entreprise et être particulièrement intéressante dans une autre.

·       La variabilité de la rentabilité dans le temps des applications. Certaines opérations sont à leur lancement très rentables mais au fil des années elles deviennent moins rentables. On constate aussi l’inverse.

C’est, par exemple, le cas des logiciels intégrés. Quand les premiers projets de mise en place d’ERP ont été lancés à la fin années 90 c’étaient des opérations lourdes qui s’étalaient dans le temps et dont les budgets dérivaient allégrement. Globalement c’était des opérations non-rentables ([4]). Mais dix ans plus tard on s’est aperçu qu’ils devenaient des investissements rentables. Il a fallu pour cela que les entreprises arrêtent de développer du code à l’intérieur du logiciel intégré pour que celui-ci simule ce que faisait l’ancienne application. Mais les gains conséquents ont commencé à apparaître à partir du moment où les entreprises ont restructurer leurs processus. Ils ont été permis grâce à la redéfinition des tâches et du contenu des postes de travail.

Rôle des informaticiens dans ce contexte

Dans ces conditions il est nécessaire de s’interroger sur le rôle et la responsabilité des informaticiens dans l’évolution de la rentabilité des projets. Aujourd’hui, dans une grande majorité d’entreprises les utilisateurs et les maîtrises d’ouvrage ont la responsabilité de définir leurs objectifs et leur contenu. Ceci fait que ce contexte le rôle des informaticiens change. Ils ont la responsabilité d’informer le management de manière claire et non-ambiguë sur tous les aspects du projet. Ensuite ils doivent définir sa conception fonctionnelle et évaluer le coût de la solution retenue.

Par contre, il faut être très clair sur ce point, ils n’ont pas la responsabilité de calculer les gains car ceux-ci apparaissent chez les utilisateurs et non à l’informatique. Il est possible qu’il y ait des gains informatiques, mais ils sont généralement d’un assez faible montant et, la plupart du temps, ils ne sont pas suffisants pour justifier le montant des investissements.

Comme la plus grande partie des gains apparaissent dans les comptes des unités il est donc assez logique que leurs responsables aient la responsabilité de chiffrer ces montants. Et dans ces conditions les informaticiens doivent les aider à les chiffrer et si aucune étude de rentabilité n’est faite de rappeler qu’elles sont absolument nécessaires. Mais en aucun cas ils ne peuvent pas se substituer à des maîtrises d’ouvrage ou des responsables des métiers négligents ou faiblement motivés. Chacun a ses responsabilités ! 

---

[1] - Il serait plus juste de dire que seuls quelques projets disposent d’une véritable étude de rentabilité.

[2] - Si le moteur est très ancien un système électronique de surveillance est proposé au client. Il ne mesure pas tout mais effectue certaines mesures et enregistre les incidents graves. De plus il facilite les tests et donc permet de réduire la durée d’immobilisation des engins.

[3] - Ceci dit ce gain est relatif car tôt ou tard les concurrents proposeront la même solution mais il est probable que cela prendra du temps. Un concurrent avait essayé il y a quelques années d’installer un système expert qui n’avait jamais bien marché et cela a mis en péril son activité.

[4] - Il est assez amusant de constater que ces projets ont été lancés à la demande des directeurs financiers et qu’ils ont connu des dérives aussi graves mais ils se sont accrochés à leur idée et effectivement ce sont aujourd’hui des applications honorablement rentables.

Le classement de l'informatique du World Economic Forum en 2014 : France est-ce la fin de la chute ?

 Comme tous les ans le World Economic Forum (Davos) publie son classement annuel du développement informatique : The Global Information Technology Report 2014.

Page de garde du rapport 2014 du WEF

L’an passé nous avions constaté le dévissage de la France dans ce classement (Voir sur ce blog le message du 6 juillet 2013 : Economie numérique : la France classée au26ème rang mondial par le Forum de Davos, voir aussi le message du 19 mars 2012  : Le classement informatique duWorld Economic Forum : Une triste réalité). Entre 2009 et 2013 la France était passée de la 18^ème à la 26^ème place. Nous écrivions alors « Ce dévisage était prévisible. C’est la conséquence d’une série d’erreurs stratégiques faites depuis de nombreuses années notamment par les gouvernements successifs mais aussi par les nombreuses entreprises intervenant dans le domaine de l’économie numérique sans compter les universités et les grandes écoles. A force de ne pas apprécier correctement les enjeux, on finit par prendre des mesures peu efficaces, voir contre-productives ». Et nous concluions : « Il serait temps de prendre au sérieux l’économie numérique. » 

Une hirondelle fait-elle le Printemps ?

Cette année on a deux nouvelles et, selon la formule classique, une bonne et une mauvaise. La bonne est que la position de la France s’est stabilisée et à même regagné une place au 25^ème rang. La chute semble enrayée. Est-ce l’impact de la "feuille de route" de Fleur Pèlerin lancée en Février 2013 ? (Voir sur ce blog le message du 11 avril 2013 : « Est-ce le début du commencement ?» ) Nous disions l’an passé : « il est trop tôt pour porter un jugement sur l’impact du plan de Fleur Pellerin. On verra l’an prochain si elle a eu un impact et quel est son ampleur ». Aujourd’hui on peut observer l’arrêt de cette dégradation. C’est déjà pas mal. Mais il faut encore un peu de temps pour constater un redressement.

La mauvaise nouvelle est que la France n’est remontée que d’une place et elle se trouve loin derrière les premiers de la classe. Elle est encadré d’une part par le Qatar et les Emirats Arabes Unis, et de l’autre par l’Irlande et la Belgique.

Classement 2014 des pays selon le Networkeed Readiness Index

 Si on compare la position de la France à ceux des pays voisins et comparables on constate que ceux-ci sont nettement mieux classés. Ainsi la Grande Bretagne est en 9^ème position et l’Allemagne est à en 12^ème place. La France est loin derrière ses compétiteurs directs.

Le "Top ten" du classement

 Les pays leaders et les autres

Les dix premiers pays de la liste sont : la Finlande, Singapour, la Suède, la Hollande, la Norvège, la Suisse, les Etats-Unis, Hong-Kong, la Grande-Bretagne et la Corée. Cette liste est assez stable dans le temps. Les six premiers du classement sont les mêmes qu’en 2013 et sont aux mêmes places.

Deux pays rentrent dans ce classement : Hong-Kong qui est passé de la 14^ème place au 8^ème et la Corée qui passe du 11^ème rang au 10^ème. Deux pays sortent de la liste : le Danemark qui passe de la 8^ème à la 13^ème place et Taiwan du 10^ème à la 14^ème place. La Grande-Bretagne et les Etats-Unis ont permuté entre la 7^ème à la 9^ème place.

Une fois de plus on constate que sur les dix premiers pays du classement six sont européens et ce sont tous des états de l’Europe du Nord ou assimilé : la Finlande, la Suède, les Pays-Bas, la Norvège, la Suisse et la Grande Bretagne. En tête du classement il n’y a aucun pays de l’Europe du Sud !

Les 28 premiers pays du classement

 La deuxième partie du classement est composé pour l’essentiel de pays riches et souvent européens comme le Luxembourg, l’Allemagne, le Danemark, Taiwan, Israël, le Japon, le Canada, l’Australie, l’Islande, la Nouvelle Zélande, l’Estonie, l’Autriche, la Qatar, les Emirats Arabe Unis, la France, l’Irlande, la Belgique, Malte, Bahreïn et la Malaisie. On note dans cette liste d’un certain nombre de pays asiatiques et pétromonarchie du Golfe. 

L’Europe du Sud commence à partir de la 25^ème place avec la France, suivie par le Portugal (33^ème), l’Espagne (34^ème), l’Italie (58^ème) ([1]), la Grèce (74^ème),…. On observe qu’en Europe il y a manifestement deux approches différentes des TIC comme on le constate en matière financière. L’Europe du Nord fait les bons choix, réalise les bons investissements, dégage une contribution significative des TIC à l’augmentation de la valeur ajoutée et crée de nombreux emplois qualifiés. Les autres ont plus de mal à dégager des résultats significatifs. Ce sont les PIGS.

Il est à noter que les BRICS, qui sont habituellement présentés comme les espoirs de la croissance de demain, se situent dans le classement du WEF entre la 50^ème et la 83^ème place : Brésil (69ème), Russie (50ème), Inde (83^ème au lieu de la 68^ème en 2013), Chine (62ème) et l’Afrique du Sud (70ème). Manifestement ces pays, qui sont censés prendre dans les années à venir le relais des pays développés, seront tôt ou tard freinés par leurs retards dans le domaine des investissements en TIC.

Les pays se trouvant dans la deuxième partie du tableau (à partir du 75^ème rang) sont pour l’essentiel des états d’Afrique, d’Amérique Latine ou d’Asie comme le Mexique (79^ème), l’Egypte (91^ème), le Maroc (99^ème), l’Argentine (100^ème), l’Iran (104^ème), le Venezuela (106^ème), le Pakistan (111^ème), le Nigéria (112^ème , le Bengladesh (119^ème), l’Algérie (129^ème), … Ces états n’ont pas de politique claire dans le domaine des TIC et n’ont pas effectué les investissements nécessaires. De plus, ils sont pénalisés par le faible niveau de leur PIB et par le médiocre niveau de leurs investissements. Dans ces conditions ils auront beaucoup de mal à bénéficier des avantages des TIC dans les années à venir et on peut craindre que leur position va continuer de se dégrader comme l’Inde qui est passée en un an du 68^ème rang au 83^ème, le Brésil du 60^ème au 69^ème, l’Egypte du 80^ème au 91^ème, le Maroc du 89^ème au 99^ème, ….

La France : Une grande continuité dans la fragilité

La France n’est pas dans ce cas. Mais il est difficile de se contenter de la 25^ème place quand on prétend être la 5^ème nation dans le monde. On notera que son rang a varié dans le temps mais la valeur de son indicateur NRI est très stable dans le temps. Il est aujourd’hui égal à 5,1 comme l’an passé. Mais en 2007 il avait déjà la même valeur. Il a légèrement augmenté en 2008 à 5,2 puis il est retombé à 4,9 en 2010. En fait, ce qui a changé ce n’est pas l’index de la France mais ceux des différents autres pays qui ont profité de l’après-crise pour effectuer des efforts importants dans le domaine des TIC et ainsi améliorer leur position concurrentielle.

Fiche d'évaluation NRI de la France en 2014

 L’examen de la fiche de calcul de la France (page 143 du rapport) montre que les faiblesses de notre pays  sont les mêmes d’une année sur l’autre (Voir sur ce blog le message du 6 juillet 2013 : Economienumérique : la France classée au 26ème rang mondial par le Forum de Davos). Elle concerne pour l’essentiel 3 domaines sur les 10 identifiés :

·       La facilité de mise en œuvre : 72^ème. Ce positionnement calamiteux pèse lourd dans le médiocre rang de la France. Il est dû aux tarifs des télécommunications notamment ceux des mobiles qui sont parmi les plus élevés au monde (124^ème),

·       L’environnement des affaires et l’innovation : 47^ème. Plusieurs facteurs expliquent cette mauvaise situation notamment le poids des taxes sur les bénéfices (la France est au 136^ème rang !! avec un taux de prélèvement de 64,7 %), la « timidité » du venture capital, le faible niveau des achats publics dans les nouvelles technologies et le nombre faible d’étudiants dans l’enseignement supérieur (la France est au 45^ème rang !).

·       L’impact social : 35^ème. Ceci est dû au faible usage d’Internet dans les écoles et l'utilisation des TIC par l’administration et leur efficacité.

Comme on le voit il serait assez simple de corriger la plupart de ces faiblesses, il suffit d’en avoir la volonté. Quasiment toutes dépendent de décisions des instances publiques sauf la médiocrité du venture capital. Faut-il encore avoir une idée claire des faiblesses de l’économie numérique en France ! Or « la feuille de route » de Fleur Pellerin ignore la plupart de ces points.

Heureusement à côté de ces points faibles il y a quelques points forts. Ils sont au nombre de trois :

·       Les compétences : 19^ème. Ceci est dû au taux de scolarisation dans le secondaire, au faible taux d’illettrisme et à la qualité de l’enseignement des mathématiques et des sciences.  

·       Les impacts économiques : 19^ème. On note le nombre élevé de salariés ayant un haut niveau de connaissance, le nombre de brevets concernant les applications des TIC et l’impact positif des TIC sur les nouveaux produits et services.

·       Les usages dans l’entreprise : 20^ème. Ceci est dû à la capacité d’innovation et le nombre de brevets pris.

Mais ces quelques points forts ne sont pas suffisants (en nombre et en niveau) pour contrebalancer l’effet des nombreux points faibles. De plus ils ne concernent pas directement les TIC mais le contexte social et économique général.

S’inspirer du premier de la classe

Pour la deuxième année consécutive la Finlande est le 1^ère pays du classement. La comparaison de sa fiche de calcul à celle de la France permettant de constater une différence fondamentale : la France a peu de points d’excellence et un nombre élevé de points faibles.

Elle n’a qu’un seul indicateur sur 54 classée 1^er et aucun indicateur se trouvant entre la 2ème à la 4ème place. Par contre elle souffre de nombreux points faibles : 16 des 54 indicateurs du NRI sont au-delà du 40^ème rang. Leur liste est impressionnante, en dehors de ceux déjà cités on note :

·       l'efficacité du système juridique pour régler les différends,

·       la couverture du réseau mobile,

·       le tarif de l’abonnement fixe à Internet,

·       la qualité du système d’éducation,

·       le taux de souscription au téléphone mobile,

·       l’usage des réseaux sociaux virtuels,

·       l’importance de la formation continue du personnel,

·       l’importance des TIC dans la vision du gouvernement,

·       le succès de l’effort public de promotion des TIC,

·       l’impact des TIC sur les nouveaux modèles d'organisation.

La Finlande, au contraire, a 7 indicateurs en 1^ère place et au total 21 indicateurs entre la 1^ère et la 5^ème place. Elle a aussi des points faibles mais ils sont nettement moins nombreux que ceux de la France. Ainsi la Finlande n’a que 5 indicateurs situés au-delà du 40^ème rang alors que la France en a 16. C’est le secret : avoir quelques points d’excellence et ne pas avoir trop de points faibles.

Fiche d'évaluation NRI de la Finlande en 2014

 Et maintenant que faire ?

Dans les messages précédents nous avions proposés six mesures :

1.         S’inspirer des pays voisins se trouvant en tête du classement comme la Finlande Suède, las Pays-Bas, la Norvège, la Suisse ou la Grande-Bretagne, le Luxembourg,…Il n’y a pas de honte à copier les bons élèves.

2.         Améliorer l’environnement économique et notamment en simplifiant le contexte administratif et réglementaire tout particulièrement en luttant contre les nombreux dysfonctionnements de la justice commerciale et de l’administration. 

3.         Avoir une politique publique positive en faveur des TIC basée sur une vision claire de l’impact des TIC sur le développement économique. Il est nécessaire de faire connaître les succès et diffuser les bonnes pratiques.

4.         Réduire la tarification des télécommunications. L’action de Free dans le domaine du téléphone mobile est un premier pas mais il y a encore des progrès importants à réaliser dans ce domaine notamment en ce qui concerne les tarifs hors-forfaits.

5.         Inciter les entreprises moyennes et grandes à investir dans les TIC. Tous les plans publics misent sur les PME. Il faut au contraire miser sur le rôle des grandes entreprises qui ont les moyens de financer ces projets.

6.         Favoriser les capacités des entreprises du secteur de l’économie numérique à l’exportation. Il faut développer les coopérations entre les entreprises pour les inciter à intervenir dans ce domaine et faciliter leur présence au niveau mondial.

J’ajouterais à cette liste deux mesures complémentaires :

7.         Inciter les entreprises à investir dans les TIC en autorisant l’amortissement des études débouchant sur des applications rentables. Pour favoriser le développement de certaines applications notamment pour la création de nouveaux services basés sur les TIC il serait souhaitable de mettre en place un mécanisme de crédit d’impôt.

8.         Développer la formation à l’informatique notamment en matière de développement et la connaissance des systèmes d’information. On ne forme pas assez de professionnels de l’informatique et ceux qui sont formés ne sont pas toujours adaptés aux besoins ([2]).

Il est pour cela indispensable de mettre en place une « feuille de route » sérieuse qui permettent de développer réellement le secteur de l’économie numérique.

Voir sur le même sujet sur ce blog :"Le classement informatique du World Economic Forum : Une triste réalité", paru le lundi 19 mars 2012, "Economie numérique : la France classée en 2013 au 26ème rang mondial par le Forum de Davos" paru le samedi 6 juillet 2013 et "Le Classement du World Economique Forum 2015 : La France perd une place" paru le mercredi 10 juin 2015

---

[1] - On notera que l’Italie est passée en un an de la 50^ème place en 2013 à la 58^ème en 2014.

[2] - On estime qu’on forme chaque année de l’ordre de 3.000 informaticiens du niveau ingénieur alors qu’il en faudrait 10.000 (Il faut se rappeler qu’on ne forme en France que 30.000 ingénieurs par an. Pendant ce temps les USA en forme 137.000 et la Chine 350.000). L’objectif de la « feuille de route » de Fleur Pellerin est de doubler leur nombre d’ici 2017. Mais ce nombre est surement insuffisant. A cela s’ajoute la formation des programmeurs et des métiers basés sur l’emploi des systèmes d’information, curieusement appelée dans la « feuille de route » les « métiers du numérique ».