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 ». 

Le problème du périmètre fonctionnel

Certains projets ont encore tendance à dériver. Ils durent plus longtemps que prévu et finissent par coûter plus cher qu’espéré. Selon la dernière étude du Standish Group ([1]) 43 % des projets dérivent ([2]). C’est beaucoup mais par rapport à la même enquête effectuée il y a vingt ans on constate un net progrès (courbe rouge). A l’époque 53 % des projets dérivaient. En vingt ans on a gagné 10 %. C’est pas mal, cela représente un progrès moyen de 0,5 % par an. C’est un peu lent car, à ce rythme il va être nécessaire d’attendre 80 ans pour voir disparaître toute dérive des projets informatiques.

Evolution des pourcentages de réussite, de dérive et d’échec des projets selon les enquêtes du Standish Group

Heureusement on a assisté pendant ces mêmes années à une diminution significative du nombre de projets qui échouent. C’était jadis la plaie des grands projets. En vingt ans le taux d’échec est passé de 31 % à 18 % (la courbe verte). C’est un progrès considérable mais on constate depuis le début des années 2000 à une sorte de résistance de cette tendance à la baisse. En effet on était arrivé à 15 % en 2002 puis au cours des années suivantes ce pourcentage est curieusement remonté pour atteindre 24 % en 2008. Heureusement il est revenu à 18 % en 2012. A quels facteurs seraient dus cette remontée ? Relâchement des efforts de rigueur, recours à des démarches agiles mal maîtrisées ? …

Comme le montre la courbe des projets réussissant dans les budgets et les délais prévus le pourcentage de ces projets est passé en 20 ans de 16 % à 39 % (courbe bleu). C’est un progrès considérable. En gros le taux de succès des projets augmente d’un peu plus de 1 % par an. Dans les années le nombre de projets réussissant dans le budget et le planning prévus sera supérieur à celui de ceux qui dérivent.

Ces progrès sont dus à l’influence de nombreux facteurs. Parmi ceux-ci un des plus significatifs est la diminution de l’instabilité fonctionnelle des projets. Celle-ci est facile à apprécier : selon le moment et l’interlocuteur consulté le contenu de la future application varie de manière significative car chaque partie prenante à sa propre vision de la future application. Cette instabilité ne peut que se traduire par des dérives significatives. Pour limiter ce risque il est nécessaire de stabiliser le plus vite possible son périmètre fonctionnel et de faire savoir ces choix à tous les intéressés.

Un mot un peu barbare

Le terme « périmètre fonctionnel » peut paraître étrange et complexe ([3]). C’est pourtant une notion très simple. C’est une démarche permettant de définir le contenu de la future application et aussi ce qui n’en fait pas partie. En général l’ensemble des parties prenantes sont d’accord sur le noyau de l’application par contre il existe des approches très variables concernant les fonctions périphériques.

Ainsi dans une comptabilité générale le noyau comprend la saisie des écritures comptables et éditer des journaux, une balance et un grand livre. Personne n’a de doute sur la nécessité de ces fonctions. Par contre on peut s’interroger sur la nécessité de gérer les comptes clients à l’aide de ce même système et notamment la relance des clients.

La définition de la frontière fonctionnelle de l’application est toujours une opération délicate. Il existe toujours des situations délicates et, si on n’y prend pas garde, on risque de se retrouver avec de nombreuses zones floues. On ne peut pas l’éviter. Il faut simplement veiller à ce que leur importance soit limitée. Plus l’incertitude est importante plus la probabilité de dérive est élevée.

Pour lever ces ambiguïtés une première approche consiste à identifier l’ensemble des objets à produire. Pour cela on va définir :

-      la liste des fonctions à mettre en œuvre. Généralement dans une application il existe entre 5 et 10 fonctions, rarement plus. Elles figurent normalement dans la barre de commande située en haut de l’écran. Ce sont généralement des verbes d’action comme : saisir, contrôler, consulter, éditer,…

-      les sous-fonctions détaillent le contenu de chaque fonction. Elles figurent dans les menus déroulants ou dans le ruban. Il y a entre cinq et vingt sous-fonctions par fonction. Certaines applications peuvent avoir des centaines sous-fonctions mais la plupart des applications traditionnelles comprennent moins de 100 sous-fonctions.

-      les tâches sont les différentes options offertes par une sous-fonction. Elles figurent normalement dans des boites de dialogues. 

Le tableau ci-dessous donne un exemple de la décomposition en fonctions et en sous-fonctions d’une application de facturation.  

Analyse en fonctions et en sous-fonctions

 Mais il est aussi possible de définir le périmètre fonctionnel d’une application à l’aide d’un schéma. Cette approche permet de comprendre les relations de l’application avec ses voisines, les interfaces et les bases de données partagées ([4]). Ainsi la facturation se déverse dans la comptabilité clients et à en commun avec cette application la base de données des clients.

Cartographie du périmètre fonctionnel de la facturation 

