Software 3.0 : pourquoi le logiciel est en train de changer de nature

Par Matthieu Nguyen, mai 2026

L'industrie du logiciel traverse depuis dix-huit mois une succession de signaux que personne n'arrive vraiment à lire ensemble. Anthropic publie onze plugins open source pour Claude et fait évaporer 285 milliards de dollars de capitalisation en une séance. Les cycles de vente des éditeurs SaaS s'allongent. Les directions générales commencent à demander à leurs équipes pourquoi elles paient des abonnements pour des outils que leurs équipes utilisent à 15% de leurs capacités. Wall Street parle de SaaSpocalypse. Les éditeurs eux-mêmes parlent de AI-native transformation.

Tous ces récits ratent l'essentiel. Ce qui se joue n'est pas une amélioration des logiciels existants par l'IA. Ce qui se joue, c'est une transformation du logiciel lui-même. Une nouvelle génération est en train d'émerger, et elle ne se distingue pas des précédentes par ses fonctionnalités, mais par sa nature.

Pour comprendre ce qui se passe, il faut remonter le fil des générations.

Les trois générations du logiciel

Le software 1.0 est celui que tout le monde connaît. Du code écrit à la main par un développeur. Des règles explicites encodées dans des if/else, des fonctions déterministes, des conditions vérifiables. La quasi-totalité du SaaS contemporain vit dans cette catégorie, de Salesforce à SAP, de Workday à votre CRM interne. L'humain code la logique métier ligne par ligne, la machine l'exécute. Cette génération a structuré quarante ans de transformation digitale, et elle reste très puissante pour tout ce qui demande des règles stables, auditables, et des comportements prévisibles.

Le software 2.0 a émergé au tournant des années 2010 avec la montée du machine learning. Cette fois, le développeur ne code plus la logique. Il définit l'architecture du modèle, fournit la donnée d'entraînement, et le modèle apprend les règles tout seul. C'est la génération qui fait tourner la reconnaissance vocale de Siri, le feed personnalisé d'Instagram, la vision par ordinateur des Tesla, la détection de spam dans Gmail, les recommandations Netflix. Pour l'utilisateur, cette génération est restée largement invisible. On ne dit pas "j'utilise du software 2.0", on dit "ça marche bien". Mais elle a profondément modifié la manière dont les logiciels prennent des décisions à l'échelle.

Le software 3.0 est ce qui émerge depuis dix-huit mois, avec la maturité des grands modèles de langage. Et il introduit une rupture conceptuelle plus profonde que la précédente. Cette fois, ce n'est plus une fonction du logiciel qui est apprise par un modèle. C'est l'exécution du logiciel elle-même qui devient le fait d'un système d'agents capables de raisonner en langage naturel, d'utiliser des outils, de coordonner d'autres agents, et de livrer un service de bout en bout. Le langage naturel devient le langage de programmation. Le système agentique devient le système d'exploitation.

Pourquoi parler d'OS

L'analogie n'est pas marketing, elle est structurelle. Un système d'exploitation, c'est une couche qui orchestre des ressources hétérogènes pour qu'un utilisateur ou une application puisse en tirer un service cohérent. Il gère la mémoire, ordonnance les processus, expose des APIs aux applications, médiatise l'accès au matériel.

Un système agentique mature fait exactement la même chose, à un niveau d'abstraction supérieur. Il orchestre des agents au lieu d'orchestrer des processus. Il gère du contexte au lieu de gérer de la mémoire. Il expose des outils au lieu d'exposer des APIs. Il médiatise l'accès aux données et aux services métier au lieu de médiatiser l'accès au matériel. Et comme un OS, il ne se contente pas de faire tourner une application : il devient la couche sur laquelle se construisent toutes les applications de la nouvelle génération.

Cette analogie change radicalement la grille de lecture. Un éditeur qui ajoute un agent IA à son SaaS existant ne fait pas du software 3.0, il fait du 1.0 avec une couche d'IA dessus. Le vrai 3.0, c'est quand le système agentique n'est plus une fonctionnalité du logiciel, mais l'environnement dans lequel le logiciel s'exécute.

Trois conséquences pour le logiciel existant

Cette bascule a des effets tangibles sur tout le paysage du logiciel actuel. Trois destins se dessinent.

Le premier destin concerne les logiciels qui ne disparaîtront pas, et qui pourraient même se renforcer. Ce sont ceux qui sont devenus indissociables des processus d'entreprise et qui contiennent des décennies de données structurées : les CRM, les ERP, les systèmes de gestion documentaire, les outils métiers verticaux profondément intégrés. Ces logiciels ne sont plus seulement des applications, ce sont des actifs. Leur valeur ne tient pas à l'interface qu'ils proposent, elle tient à l'historique qu'ils contiennent et à la place qu'ils occupent dans les flux de travail. Un système agentique va venir s'y connecter, les interroger, les enrichir, mais il ne les remplacera pas. Il les rendra simplement plus utiles.

