18 Productivité et TICs

Un article qui ne voulait pas accoucher, sur l’éthique des TICs, qui seraient à la fois les meilleures et les pires des choses.

Finalement 3 articles dont voici le premier : TICs et productivité.

Le suivant devrait traiter : « les TIC, l’IA : diaboliques, angéliques ? ».

Et enfin la rupture TIC du troisième millénaire conduira-t-elle à une nouvelle guerre du feu ?

Pour l’instant, parlons économie, et d’abord microéconomie.

Il y a eu une phase de doute sur le lien entre productivité et investissement dans les TIC aux alentours des années 2000. En fait aujourd’hui, le doute n’est plus de mise, en particulier parce que dans un même secteur on observe une corrélation forte entre investissements d’une entreprise dans les TICs et sa performance.

Mais il faut avoir en tête un certain nombre d’éléments. Les gains de productivité varient selon les secteurs d’activité et évoluent dans le temps. Dernièrement les gains semblent être surtout dans les services, par exemple bancaires.

Ensuite les projets TICs amènent rarement des gains s’ils ne sont pas inscrits dans une réingénierie des processus et des savoirs de l’entreprise. Dans le temps, l’idée que à laquelle je tiens, était justement que, côté métier, il n’y a pas de projets TICs : il n’y a que des projets « métier » avec une composante TIC. Faute de quoi l’échec ou le semi-échec sont garantis. Et les coûts d’investissement échoués font évidemment baisser les ratios de productivité des TICs.

Il faut pouvoir aussi mesurer la productivité ramenée par exemple à l’heure de travail : or une partie de la productivité se traduit par une plus grande flexibilité et une plus grande qualité de la production des biens ou des services : on ne sait pas très bien ni mesurer ni valoriser ces facteurs.

Et attention, on sait mesurer dans certains secteurs la baisse de main d’œuvre à production constante : mais si l’on mesure la productivité en la ramenant aux coûts salariaux, on risque d’être déçu. En effet les diminutions d’effectifs affectent essentiellement les salariés aux salaires inférieurs ou intermédiaires et l’on sait qu’une robotisation se traduit par des embauches de cadre et de techniciens plus diplômés, et donc payés plus cher : la masse salariale diminue mais moins relativement que le nombre d’heures de travail, toutes catégories confondues.

Autre point : les changements de paradigme permis par les nouvelles techniques compliquent aussi les analyses des gains en productivité. Ainsi si l’on prend le commerce, les gains permis par les TICs au niveau des commerces traditionnels sont très faibles. Cependant on assiste à une explosion de la vente en ligne : les gains de productivité ne peuvent être appréciés qu’en incluant ce nouveau paradigme dans l’analyse du secteur commerçant.

Je me suis intéressé essentiellement aux gains de productivité par rapport aux heures de travail. Mais les TICs permettent aussi des gains de productivité par rapport au capitale.  Par exemple, ils permettent de produire à flux tendus, ce qui permet d’éviter les stocks de biens intermédiaires et donc de baisser le capital circulant.

Côté macro-économie,

il y a un certain consensus aujourd’hui sur le fait que les TICs ont permis des gains de productivité, mais moins que ce que l’on attendrait.

S'il est déjà délicat de mesurer l’impact des TICs sur la productivité pour un secteur de production donnée, ça l’est encore plus au niveau global. On se heurte de plein fouet à l’ambiguïté du thermomètre PIB. Le plus souvent, en effet, les calculs sont faits grosso modo en divisant ce PIB par un nombre d’heures travaillées.

Or si la production des biens matériels est assez bien connue, une partie des services est peu ou mal mesurée. Par exemple, pour les services non-marchands, assurés par les collectivités et l’état, les montants sont évalués à leur coût de revient. Supposons qu’un coût de baguette magique Macronien permette de doubler les services rendus : à prix de revient équivalent, ça ne fera pas augmenter le PIB d’un iota. Et même plus, si l’on en profite pour réduire le nombre de fonctionnaires, le PIB baissera, et les gains de productivité... baisseront.

Globalement, en réalité, on retrouve les critiques qui sont faites au PIB quand il s’agit d’évaluer les coûts et les bénéfices des démarches environnementales. Exemple bien connu des Shadocks : pour augmenter le PIB il suffit de payer les uns pour faire des trous et les autres pour les boucher. Gaspiller fait monter le PIB, et encore plus si cela génère plus de déchets qu’il faudra traiter.