Le périmètre fonctionnel permet d’évaluer l’importance des développements à effectuer et ainsi d’en déduire la charge de travail nécessaire, le budget et le planning du projet.

Fixer le plutôt possible le périmètre fonctionnel

En effet, pour arriver à fixer un planning et un budget il est au préalable nécessaire d’avoir stabilisé le périmètre de la future application. Avant d’avoir fait ce travail il est toujours délicat de dire combien cela va coûter. Il est difficile de chiffrer quelque chose tant qu’elle n’a pas été définie. Dans ces conditions la stratégie consistant à stabiliser le périmètre fonctionnel le plus tardivement possible n’est pas la meilleure approche pour maîtriser les risques liés à un projet. Plus on repousse le moment de la stabilisation du périmètre fonctionnel plus la maîtrise du processus est délicate et donc plus la probabilité de dérive du projet augmente.

Au contraire la bonne pratique consiste à le stabiliser le plutôt possible, c’est-à-dire dès la première étude concernant le projet. Selon l’entreprise elle s’appelle l’expression des besoins, l’étude de faisabilité ou d’opportunité, le dossier d’investissement, le business case,… Les noms sont différents mais d’un document à l’autre on retrouve les mêmes éléments et en particulier la définition du périmètre fonctionnel.

Normalement, dans le cours ultérieur du projet, il ne doit pas y avoir de remise en cause du périmètre fonctionnel. Il est par contre très fréquent qu’il y ait des rectifications de frontière. Généralement elles concernent des points mineurs. Cependant, si ces changements portent sur des points essentiels cela signifie qu’il est probablement nécessaire de revoir le budget du projet et donc son planning de réalisation.

L’impact des rectifications mineures de frontière

Un calcul simple permet de mesurer l’impact de ces rectifications. Dans une application moyenne il y a 10 fonctions qui ont chacune 10 sous-fonctions soit au total 100 sous-fonctions. L’oubli d’une sous-fonction comme un écran de consultation ou l’édition d’un état représente statistiquement 1 % du budget. Par contre l’oubli d’une fonction complète c’est un risque de dérapage de 10 %. Or, il arrive qu’on puisse oublier au départ deux ou trois fonctions importante qui vont apparaître au moment de l’analyse fonctionnelle, voire de la programmation. Leur découverte tardive ne peut que se traduire par des dérapages significatifs des délais et du budget du projet.

Ces différents travaux et notamment l’analyse fonctionnelle n’ont pas pour but de découvrir de nouvelles fonctions à traiter mais de détailler celles qui sont identifiées. Ceci peut, le cas échéant, amener à rectifier les frontières du périmètre fonctionnel mais pas à les déplacer.

Dans le cas des projets simples ce travail peut se faire en une seule étape mais dès que la future application est un peu compliquée on a intérêt à procéder en trois temps :

-      l’expression des besoins afin de fixer le périmètre fonctionnel, len budget et le délai du projet,

-      l’analyse fonctionnelle permet de vérifier que tout ce qui a été demandé par le métier a bien été identifié, Ceci se traduit par une série d’exigences ([5]).

-      l’analyse détaillée définit la manière dont seront produits les différents services demandés.

A la fin de l’analyse fonctionnelle il est trop tard pour corriger le tir

Parfois, pour différentes raisons, dont certaines sont parfaitement honorables, on a tendance à repousser le moment de la stabilisation du périmètre fonctionnel jusqu’à la fin du processus d’établissement du cahier des charges. C’est en particulier le cas lorsque les points de vue des différentes parties-prenantes concernées par le projet sont très divergents. Dans ce cas on profite des groupes de travail créés dans le cadre de l’analyse fonctionnelle pour chercher à dégager un consensus et généralement on l’obtient. Cette approche est intéressante mais elle a souvent pour effet d’accumuler le nombre de fonctions et de sous-fonctions à mettre en œuvre. Cela risque de se traduire par un alourdissement de la conception de la future application avec des risques significatifs de dérive du projet.

En fait, à la fin de l’analyse fonctionnelle il est un peu tard pour stabiliser le périmètre fonctionnel car à ce moment on a déjà dépensé environ 20 % du budget du projet. Si on constate qu’il faut revenir sur les choix préalablement effectués la dérive risque d’être alors conséquente. Pour éviter ce type de situation il est préférable de fixer le plutôt possible le périmètre fonctionnel et de s’tenir.

Pour établir un budget et un planning il est nécessaire d’avoir stabilisé le périmètre fonctionnel

Il est difficile de lancer un projet sans avoir une idée du budget et du délai nécessaire pour le mener à bien. La décision dépend en grande partie de ces deux informations. Il est, pour cela, nécessaire d’avoir au préalable stabilisé le périmètre fonctionnel. Comme, généralement la décision du « go-no go » est prise à la fin de l’étude d’expression des besoins il est logique que ces choix aient été arrêtés à ce moment-là.

