Concevoir des logiciels pour les agents, pas seulement pour les humains

La plupart des logiciels d'entreprise ont aujourd'hui deux sortes d'utilisateurs : des personnes dans un navigateur ou une application, et d'autres systèmes qui appellent une API. Une troisième arrive. Un employé demande à Claude, ChatGPT ou Cursor de « saisir les factures fournisseurs de la semaine dernière » ou de « fermer les tickets corrigés dans la dernière version », et l'agent s'en charge en appelant directement votre logiciel.

Pour une entreprise qui développe ou exploite des logiciels, la question pratique devient : lesquels de vos produits et outils internes un agent doit-il pouvoir utiliser, et que faut-il mettre en place à l'intérieur avant de l'ouvrir ?

Comment les agents accèdent aux logiciels

La voie la plus courante est le Model Context Protocol (MCP), un standard ouvert qui décrit les actions qu'un système propose (« lister les factures », « créer un ticket ») pour que n'importe quel agent compatible puisse les appeler. Un même serveur fonctionne alors avec de nombreux agents différents. Le protocole est maintenu publiquement ; sa version actuelle est datée du 28/07/2026, et ses mainteneurs font état de « close to half-a-billion downloads a month », soit près d'un demi-milliard de téléchargements par mois sur les principaux SDK (les deux vérifiés le 26 septembre 2026).

Beaucoup d'outils que vos équipes utilisent déjà publient un serveur officiel. Vérifié dans la documentation de chaque éditeur le 26 septembre 2026 :

Produit	Ce qu'un agent peut faire	Contrôles documentés par l'éditeur
Stripe	Lire et écrire les données de paiement	Clés propres à l'agent ; validation humaine par lien pour les remboursements et paiements sortants
GitHub	Dépôts, issues, pull requests	OAuth ou token personnel, mode lecture seule
Sentry	Erreurs et issues	Limité à une organisation ou un projet
Notion	Lire, créer, modifier des pages	Les propriétaires de l'espace voient et révoquent les connexions
Qonto	Banque professionnelle, lecture et écriture	OAuth
Linear	Issues et projets	OAuth ou clé API

Deux chiffres sur l'usage, tous deux publiés par les entreprises concernées. En annonçant le rachat de Neon, Databricks a écrit que les agents étaient passés de 30 % à plus de 80 % des bases de données créées sur la plateforme ; Neon vend à des gens qui développent avec des agents, ce chiffre décrit donc son propre marché. L'Economic Index de septembre 2025 d'Anthropic a constaté que 77 % de l'usage professionnel via son API relevait de l'automatisation : le modèle accomplit la tâche au lieu d'aider une personne à la faire.

Le protocole est la petite partie

Placer un serveur MCP devant un système existant demande peu de code. Les SDK officiels gèrent le transport et, d'après notre expérience, un premier outil en lecture seule tourne en moins d'une journée. Le travail qui détermine si l'accès des agents peut être activé sans risque se trouve dans le produit.

La règle dont nous partons : un agent ne peut jamais faire ce que la même personne ne pourrait pas faire dans l'application. Il peut en faire moins. Cette règle coûte peu à tenir quand les outils de l'agent appellent les mêmes fonctions internes que l'application, avec les mêmes contrôles de droits. Elle coûte cher quand l'accès des agents est greffé de l'extérieur et réimplémente les droits à un second endroit, car les deux copies divergent dès que quelqu'un modifie l'une d'elles.

L'effort d'ingénierie va dans les écritures

Lire des données via un agent pose un risque pour la vie privée mais casse rarement quelque chose. Les écritures, si : un agent qui comprend mal « supprime le doublon » peut effacer le mauvais enregistrement à la vitesse d'une machine.

Quand nous avons construit l'accès des agents pour l'un de nos propres produits, l'essentiel de l'effort est allé dans quatre chantiers autour des écritures.

Une confirmation avant chaque écriture. Les instructions du serveur et la description de chaque action d'écriture demandent à l'agent de n'agir qu'une fois que l'utilisateur a confirmé cette modification précise. Les actions sont marquées comme lecture seule ou destructives de manière standard, ce qui permet à des clients comme Claude Code et ChatGPT d'afficher leur propre demande de validation. Une action d'aperçu calcule le résultat côté serveur, de sorte que les chiffres validés par l'utilisateur sont ceux qui sont enregistrés.

Un historique de chaque écriture, quel que soit le client. Chaque modification enregistre qui l'a faite, personne ou agent, quel agent, la raison donnée par l'agent, et des instantanés complets avant et après. Le plus long a été de journaliser aussi les écritures humaines faites dans l'application. Sans elles, le système ne sait pas si une personne a modifié un enregistrement après l'agent, et une annulation écraserait son travail sans prévenir.

