On oppose volontiers l'intelligence artificielle au modèle de l'abonnement, comme si la première venait bousculer le second. Les éditeurs qui ont passé dix ans à basculer leur produit en SaaS s'entendent aujourd'hui expliquer que la vraie rupture est ailleurs, et qu'ils ont peut-être couru après le mauvais train.

C'est presque l'inverse. Sans vingt ans de SaaS et de cloud, il n'y aurait pas d'IA industrielle intégrée au logiciel telle que nous commençons à la connaître. Il y aurait des modèles puissants, des démonstrations impressionnantes, des capacités accessibles par API. Mais beaucoup plus difficilement de l'intelligence artificielle dans les produits métier, à l'échelle, alimentée par le contexte réel des entreprises et améliorée en continu. Le SaaS n'est pas la victime de la vague actuelle : il en a construit une partie des fondations.

Cette affirmation mérite d'être démontrée plutôt qu'assénée. Elle change ce qu'un éditeur doit faire cette année.

Soixante ans d'attente, et deux verrous

L'intelligence artificielle n'est pas née en 2022. Le test de Turing date de 1950, le premier agent conversationnel des années 1960. À l'époque déjà, certains annonçaient que l'intelligence humaine serait reproduite en quelques décennies.

Elle ne l'a pas été, et les raisons sont documentées. Les premières approches étaient largement symboliques — on écrivait les règles à la main, une par une, dans l'espoir qu'elles finiraient par couvrir suffisamment de situations pour reproduire une forme d'intelligence. Elles se sont heurtées à la complexité du réel. Il manquait également deux ressources essentielles : la puissance de calcul et les données exploitables à grande échelle. Les périodes de désillusion qui ont suivi sont restées dans l'histoire du domaine sous le nom d'hivers de l'IA.

Puis un ordinateur a battu le champion du monde d'échecs, les méthodes statistiques et l'apprentissage automatique ont progressé. L'IA fonctionnait — mais souvent dans des cas spécifiques, sur des problèmes fermés et avec des jeux de données soigneusement constitués.

Le premier verrou a progressivement sauté avec l'explosion de la puissance de calcul, notamment grâce aux processeurs graphiques : des milliers d'opérations exécutées en parallèle, des calculs auparavant inaccessibles devenus industrialisables.

Le second verrou est plus intéressant pour les éditeurs : une partie des données et des infrastructures dont l'IA métier a aujourd'hui besoin s'est organisée pendant que nous poursuivions un tout autre objectif.

Le second verrou c'était NOUS.

Les grands modèles génératifs apprennent à partir d'immenses corpus de textes, de code, d'images et d'autres contenus provenant de sources multiples. Mais pour transformer un modèle généraliste en produit métier, il faut autre chose : lui donner accès au contexte. Aux clients, aux transactions, aux documents, aux historiques, aux workflows, aux permissions, aux décisions passées et, progressivement, aux résultats de ses propres actions.

La question devient alors : pourquoi une part croissante de ces données existe-t-elle aujourd'hui sous une forme accessible, structurée et exploitable par le logiciel ?

Parce que pendant vingt ans, l'industrie du logiciel a progressivement fait basculer les entreprises vers un modèle où les applications, les données et les usages sont de plus en plus centralisés, connectés et accessibles en continu.

Le logiciel installé chez le client produisait des données lui aussi. Mais elles étaient dispersées sur des milliers d'installations, parfois dans différentes versions, derrière différents systèmes et différents pare-feux. Les agréger, les observer et les exploiter à grande échelle était infiniment plus difficile.

Cet écart-là n'a pas été franchi pour l'intelligence artificielle : il l'a été pour réduire les coûts, simplifier l'exploitation, améliorer la disponibilité et accélérer la livraison du logiciel.

Le passage au SaaS et au cloud a changé cela sans que ce soit son objectif. Il a apporté six choses :

  • Disponibilité

    La donnée est là, en continu — pas dans une sauvegarde trimestrielle.

  • Agrégation

    Mille clients sur une plateforme font un corpus. Sur mille installations, mille silos.

  • Apprentissage

    Un modèle veut du volume et de la diversité : exactement ce que produit une base mutualisée.

  • Maîtrise des coûts

    L'élasticité du nuage a rendu abordable un calcul réservé hier à quelques laboratoires.

  • Mise à l'échelle

    Livrer une capacité à toute une base d'un coup, au lieu d'installation en installation.

  • Industrialisation

    Livraison continue, supervision, mesure : mettre en production une chose imparfaite et la corriger vite.

Aucune de ces six conditions n'a été construite pour l'intelligence artificielle. Toutes deviennent déterminantes lorsqu'on veut transformer l'intelligence artificielle en produit.

Trente ans d'industrialisation, et un changement d'objet

Il y a une façon simple de résumer le mouvement.

