Votre prochain logiciel doit convaincre deux utilisateurs

Je veux acheter une capacité d'action, pas seulement une belle interface

Quand j'évalue un logiciel, je ne regarde plus seulement ce que mes collègues pourront faire sur leurs écrans. Je veux aussi savoir ce qu'un agent autorisé pourra exécuter, avec quelles limites et sous quel contrôle. Je ne fais pas de cette question une règle universelle. Pour un outil isolé, utilisé ponctuellement, une bonne interface utilisateur peut suffire. Pour un système appelé à participer à plusieurs processus, l'absence d'actions accessibles constitue toutefois un coût à prendre en compte avant l'achat.

Cette position change la démonstration attendue. Un assistant capable de répondre à une question sur les données du produit peut être utile. Il ne prouve pas que le produit permet à un autre système de créer un dossier, modifier un statut ou déclencher une opération. La distinction est moins spectaculaire qu'une conversation avec une IA, mais elle engage davantage la capacité future de la PME à composer ses outils.

Je traiterais donc le logiciel comme un produit destiné à deux utilisateurs. Le premier est humain, responsable de la décision et de ses conséquences. Le second est un agent dont les capacités doivent rester bornées. Une réflexion sur l'Agentic UX formule ce principe ainsi : concevoir pour les agents ajoute un second type d'utilisateur sans retirer l'expérience humaine. Cette source propose un cadre émergent, pas un standard établi. Le cadre me paraît néanmoins utile pour poser une question d'achat concrète : le produit sert-il ces deux utilisateurs, ou ajoute-t-il seulement une conversation à son interface actuelle?

Un assistant interne et une capacité composable ne jouent pas le même rôle

Le mot « IA » rassemble des fonctions très différentes. Une interface conversationnelle peut expliquer le contenu d'un logiciel. Une capacité composable permet à un système externe d'appeler une action définie. Les deux peuvent coexister, mais l'une ne garantit pas l'autre.

Salesforce présente clairement cette séparation dans son propre contexte : Agentforce gère la conversation avec le client, tandis que MCP soutient le travail opérationnel de l'équipe. C'est le positionnement d'un fournisseur sur ses produits, pas une preuve applicable à tous les assistants. Il montre tout de même pourquoi je refuse de confondre qualité de conversation et possibilité d'agir entre plusieurs logiciels.

Le Model Context Protocol apporte ici un vocabulaire plus précis. La spécification MCP décrit un protocole qui expose des outils et des capacités aux systèmes d'IA. Elle ne certifie pas qu'un produit expose les bonnes actions métier. Un logo MCP dans une fiche commerciale ne répond donc pas à la question. Il faut voir les outils disponibles, leurs paramètres, leurs permissions et les effets qu'ils produisent.

MCP ne rend pas non plus les API inutiles. Un guide de Mercury explique que les API continuent d'alimenter les systèmes et que MCP leur fournit une forme structurée utilisable par l'IA. Le même guide réserve surtout l'intérêt de MCP aux situations où un vrai travail doit être orchestré entre des outils. Cette nuance compte pour une PME. Si le besoin se limite à tester des prompts, exiger MCP peut ajouter une contrainte sans bénéfice clair. Si le logiciel doit prendre part à un processus interoutils, la capacité d'action mérite une vérification beaucoup plus serrée.

Trois choix, trois coûts à accepter

Je vois trois options raisonnables. Garder un logiciel fermé préserve parfois une expérience humaine supérieure, mais limite les automatisations externes. Utiliser ses API permet de bâtir l'intégration voulue, au prix de compétences, de maintenance et de décisions d'architecture assumées par la PME ou son partenaire. Choisir un produit qui expose déjà des outils MCP peut réduire le travail de traduction entre l'agent et l'API, sans éliminer l'intégration ni la gouvernance.

Les exemples officiels aident à distinguer une promesse d'une capacité vérifiable. Le serveur MCP distant de HubSpot agit comme pont entre les systèmes d'IA et les API HubSpot. Sa documentation indique aussi des écritures sur plusieurs objets CRM et précise que les utilisateurs ne peuvent voir ou modifier que les enregistrements auxquels ils ont déjà accès. Voilà le niveau de détail que j'attends : quelles actions, sur quels objets, avec quelles permissions.

Le serveur MCP officiel de Xero relie lui aussi MCP à son API et expose des fonctions comptables et métier. Le dépôt documente des permissions OAuth plus granulaires pour certaines connexions récentes, tout en conservant un chemin fondé sur d'anciens regroupements de scopes. La granularité disponible reste une possibilité technique. Elle ne démontre pas que le moindre privilège sera correctement configuré, ni que l'installation sera sans entretien.

