ROI des projets IA : la formule complète et les éléments cachés

Trente ou quarante milliards de dollars investis par les entreprises dans l’intelligence artificielle générative, et 95 % des organisations n’enregistrent aucun retour sur leur compte de résultat. Les données proviennent de The GenAI Divide: State of AI in Business, l’étude du projet NANDA du MIT Media Lab basée sur 52 business cases, 153 questionnaires adressés aux hauts dirigeants et l’analyse de 300 initiatives publiques.

Le chiffre a circulé bien plus que la méthode qui l’a produit, et il faut le dire : 52 entretiens ne constituent pas un échantillon statistique représentatif, la définition du rendement retenue est celle de l’impact mesurable sur le compte de résultat, et plusieurs initiatives exclues pourraient produire de la valeur à plus long terme.

Mais le signal reste fort, et surtout l’explication des auteurs est vérifiable pour quiconque a vu de près un projet : la différence entre ceux qui obtiennent des résultats et ceux qui n’y parviennent pas est organisationnelle plutôt que technologique.

Le coût des licences représente moins d’un cinquième du total

UN analyse de rentabilisation typique met une économie estimée d’heures comme numérateur et les honoraires du fournisseur comme dénominateur. Cette fraction produit presque toujours des rendements spectaculaires, et c’est pourquoi les projets sont si facilement approuvés et rejetés tout aussi facilement.

Il manque quatre entrées et, ensemble, elles dépassent de loin la licence.

• Intégration avec les systèmes existants, qui dans des contextes de gestion stratifiée absorbe plus de jours que la configuration du modèle n’en absorbe.
• La préparation des données, qui, dans les projets arrivés en production, vaut souvent la moitié de l’effort.
• Surveillance continue, car le système doit être surveillé, les cas limites doivent être collectés et les configurations revues lors des mises à jour du fournisseur.
• Le temps des personnes qui réalisent le processus aujourd’hui, retiré du travail en cours pour des sessions de validation et de formation.

Un ordre de grandeur qui sert à démanteler la fraction optimiste : dans les projets suivis jusqu’à la production, l’honoraire du fournisseur dépasse rarement 20 % du coût total de la première année. Qui construit le analyse de rentabilisation de l’autre 80% invisible il construit un engagement qu’il ne tiendra pas.

Les heures économisées ne se transforment pas en dollars jusqu’à ce que quelqu’un les réaffecte

Du côté des bénéfices, l’erreur est en miroir et plus insidieuse, car elle semble rigoureuse. On mesure le temps que nécessitait l’activité avant, on mesure ce qu’elle nécessite après, on multiplie la différence par le coût horaire et par le nombre de répétitions annuelles. Le résultat est un grand nombre faux.

Ce chiffre ne devient vrai que si l’une des trois choses suivantes se produit : l’organisation réduit la capacité utilisée sur ce processus, ou augmente le volume géré pour le même nombre de personnes, ou réaffecte le temps libéré aux activités génératrices de revenus. Si aucun des trois ne se produit, le temps gagné est perdu dans la journée de travail et le compte de résultat ne s’en aperçoit pas.

La conséquence pratique est que le analyse de rentabilisation il doit être rédigé en collaboration avec ceux qui dirigent la fonction, et pas seulement avec le service informatique, et doit contenir une déclaration explicite sur ce qui est fait du temps libéré. Une phrase, avec un nom et une date. C’est la ligne qui distingue un projet générateur de valeur d’une démonstration réussie.

Il existe également des avantages qui méritent d’être pris en compte séparément, car ils sont réels et difficiles à monétiser : réduction des écarts qualitatifs entre opérateurs, temps d’intégration plus court pour les nouveaux embauchés, récupération de connaissances qui vivent aujourd’hui dans la tête de peu de gens. Les placer dans une colonne distincte, déclarée comme non monétisée, rend l’analyse de rentabilisation plus crédible, pas moins.

La formule complète tient en deux lignes

Le calcul qui résiste à l’examen d’un directeur financier est moins élégant que celui qui circule dans les présentations, et s’écrit ainsi.

Le dénominateur est le coût total de la première année : frais du fournisseur, plus coût d’intégration, plus coût de préparation des données, plus coût de suivi annuel, plus coût d’adoption interne.

Au numérateur, le bénéfice obtenu, c’est-à-dire la part des heures libérées qui a une destination déclarée, valorisée au coût total de l’entreprise, plus les revenus supplémentaires attribuables, moins les coûts évités qui auraient de toute façon été éliminés pour d’autres raisons.

Au cours de la deuxième année, la situation change considérablement, car l’intégration et la préparation des données ne sont pas répétées tant que les bénéfices se poursuivent. Un projet avec un rendement négatif la première année et positif la seconde est un projet normal, et le présenter ainsi protège contre des révisions difficiles au premier trimestre. Le présenter comme positif à partir du troisième mois garantit cependant que quelqu’un demandera les chiffres avant que le système ne soit pleinement opérationnel.

Il faut ajouter un élément que presque personne ne mentionne et que les modèles prépayés rendent nécessaire : le coût d’exploitation variable augmente avec l’utilisation. Un pilote sur vingt personnes et une version sur deux mille ont des structures de coûts différentes, et le business case qui extrapole linéairement à partir du pilote sous-estime systématiquement la facture d’exploitation.

Mesurez avant de signer, par rapport à une référence qui existe

La contrainte la plus dure de tout l’exercice se situe avant le projet. Pour démontrer une amélioration, vous devez savoir combien de temps le processus a pris, combien d’erreurs il a produit, combien de fois il a fallu le retravailler. Dans la plupart des organisations, ces données n’existent pas et sont reconstruites après coup en demandant une estimation aux personnes, ce qui est le moyen le plus rapide de rendre le résultat indiscutable et inutile.

Deux semaines de mesure avant le départ changent complètement la solidité de ce qui peut être dit après. Une référence est nécessaire sur trois quantités : le temps nécessaire pour parcourir le processus, le taux de reprise, le volume traité au cours de la période. Si le processus n’est mesurable sur aucun des trois, le cas d’utilisation doit être choisi différemment, car tout résultat sera une opinion.

La mesure doit ensuite être répétée avec le même instrument à trois et six mois, et voici l’effet qui ruine la plupart des évaluations : la courbe d’apprentissage. Les premières semaines sont toujours pires que prévu, car les gens apprennent et le système reçoit des cas extrêmes. Quiconque mesure trente jours et conclut que cela ne fonctionne pas s’intéresse à l’apprentissage et non à la performance.

Ceux qui ont mis des projets en production le reconnaissent : le retour d’un projet d’IA ne se découvre pas, il se construit et implique presque toujours une décision organisationnelle que le business case rend explicite des mois avant que quiconque ne doive le prendre.