Système agentique intégré : la troisième catégorie de produit IA

Une question suffit à les distinguer

Cette question est : qui déclenche le travail ? Elle porte sur le produit, jamais sur la technologie qu'il embarque — une distinction détaillée dans IA agentique ou système agentique.

Les deux premières lignes ont un point commun décisif : rien ne se produit tant que personne ne se manifeste. C'est ce qui les rapproche bien plus que leurs différences techniques ne les séparent.

Première catégorie : le SaaS augmenté

C'est de loin la plus répandue, et la plus facile à reconnaître : retirez l'IA par la pensée, il reste un produit complet. La fonction de l'intelligence artificielle y est presque toujours la même — accélérer la saisie. Rédiger le message que vous alliez écrire, trouver le contact que vous alliez chercher, résumer ce que vous alliez lire. C'est utile, et souvent très bien fait.

On présente parfois ce choix comme de la paresse ou de l'opportunisme. C'est une erreur d'analyse : c'est le seul mouvement rationnel disponible pour un éditeur installé, et cela pour quatre raisons qui tiennent à l'architecture, pas à l'ambition.

• Le modèle de données. Un séquenceur est bâti autour d'un objet campagne : une liste, des étapes, des délais. Un système agentique est bâti autour d'un objectif et d'un état du monde — les comptes, les situations, ce qui a été établi, ce qui reste incertain. On n'obtient pas le second en ajoutant des colonnes au premier.
• Le sens de l'initiative. Un logiciel classique fonctionne en requête-réponse : l'utilisateur agit, le système réagit. L'agentique inverse ce rapport. Or tout le code existant suppose que c'est le clic qui déclenche — les sessions, l'état de l'interface, l'ordonnancement des traitements. Inverser l'initiative touche les fondations.
• L'objet central de l'interface. Il faudrait passer d'une surface de configuration à une file de décisions. Ce n'est pas une refonte graphique, c'est un autre produit.
• Le modèle économique. La facturation au siège, à l'envoi ou au crédit n'a aucun rapport avec la valeur d'un système qui travaille sans que personne se connecte. Changer de tarification, c'est casser le revenu qui financerait justement la reconstruction — et abandonner des clients qui, eux, veulent l'outil qu'ils ont acheté.

Autrement dit : le produit existant n'est pas un actif dans cette transition, c'est une contrainte. Ce constat n'a rien d'original — c'est le dilemme de l'innovateur, appliqué à l'agentique. Il découle directement du changement de nature du logiciel que nous décrivions dans Software 3.0 : quand la matière première passe du code écrit à l'intention exprimée, ce qui a été bâti sur l'ancienne matière ne se convertit pas, il se remplace. Les tests permettant de reconnaître cette catégorie en démonstration sont détaillés dans le guide comment reconnaître un vrai système agentique.

Deuxième catégorie : l'assistant généraliste connecté

La seconde voie est plus récente et beaucoup plus intéressante. Elle consiste à sortir l'intelligence des outils : un assistant généraliste — ChatGPT, Claude — pilote vos logiciels métier via des connecteurs, aujourd'hui le plus souvent au format MCP. Vous demandez, il agit dans le CRM, la base de contacts, la messagerie.

Le fait marquant est que les éditeurs eux-mêmes y vont. Beaucoup publient désormais leur propre serveur MCP. HubSpot présente le sien comme un moyen de donner à n'importe quel outil ou agent IA compatible un accès en lecture et écriture à ses données CRM. Des éditeurs d'outreach vont jusqu'à publier sur leur blog des comparatifs des meilleurs serveurs MCP pour la vente.

Le cas le plus éloquent est celui de lemlist, qui se présente par ailleurs comme une plateforme d'outbound à base d'agents IA. Sa page consacrée au MCP est intitulée « Stop doing outbound. Start prompting it. » et propose de connecter le produit à Claude en un clic, pour que l'assistant accède aux contacts, aux enrichissements et aux séquences. Un éditeur qui vend des agents IA intégrés explique donc simultanément à ses clients comment le piloter depuis un assistant extérieur.

