Ce qui change quand l’outil agit

Trois ruptures, et elles ne sont pas de degré. Un outil agentique n’est pas un assistant plus puissant : c’est un autre objet d’encadrement, dont les trois notions sur lesquelles reposent les chartes existantes — le périmètre, la relecture, la trace — changent de contenu.

Le périmètre n’est plus ce que l’agent a écrit. Dans une fenêtre de conversation, les données qui parviennent à l’outil sont celles que l’agent a saisies ou déposées. Il les a vues passer, il peut les décrire, et une charte peut lui demander de ne pas y mettre certaines catégories d’informations. Un outil agentique, lui, travaille sur un dossier. Le périmètre devient tout ce que ce dossier contient, y compris ce dont l’agent a oublié la présence : l’ancien export de la base des administrés, le classeur de suivi d’un collègue parti, les pièces jointes d’un dossier instruit l’an dernier. La question « qu’avez-vous mis dans l’outil ? » cesse d’avoir une réponse fiable, et il faut la remplacer par « sur quel dossier l’avez-vous fait travailler ? ».

Le résultat n’est plus relu avant d’être utilisé. Un texte produit dans une conversation est lu, corrigé et recopié par l’agent : la relecture est dans le geste. Un outil qui écrit directement un fichier, renomme une série de documents ou met à jour un tableau produit un résultat déjà en place. La relecture devient un geste séparé, qu’il faut vouloir, et que la commodité de l’outil pousse justement à ne pas faire. C’est sur ce point précis que les chartes existantes sont le plus démunies : elles demandent de vérifier ce que l’IA produit, ce qui suppose un moment où l’on vérifie, et ce moment a disparu.

La trace n’est plus une conversation. Dans une console d’administration, on retrouve des échanges. Avec un outil agentique, ce qui compte s’est passé sur la machine : des fichiers ouverts, des fichiers écrits, parfois des commandes exécutées. Le journal utile n’est plus celui de l’éditeur mais celui du poste, et aucune collectivité que nous rencontrons ne l’a prévu. Nous verrons plus loin que la réponse réaliste n’est pas de tout journaliser, mais de restreindre le terrain de jeu pour que le journal devienne inutile.

Deux outils, deux métiers, deux publics

Les deux noms circulent souvent ensemble, parfois comme deux niveaux du même produit. Ce n’est pas le cas, et les confondre conduit à la plus fréquente des erreurs de cadrage : réserver aux informaticiens un outil qui est fait pour les autres.

L’erreur de cadrage la plus courante consiste à traiter les deux ensemble, sous une ligne unique de la charte, du type « les outils d’IA agissant sur les systèmes sont réservés à la direction des systèmes d’information ». Cette ligne a l’air prudente. Elle produit en réalité deux effets : elle bloque l’outil dont les directions métier ont l’usage le plus immédiat, et elle n’empêche pas son installation, puisqu’il s’active dans un abonnement que l’agent possède déjà. Nous avons décrit ce mécanisme ailleurs : un refus sans alternative ne supprime pas l’usage, il le rend invisible. Le même Département a constaté l’installation de l’outil sur des postes où sa charte ne l’autorisait pas, et il l’a su par les statistiques d’usage de sa propre console — ce qui est, dans l’ordre des mauvaises nouvelles, la meilleure version possible : la collectivité a découvert l’écart chez elle, avant que quiconque ne le découvre pour elle.

Les quatre questions d’emploi

Voici le cœur de l’article. Ces quatre questions remplacent, pour un outil qui agit, la discussion habituelle sur les fonctions et les garanties de l’éditeur. Elles s’écrivent dans une note de cadrage et se vérifient sur le poste, pas dans une documentation commerciale.

1. Qui

Non pas « quel grade » ni « quelle direction », mais : qui est en capacité de relire ce que l’outil produit, et d’en répondre. Pour l’outil qui travaille sur des fichiers, la capacité requise est métier : savoir si le tableau consolidé est juste, si la liste est complète, si le document dit ce que le service voulait dire. Elle existe dans toutes les directions, et elle ne coïncide pas avec la maîtrise informatique. Pour l’outil qui travaille sur du code, la capacité requise est technique, et la restreindre est légitime.