Pendant trente ans, nous avons industrialisé le logiciel : le sortir de l'artisanat, le rendre reproductible, distribuable, observable et exploitable à grande échelle. Ce travail a été long.

  1. 1970-1985 — Centralisation
  2. Le calcul vit au centre. L'utilisateur est au bout d'un terminal qui dispose de très peu de puissance propre.
  3. 1985-1995 — Client-serveur
  4. La puissance descend sur le poste de travail. Le logiciel s'installe, et il faudra le déployer, le maintenir et le mettre à jour installation par installation.
  5. 1995-2005 — Web
  6. Le navigateur devient progressivement l'interface. Le serveur reprend une place centrale et le logiciel commence à se délivrer à distance.
  7. 2005-2020 — SaaS et cloud
  8. Une même plateforme peut servir des milliers de clients. Les mises à jour deviennent continues. Les données et les usages deviennent observables à une échelle qui n'existait pas auparavant.

Chacune de ces quatre marches a été franchie pour des raisons qui avaient peu à voir avec l'intelligence artificielle : réduire les coûts, simplifier l'exploitation, accélérer les mises à jour, améliorer la disponibilité. Le résultat, lui, a progressivement été le même — rapprocher le logiciel, les données, les utilisateurs et les systèmes entre eux.

Aujourd'hui commence l'industrialisation de l'intelligence : rendre reproductible et exploitable à grande échelle une capacité qui ne se contente plus d'exécuter des règles écrites, mais qui interprète une situation, propose une décision et, de plus en plus, exécute une action.

Le premier chantier était une condition du second. On industrialise difficilement un système probabiliste si l'on ne sait pas déjà déployer en continu, mesurer son comportement, observer ses erreurs et corriger rapidement.

Le SaaS est le corps du logiciel ; l'intelligence artificielle peut désormais en devenir le cerveau. Un cerveau sans corps peut raisonner. Il ne peut pas agir.

Le logiciel cesse d'être un outil

Il y a une seconde rupture, et elle ne porte pas sur l'origine de la vague mais sur la nature de ce qu'on livre.

Pendant trente ans, l'essentiel du logiciel métier a été déterministe : on écrivait les règles, il les exécutait. Sa qualité se mesurait largement à sa prévisibilité — une même entrée devait produire la même sortie, et un comportement inattendu était généralement un défaut qu'il fallait reproduire, identifier puis corriger.

Ce qui arrive maintenant est d'une autre nature, et la différence tient à la forme de la sortie.

Une entrée, une sortie

Le résultat attendu est défini et reproductible. On peut largement le vérifier AVANT de livrer : un test compare la sortie attendue et la sortie obtenue.

Une entrée, une distribution

Plusieurs réponses sont plausibles, inégalement. Plusieurs réponses sont possibles, avec différents niveaux de pertinence. Le système en produit une. Il faut ensuite l'évaluer, la superviser et mesurer sa performance dans le temps.

C'est de cette différence que découle une grande partie du reste — et elle est plus profonde qu'elle n'en a l'air. Une réponse fausse n'est plus nécessairement un bug reproductible. Elle peut provenir du modèle, du contexte fourni, des données récupérées, d'une mauvaise orchestration ou d'une décision probabiliste qui sera différente à l'exécution suivante. On ne corrige donc plus uniquement en livrant un correctif : on agit aussi sur ce que le modèle voit, les outils auxquels il accède, les règles qui encadrent son action et les situations dans lesquelles un humain doit reprendre la main.

Les conséquences se lisent poste par poste.

Ce que ça change

Déterministe → probabiliste

Ce que ça change : Tester

Déterministe → probabiliste : LDéterministe → probabiliste : l'égalité ne suffit plus. On construit des jeux d'évaluation, on mesure la pertinence et les erreurs, puis on suit ces performances dans le temps.

Ce que ça change : Vendre

Déterministe → probabiliste : Déterministe → probabiliste : on ne promet plus seulement un comportement logiciel. On promet progressivement un niveau de résultat, dans certaines conditions, avec un certain niveau d'autonomie.

Ce que ça change : Supporter

Déterministe → probabiliste : Déterministe → probabiliste : une mauvaise réponse n'est plus systématiquement un ticket de bug. Elle devient aussi un signal permettant d'améliorer le contexte, les données, les règles ou les mécanismes de contrôle.

Ce que ça change : Contractualiser

Déterministe → probabiliste : éterministe → probabiliste : garantir la disponibilité d'un logiciel n'est pas la même chose que garantir la qualité d'une décision ou le résultat d'une tâche exécutée par ce logiciel.

Ce que ça change : Facturer

Déterministe → probabiliste : Déterministe → probabiliste : le nombre d'utilisateurs mesurait l'accès à l'outil. Il mesure beaucoup moins bien la valeur lorsque c'est progressivement le logiciel lui-même qui réalise une partie du travail.

Le logiciel n'est plus seulement un outil que l'on utilise. Il devient un acteur qui exécute. Et un acteur ne se vend pas, ne se teste pas, ne se contractualise pas et ne se facture pas comme un outil.

Ce que cela change, pour un éditeur, cette année

De cette généalogie découle une conséquence directe, et elle est inconfortable.

Hier

Le SaaS était un avantage compétitif

Aujourd'hui

