MCP et agents IA : comment les humains utiliseront les logiciels en 2030

Aujourd'hui, un employé ouvre son CRM, son ERP, Outlook, Teams, le logiciel comptable et parfois trois fichiers Excel pour répondre à une seule question.

En 2030, il pourrait simplement demander :

Trouve les occasions de vente de plus de 25 000 $ qui n'ont reçu aucun suivi depuis deux semaines. Vérifie si ces clients ont des factures impayées. Prépare les courriels, mais demande-moi l'autorisation avant de les envoyer.

Un agent IA consulterait alors le CRM, interrogerait la comptabilité, lirait les échanges autorisés, préparerait les suivis et présenterait uniquement les décisions qui nécessitent un humain.

Ce scénario ne demande pas que tous les logiciels soient remplacés. Il demande que les agents puissent les utiliser. C'est là que le Model Context Protocol, mieux connu sous l'acronyme MCP, pourrait transformer la relation entre les humains et les logiciels accessibles en ligne, souvent appelés SaaS dans le milieu technologique.

La prédiction de PostHog : les agents deviendront les principaux utilisateurs des logiciels

Dans son texte « 2030-shaped software », PostHog avance qu'en 2030, les agents IA seront les principaux utilisateurs des logiciels.

Les humains ne disparaissent pas du processus. Leur travail se concentre plutôt sur deux responsabilités :

1. Juger et décider : approuver, prioriser, choisir une direction et résoudre les ambiguïtés.
2. Comprendre et faire confiance : vérifier ce qui a été fait, évaluer le risque et voir ce qui a changé.

Le travail d'exécution — chercher, filtrer, recopier, configurer, créer et mettre à jour — passe progressivement aux agents.

Cette idée change la question posée aux éditeurs. Il ne suffit plus de demander : « Comment ajouter un assistant conversationnel à notre logiciel ? » Il faut demander : « À quoi ressemblerait ce produit si l'agent était une interface principale dès le départ ? »

PostHog appelle cette approche le développement de produits agent-first. L'agent n'est plus une fonction ajoutée dans un coin de l'application. Il devient un véritable utilisateur du système.

Les humains ne travailleront pas directement avec les MCP

Dire que les humains « utiliseront des MCP » est presque juste, mais il manque une couche.

Un serveur MCP n'est généralement pas l'endroit où l'humain écrit sa demande. L'humain travaille avec un agent IA dans ChatGPT, Claude, Codex, Slack, Teams, un éditeur de code ou une application interne. C'est cet agent qui se connecte aux serveurs MCP.

L'humain fournit l'intention : « prépare les suivis prioritaires ». L'agent décompose le travail. Les serveurs MCP lui indiquent les données qu'il peut consulter et les actions qu'il peut exécuter dans chaque logiciel.

Le résultat revient ensuite à l'humain sous une forme adaptée : une réponse courte, un tableau, un rapport, un document, une demande d'approbation ou une interface temporaire générée pour la décision en cours.

Qu'est-ce que le Model Context Protocol ?

Le Model Context Protocol est un protocole ouvert permettant à une application d'IA de se connecter à des données et à des outils externes. La spécification officielle de MCP distingue notamment les ressources, les outils et les instructions que les serveurs peuvent exposer.

Lorsqu'il est connecté à un logiciel, le serveur MCP peut présenter à l'agent des capacités comme :

• rechercher un client;
• lire une occasion de vente;
• créer une tâche;
• modifier une date de livraison;
• exécuter une requête analytique;
• produire un rapport;
• ouvrir un billet de soutien;
• déclencher une automatisation;
• demander une approbation.

Le serveur ne donne pas nécessairement accès à tout. Il décrit les outils disponibles, leurs paramètres et les résultats retournés. Il peut aussi transmettre du contexte : définitions internes, conventions, limites, façons recommandées d'utiliser le produit et cas où l'agent doit s'arrêter.

MCP crée ainsi un langage commun entre les agents et les logiciels, un peu comme d'autres standards ont simplifié les connexions entre navigateurs, serveurs web et services d'authentification.

MCP ne remplace pas les API des logiciels

Une API permet déjà à deux systèmes de communiquer. Pourquoi ajouter MCP ?

Parce qu'une API est principalement conçue pour les programmeurs. Elle expose des routes, des paramètres et des réponses techniques. Le développeur connaît le résultat voulu et écrit le code qui enchaîne les appels.