La conséquence pratique est qu’une collectivité a besoin de deux règles, pas d’une. Et qu’elle gagne à les écrire en termes de capacité de relecture, qui est vérifiable, plutôt qu’en termes de périmètre organisationnel, qui vieillit mal et se contourne à la première réorganisation.

2. Sur quelle machine

C’est la question la plus déterminante, et la plus souvent omise. Un outil agentique installé sur le poste courant d’un agent a potentiellement accès à tout ce que ce poste atteint : le disque local, les lecteurs réseau montés, les dossiers synchronisés, les espaces partagés auxquels l’agent a droit. Les droits de l’outil sont ceux de l’agent, ce qui semble rassurant jusqu’au moment où l’on regarde l’état réel des habilitations dans une collectivité qui a connu plusieurs réorganisations sans revue des accès.

Trois dispositions existent, par ordre de prudence décroissante. Une machine dédiée, hors du réseau de production, sur laquelle on dépose la matière de la tâche et dont on récupère le résultat : c’est le choix du Département dont nous relayons l’expérience, qui a réservé l’outil à un poste administré par sa direction informatique et détaché du réseau. Un poste courant avec un périmètre de travail explicitement restreint, l’outil n’ayant accès qu’à un dossier désigné, les lecteurs réseau étant démontés pendant la session. Un poste courant sans restriction, qui n’est pas une disposition mais l’absence de disposition.

La première coûte une machine et un peu de friction, et permet de commencer tout de suite, y compris sur des cas d’usage que les arbitrages juridiques n’ont pas encore couverts. C’est le meilleur rapport entre ce qu’on apprend et ce qu’on risque, et c’est pour cela que nous la recommandons pour toute première expérimentation.

3. Avec quelles données

Pour un outil qui travaille sur un dossier, la réponse à cette question n’est pas une liste de catégories de données autorisées : c’est le contenu effectif du dossier. Le geste d’encadrement consiste donc à constituer le dossier de travail, et non à instruire l’agent sur ce qu’il peut y mettre. On copie dans un dossier dédié les seules pièces nécessaires à la tâche, on y fait travailler l’outil, et on en sort le résultat. Ce qui n’est pas dans le dossier n’est pas dans le périmètre, et cela se vérifie en regardant le dossier.

Quand la matière contient des données à caractère personnel ou des éléments couverts par un secret, le sas d’anonymisation est la réponse qui permet de ne pas attendre. Un outil local qui remplace les noms, les identifiants, les montants et les dates par des jetons avant que la matière n’entre dans le dossier de travail laisse la tâche s’exécuter sur une matière neutralisée, et le résultat se réassocie ensuite. Ce dispositif, que nous utilisons en mission, n’est pas une exigence réglementaire déguisée : c’est ce qui permet à une expérimentation de démarrer en semaine deux plutôt qu’au trimestre suivant.

4. Avec quelle validation humaine

Un outil qui agit doit rencontrer un geste humain avant toute opération qu’on ne sait pas défaire. La distinction utile n’est pas entre les actions importantes et les actions mineures, qui est affaire d’appréciation, mais entre ce qui est réversible et ce qui ne l’est pas. Lire un fichier, écrire un nouveau fichier, produire un tableau : réversible, la validation peut être une relecture après coup. Écraser un fichier existant, supprimer, renommer en série, envoyer un message, écrire dans une application métier : irréversible ou visible de l’extérieur, la validation doit précéder.

Cette règle s’écrit en trois lignes dans une note de cadrage et elle est comprise immédiatement, parce qu’elle recouvre une pratique administrative ordinaire. Elle a un corollaire que les collectivités adoptent spontanément dès qu’on le formule : on travaille sur une copie. Un dossier de travail est une copie du dossier de référence, et le résultat est reversé par une personne. Cela supprime d’un coup la plus grande partie du risque, sans rien interdire.

