Aller au contenu
Blog

Gouvernance

Personne ne regarde l’agent qui tourne à 3 heures

Une tâche programmée n’a pas de demandeur. Elle hérite des droits de qui l’a créée, survit à son départ, et échoue en silence.

La personne qui l’a mise en place, et cette réponse doit avoir une conséquence désagréable, sinon elle ne veut rien dire : la tâche s’arrête quand cette personne s’en va. Une exécution programmée est le seul cas où un agent agit sans que personne ne le lui demande, et c’est exactement ce qui la rend difficile à gouverner.

Nous défendons par ailleurs qu’un agent agit avec les droits du demandeur et jamais avec les siens, parce qu’une identité propre crée un chemin qui contourne toutes les habilitations. La tâche programmée est le trou de cette règle, et nous le disons plutôt que de le cacher : à 3 heures du matin, il n’y a pas de demandeur. Le rattachement à la personne qui a créé la routine est le moins mauvais des choix disponibles, et il n’est honnête que si l’on accepte ce qu’il implique au départ de cette personne.

Qu’est-ce qui distingue une tâche programmée d’une conversation ?

Trois choses disparaissent en même temps, et elles ne se remplacent pas séparément.

Le demandeur, d’abord, donc le rattachement des droits. Le contexte, ensuite : dans une conversation, l’agent sait pourquoi on lui demande quelque chose, alors qu’une routine part d’une heure et d’une condition. Et le témoin, enfin, celui qui aurait vu passer une réponse absurde et l’aurait signalée dans la seconde.

Cette dernière perte est la plus sous-estimée. Dans un usage conversationnel, la relecture humaine est gratuite et permanente : elle n’est écrite nulle part, personne ne l’appelle un contrôle, et elle attrape pourtant l’essentiel. En la retirant, on ne perd pas du confort, on perd le seul dispositif de détection qui fonctionnait sans avoir été conçu.

Le déclenchement autonome est d’ailleurs l’un des cinq comportements qui séparent un agent réel d’un assistant bien habillé. C’est aussi celui qui change le plus la nature du risque, parce qu’il est le seul à supprimer l’humain de la boucle par construction plutôt que par négligence.

À qui appartient une routine, six mois après ?

À personne, le plus souvent, et c’est devenu une catégorie de risque nommée.

Un agent orphelin est un agent dont le propriétaire humain a quitté l’organisation ou n’est plus identifiable, pendant que ses identifiants restent valides. Le phénomène n’est pas théorique : les équipes de sécurité constatent une accumulation d’outils autonomes toujours en train de tourner après le départ de leurs créateurs. Les identifiants concernés sont couramment créés avec une expiration d’un à deux ans, parfois aucune, quand la recommandation courante tient en 90 jours et deux propriétaires actifs déclarés par inscription.

L’ordre de grandeur du problème est celui que nous citions à propos des identités non humaines : 45 comptes non humains pour un compte humain, et 92 % des outils de gestion des identités inadaptés à ces objets. Une routine n’est pas autre chose qu’un compte non humain avec une horloge dessus.

La parade est administrative et sans mystère : ajouter les agents à la procédure de départ, au même titre qu’un badge, une boîte aux lettres ou un accès distant. Ce n’est pas séduisant, cela tient en une ligne dans une liste existante, et c’est la différence entre une routine qui s’arrête proprement un vendredi et une routine qui continue d’écrire dans un CRM au nom de quelqu’un qui travaille ailleurs depuis huit mois.

Pourquoi le silence est le pire mode de défaillance

Parce qu’une exécution qui n’a rien trouvé et une exécution qui n’a pas eu lieu produisent exactement la même chose.

Les chiffres rendent la situation concrète. Datadog mesure environ 5 % d’échecs sur les requêtes de modèles en production, dont près de 60 % viennent de limites de capacité. Sur une routine quotidienne, cela représente en moyenne une exécution ratée par mois, à une heure où personne ne regarde, pour une raison qui n’a rien à voir avec la qualité de ce qui a été demandé. Ajoutez que près de sept entreprises sur dix font tourner au moins trois modèles différents, et vous obtenez plusieurs sources d’indisponibilité qui ne se coordonnent pas.

La règle que nous en tirons est plus exigeante qu’il n’y paraît : l’absence de résultat doit être un événement. Une routine qui a tourné et n’a rien trouvé le dit, brièvement, à l’endroit où elle parle d’habitude. Cela paraît bavard pendant deux semaines, puis cela devient la seule chose qui distingue un mois calme d’un mois où la tâche était cassée. Le coût de cette convention est une ligne par jour ; le coût de son absence est un écart découvert au bout de six semaines, quand quelqu’un remarque qu’il n’a plus rien reçu depuis un moment sans savoir dire depuis quand.

Un corollaire, moins évident : une exécution qui échoue ne réessaie pas indéfiniment en silence. Réessayer sans le dire est l’un des comportements qu’un bon agent refuse, parce qu’une série de tentatives invisibles transforme une panne franche en une lente dégradation que personne ne peut dater.

Quelles tâches méritent d’être programmées ?

Celles dont le résultat se vérifie plus vite qu’il ne se produit, ce qui est le même critère que pour la première délégation à un agent et pour la même raison : la confiance se construit sur ce qui se contrôle d’un coup d’œil.

