Un abonnement logiciel donne une impression de simplicité. On souscrit, on paie au mois ou à l’année, le service est délivré, et le contrat semble se gérer de lui-même. C’est précisément cette tranquillité apparente qui devrait alerter. Le plus souvent, dans un contrat SaaS, les écarts tarifaires et les risquent ne se manifestent que peu souvent sous la forme d’un incident spectaculaire. Ils apparaissent en silence, au fil des renouvellements, des montées en charge et des fonctionnalités qu’on active sans toujours en mesurer la portée.
En tant que contract manager, cet article n’aborde pas le sujet des licences et du logiciel sous l’angle du droit d’auteur ou de la propriété intellectuelle. Il a vocation à aborder les sujets sur lesquelles un contract manager peut agir, c’est-à-dire le pilotage des engagements dans la durée, une thématique rendue plus que contemporaine par l’irruption de l’intelligence artificielle dans les offres des éditeurs, rendant les questions de pilotage plus sensibles qu’elles ne l’ont jamais été.
SaaS, licence ou encore abonnement : de quoi parle-t-on ?
Trois notions sont régulièrement confondues, alors qu’elles n’engagent pas du tout la même relation contractuelle. En premier lieu, la licence perpétuelle est un droit d’usage acquis une fois pour toutes. C’est le modèle des anciens CD de Microsoft Office que l’on achetait en magasin, que l’on installait sur son poste et que l’on utilisait ensuite aussi longtemps qu’on le souhaitait. L’entreprise paie à l’entrée, installe le logiciel sur ses propres environnements et l’exploite sans dépendre de l’éditeur pour le faire fonctionner. La maintenance et les mises à jour relèvent d’un contrat distinct, mais le droit d’usage, lui, reste acquis.
L’abonnement dit « on-premise », que l’on retrouve notamment dans les secteurs sensibles, introduit une location plutôt qu’un achat, tout en conservant une installation locale (d’où sa dénomination). Le logiciel demeure hébergé chez le client, mais le droit d’usage devient temporaire et conditionné à un paiement récurrent.
Le SaaS, pour Software as a Service, va plus loin. Le logiciel n’est plus installé chez le client, il est hébergé et exploité par l’éditeur, puis consommé à distance. Là où l’on achetait jadis un CD d’Office en magasin, on enregistre désormais ses coordonnées bancaires sur une plateforme Microsoft (ou autre) et l’on paie aussi longtemps que l’on utilise le service. L’entreprise n’achète plus un produit, elle souscrit à un service dont la disponibilité, les évolutions et l’hébergement reposent entièrement sur le fournisseur.
En pratique, peu d’organisations n’utilisent qu’un seul modèle. La plupart pilotent un parc hybride, où des licences historiques cohabitent avec des abonnements récents, on-premise ou en SaaS. Cette coexistence est une difficulté en soi, puisqu’elle oblige à raisonner simultanément selon deux logiques de risque opposées.
L’évolution des modèles a déplacé le risque
Le risque contractuel n’a pas disparu avec le passage de la licence perpétuelle au SaaS (ou dit autrement, avec la dématérialisation du logiciel), il a simplement changé de place. Chaque fois que le modèle d’usage a évolué, le point où se concentre l’exposition s’est déplacé avec lui. Deux mouvements successifs méritent qu’on s’y arrête, car ils n’appellent pas les mêmes réflexes.
Le premier mouvement va de la licence perpétuelle au SaaS. Avec la licence, le risque se concentrait à l’achat. Une fois la décision prise et le droit d’utilisation acquis, l’entreprise maîtrisait son exploitation, quitte à vieillir avec une version figée. Le SaaS déplace ce risque vers l’exécution continue. Le service vit, change, augmente, et la dépendance à l’éditeur s’installe dans la durée. Le rapport de force évolue lui aussi avec le temps. Plus l’usage s’ancre dans les processus, plus il devient coûteux d’en sortir, et plus le levier de l’éditeur se renforce à chaque renouvellement.
Le second mouvement est plus récent. Il sépare le SaaS d’avant l’IA (en gros de 2000 à 2020), du SaaS que l’on connaît désormais intégrant l’IA s’invite dans presque toutes les offres. Des questions hier théoriques deviennent concrètes. La pérennité même de certains modèles économiques interroge, lorsque le prix d’un service dépend en amont du coût au token facturé par les fournisseurs de grands modèles de langage. Des décisions publiques peuvent restreindre l’accès à certaines fonctionnalités, et l’actualité récente (ces derniers jours avec Anthropic qui a coupé l’accès au modèle Fable 5 à tous les « non-américains ») a montré que cet horizon n’avait rien d’abstrait. L’arbitrage entre faire et acheter, enfin, ne se pose plus uniquement au moment de la décision initiale. Bâtir sa propre solution outillée par l’IA, hier hors de portée pour la plupart, devient une option crédible, ce qui change la nature même de l’engagement qu’on accepte de prendre. Derrière tout cela, une constante demeure, à savoir la valeur que le logiciel crée, celle qu’un coût de sortie élevé peut détruire, et la flexibilité qu’on a su, ou non, se réserver dans l’exécution.
Cinq points de vigilance en contract management
Les métriques de facturation
Le premier changement à observer (et à prendre en compte) est que le prix affiché n’est plus le bon indicateur tant les grilles évoluent vite !
Ce qui mérite l’attention, c’est le coût induit, c’est-à-dire ce que déclenche réellement l’unité de facturation une fois le service en production. On est passé de l’utilisateur nommé ou concurrent, lisible et prévisible, à des métriques de consommation dont le token est aujourd’hui l’exemple le plus parlant.
Activer une brique d’IA revient à accepter une facturation au volume consommé, par nature mouvante et délicate à modéliser en amont. Comprendre la métrique ne consiste donc plus à négocier un nombre de sièges, mais à anticiper une trajectoire de consommation. Cette trajectoire pose aussitôt la question de sa vérification, sur laquelle nous revenons plus bas.
L’évolution tarifaire et modalités de renouvellement
Au-delà des métriques abordées ci-dessus, c’est sur l’évolution et le renouvellement que se situe l’un des plus gros foyers de (sur)coûts. Entre indexation annuelle, clauses de hausse encadrées de façon trop large, reconduction tacite, préavis de dénonciation calibrés à l’avantage de l’éditeur, il existe autant de mécanismes qui paraissent anodins pris isolément et qui, cumulés, verrouillent une relation économiquement non souhaitée.
Le fil directeur tient en une idée simple, se ménager une ou plusieurs possibilités concrètes de sortie, ou encore encadrer les possibilités d’évolution tarifaire avec des seuils. Le contract manager doit travailler à rendre ses droits de résiliation concrets, mesurables et activables, pour ne pas se retrouver prisonnier de la relation contractuelle.
Les engagements et niveaux de services
Si dans le précédent modèle SaaS, les indicateurs existaient, tels que des taux de disponibilité ou d’uptime, ces derniers étaient en pratique assez peu suivis. Ce laxisme n’a plus sa place dès lors que l’on automatise des pans entiers d’activité et qu’on en vient à dépendre de l’IA pour produire de la valeur.
La disponibilité cesse alors d’être un indicateur de façade pour devenir une mesure du risque opérationnel réel et plus généralement un facteur clé de continuité de services. Ce niveau d’exigence ne se rédige pas seul dans son coin. Il se construit avec les utilisateurs, le métier et l’éditeur, afin d’évaluer ensemble ce qui se passe vraiment lorsque le service s’interrompt, et calibrer des engagements qui circonscrivent ce risque au lieu de l’éluder.
L’audit d’usage et de conformité
Le risque classique subsiste. L’éditeur conserve un droit d’audit, les régularisations en matière de sur-déploiement peuvent être lourdes, et l’accès indirect, lorsqu’un autre système vient consommer le service, reste un usage facturable que beaucoup découvrent tardivement. À cela s’ajoute une dépendance informationnelle propre au SaaS, où la plateforme mesure tout, et où le client a besoin de sa propre visibilité sur la consommation réelle pour ne ni surpayer des licences dormantes, ni se découvrir non conforme.
L’IA introduit un troisième niveau, sans doute le plus délicat. La consommation de tokens est une donnée produite par l’éditeur, et elle est difficilement vérifiable par le client, pour ne pas dire pas vérifiable du tout. On facture sur un compteur que l’on ne tient pas, que l’on ne peut pas répliquer, et dont on n’a (presque) aucun moyen indépendant de contester la justesse. L’asymétrie est d’une nature inédite. Ce n’est plus l’éditeur qui audite le client, ni le client qui peine à s’auditer lui-même, c’est le client qui doit s’en remettre à une mesure qu’il subit. À défaut de pouvoir vérifier, la vigilance se reporte sur ce que le contrat peut exiger, à savoir la transparence sur la méthode de comptage, une journalisation accessible, des plafonds et des alertes, un droit de réconciliation, et lorsque c’est envisageable un mécanisme de contestation.
La réversibilité et la maîtrise du switching cost
La question de fond n’est pas seulement de pouvoir partir, mais de savoir à quel prix, et dans quel état on récupère ses données. Sous quel format elles sont restituées, dans quel délai, avec quelle documentation, et au prix de quels efforts de réintégration. Ce sont ces conditions, bien plus que la clause de résiliation elle-même, qui déterminent le coût réel d’un changement (sans compter la dimension culturelle ou « change management »). Une réversibilité mal négociée transforme une liberté théorique en dépendance de fait. Nous avons consacré un article entier à ce sujet et il prend dans le contexte SaaS une acuité particulière.
Le contract manager doit intervenir en amont
Ces cinq points ont un dénominateur commun : aucun ne se traite utilement dans l’urgence. La métrique se comprend avant la signature, la fenêtre de sortie se négocie quand on a encore le choix, les engagements de service se calibrent avant la mise en production, et les conditions de réversibilité se posent au moment où l’on entre dans la relation, pas quand on cherche à en sortir. Il est ainsi indispensable pour le contract manager IT de s’intégrer aux phases avant-signature du cycle de vie des contrats, et pas de s’intéresser uniquement à l’exécution.
En effet, le contrat SaaS (en dehors des développements spécifiques et de l’intégration) se signe et se négocie en amont, une fois signé il ne reste qu’à subir. Si le contract manager se borne à intervenir en phase d’exécution, son impact peut rapidement se révéler négligeable du fait des stipulations contractuelles convenues, limitant son champ et ses leviers d’action.
Plus généralement, cette évolution des modèles de contrats SaaS contribue à repositionner le contract manager IT. Le réduire à un appui administratif une fois le contrat signé, n’a jamais été tout à fait juste, et l’est de moins en moins. Dans une économie de l’abonnement où l’arbitrage entre faire et acheter se rejoue en permanence, et où la valeur d’un service se crée ou se détruit pendant son exécution, le contract manager devient le garant de cette valeur sur toute la durée de vie du contrat. Cela suppose de dialoguer avec les équipes techniques, financières et métier autant qu’avec l’éditeur, et de raisonner en termes d’actifs logiciels et de coûts dans la durée, pas seulement en termes de clauses.
Conclusion
Le contrat SaaS est un objet vivant. Sa valeur ne se capte pas à la signature, elle se pilote dans le temps, à mesure que les usages s’étendent, que les prix bougent et que les fonctionnalités se transforment. L’IA n’a rien inventé de ce mécanisme, elle l’a accéléré et rendu plus visible. Là où la maîtrise de ces contrats relevait hier d’une bonne pratique parmi d’autres, elle devient une condition de la performance, et c’est une excellente nouvelle pour le contract management.