À l’inverse, si vous prenez des plates-formes d’intermédiation emblématiques comme BlaBlaCar ou Lebon Coin, la valorisation de leurs services se fait vraisemblablement au prix de vente de leurs services (abonnements, ou coûts des annonces).

Or leur valeur ajoutée n’est pas là et n’est pas comptabilisée : moins de transports traditionnels, une réutilisation massive de biens un peu défraîchis, utilisables, qui sans cela auraient fini au fond d’un grenier ou dans une benne à ordures.

Et non seulement ces économies ne sont pas comptabilisées, mais en plus elles contribuent à baisser le PIB et donc la productivité globale !

Autre point. En principe on raisonne à euros constants : on enlève l’inflation de l’augmentation du PIB. Et dans l’autre sens, mais pas toujours, on corrige, pour tenir compte de la baisse des biens ou services produits.

Mais très rarement tient-on compte des améliorations des produits ou services. Si l’on regarde les TICs, la puissance de calcul, ou le volume de données transmises, ramenés à l’euro

d’achat ont explosé en une génération. Les PCs d’aujourd’hui ont la puissance des gros bouzins d’antan pour un coût ridicule à l’aune des anciens monstres. Il est vrai que c’est moins marquant dans la plupart des autres secteurs, ce qui explique que les TICs sont quasiment le seul secteur économique ou quelques économistes ont tenté de tenir compte de cette véritable explosion.

Bref, ce n’est pas parce que le PIB stagne que le niveau de vie baisse ou que la productivité réelle n’augmente pas !

La suite au prochain numéro.

5 SI …politique

En tant que chef adjoint du département SI, je découvrais donc que le SI n’est pas qu’une simple affaire technique mais aussi une affaire économique et politique.

Avoir des vues stratégiques, bien fondées, sur le développement du SI ne suffit pas ! Il faut en convaincre toutes les parties prenantes : la Direction de l’entreprise, certes, mais aussi ce qu’il est convenu d’appeler les « métiers » et en tout premier lieu, leurs responsables. Le développement du SI en entreprise n’a de sens que si l’entreprise y voit son intérêt, sur le plan économique, à l’évidence, mais aussi sur les plans organisation et politique interne.

Au premier abord, le plan économique paraît facile à aborder : après tout, comme pour tout projet, on peut chercher le BiKet (Business Case !) d’un projet informatique.

On calcule son coût de réalisation - l’investissement initial -, ses coûts récurrents une fois le projet réalisé, et on compare aux recettes attendues. Si le ROI est au rendez-vous (Return on Investment), on y va…

De fait, progressivement, nous avons été amenés à formaliser la façon des monter les BK selon les types de projets informatiques.

Deux types de projet informatiques ont été pris en compte : les projets applicatifs dits métiers, et les projets dits d’infrastructure.

Les services d’infrastructure sont en fait des services mutualisés pour les applications ; serveurs, stockages mutualisés, réseaux…
Je ne détaillerai pas la façon de calculer les coûts d’investissement et les coûts récurrents d’un projet. Même si ce n’est pas toujours simple, c’est en général connu.

Mais les recettes ? En théorie, ce n’est pas compliqué, et il ne manque pas de bons auteurs pour gloser sur le sujet. On peut représenter la chose sur le schéma comme ceci :.

Pour évaluer les recettes d’une application métier, on va d’abord prendre en compte les gains (éventuels) sur l’exploitation de l’application. Si, si ça arrive, car les vieux bouzins finissent par coûter très cher et leur remplacement peut faire gagner de l’argent.

Mais le poste principal de recette réside en générale dans ce qu’il est convenu d’appeler les « gains métier ». J’en reparlerai.

Pour tout ce qui sert de support mutualisé aux applications métier, c’est un peu pareil.

L’exploitation d’une nouvelle infrastructure en remplacement d’une ancienne peut être très rentable, du fait des progrès continus de l’informatique qui conduisent à des matériels et des services plus performants pour des coûts inférieurs. Là aussi, ce sont surtout les gains pour les services supportés qui vont en général être les plus importants : les coûts récurrents des applications baissent. Mais il peut y avoir aussi des gains métier, plus difficiles à appréhender, du fait d’une meilleure disponibilité et d’une meilleure efficacité des applications.

