Les actions de logiciels ont perdu environ mille milliards de dollars de capitalisation boursière au début de 2026, et l’étiquette qui est restée, « SaaSpocalypse », a conduit tout le monde à se poser la même question : est-ce que certaines entreprises de logiciels existeront encore. Ce n’est pas la bonne question, ou du moins elle est incomplète. La meilleure question est de savoir si une entreprise peut protéger sa valeur terminale : sa capacité à rester compétitive face aux entreprises d’IA émergentes et à adopter le même état d’esprit et le même rythme d’innovation. Le chiffre du mille-milliards de dollars donne l’impression que toute la catégorie est en train de mourir. En réalité, ce qui se passe, c’est une dispersion. Certaines entreprises de logiciels ont regagné des hausses à deux chiffres depuis la vague de ventes. D’autres sont encore en baisse de 60 % ou plus par rapport à leurs sommets. Le récit global de la catégorie masque celui, plus utile, qui se trouve en dessous.

La véritable fracture

Le cadre « Moat & Journey » de Morgan Stanley « Moat & Journey » l’explique bien : il s’agit d’une segmentation en trois groupes, et non de deux. Il y a des entreprises sans véritable avantage défendable : des produits légers posés au-dessus du workflow de quelqu’un d’autre, faciles à répliquer maintenant que l’IA a fait chuter le coût de création d’un clone acceptable. Il y a des entreprises dotées d’un avantage défendable, mais devenues complaisantes : une vraie capacité de défense aujourd’hui, mais aucun réinvestissement dans ce qui vient ensuite. Cela érode la valeur terminale plus lentement que l’absence totale d’avantage défendable, mais cela l’érode tout de même. Et il y a des entreprises dotées d’un avantage défendable qui utilisent l’IA pour l’étendre, en approfondissant le workflow, les données et la confiance qu’elles ont déjà construits avec leurs clients. Seul ce troisième groupe protège réellement sa valeur terminale. 

Le test pratique

Cette segmentation en trois groupes explique aussi pourquoi l’arbitrage build vs. buy revient sans cesse comme une question d’actualité au sein des organisations finance, et c’est le même raisonnement que j’ai exposé dans une précédente édition : achetez les fondations, construisez l’avantage. Le marché du SaaS est désormais en train de valider cette logique à grande échelle, avec les valorisations des entreprises plutôt que des budgets de mise en œuvre.

C’est la même raison pour laquelle les organisations finance achètent leurs systèmes de référence plutôt que de les développer. Le droit fiscal, les normes IFRS et les exigences d’audit évoluent. Un système interne conçu pour répondre aux questions réglementaires d’aujourd’hui devient obsolète dès que ces questions changent — et en finance, elles changent en permanence. Acheter signifie qu’un éditeur absorbe le coût nécessaire pour suivre cette évolution sur des milliers de clients plutôt que sur un seul. L’IA exerce désormais la même pression sur toutes les autres décisions de build, parce que la cible vers laquelle vous développez ne reste pas immobile assez longtemps pour qu’un développement puisse réellement se terminer.

J’en ai entendu une version par un banquier qui a pris exactement cette décision au début de sa carrière. Son équipe a développé une solution logicielle au lieu d’en acheter une. Cela a fonctionné, jusqu’à ce que les ingénieurs qui l’avaient construite quittent l’entreprise. Personne parmi ceux qui restaient ne comprenait suffisamment le système pour le faire évoluer, et le coût de cette décision a fini par se chiffrer en millions. Les outils de codage par IA rendent cette histoire plus fréquente, pas moins. Ils accélèrent le développement initial, mais ne rendent pas le code sous-jacent plus documenté ni plus transférable.

Le niveau d’exigence de la finance

La finance a moins de marge d’erreur que la plupart des fonctions qui doivent trancher. Une réponse exacte à 90 % ne suffit pas lorsque le résultat alimente le reporting externe ; la comptabilisation du chiffre d’affaires et la facturation sont des exemples qui doivent être exacts à 100 %. Il existe de réelles conséquences, même en cas d’écart minime, susceptibles de nuire à la fois à l’entreprise et à la réputation des dirigeants. Un système interne doit également résister à un audit et, le cas échéant, devant un tribunal. 

Avant de valider un développement aujourd’hui, nous posons ces questions : 

1. Est-ce au cœur de ce que nous vendons, ou s’agit-il d’une infrastructure qui le soutient ? 
2. Cela sera-t-il encore différenciant dans dix-huit mois, ou un éditeur livrera-t-il la même capacité sous forme de fonctionnalité et nous forcera-t-il à reconstruire autour de la sienne ? 
3. Si l’ingénieur qui l’a développée avec un outil de codage par IA quitte l’entreprise, quelqu’un d’autre comprend-il réellement comment cela fonctionne ?
4. Cela résistera-t-il à un audit et à l’examen des autorités de régulation ?