Sur la base du nombre de fonctions et de sous-fonctions identifiées on va s’efforcer d’estimer la charge. Ce n’est pas simple car à ce stade du processus de définition du contenu de la future application ses concepteurs ne connaissent pas le détail des opérations qui vont devoir être réalisées. Pour effectuer ce premier chiffrage on procède par analogie avec des projets similaires. Cela donne des phrases du type : « on est plus tôt autour de 1.000 jours » ou bien « on est entre 800 ou 1.200 jours ». Ce premier chiffrage est ensuite affiné à la fin de l’analyse fonctionnelle.  

Sur la base de cette estimation on va établir un premier planning du projet compte-tenu de la disponibilité des équipes et des compétences nécessaires. Ce sera le « baseline ». Elle permettra ensuite d’évaluer les décalages constatés. De même on effectuera un premier chiffrage du budget du projet qui permettra d’apprécier l’importance d’éventuelles dérives.

Si on s’aperçoit que le projet ne rentre pas dans le planning ou dans le budget prévu il est alors possible de revoir le périmètre fonctionnel de la future l’application. Il est alors possible de chercher à le restreinte au seul noyau et de repousser une partie des demande à la prochaine version. Dans certains cas on peut envisager d’éclater le projet en deux et de confier leur réalisation à deux équipes différentes ou choisir de faire réaliser les deux projets successivement par la même équipe.

Une autre approche est possible !

Face à l’approche classique réputée lourde et lente on oppose souvent une possible démarche plus légère et plus rapide : l’approche agile. Ses défenseurs affirment que les projets connaissent moins d’échecs et moins de dérive. Comme on ne disposait pas jusqu’alors de statistiques il fallait les croire sur parole. Le rapport 2013 du Chaos Report du Standish Group analyse les probabilités de succès ou d’échec des petits projets (1 million de dollars en coût de développement ([6])) selon qu’ils utilisent une démarche en cascade ou une approche agile.

	Enquête Globale	Démarche Agile	Approche cascade
Succès	39 %	46 %	49 %
Dérive	43 %	48 %	43 %
Echec	18 %	6 %	8 %

Taux de succès, de dérive et d’échec des petits projets selon la démarche utilisée : agile ou cascade

On constate que les petits projets réussissent mieux que les grands car ils ont un taux d’échec plus faible. Mais surtout on observe qu’il n’y a pas de différence significative entre les deux approches. Plus étonnant : le modèle en cascade a un taux de succès supérieur à la démarche agile : 49 % contre 46 %. A l’inverse les projets en suivant une approche de type cascade dérivent moins : 43 % contre 48 %. Cependant, il faut être prudent, les écarts sont faibles et peu significatifs. Ce tableau montre, que contairement à ce qui est souvent affirmé, le recours aux démarches agiles n’améliore pas significativement les taux de succès des projets.

Ceci explique peut-être le faible rythme de baisse du pourcentage des projets dérivant qui sont passés en vingt ans de 53 % à 43 %. Les démarches de type agile ont l’avantage d’éviter de devoir effectuer une analyse fonctionnelle qui est toujours une étape longue mais elles n’évitent pas les risques de dérive. Pour lutter contre celle-ci la bonne pratique consiste à renforcer le travail effectué en amont notamment lors de l’expression des besoins de façon à avoir un périmètre fonctionnel stabilisé dès le début du processus de gestion de projet.

En guise de conclusion

Cette bonne pratique est évidente et devrait être connues de tous mais, il faut bien le constater, ce n’est pas toujours le cas. La preuve : le niveau élevé des projets qui dérivent reste encore important. Au lieu de s’échiner à trouver la démarche parfaite, qui n’existe peut-être pas, on devrait plutôt concentre les efforts sur la définition rapide du périmètre fonctionnel.

---

[1] - Chaos Manifesto 2013, Think Big, Act Small, The Standish Group.

[2] - La dérive moyenne des délais observée est de 74 % et la dérive des coûts est de 59 %. Dans ces cas on ne délivre en moyenne que 69 % des fonctions prévues. La dérive des délais et des coûts sont liés.

[3] - En anglais on utilise le terme « scope ». On peut le traduire par champ. En français on l’utilise peu et à peine plus celui de champ fonctionnel.

[4] - On appelle parfois ce type de représentation de l’urbanisme. Le terme est un peu grandiloquent. Celui de schéma fonctionnel est plus juste.

[5] - Le terme exigence est une mauvaise traduction de l’anglais requirement. Le terme spécification aurait été plus juste.

[6] - A mon avis en fixant le seuil des grands projets à 1 million de dollars le Standish Group met la barre un peu haute. Un projet d’un million de dollars est de l’ordre de 1.500 jours-hommes. Cela me semble un seuil un peu trop élevé. Personnellement, j’aurais plutôt mis le seuil vers 250.000 euros soit 340.000 dollars correspondant à environ 500 jours-hommes.