Ce slogan est d'ailleurs la définition exacte de cette deuxième catégorie, écrite par l'un de ses acteurs : le travail ne se fait plus en cliquant, il se fait en demandant. Le déclencheur reste la même personne.

Il faut lire ce mouvement comme une lucidité, pas comme une capitulation. Ces éditeurs ont compris avant les autres que la valeur de leur produit tient à leurs données et aux actions qu'il permet — pas aux écrans par lesquels on y accède. Ils actent que l'interface devient une couche d'exécution appelable, et ils préfèrent organiser ce passage plutôt que le subir. C'est le bon calcul.

Ce que le pattern MCP ne résout pas

Il résout un vrai problème, et il faut le dire clairement : l'interface n'est plus dans le chemin, et l'intelligence n'est plus prisonnière de chaque outil. Mais il en laisse quatre entiers.

C'est encore vous qui déclenchez

Un assistant connecté n'existe pas entre deux conversations. Il n'a rien fait cette nuit, rien pendant vos congés. La demande a simplement changé de forme : elle était un clic, elle est devenue une phrase. Tant que le travail n'a lieu qu'au moment où vous vous manifestez, la charge de savoir quoi demander et quand reste entièrement sur vous — et c'est justement la charge la plus lourde.

Il n'accumule pas de modèle de votre activité

Un assistant dispose d'un contexte de conversation, pas d'une mémoire de votre monde. Il ne sait pas ce qui a été établi sur ce compte il y a trois semaines, ce qui a été promis, ce qui a déjà été tenté et a échoué. Chaque session repart à froid et relit. Un accès aux données n'est pas une compréhension accumulée.

Il n'a pas de frontière déclarée

Un assistant fera ce que vous lui demandez, dans tous les outils qu'il peut atteindre. La limite entre ce qui s'exécute seul et ce qui attend un accord est celle que vous avez pensé à formuler dans votre demande. Un système intégré porte ce partage dans sa conception : il est explicite, vérifiable et opposable — c'est l'objet du guide sur le placement du point de contrôle.

Il n'a pas de jugement métier

Appeler l'API d'un CRM ne dit pas qu'une nomination à la direction des opérations d'un industriel de deux cents personnes vaut davantage, pour un cabinet qui vend de la transformation, qu'une levée de fonds dans une jeune pousse. Ce discernement est vertical : il se construit sur un métier, et il ne se déduit d'aucune documentation d'API.

Troisième catégorie : le système agentique intégré

La troisième voie n'est ni un logiciel auquel on a ajouté de l'IA, ni une intelligence généraliste branchée sur des logiciels. C'est un système conçu autour de l'agent dès l'origine, où le travail et l'intelligence ne sont pas deux couches séparées.

Quatre propriétés le caractérisent, et elles se vérifient.

• Il travaille sans être sollicité. Si personne ne se connecte de la semaine, il s'est passé quelque chose de descriptible : des comptes surveillés, des situations qualifiées, des dossiers préparés.
• Il entretient un modèle de votre monde. Ce qu'il sait d'un compte s'accumule au lieu d'être relu à chaque fois.
• Il porte une frontière déclarée. Ce qui s'exécute seul et ce qui attend un accord sont définis à l'avance, pas laissés à la formulation d'une demande.
• Il revient au bon moment. Ce qui exige un jugement remonte dans une surface unique qui peut être vidée — c'est le rôle de l'inbox agentique.

Ces quatre propriétés sont le prolongement concret de la définition générale exposée dans qu'est-ce qu'un système agentique, et de la migration de la valeur de l'outil vers le résultat que décrit Le SaaS est mort, vive le Service as a Software. La troisième catégorie n'est pas une nouveauté de vocabulaire : c'est ce que devient un logiciel quand on cesse de vendre un outil pour vendre un travail fait.

Cette catégorie est verticale par nécessité, non par choix commercial. Le jugement métier — quels signaux comptent, ce qu'ils autorisent à conclure, ce qu'on écrit et à qui — ne s'obtient pas horizontalement. C'est pour cette raison qu'un système agentique se construit pour une activité donnée, et qu'il est honnête de dire qu'il convient mal aux autres.