Le point aveugle : ce que l’agent laisse derrière lui

C’est le sujet dont personne ne parle, et c’est celui qui décidera si ces outils produisent de la valeur durable ou une dette interne. Un outil agentique ne produit pas seulement des réponses : il produit des objets qui continuent d’exister après la fin de la tâche.

Un agent qui dispose d’un tel outil ne s’arrête pas à la consolidation d’un tableau. Au bout de quelques semaines, il a fabriqué une petite application pour son service : un formulaire qui alimente un suivi, un outil de revue de presse, un tableau de bord qui recoupe deux exports. Cela fonctionne, cela fait gagner un temps réel, et c’est très exactement ce qu’on attendait de l’outil. Le Département dont nous relayons l’expérience en a produit plusieurs, dont une qui fait gagner près d’une heure par jour à deux agents.

Et c’est là que la question se pose, parce que ces objets n’ont pas de propriétaire. Ils vivent sur le poste de leur auteur. Personne ne les a recensés, personne ne les maintient, personne ne sait ce qui se passe quand l’auteur change de service, quand le format d’un export change, ou quand l’application se met à produire un résultat faux sans le dire. Dans la collectivité en question, la formulation entendue est que l’hébergement et la maintenance de ces applications sont « la pièce manquante » — et le constat vaut bien au-delà d’elle.

Nous en tirons une recommandation qui surprend parfois, parce qu’elle semble prématurée : décider où vivront ces objets avant d’ouvrir l’outil, et non après. Concrètement, trois décisions, qui tiennent dans une page et qu’on ne peut pas prendre rétroactivement sans un gros travail de reprise.

Ces trois décisions ne freinent pas l’expérimentation, et c’est l’essentiel : elles n’ajoutent aucune autorisation préalable et ne demandent à personne de patienter. Elles organisent seulement ce qui, sans elles, s’accumulera pendant dix-huit mois avant de devenir un sujet d’audit.

Pourquoi un compte partagé ne convient pas

Beaucoup de collectivités ont ouvert leur premier déploiement sur des comptes partagés par direction, pour des raisons que nous comprenons et que nous avons détaillées ailleurs. Cette disposition, acceptable pour un assistant qui répond, cesse de l’être pour un outil qui agit.

La raison tient en une phrase. Un compte partagé casse le lien entre une personne et un acte ; or ici l’acte n’est plus l’envoi d’une question, c’est l’écriture d’un fichier. Quand le résultat de la tâche est un document faux reversé dans un dossier de service, savoir que l’opération a été conduite depuis le compte d’une direction ne sert à rien : ce qu’il faut pouvoir reconstituer, c’est qui a lancé la tâche, sur quelle matière, et qui a relu le résultat.

S’y ajoute un point plus concret. Un outil agentique travaille avec les droits de la session sur laquelle il tourne. Sur un compte partagé, cette session est celle d’un collectif, dont les droits sont par construction l’union de ce dont ses membres ont besoin — c’est-à-dire plus que ce dont chacun a besoin. Le périmètre de données accessible à l’outil cesse de coïncider avec les habilitations de la personne qui l’emploie, exactement comme pour les connecteurs.

D’où la règle que nous posons, dans le prolongement de celle que nous avions énoncée pour les connecteurs : pas d’outil agentique sur un compte partagé. Elle n’oblige pas une collectivité à basculer tout son déploiement en comptes nominatifs, ce qui serait une autre décision avec ses propres difficultés. Elle dit seulement que l’expérimentation agentique se mène sur un petit nombre de comptes nominatifs dédiés, ce qui est compatible avec un déploiement partagé par ailleurs, et ce qui est de toute façon ce que la machine dédiée impose en pratique. Nous consacrons un article entier à ce que le choix du modèle de comptes change pour le délégué à la protection des données.

Ce que la charte doit dire, et ce qu’elle ne doit pas dire