Un serveur MCP fournit plutôt à l'agent une description exploitable des capacités du produit. Il lui permet de découvrir les outils disponibles, de comprendre quand les utiliser et de construire lui-même une séquence d'actions selon la demande de l'utilisateur.

Dans plusieurs cas, le serveur MCP repose directement sur l'API existante :

• l'API demeure la porte technique vers le logiciel;
• le serveur MCP organise et décrit les capacités pour l'agent;
• l'agent choisit les outils et l'ordre d'exécution;
• l'humain intervient aux points de décision ou d'approbation.

Un bon MCP n'est donc pas une copie automatique de chaque route de l'API. PostHog explique avoir abandonné cette première approche. Son équipe expose maintenant les capacités au niveau où les agents raisonnent le mieux, tout en choisissant explicitement les actions accessibles.

Ce que PostHog permet déjà de faire sans naviguer dans son interface

Le serveur MCP de PostHog permet déjà à un agent de travailler avec plus de 50 outils. L'utilisateur peut notamment lui demander de :

• mesurer les inscriptions des derniers jours;
• exécuter un entonnoir de conversion;
• consulter les erreurs fréquentes;
• créer une expérience A/B;
• activer ou désactiver un feature flag;
• construire un sondage;
• interroger les données en SQL;
• retrouver une session particulière.

La demande peut être formulée en langage courant depuis un éditeur ou un agent compatible. L'utilisateur n'a pas à retrouver le bon menu, apprendre la structure d'un tableau de bord ou ouvrir une série d'onglets.

L'exemple de l'expérience A/B montre toutefois une exigence fondamentale. Si l'agent peut créer le feature flag et le rapport, mais qu'aucun outil ne lui permet de créer l'expérience, il doit interrompre le travail et renvoyer l'humain dans le logiciel. Le gain d'autonomie disparaît.

Pour devenir réellement agent-first, un produit doit permettre à l'agent d'accomplir un parcours complet, pas seulement quelques démonstrations impressionnantes.

À quoi ressemblerait une journée de travail en 2030 ?

Imaginons une PME manufacturière québécoise qui utilise un CRM, un ERP, Microsoft 365 et un logiciel comptable.

Le matin : l'agent prépare les exceptions

Au lieu de consulter quatre tableaux de bord, la direction reçoit un résumé :

• deux commandes risquent de manquer leur date de livraison;
• un client important attend une soumission depuis quatre jours;
• trois factures dépassent les conditions habituelles;
• une machine indisponible touche cinq travaux planifiés;
• deux décisions demandent une approbation.

L'agent ne se contente pas de résumer. Il a déjà vérifié les données dans les systèmes autorisés et préparé les options possibles.

Pendant la journée : les demandes deviennent des objectifs

Un gestionnaire peut demander :

Réorganise les travaux de demain sans déplacer les commandes prioritaires. Vérifie la disponibilité des employés et du matériel. Montre-moi les changements avant de publier l'horaire.

L'agent consulte l'ERP, les horaires et l'inventaire par leurs serveurs MCP. Il propose une nouvelle séquence et explique les compromis. Le gestionnaire juge le résultat, puis autorise la publication.

En fin de journée : les systèmes sont mis à jour ensemble

Lorsqu'une vente est confirmée, l'agent peut créer la commande dans l'ERP, joindre les documents, avertir la planification et préparer le message au client. Une seule intention humaine déclenche plusieurs actions coordonnées.

Ce fonctionnement prolonge ce que DevActif réalise déjà avec l'automatisation et l'intégration de systèmes. La différence est que l'agent peut maintenant choisir et enchaîner les outils selon l'objectif, plutôt que de suivre uniquement un scénario fixé à l'avance.

Les boutons et les formulaires vont-ils disparaître ?

Une partie d'entre eux, probablement.

Les interfaces actuelles sont construites autour du travail d'exécution : trouver un menu, filtrer une liste, remplir des champs, déplacer une carte, exporter un fichier et cliquer sur « enregistrer ». Si un agent peut accomplir ces gestes correctement, les reproduire manuellement devient une utilisation coûteuse de l'attention humaine.

Cela ne signifie pas que tous les logiciels deviendront une page blanche avec une zone de clavardage.

Le texte est souple, mais linéaire. Certaines informations sont mieux comprises dans un graphique, une carte, un calendrier, une maquette ou un tableau comparatif. PostHog propose une voie intermédiaire : l'interface générative. L'agent produit l'interface nécessaire à la tâche actuelle, puis celle-ci peut disparaître ou devenir un document durable.