« Mais une inbox est une interface aussi »

L'objection est bonne, et elle mérite une réponse directe. Si la thèse est que les interfaces deviennent des couches d'exécution, pourquoi un système agentique en conserve-t-il une ?

Parce que deux choses très différentes portent le même nom. Une surface qui existe pour que vous fassiez fonctionner le logiciel — écrans de configuration, formulaires, paramétrage, listes à filtrer — disparaît effectivement : un agent y accède mieux et plus vite que vous, et c'est précisément ce que les serveurs MCP rendent possible. Une surface qui existe pour que vous décidiez ne disparaît pas, parce que la décision est justement ce qui ne se délègue pas.

La distinction est celle entre opérer et arbitrer. Le travail d'opération est en train de quitter l'humain, et c'est une bonne nouvelle. Le travail d'arbitrage lui revient entièrement, et il a besoin d'un endroit. Une inbox agentique n'est pas un écran de pilotage de plus : c'est ce qui reste quand tous les écrans de pilotage ont disparu.

Questions fréquentes

Quelle est la différence entre un SaaS augmenté d'IA et un système agentique intégré ?

Dans un SaaS augmenté, l'intelligence artificielle a été ajoutée par-dessus un produit qui existait déjà : elle accélère la saisie — rédiger une séquence, trouver un contact, reformuler une relance — mais le travail commence toujours quand l'utilisateur ouvre l'outil. Un système agentique intégré est conçu autour de l'agent dès l'origine : il poursuit un objectif en continu et revient vers l'humain quand une décision est nécessaire. La différence n'est pas la quantité d'IA, c'est qui déclenche le travail.

Pourquoi les éditeurs SaaS n'ont-ils pas reconstruit leurs produits autour de l'IA agentique ?

Parce que ce n'est pas leur intérêt à court terme, et c'est rationnel. Leur modèle de données est bâti autour d'objets à configurer, pas d'un état du monde ; leur code suppose que l'utilisateur déclenche chaque action ; leur interface est une surface de paramétrage ; et leur tarification repose sur des sièges, des envois ou des crédits, indicateurs sans rapport avec la valeur d'un système qui travaille seul. Reconstruire reviendrait à casser le revenu qui financerait la reconstruction, et à abandonner des clients satisfaits du produit qu'ils ont acheté.

Un assistant comme ChatGPT ou Claude branché sur mes outils via MCP suffit-il ?

Il résout un vrai problème — l'interface n'est plus dans le chemin, et l'intelligence n'est plus prisonnière de chaque outil. Mais il en laisse un autre entier : c'est encore vous qui déclenchez. Tant que le travail n'a lieu qu'au moment où vous écrivez une demande, la charge de savoir quoi demander, et quand, reste sur vous. S'y ajoutent trois manques : aucun modèle accumulé de votre activité d'une session à l'autre, aucune frontière déclarée entre ce qui s'exécute seul et ce qui attend un accord, et aucun jugement propre à votre métier.

Que signifie le fait que des éditeurs publient leur propre serveur MCP ?

C'est une lucidité, pas une capitulation : ces éditeurs ont compris avant les autres que la valeur de leur produit tient à leurs données et aux actions qu'il permet, pas aux écrans par lesquels on y accède. HubSpot, par exemple, présente son serveur MCP comme un moyen de donner à n'importe quel outil ou agent IA compatible un accès en lecture et écriture à ses données CRM. C'est la reconnaissance explicite que l'interface devient une couche d'exécution appelable de l'extérieur.

Si les interfaces deviennent obsolètes, pourquoi un système agentique en garde-t-il une ?

Parce que deux choses très différentes s'appellent « interface ». Une surface qui existe pour que vous fassiez fonctionner le logiciel — écrans de configuration, formulaires, paramétrage — disparaît effectivement, puisqu'un agent y accède mieux que vous. Une surface qui existe pour que vous décidiez ne disparaît pas, parce que la décision est précisément ce qui ne se délègue pas. C'est la distinction entre opérer et arbitrer.