Une charte d’IA écrite en 2025 ou au début de 2026 ne dit rien de ces outils, et c’est normal. La tentation est alors d’ajouter une ligne d’interdiction, en attendant d’y voir plus clair. C’est le geste qui coûte le plus cher.

Notre modèle de charte traite les fonctions une à une plutôt que les outils globalement, avec un réexamen périodique, et c’est précisément pour ce genre de situation que cette structure a été retenue. Une charte qui nomme des outils doit être rouverte à chaque mouvement du marché, c’est-à-dire plusieurs fois par an, et chaque réouverture suppose de repasser devant les instances. Une charte qui nomme des fonctions — produire du texte, manipuler des fichiers, écrire du code, agir sur un système — absorbe l’arrivée d’un outil nouveau sans être modifiée, et la liste des outils autorisés vit dans une annexe que l’administration met à jour.

Ce qu’une charte gagne à dire sur les outils qui agissent se ramène aux quatre questions d’emploi, plus les trois décisions sur les objets produits. Soit, en pratique : la capacité de relecture exigée, le type de machine, la règle du dossier de travail, le geste humain avant une opération irréversible, et le registre des objets produits.

Ce qu’elle gagne à ne pas dire, c’est une interdiction générale sans délai d’instruction. Nous l’avons écrit dans notre modèle sous une forme un peu sèche : on n’interdit pas sans proposer d’alternative, et toute demande d’outil reçoit une réponse motivée dans un délai écrit. Appliqué ici, cela donne une règle simple à tenir : l’outil n’est pas ouvert à tous, une demande peut être déposée, elle est instruite en un temps annoncé, et un refus dit pourquoi. Sans cela, l’outil s’installe quand même, et la collectivité l’apprend par ses statistiques d’usage — dans le meilleur des cas.

Quatorze articles, en accès libre, avec pour chacun un texte type et un commentaire. L’article 5 traite les fonctions une à une ; l’article 3 porte le délai d’instruction.

Expérimenter sans ouvrir en grand

La bonne échelle d’une première expérimentation agentique n’est pas celle d’un déploiement d’assistant. On ne cherche pas l’adoption, on cherche à savoir si la tâche visée tient, et ce que l’outil laisse derrière lui. Huit semaines suffisent, et trois agents aussi.

Le choix de la tâche décide de tout. Une bonne tâche candidate a quatre propriétés : elle est pénible, elle est répétée, son résultat est vérifiable par celui qui la fait, et elle porte sur des fichiers que l’on peut copier dans un dossier dédié. La reprise d’une série d’exports hétérogènes en un tableau unique, la préparation d’un dossier à partir de pièces éparses, la mise en forme d’un rapport long à partir de contributions : ces tâches cochent les quatre cases. À l’inverse, une tâche dont personne ne sait dire si le résultat est juste n’apprend rien, et une tâche qui touche à un système en production n’est pas une tâche d’expérimentation.

Le protocole est volontairement pauvre. Une machine, administrée, hors réseau de production. Trois agents volontaires, sur des métiers différents, avec des comptes nominatifs dédiés. Un dossier de travail par tâche, constitué par copie. Un journal tenu par les agents eux-mêmes : la tâche, le temps qu’elle prenait avant, le temps qu’elle a pris, ce qui a dû être corrigé, et ce qui a été produit et qui va continuer d’exister. Ce dernier point est celui qu’on oublie, et c’est le seul qui renseigne sur la dette que l’on crée.

Ce qu’on en attend à huit semaines n’est pas un avis favorable ou défavorable : c’est une décision motivée et datée sur trois points. Quelles tâches confier à un outil qui agit, et lesquelles ne pas lui confier. Quelle disposition de machine retenir pour la suite. Et où vivront les objets produits. Avec ces trois réponses écrites, une collectivité peut passer à l’échelle sans rejouer la discussion de départ, et c’est exactement ce que nous appelons arriver déjà outillé.

