La réunion est toujours la même. Quelqu'un montre un agent qui marche, quelqu'un de la DSI demande quels accès il va lui falloir, et la réponse — « il faudrait qu'il puisse mettre à jour le statut dans l'ERP » — transforme une démo de quinze minutes en point d'ordre du jour d'un comité qui se réunit toutes les trois semaines. À partir de là, le calendrier du projet n'appartient plus à celui qui l'a construit.
La thèse en une phrase : les droits d'écriture d'un agent IA ne sont pas une case de sécurité qu'on coche à la fin de la conception, c'est la variable qui déplace le plus le coût et le délai de tout le reste. Un agent en lecture seule se monte en quelques semaines et se valide sans drame. Dès qu'il écrit dans un système de référence, arrivent les validations, la réversibilité, le rapprochement et l'audit, et le projet change de division. Cette case se tranche en premier, pas à la fin, parce que tout le budget en dépend.
Les droits d'écriture d'un agent IA ne sont pas une décision de sécurité : c'est la ligne la plus chère
C'est la sécurité qui convoque la discussion, alors elle se formule dans son langage : menaces, surface d'attaque, moindre privilège. Ce cadrage est juste et incomplet. Ce qui coûte cher quand on laisse un agent écrire, ce n'est pas le risque qu'on le détourne — ce risque existe et on le borne par la conception des accès, c'est une autre conversation. Ce qui coûte cher, c'est tout ce qu'il faut construire autour pour que l'écriture devienne acceptable : un chemin de retour quand l'agent se trompe, un moyen de savoir qu'il s'est trompé, et quelqu'un, avec un nom, qui répond de ce qui a été écrit.
C'est là le changement de division. Un agent en lecture seule a besoin d'un accès en consultation et d'un endroit où déposer son résultat. Un agent qui écrit a besoin, au minimum, de quatre pièces qui ne sont presque jamais budgétées : un moyen d'annuler chaque action, un rapprochement périodique qui détecte ce qui a été mal écrit sans que personne ne s'en aperçoive, une file d'exceptions avec quelqu'un qui la regarde, et une trace par action permettant de reconstituer ce qui s'est passé trois mois plus tard. Aucune des quatre n'est l'agent. On paie les quatre quand même.
La conception des accès elle-même — la matrice de ce qu'il lit, ce qu'il écrit, ce qu'il exécute et ce qu'il ne touche jamais — on la développe dans quels droits donner à un agent IA. Ce qu'on ajoute ici, c'est la couche du dessus, celle qui se discute en réunion budget et pas en réunion d'architecture : ce que chaque réponse de cette matrice te coûte.
Ce qu'un agent en lecture seule livre vraiment
L'objection immédiate, c'est qu'un agent qui n'écrit pas ne sert à rien. C'est faux, et c'est une de ces croyances qui survivent parce que personne ne prend le temps de lister le contraire. Avec un accès uniquement en lecture, et sans toucher une seule ligne d'aucun système, un agent livre des choses qui consomment aujourd'hui des heures de gens chers :
- Préparer la décision au lieu de la prendre : le dossier complet, avec l'historique, les pièces jointes et les trois chiffres qui comptent, prêt pour qu'une personne tranche en deux minutes ce qui lui prenait vingt.
- Repérer ce que personne ne regarde : contrats qui arrivent à échéance, commandes à l'arrêt, clients sans activité depuis quarante jours, écarts entre deux systèmes censés dire la même chose.
- Rédiger le brouillon : le mail, le rapport, la réponse à l'appel d'offres, la fiche du candidat. Le texte est produit en entier et c'est un humain qui l'envoie, ce qui est exactement là où était le travail.
- Répondre à des questions sur des données éparpillées : ce qui est dans l'ERP, dans le CRM et dans un dossier réseau, répondu en une phrase avec le lien vers la source.
- Surveiller la qualité de ce que les autres écrivent : comparer ce qui a été enregistré à ce qui a été documenté et lever la main quand ça ne colle pas.
Remarque le point commun des cinq : l'agent produit et une personne dispose. L'économie est réelle — chercher, réunir, comparer et rédiger, c'est le gros de beaucoup de processus — et le pire qui puisse arriver, c'est que quelqu'un lise mal et le corrige avant d'agir. D'où le fait que ces projets se valident en une réunion et pas en trois : il n'y a rien à annuler.
Ce qui apparaît à la minute où l'agent écrit
La frontière n'est pas graduelle : on la franchit d'un coup. Dès qu'une action de l'agent est enregistrée dans un système dont l'entreprise répond, cinq choses changent en même temps, qui n'étaient pas dans le projet.
| Ce qui change | Agent en lecture seule | Agent qui écrit dans un système de référence |
|---|---|---|
| Qui valide | Le propriétaire du processus, parfois son patron | Un comité : DSI, risques, protection des données et, s'il y a de l'argent, audit interne |
| Ce qu'on construit en plus de l'agent | Un accès en consultation et un endroit où déposer le résultat | Annulation par action, rapprochement périodique, file d'exceptions et trace reconstituable |
| Ce qui se passe quand il se trompe | Quelqu'un lit mal et corrige avant d'agir | L'erreur est déjà dedans et a déclenché la suite : une relance client, un paiement, une écriture |
| Délai avant la mise en service | Des semaines | Des mois, et le gros du calendrier n'est pas la construction de l'agent |
| Ce qu'exige le régulateur européen si le cas est à haut risque | Peu : l'agent ne décide rien tout seul | Un contrôle humain effectif, avec capacité d'écarter la sortie et d'arrêter le système |
La dernière ligne n'est pas de la rhétorique. Dans l'Union européenne, l'article 14 du règlement sur l'IA impose que les systèmes à haut risque soient conçus pour que les personnes chargées du contrôle puissent décider de ne pas utiliser le système, ignorer, écarter ou inverser sa sortie, et puissent l'interrompre par un bouton d'arrêt ou une procédure équivalente. Source : Article 14 — Human oversight, règlement (UE) 2024/1689. (Périmètre : Union européenne, et uniquement pour les systèmes classés à haut risque. Un agent qui lit et propose y entre rarement ; un agent qui exécute sur des personnes, souvent.)
Lu à l'envers, cet article est une liste de courses technique : écarter, inverser, arrêter. Si ton agent écrit et que tu ne sais pas dire comment se fait chacune des trois, tu n'as pas un sujet de conformité pour plus tard. Tu as trois pièces non construites et non budgétées.
Les trois motifs intermédiaires que presque personne ne met sur la table
La discussion se pose comme un interrupteur — il lit ou il écrit — et c'est là que part l'argent, parce qu'entre les deux extrêmes il y a trois positions intermédiaires qui livrent presque toute la valeur de l'écriture pour une fraction de son coût de validation.
1. Le brouillon qu'un humain confirme
L'agent prépare l'action et quelqu'un appuie. Le mail rédigé dans la boîte d'envoi, la commande créée au statut brouillon, l'écriture proposée et non comptabilisée. Techniquement l'agent écrit, mais il écrit dans un état sans effet, et cela change tout dans la conversation de validation : il n'y a rien à annuler, puisque rien ne s'est encore produit. Le coût, c'est une personne qui confirme : bon marché à faible volume, et cher précisément quand le système a déjà prouvé qu'il vise juste. C'est ce moment-là qu'il faut saisir pour monter d'un cran, pas avant.
2. L'écriture dans une zone tampon
L'agent écrit pour de vrai, mais dans une table, un espace ou un environnement qui est le sien et dont personne d'autre ne dépend. Un autre processus — souvent déjà existant — récupère de là et porte le résultat vers le système réel avec ses propres contrôles. C'est le motif le moins souvent proposé et celui qui passe les comités le plus vite, parce que le système de référence garde intacts ses contrôles d'entrée : l'agent n'est pas un utilisateur privilégié, c'est une source de données de plus, et les sources de données, l'entreprise sait déjà les traiter.
3. L'écriture réversible avec fenêtre d'annulation
L'agent agit directement, mais seulement sur des actions dont le chemin de retour tient en une phrase, et pendant une fenêtre où annuler ne coûte rien. Changer le statut d'une commande est réversible ; émettre la facture de cette commande, non. La règle pratique est brutale et utile : une action ne s'automatise sans confirmation que si quelqu'un sait expliquer en une phrase comment on l'annule. Si la phrase n'existe pas, l'action reste au motif 1. Les critères pour monter — volume de cas vus, taux de correction humaine et réversibilité — sont développés dans les niveaux d'autonomie d'un agent.
Comment négocier le saut par étapes
L'erreur de négociation la plus fréquente : demander l'écriture le jour de la proposition, quand l'agent n'a encore rien prouvé et que celui qui doit valider n'a pas une seule donnée pour trancher. On demande au pire moment possible : incertitude maximale, preuve minimale. Le résultat est prévisible — un comité, trois semaines, une liste de conditions — et c'est en général le moment où le projet commence à mourir d'ennui.
L'alternative : démarrer en lecture et arriver à la réunion d'extension avec trois chiffres qui n'existaient pas avant. Combien de cas l'agent a vus, dans quelle proportion l'humain a modifié ce qu'il proposait, et combien de ces corrections relevaient du jugement et non de la donnée. Avec ça, la conversation cesse de porter sur la confiance et porte sur la preuve, terrain où les comités avancent bien. Et ce qu'on demande, ce n'est pas « qu'il puisse écrire », c'est une liste courte d'actions précises, chacune avec sa phrase sur la façon dont on l'annule.
Il vaut mieux aussi écrire dès le départ la liste de ce qui ne monte jamais, quelle que soit la preuve accumulée : l'irréversible, ce qui touche à l'argent de tiers, ce qui est visible par le client sans relecture et ce qui affecte les droits d'une personne. Poser cette limite par écrit au jour un, c'est ce qui permet de négocier tout le reste avec aisance, parce que ça montre que la proposition a des freins et pas seulement un accélérateur.
Le marché paie déjà cette facture
Que ce ne soit pas une lubie d'architecte, la taille du gâchis le suggère. Gartner prévoit que plus de 40 % des projets d'IA agentique seront annulés avant la fin 2027, et pointe trois causes : des coûts qui dérapent, une valeur métier floue et des contrôles de risque insuffisants. Source : Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, Gartner, 25 juin 2025. (Périmètre : prévision mondiale du cabinet, pas un résultat de notre part. Elle dimensionne le problème, elle ne dit pas ce que nous livrons.)
Les trois causes sont la même chose vue de trois endroits. Un projet qui présuppose l'écriture découvre tard le coût des contrôles que l'écriture impose, et cette découverte tardive est à la fois le dépassement, le retard qui érode la valeur perçue et le contrôle de risque arrivé après la conception. La décision lecture ou écriture, prise au jour un et par écrit, c'est ce qui sépare un projet qu'on livre d'un projet qu'on annule, budget déjà dépensé.
Quand plusieurs agents tournent déjà, ça cesse d'être une décision par projet et devient une fonction : qui autorise chaque extension de périmètre, sur quelle preuve, ce qui est consigné et qui en répond. Cette fonction continue, c'est ce qu'on monte dans gouverner les agents IA de ton entreprise ; cet article, c'est la décision concrète qui la rend nécessaire.
Décide d'abord s'il écrit
Si tu as aujourd'hui une proposition d'agent sur la table, une question se traite avant les autres et avant de regarder le moindre prix : cet agent écrit-il dans un système dont nous répondons ? Si la réponse est non, le projet est court, le risque est un risque de lecture et la validation tient en une réunion. Si la réponse est oui, le budget devant toi est incomplet, parce qu'il n'inclut ni annuler, ni rapprocher, ni traiter les exceptions, ni laisser une trace. Et si la réponse est « bon, plus tard », exige d'en faire un non explicite pour la phase un et une liste d'actions précises pour la phase deux.