La discipline qui protège la valeur terminale

Bien faire les choses revient à une seule habitude, rigoureuse : chiffrer le coût complet du cycle de vie avant que l’équipe ne s’éprenne d’un prototype. Un gain rapide peut justifier un développement sur mesure, mais un besoin de long terme exige un plan clair de détention et de maintenance pour s’assurer que cela ne devienne pas la dette technique de demain. Le même test s’applique lorsque vous êtes, vous, évalué en tant que fournisseur. L’avantage défendable n’est plus l’interface. C’est la profondeur du produit, le niveau de confiance qu’un client peut accorder au système, et la manière dont il s’intègre au fonctionnement réel de l’entreprise. Les produits peuvent être copiés plus vite que jamais, mais les modèles de monétisation, les workflows et la confiance construite sur des années, eux, ne le peuvent pas.

Tous les SaaS ne se valent pas, et l’IA n’a pas créé cet écart. Elle a simplement conduit le marché à le valoriser, en fonction de ceux qui protègent la valeur terminale plutôt que de ceux qui « ont de l’IA ». C’est le même test que la finance devrait appliquer à chaque décision de build qu’elle approuve.

Poursuivre la conversation

Du lancement produit au chiffre d’affaires comptabilisé : un parcours Zuora AI au cœur du Quote-to-Cash 

Si la valeur terminale provient de plus en plus de la capacité d’une entreprise à opérationnaliser la complexité, la vitesse de mise en œuvre devient un élément clé. Passer de plusieurs mois à quelques semaines se traduit par une création de valeur plus rapide, une visibilité plus précoce sur les décisions en aval et une plus grande capacité à traiter la prochaine priorité stratégique. Dans cette session à la demande, découvrez comment l’IA peut transformer les contrats, les règles de tarification et les workflows déjà en place dans l’entreprise en un modèle opérationnel de son processus quote-to-cash avant même le début de l’implémentation. 

Étude de cas Hyland 

Pour Hyland, la création de valeur relève moins de la seule vitesse que de ce que permet, dans la durée, une meilleure infrastructure finance. Avec Zuora Revenue, l’équipe a ramené sa clôture de 12 jours à 3, automatisé les allocations de SSP et les exclusions contractuelles, et donné à la comptabilité des revenus davantage de capacité pour examiner les transactions plus tôt et soutenir l’activité de manière plus stratégique.

Pour accompagner le passage d’un chiffre d’affaires SaaS prévisible à des modèles d’IA dynamiques, les équipes finance doivent évoluer d’une planification annuelle statique vers une prévision continue fondée sur l’usage. Commencez par auditer votre pipeline de données actuel afin de vous assurer que vous pouvez suivre, en temps réel, les coûts d’infrastructure parallèlement à l’usage client. Ensuite, mettez en place une boucle de rétroaction étroite entre l’ingénierie, l’IT et la FP&A afin de relier directement la consommation de tokens ou la puissance de calcul à l’économie unitaire, ce qui vous permet d’ajuster les prix et les niveaux d’investissement avant que les marges ne soient affectées.

Chaque requête d’IA entraîne un coût associé, et comme l’usage client varie fortement d’un compte à l’autre et que les dépenses d’infrastructure fluctuent selon le modèle retenu, la relation entre revenus et coûts devient beaucoup plus dynamique. Cette complexité rend plus difficile la prévision de la rentabilité avec le même niveau de confiance, et soulève une question importante : la finance dispose-t-elle de la visibilité nécessaire pour comprendre les facteurs financiers sous-jacents à l’IA ?

Pour acquérir l’anticipation nécessaire afin de prévoir les marges, évaluer la tarification et orienter l’investissement, les équipes finance doivent faire évoluer leur approche de planification de manière proactive. Premièrement, auditez en quoi les facteurs propres à l’IA diffèrent des métriques SaaS traditionnelles : l’usage, les coûts d’infrastructure et les dépassements. Deuxièmement, identifiez les lacunes de données : pouvez-vous suivre les marges par client ? Les coûts par requête ? L’usage vs les dépassements ? Troisièmement, restructurez vos modèles de planification afin d’intégrer ces variables spécifiques. 

Les sections ci-dessous montrent comment — et en quoi cela diffère du SaaS traditionnel.

Passer de métriques fixes à des facteurs variables pilotés par l’IA