Une annulation limitée dans le temps. La modification d'un agent peut être annulée pendant une fenêtre limitée. L'annulation est refusée si quelqu'un d'autre a touché l'enregistrement entre-temps, et un groupe de modifications faites dans une même requête s'annule en bloc ou pas du tout.

Des identifiants restreints et expirants, et un interrupteur par action. Les tokens sont séparés des connexions à l'application, stockés uniquement sous forme de hash, limités à la lecture ou à l'écriture, et ils expirent. Chaque action a son propre réglage marche/arrêt : on peut en retirer une sans déploiement, et un réglage absent vaut arrêt.

Où ça casse, et quand c'est prématuré

La confirmation dépend du client. Plusieurs outils d'agents ont un mode d'approbation automatique, et une fois que l'utilisateur l'active, rien de ce que dit le serveur n'impose une demande de validation. Pour les actions à haut risque, Stripe répond par un lien d'approbation qu'un humain doit ouvrir, valable 24 heures. L'autre réponse, c'est l'historique et l'annulation : le retour arrière devient alors le mécanisme de sécurité qui tient vraiment.

L'injection de prompt n'est pas résolue. La « lethal trifecta » de Simon Willison décrit la combinaison dangereuse : un agent qui a accès à des données privées, qui lit du texte écrit par quelqu'un d'autre et qui dispose d'un moyen d'envoyer des données vers l'extérieur. Deux incidents le montrent en pratique. Invariant Labs a signalé en mai 2025 qu'une issue GitHub publique malveillante pouvait amener un agent à divulguer des données d'un dépôt privé. General Analysis a signalé en juillet 2025 que le texte d'un ticket de support Supabase avait amené un agent, doté d'une clé à accès total, à recopier une table privée dans le ticket. Tout champ que vos utilisateurs remplissent, un titre de ticket ou une note client, peut porter des instructions destinées à l'agent de quelqu'un d'autre.

Les fondations bougent encore. La version du protocole de juillet 2026 a rompu la compatibilité avec les précédentes. L'équipe d'ingénierie d'Anthropic a publié une autre manière pour les agents d'appeler des outils, qui a fait passer un exemple de 150 000 tokens à 2 000. Ce que vous construisez aujourd'hui devra être revu.

La demande peut être faible. Pour beaucoup de produits, ceux qui réclament un accès pour les agents se comptent sur les doigts d'une main, et ce sont des développeurs. Gartner prévoyait en juin 2025 que plus de 40 % des projets d'IA agentique seraient abandonnés d'ici fin 2027. Si vos clients ne le demandent jamais et que vos équipes n'utilisent pas d'agents, un pilote en lecture seule pour un usage interne est le bon périmètre.

Les données sortent aussi. Quand un utilisateur connecte un fournisseur d'IA, tout ce que l'agent lit part chez ce fournisseur. Pour des enregistrements qui contiennent des données personnelles de tiers, c'est une question RGPD à régler avant que le premier utilisateur externe se connecte.

Ce qu'il faut vérifier d'abord

À peu près dans cet ordre :

1. Chaque écriture passe-t-elle par un seul endroit ? Si l'application, le back-office et l'API modifient chacun les données à leur façon, l'accès des agents hérite des trois. Corrigez cela en premier.
2. Choisissez quelques actions, la lecture d'abord. Commencez par ce que les gens demandent le plus, en général des recherches et des rapports. Ajoutez les écritures une par une.
3. Décidez de ce qui exige une validation humaine. Les modifications réversibles et de faible valeur peuvent passer sur confirmation dans le chat. Les mouvements d'argent et les suppressions méritent une étape de validation distincte.
4. Journalisez avant d'autoriser les écritures. Auteur, source et état avant et après, pour les humains comme pour les agents.
5. Construisez l'annulation, avec détection des conflits.
6. Donnez aux agents leurs propres identifiants. Restreints, expirants, révocables, jamais la clé maître. Le guide de sécurité MCP interdit de relayer d'autres tokens, et Stripe n'acceptera plus les clés secrètes à accès total sur son serveur à partir du 31 octobre 2026.
7. Traitez chaque champ rédigé par un utilisateur comme non fiable dans ce que vous renvoyez à un agent.

Pour l'argumentaire économique, voir pourquoi votre logiciel devrait fonctionner avec les agents IA.

Nous intégrons ce type d'accès pour agents dans des produits et outils internes existants. Si vous l'envisagez pour les vôtres, écrivez-nous.