Deux propriétés supplémentaires comptent quand personne ne regarde. La tâche doit pouvoir tourner deux fois sans dommage, parce qu’une reprise après incident la rejouera : une relance envoyée en double est un dommage, un relevé recalculé ne l’est pas. Et son résultat doit être borné, au sens où l’on sait à l’avance à quoi ressemble une sortie normale. Une routine qui peut légitimement produire trois lignes ou quarante pages ne se surveille pas, puisque aucun écart ne saute aux yeux.

Ce qui échoue systématiquement à ces trois tests, ce sont les tâches de jugement : décider quel candidat rappeler, arbitrer entre deux priorités, choisir le ton d’une réponse difficile. Elles peuvent être préparées la nuit, elles ne se tranchent pas la nuit, et la différence entre les deux verbes est toute la gouvernance de ce sujet.

Ce que nous avons décidé, et le cas que nous n’avons pas résolu

Chez nous, une routine est un objet que quelqu’un possède, pas une configuration. Elle porte le nom de la personne qui l’a créée, elle s’exécute avec ses droits, elle apparaît sur son écran, et elle peut être suspendue par un administrateur pour toute l’entreprise d’un seul geste. Ce qu’elle produit arrive dans une conversation, pas dans un journal que personne n’ouvre.

La règle qui tranche le reste est celle que nous appliquons partout : la validation suit l’action et jamais l’agent. Une routine qui prépare un message le prépare et s’arrête là, parce qu’un envoi déclenché par une horloge reste un envoi vers l’extérieur, qu’une personne libère. Programmer une tâche ne crée aucune autorisation nouvelle, et c’est la seule formulation qui résiste à la pression du confort, parce que la tentation d’ajouter « et envoie-le directement » se présente à peu près chaque semaine.

Le cas que nous n’avons pas résolu proprement est celui du départ. Rattacher la routine à son créateur signifie qu’elle tombe quand il part, et ce comportement est bon pour la sécurité et mauvais pour l’exploitation : une relance hebdomadaire utile à toute une équipe s’arrête parce que la personne qui l’avait écrite a changé d’entreprise. Nous avons choisi qu’elle tombe, en sachant que cela produirait de l’agacement, parce que l’autre option consiste à faire tourner des droits qui n’appartiennent plus à personne. Un transfert explicite à un autre propriétaire reste la bonne solution, et c’est un geste humain plutôt qu’un mécanisme.

Que revoir, et à quelle fréquence ?

Une heure par trimestre suffit, à condition de regarder les bonnes colonnes.

Pour chaque routine : qui la possède, avec quels droits elle s’exécute, à quelle date un humain a lu son résultat pour la dernière fois, et ce qu’elle a produit depuis. La colonne qui parle le plus est la troisième. Une routine dont personne n’a lu la sortie depuis six mois n’est pas une routine qui fonctionne discrètement, c’est un accès actif dont plus personne ne connaît la raison, et elle se retire plutôt qu’elle ne se corrige.

Cette revue ne remplace pas la question qui la précède, et qui décide de tout le reste : quels contrôles s’appliquent à quelle action, puisque lire, rédiger, écrire en interne et écrire vers l’extérieur n’appellent pas les mêmes garde-fous, et qu’une politique unique appliquée à tous les agents échoue par les deux bouts.

Questions fréquentes

Une tâche programmée peut-elle envoyer un message sans validation ?

Non, et la programmation n’y change rien. La règle suit l’action et non l’agent : un envoi vers l’extérieur reste un envoi vers l’extérieur, qu’il soit demandé dans une conversation ou déclenché par une horloge. Ce qu’une exécution nocturne peut faire seule, c’est préparer et proposer.

Avec quels droits une exécution programmée s’exécute-t-elle ?

Avec ceux de la personne qui l’a mise en place, ce qui est le seul rattachement honnête puisqu’il n’y a pas de demandeur au moment de l’exécution. La conséquence assumée est qu’elle s’arrête quand cette personne quitte l’entreprise, plutôt que de continuer avec des droits qui n’appartiennent plus à personne.

Que se passe-t-il si une exécution programmée échoue la nuit ?

Rien de visible, et c’est le problème. Il faut donc que l’absence de résultat soit elle-même un événement : une exécution qui n’a rien trouvé doit le dire, sinon elle est indiscernable d’une exécution qui n’a pas eu lieu, et l’écart se découvre plusieurs semaines plus tard.

Combien de tâches programmées une entreprise peut-elle raisonnablement tenir ?

Autant qu’elle en revoit. Le bon indicateur n’est pas le nombre mais la date de la dernière relecture : une routine qu’aucun humain n’a rouverte depuis six mois est un accès actif dont plus personne ne connaît la raison, et elle se retire plutôt qu’elle ne se corrige.

Sources

  1. Datadog, State of AI Engineering 2026datadoghq.com
  2. Security Arsenal, Orphaned AI Agents: Detecting and Remediating Shadow AI Access Riskssecurityarsenal.com
  3. Raconteur, Autonomous AI agents 2026 : the new rules for business governanceraconteur.net

À lire ensuite

On vous paie pour travailler moins.Récupérez vos 100 € maintenant.

Rejoignez la waitlist.

Laissez votre adresse mail, nous vous prévenons dès que Balt pourra rejoindre votre équipe.

Déjà 247 ESN sur la waitlist