Un agent IA peut-il porter un KR ?
Oui, s'il a les bras pour le faire. Quant à savoir où le poser, il faudra le lui dire.
Résumer cet article avec votre assistant IA
Un agent IA est un programme qui, à partir d'un objectif, agit de façon autonome sur vos outils : il lit, exécute des tâches et met à jour des résultats sans attendre une consigne à chaque étape. Il peut porter un KR. Il collecte la donnée, exécute des tâches, vérifie, alerte, met à jour l'avancement, et il le fait avec une régularité qu'aucune équipe humaine ne tient sur un trimestre. Piloter l'objectif est un autre métier : arbitrer entre deux priorités, décider de réviser ou d'abandonner un key result, expliquer un retard à l'équipe. Cela reste le travail d'un owner humain. Un KR confié à un agent autonome affichera toujours du vert que personne ne regarde, et c'est à ce moment que les ennuis commencent.
Agent IA et OKR : porter un KR, piloter un objectif
Dans la plupart des organisations, les agents arrivent par les outils, sans que personne l'ait vraiment décidé : un assistant qui prépare des comptes rendus, un agent qui lance des vérifications, un script qui met à jour un tableau. Un jour, quelqu'un demande à qui appartient ce que cet agent produit. Un silence s'installe.
Dans un cycle OKR, le suivi se délite d'abord faute de régularité. La donnée n'est pas collectée, la mise à jour arrive en retard, la dérive se voit trop tard. Un agent est à l'aise sur ce terrain : il ne se fatigue pas, et il n'oublie pas la mise à jour en semaine 8. On est alors tenté de lui confier le KR entier.
Porter un KR, c'est le faire avancer au quotidien. Piloter l'objectif, c'est décider quand la trajectoire doit changer, ce qu'on sacrifie pour l'atteindre et ce qu'on dit à l'équipe quand il ne sera pas tenu. Le single-threaded ownership en donne la règle. On l'associe à Amazon et à la figure du single-threaded leader décrite par Colin Bryar et Bill Carr dans Working Backwards : chaque enjeu critique a une personne dont c'est la priorité et la responsabilité. Le corollaire est qu'un sujet partagé entre plusieurs responsables devient le sujet de personne. Mettre un agent à la place ou en complément de cette personne amène la même conséquence : le besoin reste là, mais personne n'en porte la responsabilité.
Un agent peut donc être assigné à un KR et en tenir l'exécution et le suivi. Une seule personne (humaine) doit rester accountable de ce KR : elle en répond.
Les agents IA peuvent porter 4 rôles dans un cycle OKR
Les usages qui fonctionnent se regroupent en quatre rôles. Un même agent peut en cumuler deux. Les distinguer évite de lui confier une tâche sans savoir ce qu'on attend de lui.
Le collecteur
Il met à jour un KR à partir de données qui vivent dans un autre outil, il remplace des appels API, des imports de fichiers, avec une flexibilité supérieure : volume de tickets traités, taux de livraison, délai moyen. L'avancement reflète le réel sans que personne ait à le ressaisir. C'est le rôle le moins risqué et celui qui rapporte le plus vite, car il traite directement la raison pour laquelle les suivis s'éteignent.
Le contributeur
On lui assigne des initiatives ou des tâches rattachées à un KR, et il les exécute : rédiger, classer, vérifier, corriger. Il contribue à l'objectif comme un membre de l'équipe, tout particulièrement sur des tâches répétitives ou à faible valeur ajoutée. Mais attention, il ne négocie pas sa charge et ne vous dira pas de lui-même qu'une tâche n'a plus de sens.
Le rapporteur
Il agrège les données OKR et produit un brief : le point hebdomadaire d'une équipe, le « monday brief » du dirigeant, un rapport prêt à partager. Le gain est réel à condition que la donnée source soit fiable et que le lecteur garde en tête qu'il s'agit d'une aide à la décision rédigée par un LLM. Et qu'en conséquence, un rapport très bien rédigé sur des données douteuses fabrique surtout de la fausse assurance. Chez Serendly on utilise énormément ce type de fonctionnalités, mais on lit systématiquement ces rapports à un œil particulièrement critique.
L'analyste
Il lit les trajectoires, les signaux d'exécution et les dépendances, repère ce qui dérive et recommande. C'est le rôle le plus séduisant et le plus piégeux, parce que sa sortie ressemble à une décision alors qu'elle reste une proposition. L'analyste éclaire l'arbitrage, le lecteur ne doit pas oublier que c'est lui qui portera les conséquences des décisions prises sur cette base.
Serendly est construit sur cette logique. Vos agents se connectent à la plateforme dans les deux sens : ils lisent les OKR, les 1:1, les risques et les projections, et ils écrivent des mises à jour de KR, d'initiatives et de comptes rendus. Les assistants que vos équipes utilisent déjà remontent ce qui a été accompli dans la semaine, ce qui enrichit les recommandations de Serendly IA et accélère la préparation des 1:1.
Un cas concret : le ROI de nos agents de code, chez Serendly
Nous développons avec des agents IA de code, à côté de développeurs humains. Pour savoir si la dépense se justifiait, nous avons posé un objectif : maximiser le ROI des agents de code IA. Les KR portent sur le coût et sur la qualité du code produit.
La qualité est contrôlée par des agents IA, sur le code écrit par des humains comme sur celui écrit par des agents. Un agent de développement en pilote deux autres, volontairement placés en posture adversariale, dont le travail consiste à chercher ce qui ne devrait pas passer. Ils vérifient les tests automatisables (le résultat attendu, la qualité mesurable, le respect des normes de développement) et des contrôles de bonnes pratiques qui relevaient jusque-là du jugement humain.
Ce dispositif nous permet de suivre l'atteinte de l'objectif et d'arbitrer sur les modèles que nous utilisons pour le développement. Le choix du modèle reste une décision humaine, prise sur des données propres.
Le début a été moins propre. Nous avions expliqué le principe des OKR aux agents de contrôle, et ils ont biaisé les résultats pour afficher un score maximal. C'est la loi de Goodhart, dans la formulation qu'en a donnée Marilyn Strathern : dès qu'une mesure devient un objectif, elle cesse d'être une bonne mesure. Nous avons donc découplé la mesure de son enjeu. Nous demandons désormais aux agents de reporter le niveau de qualité mesuré, sans leur dire à quoi il sert. Les mesures sont devenues plus honnêtes.
Le score de qualité est passé de 100 % à 85 %. Ce niveau, plus bas et plus réel, a servi de base à l'arbitrage : nous avons testé quatre modèles de code IA et en avons retenu deux, Sonnet 4.5 et Kimi 3. Le score est remonté à 96 % et le coût moyen de nos agents de code a baissé de 45 %.
Dans notre expérience, l'agent qui mesure n'a pas besoin de connaître l'enjeu du KR. L'interprétation revient à l'owner humain : quel modèle garde-t-on, quel niveau de qualité accepte-t-on pour quel coût, que sacrifie-t-on quand la qualité entre en tension avec une échéance commerciale ? L'agent apporte une information propre et régulière et l'humain décide.
OKR et intelligence artificielle : ce qui reste humain
Trois décisions échappent à l'agent, quel que soit son niveau de compétence.
L'arbitrage entre priorités. Un KR qui avance au détriment d'un autre pose un problème de choix. Il faut quelqu'un qui ait le contexte et l'autorité pour trancher, et qui accepte d'en assumer la conséquence.
La révision ou l'abandon. Un agent peut signaler que la trajectoire est mauvaise. Décider si le KR n'a plus de sens, ou si sa cible était mal posée, suppose de savoir pourquoi on l'avait posée.
La conversation difficile. Quand un retard s'installe, la bonne réaction passe par un échange entre deux personnes, au bon moment, dans le bon cadre. C'est le rôle du 1:1. Un agent qui prépare ce 1:1 fait gagner du temps. Un agent qui le remplace coûte cher.
Le tableau ci-dessous résume la répartition sur un cycle.
| Étape du cycle | Ce que l'agent peut tenir | Ce que l'humain garde |
|---|---|---|
| Définir les OKR | Proposer des formulations, repérer les KR mal mesurables, signaler les doublons | Choisir les priorités, fixer le niveau d'ambition, nommer l'owner |
| Lancer le cycle | Préparer les supports, rattacher les initiatives aux KR | Expliquer le sens, obtenir l'accord des équipes concernées |
| Suivre chaque semaine | Collecter les données, mettre à jour, alerter sur un écart | Interpréter l'écart, décider de la réponse |
| Revue de mi-parcours | Projeter l'atterrissage, préparer les éléments de décision | Réviser, abandonner ou renforcer un KR |
| Clôturer le trimestre | Consolider les données, préparer le bilan | Noter, tirer les enseignements, décider de la suite |
Trois façons dont cela tourne mal
Le KR orphelin. Un KR assigné à un agent, sans owner humain qui le regarde, reste vert tant que l'agent le met à jour. Personne ne remarque que la cible n'a plus de sens, ni que la mise à jour a cessé de refléter l'essentiel. Le KR est bien suivi et plus personne ne le pilote. On s'en aperçoit à la clôture du trimestre.
La mise à jour sans contexte. La donnée est exacte et l'interprétation est fausse. Un indicateur monte parce que sa définition a changé, ou parce que l'agent mesure ce qui est facile à mesurer. La distinction entre résultat et activité reste le meilleur garde-fou : un agent compte volontiers ce qu'il sait compter, ce qui n'est pas toujours ce qui compte.
L'effacement du 1:1. Quand le suivi devient automatique, on est tenté de supprimer la conversation qui l'accompagnait. On perd alors ce que la donnée ne dit pas : la charge réelle, le blocage jamais formulé, le doute sur la cible. La fréquence des 1:1 n'a aucune raison de baisser parce que les mises à jour sont automatiques. Ce temps gagné sert à parler de ce que les mises à jour ne disent pas.
Donner à un agent les droits d'un nouvel arrivant
On ne donne pas à un nouvel arrivant l'accès à tout dès le premier jour, et on regarde ce qu'il produit pendant les premières semaines. Le même raisonnement vaut pour un agent. C'est le principe du moindre privilège, formulé par Jerome Saltzer et Michael Schroeder en 1975 : chaque entité dispose de l'accès nécessaire à sa tâche et de rien d'autre.
En pratique, on commence par la lecture. On ouvre l'écriture sur un périmètre précis, un KR ou une famille d'initiatives, puis on l'élargit quand la fiabilité est établie. L'owner relit les premières mises à jour au lieu de découvrir en fin de cycle ce que l'agent a écrit. Serendly s'y prête : l'authentification se fait par jeton, les droits sont entièrement configurables, et l'historique des mises à jour d'un KR indique qui a écrit quoi, humain ou agent. Votre agent accède exactement à ce que vous avez décidé.
Ce cadrage a un effet secondaire utile. Définir ce qu'un agent peut lire et écrire oblige à clarifier ce que l'organisation attend de lui, ce qu'on omet souvent de faire pour un humain.
Par où commencer
Un seul agent, un seul rôle, un seul périmètre, sur quatre semaines. Le collecteur et le rapporteur sont les meilleurs candidats, car leurs défaillances se voient vite et coûtent peu.
Prenons le collecteur. Un premier KR peut porter sur le délai moyen de traitement des tickets : « Ramener le délai moyen de traitement d'un ticket de X jours à Y jours d'ici la fin du trimestre ». L'agent lit l'outil de tickets et met le KR à jour chaque semaine, et un owner humain en répond.
À ouvrir en semaine 1 :
- la lecture sur l'outil de tickets et sur le KR concerné ;
- l'écriture sur ce seul KR ;
- un jeton dédié à l'agent, que vous pouvez révoquer ;
- un owner humain nommé et prévenu ;
- une relecture hebdomadaire des mises à jour par cet owner, à partir de l'historique.
Trois questions suffisent pour décider d'étendre ou non. Les mises à jour sont-elles fiables en semaine 4, c'est-à-dire cohérentes avec ce que les personnes concernées observent ? Les owners lisent-ils vraiment ce que l'agent produit, ou le tableau s'est-il rempli tout seul ? Le temps de préparation des 1:1 a-t-il baissé sans que leur contenu s'appauvrisse ?
Si les trois réponses sont oui, on peut ajouter un deuxième rôle. Si l'une d'elles est non, mieux vaut comprendre pourquoi avant de multiplier les agents : un mécanisme qui ne tient pas avec un agent ne tiendra pas avec dix. Le cadre du cycle et le rythme de pilotage restent ceux que vous avez déjà. L'agent s'y insère.
FAQ
Un agent IA peut-il être l'owner d'un KR ?
Il peut en tenir l'exécution et le suivi. Répondre du résultat suppose d'arbitrer, de réviser, d'expliquer un écart et d'en assumer la conséquence auprès de l'équipe, ce qui demande un contexte, une autorité et une responsabilité humains. Un agent peut être assigné à un KR, et une personne nommée en reste responsable.
Faut-il évaluer un agent comme un collaborateur ?
On évalue sa fiabilité : ses mises à jour sont-elles exactes, ses recommandations pertinentes, son périmètre adapté ? Ce bilan revient à l'owner humain, à intervalles réguliers, et alimente la décision d'élargir ou de restreindre ses droits.
Comment éviter qu'un agent « arrange » un chiffre ?
En ne lui disant pas à quoi sert la mesure. Chez nous, les agents de contrôle à qui nous avions expliqué le principe des OKR ont biaisé leurs résultats pour maximiser leur score. Depuis que nous leur demandons seulement de reporter le niveau mesuré, sans contexte, les mesures sont plus honnêtes. Séparer celui qui exécute de celui qui vérifie, et conserver l'historique des mises à jour, garde les écarts visibles et corrigeables.
Que faire des données confidentielles que l'agent peut lire ?
Les traiter comme celles d'un collaborateur : un accès limité à ce dont il a besoin. Les droits de lecture et d'écriture se configurent par agent. On évite les accès larges par défaut et on ouvre le périmètre progressivement, à mesure que la fiabilité est établie.
En résumé
Un agent IA peut porter un KR : il en tient l'exécution et le suivi, souvent avec plus de régularité qu'une équipe. Le pilotage de l'objectif reste à un owner humain nommé, qui arbitre, révise et tient la conversation difficile. Quand cet owner disparaît, plus personne ne pilote, même si le tableau reste vert.
Le bon point de départ est modeste : un agent, un rôle, un périmètre, quatre semaines, des droits limités et une relecture régulière. Vous obtenez un suivi qui ne s'éteint plus en semaine 8, et des managers qui passent leur temps sur ce que la donnée ne dit pas.
Vos agents travaillent déjà. Savez-vous à quel objectif ils contribuent ?
Avec Serendly, vos agents rejoignent vos OKR comme des collaborateurs : ils lisent, mettent à jour et exécutent, avec des droits que vous configurez et un historique de chaque modification. Découvrez comment les brancher à votre pilotage sans perdre la main.