La frugalité d’un outil qui travaille longtemps

Ici, l’approche habituelle de la sobriété numérique est mise à l’épreuve. Comparer des outils à la requête n’a plus grand sens quand une seule demande déclenche une longue série d’opérations. Il faut changer d’unité.

Une tâche confiée à un outil agentique n’est pas une question posée dans une fenêtre de conversation : c’est un enchaînement de nombreuses étapes, dont chacune mobilise le modèle. L’ordre de grandeur du coût, budgétaire comme environnemental, n’est donc pas celui d’un échange, et le raisonnement à la requête conduit à des conclusions fausses dans les deux sens. On surestime le coût si l’on compte une tâche comme une question, et on le sous-estime très largement si l’on continue de raisonner avec les repères de l’assistant conversationnel.

L’unité qui a du sens est la tâche aboutie, comparée à ce qu’elle coûtait avant. Une reprise de fichiers qui occupait un agent une demi-journée et qui s’exécute en quelques minutes a un bilan favorable, même avec un coût unitaire plus élevé, parce que le terme de comparaison n’est pas une question posée à un assistant mais une demi-journée de travail humain et les outils qu’elle mobilisait. Une tâche relancée onze fois parce que la consigne était mal écrite a un bilan défavorable, et c’est la formation qui le corrige, pas le choix de l’outil.

Le second niveau est le même que pour les licences d’assistant, et il est encore plus net ici : un droit d’accès payé et inutilisé est un gaspillage budgétaire et environnemental, et le pilotage consiste à mesurer l’usage réel plutôt qu’à compter les accès ouverts. Pour un outil agentique, l’usage réel se mesure en tâches abouties, ce qui suppose que quelqu’un les compte — raison supplémentaire de tenir le journal de l’expérimentation. Notre calculateur de coût d’un programme d’IA générative, qui sépare le coût par accès ouvert du coût par agent réellement actif, s’applique sans changement à ce cas.

Alors, faut-il y aller ?

Oui, et pas comme on a ouvert l’assistant. Ce n’est pas une position prudente de façade : les deux gestes n’ont pas la même forme, et confondre les deux est la seule vraie erreur.

Un assistant conversationnel s’ouvre largement et s’encadre par une charte, parce que sa valeur vient du nombre d’agents qui s’en servent et que son risque principal est ce qu’ils y saisissent. Un outil agentique se mène à l’inverse : peu d’agents, un périmètre étroit, une machine désignée, et un encadrement qui porte sur la machine et sur ce qui en sort plutôt que sur le comportement de l’utilisateur. Sa valeur ne vient pas du nombre d’utilisateurs mais du nombre de tâches pénibles qu’il fait disparaître, et une collectivité qui en traite trois sérieusement a plus de résultat qu’une collectivité qui ouvre l’outil à deux cents personnes sans dossier de travail ni registre.

Trois règles d’ordre, pour finir, qui valent mieux qu’une recommandation d’outil. Commencer par la tâche, jamais par l’outil : une tâche pénible, répétée, vérifiable. Décider où vivront les objets produits avant d’ouvrir, parce que c’est la seule décision qu’on ne peut pas prendre après. Et ouvrir par le haut des capacités de relecture plutôt que par le haut de la hiérarchie, ce qui conduit souvent à commencer dans une direction métier et non à la direction informatique.

Nos ressources sur ce sujet

Trois documents en accès libre sur notre page Ressources servent directement un cadrage d’outils agentiques. Le modèle de charte IA traite les fonctions une à une, ce qui permet d’absorber l’arrivée de ces outils sans réadopter la charte. Le modèle de CCTP d’assistance à maîtrise d’ouvrage contient une fiche de cas d’usage utilisable telle quelle pour qualifier une tâche candidate. Et la grille comparative des solutions d’IA générative permet de poser les mêmes questions à plusieurs éditeurs, en consignant la date de chaque réponse.

Questions fréquentes

Lien direct : calendar.app.google/8FprCJKk4xFnm4f57