Le run-rate, pas le prix du projet : ce que le logiciel coûte vraiment sur cinq ans

Mettez deux montants côte à côte. Le premier figure en gras sous un devis : le prix de la construction, unique, payé la première année. Le second n'apparaît sur aucune ligne, et pourtant il revient chaque mois tant que le système tourne. Les directions signent pour le premier montant et vivent des années avec le second. C'est le mauvais ordre.

Le montant qui compte s'appelle le run-rate : la charge fixe qui revient chaque mois jusqu'à ce que quelqu'un éteigne le système. Avec un logiciel que vous louez par utilisateur, cette charge grandit avec votre personnel. Vous embauchez dix personnes, la facture augmente, que ces dix-là ouvrent ou non les modules les plus chers. La dépense dépend de votre taille, pas de ce que le logiciel vous rapporte. Et la taille est justement ce dont une entreprise en croissance a chaque année davantage.

Ce que le prix par utilisateur coûte vraiment sur cinq ans

Prenez un tarif concret. Microsoft facture Dynamics 365 Finance 210 dollars par utilisateur et par mois, et 300 dollars pour la variante Finance Premium. Mettez-y cinquante personnes : 210 dollars, fois cinquante, fois douze mois, et vous atteignez 126.000 dollars par an, avant même qu'un seul euro d'implémentation ne s'y ajoute. Et l'implémentation elle-même va généralement de 250.000 à plus de 1,5 million de dollars. Ce montant mensuel n'est donc pas le début de la facture. C'est la partie qui ne s'arrête plus jamais.

Étalez cela sur soixante mois et le tableau bascule. Cinquante utilisateurs à 210 dollars, cela fait sur cinq ans 630.000 dollars de licences uniquement, sans l'implémentation, sans indexation, sans les nouvelles personnes que vous embauchez entretemps. Chaque tête qui s'ajoute inscrit son propre tarif mensuel au compteur. Le prix de construction unique que vous trouviez si élevé devient, sur cette échelle de temps, l'un des postes les plus modestes.

La fuite qui n'est pas encore dans le calcul

Et vous payez encore pour des sièges qui restent vides. Le rapport Flexera 2024 State of ITAM chiffre que les organisations gaspillent 20 % à 30 % de leurs dépenses informatiques, et que plus de la moitié des licences SaaS ne sont pas utilisées. Dans un modèle par utilisateur, ce n'est pas un cas marginal mais le cœur de la construction : la facture compte des têtes, pas de l'usage. Quelqu'un part, le siège reste dans le décompte. Un département achète des licences pour un projet qui s'arrête au bout d'un an, et la dépense continue simplement. Vous payez pour l'accès, pas pour la valeur.

Il y a encore une couche sous les licences : la maintenance des systèmes que vous faites déjà tourner. Les systèmes vieillissants portent une dette technique, et cette dette a un prix. McKinsey (2020) l'estime à 20 % à 40 % de la valeur de l'ensemble de votre paysage technologique, et chiffre que 10 % à 20 % du budget destiné aux nouveaux produits sert à la résorber. Chaque euro qui va là ne construit rien. Il paie une facture du passé. Une plateforme en propriété inverse cette logique : le coût suit l'infrastructure que vous faites réellement tourner, pas le nombre de noms sur une liste d'utilisateurs.

Le prix du projet, vous le payez une fois. Le run-rate, vous le payez jusqu'à ce que vous éteigniez le système.

Où se trouve l'argent après cinq ans

Soyez honnête sur l'autre versant. Construire une plateforme est un véritable investissement initial. Vous payez la première année plus que ne coûte une licence mensuelle, et cet argent est parti avant que le système n'ait économisé une seule facture. Celui qui fait comme si une construction ressortait toujours immédiatement moins chère vous vend quelque chose. Le point n'est pas le montant de départ. C'est l'endroit où se trouve l'argent après soixante mois.

Mettez donc les deux échéanciers côte à côte plutôt que les deux prix. Louer par utilisateur : un démarrage bas, puis un montant qui revient chaque année et augmente avec chaque tête et chaque indexation. Construire en propriété : un démarrage plus élevé, puis un run-rate qui suit les serveurs et le stockage que vous utilisez réellement. Le moment où ces deux lignes se croisent dépend de la vitesse à laquelle vous grandissez, mais elles se croisent, et à partir de ce point le locataire continue de payer chaque mois tandis que le propriétaire paie surtout de l'infrastructure. Nous construisons cette plateforme par vagues avec un go/no-go à chaque étape, pour que l'investissement initial ne devienne pas un pari sur une seule date, mais une série de décisions qui exigent chacune leurs propres preuves.

• Votre facture suit les serveurs et le stockage, pas le nombre de têtes sur la feuille de paie.
• La croissance sollicite l'infrastructure, pas chaque nouvel utilisateur avec son propre tarif mensuel.
• Le code se trouve dans votre propre dépôt, transférable, sans licence qui continue de tourner par siège.
• Pas de sièges vides dans le décompte, puisqu'il n'y a pas de décompte par siège.

La première étape n'est pas de construire, et ce n'est pas non plus de signer. C'est de calculer. Posez trois chiffres côte à côte : ce que vous payez cette année en licences, combien de ces sièges sont réellement utilisés, et ce que devient ce même modèle sur cinq ans si votre personnel grandit comme vous le prévoyez. Presque personne ne connaît ces trois chiffres par cœur. Un audit IT FinOps les met sur papier, à prix fixe et neutre par rapport aux fournisseurs, avec une baseline que votre propre finance cosigne.

Ensuite, ne comparez pas deux prix mais deux échéanciers. La question n'est pas ce que coûte la construction face à la licence du mois prochain. La question est de savoir quel modèle vous appauvrit sur soixante mois, et quel modèle laisse le coût évoluer avec ce que vous faites tourner plutôt qu'avec qui vous embauchez. Celui qui fixe le prix du projet voit l'option bon marché. Celui qui additionne le run-rate voit l'option chère.