Tout ça semble simple. C’est quand on commence à essayer de calculer tout ça que ça se complique.

D’abord, il y des applications qui sont difficiles à classer, et à vrai dire elles sont un peu intermédiaires entre les deux types précédents. Ce sont les applications qui sont transverses à l’entreprise, qui servent souvent aux applications, mais qui sont aussi tournées vers l’utilisateur dit final. Exemples : la messagerie d’entreprise, le poste de travail (quelle qu’en soit la forme : PC, tablette, smartphone), les RSE (réseaux sociaux d’entreprise). Et là, commencent les problèmes : si les gains d’exploitation pour une renouvellement d’application sont évaluables, c’est un acte de foi que d’évaluer les gains de productivité pour l’entreprise d’un RSE, ou d’une amélioration des postes de travail. Quelques minutes par jour gagnées, même multiplié par le nombre de salariés, ne convainc généralement pas les financiers. La disponibilité de salariés équipés de postes mobiles, tablettes ou smartphones, idem en général. Quant au RSE, les gains de créativité ou nés d’un travail plus transverse …

Mais en fait les gains métier, ne sont pas si faciles à évaluer non plus. Et le ROI sujet à caution. D’abord, il convient de rappeler ce qui devrait être une évidence : il n’y a pas de projet informatique métier. Il y a des projets métier avec une composante informatique et obligatoirement une composante métier : en général les processus métier sont impactés, et il y a des coûts de transition à prendre en compte. Insertion métier est un mot faible à cet égard (formations, reclassements, réorganisations…).

Et pour un projet métier identifié, il n’y a pas qu’une solution informatique : avec différents curseurs comme le degré d’automatisation, la facilité d’utilisation…

Le BiKet ne peut être que global au niveau du projet métier et les différentes alternatives se doivent d’être étudiées dans ce contexte global.

Cela signifie aussi que la maîtrise d’ouvrage d’un projet informatique métier ne peut être que subordonnée à la maîtrise d’ouvrage du projet métier : le projet informatique est un lot, qui peut très important, du projet métier. Faute d’avoir compris cela, combien de luttes intestines à l’entreprise ont lieu entre « l’informatique » et « le métier ».

Encore faut-il que le « métier », souvent très éloigné de la sphère informatique soit structurée pour décider et conduire ces projets à composante informatique.

Une des choses dont je suis fier, lors de mon passage à RTE, a été l’institution de programmes métiers, présidés par des décideurs du métier ; les commanditaires. Ces programmes géraient les projets, mais suivaient aussi l’ensemble des dépenses induites par l’utilisation de l’informatique. Ils avaient dont en principe tous les éléments pour optimiser les dépenses informatiques au sein du budget global métier.

Tout irait pour le mieux si cette logique n’était pas régulièrement battue en brèche par les financiers. Dans un contexte économique tendu, ceux-ci n’acceptent pas en général la hausse continue des dépenses informatiques … pourtant quasi inéluctables, du fait de la substitution croissante de la puissance informatique au travail surtout tertiaire. A production équivalente, la part du travail baisse dans le produit final, ce qui ne se voit que sur la durée et à condition de raisonner à production équivalente.

Nos financiers, donc, souvent court-termistes, imposent des contraintes budgétaires sur l’informatique prise dans son ensemble. Croissance zéro, voire baisse importante.

De fait, les coûts unitaires de l’informatique baissent régulièrement (5 à 10%) ce qui permet des développement informatiques même avec une croissance zéro des budgets.

Malheureusement, la pression est souvent beaucoup plus forte, à tels que l’on assiste à des paradoxes : le métier a le budget pour faire le projet métier, mais la contrainte sur les dépenses SI fait qu’il est impossible de le mener ! Souvent d’ailleurs le métier se débrouille pour que des dépenses SI ne soient pas comptabilisées en SI. De ce point de vue le développement (inéluctable)  du BAAS (ni Syrien, ni Irakien : Business As A Service) est une aubaine car il masque les dépenses informatiques sous-jacentes qui sont réalisées par le fournisseur du service.

Mais ça j’en reparlerai certainement dans la suite de ma chronique.