Je ne choisirais donc pas entre « avec MCP » et « sans MCP » sur une case à cocher. Je comparerais le coût du raccordement, la portée réelle des actions et la dépendance créée. Votre contexte peut favoriser une API bien documentée, un serveur MCP fourni, ou même un outil fermé lorsque l'usage restera humain. Le renoncement doit seulement être visible au moment de signer.

L'ouverture ne vaut rien sans des limites observables

Permettre à un agent d'écrire dans un CRM ou un système comptable déplace la question vers l'autorisation. Une identité d'agent peut, dans l'environnement Microsoft Entra, agir au nom d'un utilisateur avec des permissions déléguées et son consentement. Ce mécanisme documenté par Microsoft n'est pas une règle commune à tous les SaaS. Il donne toutefois un test utile : le fournisseur sait-il expliquer qui autorise quoi, au nom de qui, et pour combien de temps?

La spécification MCP demande aux applications hôtes d'obtenir un consentement explicite avant l'invocation d'un outil. Elle précise aussi que les descriptions d'outils doivent être considérées comme non fiables lorsqu'elles ne viennent pas d'un serveur de confiance. Le protocole énonce ces principes, mais ne peut pas les imposer seul. L'application hôte et sa configuration portent une part du contrôle.

Ce n'est pas une réserve théorique. Une prépublication portant sur sept clients MCP relève des problèmes liés à une validation statique insuffisante et à une visibilité limitée des paramètres. Sept clients ne représentent pas tout le marché. Le résultat suffit cependant à écarter un raccourci : présence de MCP ne signifie pas sécurité acquise.

Le même raisonnement vaut pour le retour arrière. Une architecture d'event sourcing peut conserver chaque changement d'état sous forme d'événement immuable, mais cette prépublication porte sur deux cas de génie logiciel. Elle ne prouve pas que le SaaS évalué offre cette piste d'audit. Une saga peut de son côté déclencher des transactions compensatoires lorsqu'une opération locale ultérieure échoue. Compenser n'est pas revenir parfaitement à l'état initial : certaines actions restent irréversibles et une compensation peut elle-même échouer.

Ma grille pour une démonstration d'achat

Je demanderais une démonstration fondée sur une action réelle, puis je garderais cinq questions. Elles ne constituent pas un standard du marché. C'est une grille éditoriale pour rendre l'arbitrage observable.

1. Quelle action métier l'agent peut-il réellement exécuter? Je veux un verbe, un objet et le résultat attendu, pas seulement une réponse en langage naturel.
2. Quelle identité et quelles permissions utilise-t-il? Je cherche la portée minimale, la délégation, l'expiration et la manière de retirer l'accès.
3. Où intervient l'humain? Je veux voir le consentement, l'approbation d'une action sensible et la possibilité de refuser avant exécution.
4. Quelle trace reste après l'action? Le fournisseur doit montrer ce qui a été demandé, les paramètres transmis, le résultat et l'identité responsable.
5. Que se passe-t-il en cas d'erreur? Annulation, compensation et intervention manuelle ne sont pas équivalentes. Je veux connaître la limite de chacune.

J'ajouterais un volet québécois dès que des renseignements personnels sont concernés. La Commission d'accès à l'information indique qu'une EFVP est requise pour un projet d'acquisition, de développement ou de refonte d'un système impliquant de tels renseignements. La même page traite aussi de la communication hors Québec, des décisions fondées exclusivement sur un traitement automatisé et des politiques de gouvernance. Elle vulgarise les obligations et n'a pas force de loi. Je l'utiliserais pour ouvrir la vérification juridique et contractuelle, pas pour déclarer automatiquement un produit conforme ou non conforme.

Les angles morts que j'accepte

Ma préférence va aux produits capables de démontrer leurs actions, leurs permissions et leurs contrôles lorsque l'usage visé dépasse l'interface humaine. J'accepte qu'une telle préférence puisse écarter un outil plus agréable à utiliser ou demander davantage de travail d'évaluation. Je n'en fais pas une obligation pour chaque achat.

J'accepte aussi qu'une API ou un serveur MCP ne règle ni l'auditabilité, ni l'approbation, ni l'annulation. Le fournisseur d'infrastructure Airbyte affirme que la plupart des fournisseurs n'offrent pas d'écriture multiple atomique. C'est un constat de vendeur, pas un inventaire indépendant de toutes les API. Il rappelle néanmoins que la réversibilité doit être testée action par action.

La décision reste donc contextuelle. Pour un logiciel périphérique, l'interface humaine peut gagner. Pour un système appelé à participer à un travail orchestré, je donnerais plus de poids aux capacités vérifiables qu'au discours sur l'IA. Le lecteur garde le dernier mot : accepter aujourd'hui un produit fermé peut être cohérent, à condition de reconnaître le coût de ce choix plutôt que de le découvrir après l'achat.