Si l’objectif central de la planification — protéger les marges et orienter l’investissement — reste inchangé, les facteurs ont fondamentalement évolué. La planification traditionnelle s’appuyait sur des métriques stables telles que les effectifs et des paliers d’abonnement fixes. À l’ère de l’IA, ils sont remplacés par des dépenses d’infrastructure variables, des coûts liés au choix du modèle et des schémas d’usage client très individualisés. La finance doit désormais concilier les coûts fixes du développement avec les coûts de délivrance, variables et fondés sur les requêtes.

Cela implique que la finance comprenne de nouveaux déterminants de la performance : le coût de traitement des requêtes d’IA, les produits qui génèrent les marges les plus élevées, la manière dont les clients consomment les ressources d’infrastructure et l’impact, sur la rentabilité, des schémas d’usage tels que les crédits non utilisés et les dépassements. Ces métriques constituent le socle pour prévoir la performance et identifier où l’entreprise crée de la valeur et où elle doit investir ensuite.

Prenez l’exemple des crédits d’IA engagés. Tous les clients ne vont pas consommer les crédits de la même manière. Certains laisseront une capacité achetée inutilisée, tandis que d’autres dépasseront systématiquement leurs engagements. Ces schémas d’usage influencent les marges, les décisions de tarification et les investissements futurs. Les comprendre aide la FP&A à prévoir la performance plus précisément et à identifier des opportunités d’affiner le packaging, d’améliorer l’adoption ou d’ajuster la tarification dans le temps.

Ces métriques aident la FP&A à prévoir la performance, à évaluer les investissements et à planifier avec davantage de confiance à mesure que l’adoption de l’IA progresse.

Collaborer avec le produit et l’ingénierie pour concevoir votre modèle de données

Une grande partie des analyses dont la FP&A a besoin ne peut pas être construite après le lancement d’un produit d’IA. À ce stade, les décisions relatives aux données d’usage, à l’imputation des coûts et au reporting ont déjà été prises. Si la finance n’est pas impliquée en amont, la planification devient nettement plus difficile.

La FP&A doit travailler aux côtés des équipes produit, ingénierie et opérations lors de la conception de nouvelles offres d’IA afin de s’assurer que l’entreprise peut mesurer les métriques les plus critiques. Cela inclut la compréhension de la manière dont l’usage sera suivi, dont les coûts seront imputés et dont la performance sera évaluée dans le temps.

Cela signifie également anticiper les métriques dont la finance aura besoin une fois les produits d’IA sur le marché. À quel point la capacité non utilisée est-elle prévisible selon les segments de clientèle ? Quel est l’impact sur la marge si l’entreprise choisit de ne pas facturer certains dépassements ? Les schémas d’usage évoluent-ils à mesure que les clients gagnent en maturité ? Ce sont des questions de planification, et y répondre exige de disposer des bonnes données dès le premier jour.

Lorsque ces éléments de base sont en place dès le départ, la FP&A peut prévoir avec davantage de confiance, évaluer les décisions de tarification plus efficacement et aider l’entreprise à s’adapter à mesure que le comportement client évolue.

Exploiter des analyses d’usage fines pour optimiser la rentabilité

Une meilleure visibilité transforme également les échanges que la FP&A peut avoir avec le business. Au lieu de se contenter d’indiquer que l’adoption de l’IA a augmenté, la finance peut aider à répondre à des questions plus stratégiques. Investissons-nous dans les bonnes capacités d’IA ? Quels segments de clients génèrent les marges les plus saines ? Devons-nous ajuster la tarification ou le packaging ? Les coûts d’infrastructure augmentent-ils comme prévu ?

Ce sont ces décisions qui façonnent la croissance à long terme. Lorsque la FP&A comprend les leviers financiers sous-jacents à l’activité, elle peut dépasser le simple reporting des résultats et devenir un partenaire stratégique plus solide.

L’avenir de la FP&A

Alors que l’IA continue de remodeler la manière dont les entreprises conçoivent, tarifient et monétisent leurs produits, la FP&A a l’opportunité d’influencer la façon dont ces entreprises se développent. Les responsables finance qui comprennent de manière proactive leurs pipelines de données, collaborent avec les équipes produit et ingénierie, et construisent des modèles de planification spécifiques à l’IA orienteront de meilleures décisions d’investissement, évalueront de nouveaux business models, optimiseront la tarification et s’adapteront plus vite à mesure que les marchés évoluent.

C’est là que la FP&A peut créer une valeur stratégique durable.

Continuer à explorer

Évaluation de la complexité des revenus

La multiplication des bundles, l’expansion internationale et la tarification des produits d’IA créent un niveau de complexité des revenus que de nombreuses équipes ont du mal à maîtriser. Réalisez l’évaluation de Zuora pour identifier les principaux facteurs de complexité dans votre entreprise et obtenir des recommandations personnalisées sur la manière de commencer à les traiter.