Le deuxième destin est plus brutal. Une grande partie du SaaS classique va devenir headless. Les fonctions resteront utiles, mais les interfaces deviendront inutiles, parce qu'elles ont été dessinées pour des humains qui ne s'y connecteront plus directement. Les agents les consommeront via API, via MCP, via des couches d'intégration qui n'existent pas encore complètement. Les UIs raffinées que les éditeurs ont mis quinze ans à perfectionner se videront progressivement de leurs utilisateurs. Le code qui les sous-tend continuera de tourner, mais ce sont des agents qui en seront les usagers. Pour les éditeurs concernés, c'est une question existentielle : leur valeur perçue va devoir migrer du front vers le back, ou ils seront contournés.

Le troisième destin est l'émergence d'une nouvelle catégorie, et c'est celle qui m'intéresse particulièrement parce que c'est celle que je construis. Des interfaces pensées dès le départ pour orchestrer des systèmes agentiques. Pas pour saisir des données ou cliquer dans des menus, mais pour piloter des agents qui travaillent en parallèle, pour arbitrer entre plusieurs trajectoires possibles, pour valider une décision, pour intervenir quand le système le sollicite. L'humain n'est plus l'opérateur du logiciel, il est le chef d'orchestre d'un système qui livre le service. Cette catégorie n'a pas encore de nom stable. Certains parlent d'agentic UX, d'autres de copilots de seconde génération. Ce qui est certain, c'est que ces interfaces n'ont rien à voir avec ce que produit aujourd'hui un éditeur SaaS classique, parce qu'elles ne servent pas à faire la même chose.

Pourquoi la donnée propriétaire devient le seul moat

Une fois ce paysage en place, une question stratégique s'impose : sur quoi se construit la valeur dans un monde où le logiciel se redistribue ainsi ?

La réponse tient en quelques observations convergentes.

Les modèles vont continuer à devenir meilleurs, plus rapides, et moins chers. C'est leur trajectoire structurelle, alimentée par des centaines de milliards de dollars d'investissement chez les grands labs. Personne ne construira un avantage durable en pariant sur un modèle propriétaire. Le code, lui aussi, devient de moins en moins défendable. Pas parce qu'il serait trivial à reproduire, l'ingénierie reste complexe, mais parce que la valeur perçue migre du code vers ce que le code permet d'orchestrer. Et les interfaces, comme on l'a vu, sont en train de se vider de leurs utilisateurs ou de se réinventer dans des paradigmes encore instables.

Ce qui reste, c'est la donnée. Pas n'importe quelle donnée, et pas la donnée brute des plateformes massives qui alimentent les modèles publics. La donnée propriétaire d'outcomes vérifiables, accumulée déploiement par déploiement, client par client, dans une verticale spécifique.

Cette donnée n'existe nulle part dans les corpus d'entraînement publics. Aucun grand laboratoire ne descendra dans les milliers de niches verticales où elle se trouve, parce que ce n'est ni leur modèle économique ni leur intérêt stratégique. Elle ne se construit que par déploiement réel, dans des conditions opérationnelles, avec des feedbacks observables. Et plus elle s'accumule, plus elle devient irrépliquable.

Pour donner un exemple concret tiré de mon propre travail, dans l'intelligence commerciale pour cabinets de conseil, les outcomes sont parfaitement vérifiables. Un signal de marché a-t-il précédé un besoin réel chez le prospect, oui ou non. Un contact qualifié a-t-il converti en mission gagnée, oui ou non. Ces réponses sont binaires, observables, et elles constituent la matière première d'un système qui apprend de chaque cabinet client. À douze mois, ce dataset devient un actif stratégique qu'aucun concurrent et aucun frontier lab ne peut reconstruire de zéro.

C'est le déplacement le plus important de cette transition : la valeur ne se loge plus dans le code, plus dans l'interface, plus dans le modèle. Elle se loge dans la donnée d'outcomes que les agents viennent consommer.

Ce que cela signifie pour les dirigeants

Cette grille de lecture a des implications immédiates pour quiconque dirige une entreprise qui produit ou utilise du logiciel.

Pour un éditeur SaaS, la question n'est plus comment intégrer de l'IA dans mon produit, elle est à quel destin mon produit appartient-il. Si ce destin est celui des actifs incontournables, l'enjeu est de garantir que les agents pourront s'y connecter proprement et d'enrichir l'historique de données. Si ce destin est celui du headless, l'enjeu est d'accepter cette migration et d'en faire une force, en exposant des APIs et des MCP qui font de votre logiciel une primitive invocable. Si ce destin est celui des UX agentiques, l'enjeu est de repenser l'interface depuis zéro, parce que les paradigmes hérités ne fonctionneront pas.

Pour un dirigeant qui consomme du logiciel, la question est de savoir lesquels de ses outils méritent encore une interface dédiée, et lesquels seraient mieux servis par un agent qui consomme directement les données. La plupart des entreprises sont saturées d'outils sous-utilisés, dont la valeur réelle est portée par 15% des fonctionnalités. Un système agentique bien construit peut absorber ces 15% et libérer les équipes des 85% restants.

Pour un fondateur qui construit aujourd'hui, la question est encore plus simple : votre produit est-il du software 1.0 avec une couche d'IA, ou est-ce un système agentique qui se trouve livrer un service ? La différence ne se voit pas toujours dans la démo, mais elle se voit dans dix-huit mois.

C'est cette différence qui guide ce que nous construisons chez HNTIC.