Le SaaS est un prérequis

Un éditeur encore majoritairement installé chez ses clients peut évidemment intégrer de l'intelligence artificielle. Mais il part avec un handicap : il lui est plus difficile d'agréger le contexte, d'observer les usages, de mesurer les résultats, d'améliorer rapidement le système et de livrer simultanément ces améliorations à toute sa base. Il peut acheter un modèle ; il lui sera beaucoup plus difficile d'en faire une boucle d'apprentissage industrielle et un avantage compétitif durable.

Trois questions permettent de se situer honnêtement, et elles se répondent en une demi-journée :

  • Quelle part de votre base est réellement mutualisée ?

    Pas « disponible en SaaS » : réellement basculée. C'est ce chiffre, pas l'existence d'une offre, qui mesure votre capacité à observer et industrialiser les usages.

  • Vos données sont-elles agrégeables ?

    Juridiquement, techniquement et sémantiquement. Des données présentes mais impossibles à rapprocher ou inutilisables contractuellement constituent toujours un silo.

  • En combien de temps livrez-vous à toute la base ?

    Si la réponse se compte en trimestres, la boucle d'apprentissage qui fait la valeur d'un produit augmenté par l'IA tournera trop lentement.

Ceux qui répondent bien à ces trois questions vont accélérer. Les autres risquent de décrocher — non pas faute d'accès à l'intelligence artificielle, puisque les mêmes modèles seront accessibles à presque tous, mais faute des fondations qui permettent de la transformer en produit et en avantage compétitif.

Le cycle suivant est déjà engagé

Cette généalogie n'est pas une rétrospective. Elle sert à situer ce qui vient, et ce qui vient est déjà là chez quelques-uns.

Trois paliers se distinguent, et ils n'exigent pas la même maturité :

  • Copilotes et automatisation

    Le système conseille, rédige, résume ou exécute certaines étapes. L'humain conserve la décision et reste largement dans la boucle.

  • Agents

    Une tâche peut être exécutée de bout en bout. L'humain fixe l'objectif et supervise le résultat plutôt que chacune des étapes. Le logiciel commence réellement à devenir un acteur.

  • Systèmes autonomes et adaptatifs

    Le système observe, décide et exécute dans un cadre défini ; l'humain intervient principalement sur les règles et les exceptions. Ce palier exige toutes les fondations — données, intégrations, observabilité, confiance — et sera le plus difficile à rattraper.

Une maison d'investissement américaine a résumé le déplacement économique en une phrase que nous n'avons pas fait mieux que reprendre :

Un copilote vend l'outil. Un pilote automatique vend le travail.

C'est exactement le changement d'assiette : on cesse progressivement de facturer uniquement un utilisateur pour facturer un usage, un workflow, une transaction ou un résultat. Seat → Usage → Workflow → Transaction → Outcome. Et un résultat se mesure — donc se conteste, donc se prouve.

Cela crée un paradoxe pour l'éditeur SaaS. Si son produit permet demain à cinquante personnes d'effectuer le travail de cent, il vient de créer énormément de valeur pour son client. Mais s'il continue à facturer uniquement au nombre d'utilisateurs, il risque simultanément de réduire sa propre assiette de revenus.

Les éditeurs qui s'y engagent découvrent ainsi qu'ils ont changé de métier avant d'avoir changé de tarif : l'enjeu n'est plus seulement de créer de la valeur avec l'IA, mais de savoir en capturer une partie.

Et ensuite

Cette généalogie explique d'où vient la vague. Elle ne dit pas encore tout ce qu'elle change à ce que vous vendez.

Car si le logiciel cesse d'être un outil que l'on utilise pour devenir un acteur qui exécute, alors la promesse commerciale change de nature : on ne loue plus seulement un outil pour faire le travail, on commence à vendre un système qui en réalise une partie. C'est le passage du Software as a Service au Service as a Software — et il déplace le prix, la mesure de la valeur et la relation client.

Il déplace également l'avantage compétitif. Si tous les éditeurs ont progressivement accès aux mêmes grands modèles, le moat ne réside plus nécessairement dans le modèle lui-même. Il se déplace vers ce que l'éditeur possède autour de lui : la distribution, les données métier, les workflows, les intégrations et la confiance. Un modèle généraliste connaît un métier. Un éditeur vertical connaît les dossiers, les transactions, les historiques, les règles, les exceptions et les actions autorisées de milliers de clients. Le modèle peut devenir une commodité ; le contexte métier, lui, peut devenir un actif stratégique.

C'est l'objet de Service as a Software : ce que l'IA change vraiment à la promesse du logiciel.

Une dernière remarque, pour finir là où nous avons commencé. On présente souvent l'intelligence artificielle comme une menace pour ceux qui travaillent. La réalité est plus précise : l'IA ne décide pas ce que devient le temps qu'elle libère. Elle le rend disponible. Une entreprise peut convertir ce temps en croissance, en qualité de service, en capacité supplémentaire, en marge — ou en réduction d'effectifs. Ce qu'elle en fait ensuite est une question de management, pas de technologie.