ROI d'un projet Power Platform : la méthode pour le chiffrer avant de lancer

Le low-code se vend bien parce qu'il promet de livrer vite et pour moins cher qu'un développement classique. Cette promesse est souvent tenue. Le problème est ailleurs : parce que le ticket d'entrée paraît faible, le projet est arbitré sans modèle économique, puis jamais réévalué. Douze mois plus tard, personne ne sait dire si l'application a rapporté quelque chose.

Le calcul n'est pourtant ni long ni complexe. Il tient sur une page, à condition de ne pas oublier les postes que tout le monde oublie.

Les quatre postes de coût

Poste	Ce qu'il recouvre	Erreur fréquente
Construction	Cadrage, conception, développement, recette, reprise des données existantes	Sous-estimer la reprise de données, qui pèse souvent 20 à 30 % de la charge sur un processus historique
Licences	Licences Power Apps ou Power Automate premium, capacité Dataverse, connecteurs premium	Chiffrer sur le pilote à 10 utilisateurs et découvrir la facture au déploiement à 400
Run et maintien en condition	Corrections, évolutions mineures, adaptation aux mises à jour et dépréciations Microsoft	Le poser à zéro. Une application non maintenue redevient un fichier Excel parallèle en 18 mois
Conduite du changement	Formation, documentation, support de premier niveau les trois premiers mois	Le poste le plus systématiquement absent des budgets, et le premier facteur d'échec d'adoption

Sur le run, une règle empirique couramment retenue consiste à provisionner l'équivalent de 15 à 20 % du coût de construction par an. Ce n'est pas une norme, c'est un point de départ à ajuster selon la criticité de l'application et le rythme d'évolution du processus.

Les trois postes de gain, et comment ne pas les gonfler

1. Le temps opérationnel libéré

C'est le gain le plus facile à calculer et le plus facile à surévaluer. Une heure libérée ne devient un euro que si elle est réaffectée à une activité à valeur, ou si elle évite un recrutement. Sinon, c'est du confort de travail : réel, appréciable, mais qui ne se présente pas devant une direction financière comme une économie.

2. Les erreurs et reprises évitées

Coût unitaire moyen d'une erreur multiplié par sa fréquence. C'est souvent le poste le plus important et le moins mesuré, parce que les erreurs de saisie et les doubles ressaisies ne sont enregistrées nulle part. Une estimation discutée avec les opérationnels vaut mieux qu'une case laissée vide.

3. Les coûts directement évités

Licence d'un outil tiers supprimé, prestation externe arrêtée, serveur décommissionné. Seul poste qui se traduit intégralement en trésorerie, et le plus solide en comité d'investissement.

Les deux indicateurs à présenter

Le gain annuel net se calcule ainsi : gains annuels moins coûts récurrents annuels (licences plus run). L'investissement initial regroupe la construction et la conduite du changement.

• Délai de retour = investissement initial ÷ gain annuel net. C'est le chiffre qu'un directeur financier regardera en premier.
• ROI à trois ans = (gain annuel net × 3 − investissement initial) ÷ investissement initial.

Fixez le seuil d'acceptation avant l'étude, pas après avoir vu le résultat. C'est la seule façon d'en faire un outil d'arbitrage plutôt qu'une justification rétroactive.

Un exemple chiffré, hypothèses explicites

Processus de validation des demandes d'achat, six valideurs, aujourd'hui traité par fichier Excel partagé et échanges par mail. Les chiffres ci-dessous sont un modèle illustratif destiné à montrer la mécanique, pas un résultat observé.

Ligne	Hypothèse	Montant annuel
Temps libéré	900 demandes par an, 25 min avant, 8 min après, soit 255 h ; coût chargé 45 €/h	+ 11 475 €
Erreurs évitées	Taux d'erreur de 4 % ramené à 1 %, reprise moyenne 90 €	+ 2 430 €
Licences	6 utilisateurs, licence premium	− 1 440 €
Run et MCO	Environ 20 % du build	− 2 800 €
Gain annuel net		+ 9 665 €

Côté investissement initial : 22 jours de construction à 650 € soit 14 300 €, plus 2 000 € de conduite du changement, soit 16 300 €.

Délai de retour : environ 20 mois. ROI à trois ans : environ 78 %.

Ce projet passe, mais sans marge. Et il ne passe que si les 255 heures libérées sont effectivement réaffectées. Si elles ne le sont pas, le seul gain réel devient les 2 430 € d'erreurs évitées, et le délai de retour dépasse six ans. C'est exactement le type d'arbitrage qu'un modèle rend visible avant l'engagement, et qu'un ressenti rend invisible pendant trois ans.

Les trois pièges qui faussent le calcul

• Compter les heures libérées comme de la trésorerie. Sans réaffectation explicite ni recrutement évité, ce gain reste théorique. Posez la question au responsable métier avant de l'inscrire.
• Extrapoler les licences linéairement depuis le pilote. Le modèle de licences Power Platform dépend des connecteurs utilisés, du mode d'attribution et du volume ; il se vérifie sur la cible complète, pas sur les dix premiers utilisateurs.
• Oublier le run. C'est le poste qui transforme un ROI brillant sur trois ans en résultat neutre, et une application abandonnée en Excel parallèle.

Questions fréquentes

Faut-il un modèle de ROI pour un projet de dix jours ?

Non, la modélisation coûterait plus cher que l'arbitrage qu'elle éclaire. En revanche, fixez un critère de succès mesurable et une date de revue, même pour un petit périmètre.

Qui doit produire ce modèle ?

Le métier fournit les volumes et les temps, la direction financière les coûts chargés, le prestataire la charge de construction et de run. Un modèle produit uniquement par le prestataire n'a aucune valeur d'arbitrage, quelle que soit sa qualité.

Comment mesurer le ROI après coup ?

En posant la mesure avant. Sans relevé initial des volumes, des temps et des taux d'erreur, il n'y a plus rien à comparer après la mise en service, et l'évaluation se réduit à une impression.