Les humains auront encore besoin d'interfaces persistantes pour :

• approuver une action importante;
• vérifier ce que l'agent a modifié;
• comparer plusieurs scénarios;
• traiter les exceptions et les ambiguïtés;
• visualiser une tendance complexe;
• consulter l'historique et les preuves;
• reprendre manuellement le contrôle.

L'interface de 2030 servira moins à faire le travail et davantage à juger le travail.

Les logiciels ne vont pas disparaître : leur valeur va se déplacer

L'agent ne remplace pas la plateforme qui détient les données et applique les règles. Le logiciel demeure responsable de fonctions essentielles :

• conserver les données;
• appliquer les permissions;
• exécuter les calculs;
• maintenir l'historique;
• garantir la disponibilité;
• gérer les intégrations;
• protéger les renseignements;
• exposer des actions fiables.

Ce qui change, c'est le point d'entrée. L'utilisateur pourrait passer beaucoup moins de temps dans l'interface officielle du produit.

L'avantage concurrentiel d'un logiciel se déplacera alors de ses menus vers la qualité de son contexte et de ses capacités : données bien structurées, API complètes, serveur MCP fiable, permissions précises et connaissance intégrée du domaine.

Les modèles d'IA seront accessibles à plusieurs fournisseurs. Le contexte propre au produit — son historique, ses données, ses conventions et sa façon reconnue de bien accomplir le travail — deviendra beaucoup plus difficile à reproduire.

Un agent a besoin de contexte, pas seulement d'outils

Donner accès à une fonction ne garantit pas que l'agent l'utilisera correctement.

Un agent connecté à un ERP peut savoir comment modifier une commande sans comprendre pourquoi une commande prioritaire ne doit jamais changer de machine après une certaine étape. Il peut calculer un indicateur sans connaître les événements irréguliers qui faussent le résultat.

PostHog charge donc certains éléments au début de chaque session MCP : sa terminologie, sa syntaxe de requête et les règles critiques applicables à chaque analyse. Le reste du contexte est récupéré au moment où il devient pertinent.

Une entreprise devra faire le même exercice :

• définir ses termes et acronymes;
• documenter les exceptions importantes;
• expliquer quelles données font autorité;
• préciser les actions qui exigent une approbation;
• indiquer les résultats considérés comme normaux ou suspects;
• transmettre ses standards de qualité.

Cette connaissance peut être fournie sous forme d'instructions ou de compétences destinées aux agents. Elle représente ce qu'un nouvel employé qualifié ne pourrait pas deviner seul.

La sécurité devient plus importante, pas moins

Un agent capable de lire un rapport présente un risque limité. Un agent capable de modifier un ERP, d'envoyer des courriels et d'accéder à la comptabilité peut produire beaucoup plus de valeur — et beaucoup plus de dommages s'il se trompe ou reçoit une instruction malveillante.

La documentation de sécurité de MCP insiste notamment sur l'autorisation, la validation des jetons, la limitation des permissions et la protection contre plusieurs formes de détournement d'accès.

Dans une entreprise, une intégration sérieuse devrait prévoir :

• des permissions distinctes pour lire, créer, modifier et supprimer;
• le minimum d'accès nécessaire pour chaque agent;
• une approbation humaine pour les actions sensibles;
• un journal indiquant qui a demandé quoi et ce qui a changé;
• des limites de volume et de fréquence;
• des actions réversibles lorsque c'est possible;
• des environnements isolés pour tester;
• une gestion sécurisée des identifiants et des jetons;
• un arrêt automatique lorsqu'une situation devient ambiguë.

Il faut aussi protéger l'agent contre les instructions cachées dans les données qu'il consulte. Un courriel, un document ou une page web ne devrait jamais pouvoir élargir ses permissions ou remplacer les règles définies par l'entreprise.

L'objectif n'est pas d'éliminer l'humain de la boucle. Il est de placer son attention exactement là où le risque et le jugement l'exigent.

Comment les modèles d'affaires des logiciels pourraient changer

Les logiciels accessibles en ligne par abonnement sont souvent facturés par utilisateur. Mais qu'est-ce qu'un utilisateur lorsque cinq employés partagent un agent qui exécute des milliers d'actions ? Et comment facturer un agent qui travaille dans dix produits différents ?

La transition pourrait pousser les éditeurs vers d'autres modèles :

• facturation selon l'utilisation;
• volume d'actions exécutées;
• quantité de données traitées;
• résultats ou processus automatisés;
• niveaux de capacité accordés aux agents;
• frais pour le contexte, la gouvernance ou les contrôles avancés.

Les critères d'achat changeront eux aussi. Une entreprise évaluera non seulement l'interface et les fonctions, mais aussi :

• la qualité de l'API et du serveur MCP;
• la couverture réelle des actions;
• les permissions disponibles;
• la traçabilité des interventions;
• la capacité d'exporter les données;
• la compatibilité avec différents agents;
• la facilité d'intégration aux autres systèmes.

Un logiciel difficile à utiliser par un agent pourrait devenir aussi contraignant qu'un logiciel sans API aujourd'hui.

Ce que les éditeurs de logiciels devraient construire maintenant

PostHog reconnaît que 2026 n'est pas encore 2030. Les éditeurs doivent continuer de servir les utilisateurs actuels tout en préparant une autre façon d'interagir avec leurs produits.

Une transition raisonnable peut commencer ainsi :

1. Inventorier les actions offertes dans l'interface. Lesquelles sont aussi accessibles par API ?
2. Compléter les parcours critiques. Un agent doit pouvoir terminer une tâche entière sans renvoyer l'utilisateur vers un formulaire oublié.
3. Créer des outils MCP à la bonne granularité. Ni une copie brute de chaque route technique, ni un outil trop rigide pour chaque scénario.
4. Structurer les permissions. La lecture, l'écriture, l'envoi et la suppression ne doivent pas partager un seul droit général.
5. Fournir le contexte universel. Terminologie, règles critiques et limites doivent accompagner les outils.
6. Observer les agents comme de vrais utilisateurs. Examiner leurs traces, leurs erreurs et les endroits où ils demandent inutilement de l'aide.
7. Construire des surfaces de confiance. Approbations, historique, comparaison et reprise manuelle.

Ajouter une boîte de clavardage au produit actuel sans ouvrir ses capacités revient à installer une réceptionniste devant une porte verrouillée.

Comment préparer un logiciel existant sans le remplacer

Les entreprises n'auront pas nécessairement à abandonner leurs systèmes actuels. Plusieurs peuvent devenir utilisables par des agents grâce à une couche ajoutée progressivement.

Pour un logiciel récent, il peut suffire d'étendre l'API et de bâtir un serveur MCP bien limité. Pour un ancien système, le travail peut commencer par un service intermédiaire qui expose uniquement quelques données et actions prioritaires.

Une démarche réaliste consiste à :

• choisir un processus fréquent et mesurable;
• repérer les systèmes et données nécessaires;
• ajouter les API manquantes;
• définir les permissions et approbations;
• exposer quelques outils MCP;
• tester avec des données contrôlées;
• mesurer les erreurs et le temps économisé;
• élargir l'accès seulement après validation.

DevActif a déjà l'habitude de faire communiquer des logiciels qui n'ont pas été conçus ensemble et de moderniser des systèmes existants. Ajouter une surface destinée aux agents prolonge cette même logique : préserver ce qui fonctionne et ouvrir proprement les capacités qui manquent.

Le logiciel de 2030 se construit en 2026

La prédiction de PostHog ne sera peut-être pas exacte dans chaque détail. Les interfaces ne disparaîtront pas toutes, et les agents ne recevront pas un accès autonome à chaque décision importante.

Mais la direction est crédible : les humains passeront moins de temps à manipuler leurs logiciels et davantage de temps à exprimer des objectifs, examiner des options et approuver des résultats.

Les agents feront le travail d'exécution. Les serveurs MCP leur donneront une façon commune de comprendre et d'utiliser les logiciels. Les interfaces serviront à la confiance, au jugement et aux exceptions.

Pour une entreprise, la question à poser dès maintenant est simple :

Si un agent devait accomplir demain ce qu'un employé fait aujourd'hui dans notre logiciel, aurait-il accès à toutes les données, actions, permissions et règles nécessaires ?

Si la réponse est non, il n'est pas nécessaire de tout reconstruire. Il faut commencer par la première capacité utile.

Parlez à DevActif de vos logiciels et de vos intégrations. Nous pouvons déterminer quels systèmes sont prêts pour les agents IA, quelles API manquent et où un serveur MCP créerait une valeur réelle plutôt qu'une simple démonstration.