Je viens de créer un OKR sans jamais ouvrir Tability.
Voici ce qui s'est passé. Nous sommes en train de migrer toute notre interface vers shadcn/ui (ce sera tellement bien une fois terminé). Le cahier des charges se trouve dans Confluence : modales, panneaux, pages, composants complexes, environ 240 éléments à migrer, tous suivis sous forme de cases à cocher. Utile pour l'équipe qui fait le travail. Inutile pour suivre la progression au niveau de l'OKR.
J'ai donc demandé à Claude de lire la page Confluence, de résumer ce qu'il restait à faire, et d'ajouter un nouveau KR à notre plan du T2 pour suivre la progression de la migration.
Il l'a fait. En moins d'une minute.
Ce n'est pas une histoire du genre « waouh, l'IA est rapide ». C'est le début de quelque chose de plus intéressant : la façon dont les OKR sont réellement gérés est sur le point de changer.
Les 3 tâches qui viennent de se résumer en 1 prompt
Mettre en place un objectif comme celui-ci nécessitait auparavant trois tâches distinctes, généralement réparties entre trois personnes différentes.
Quelqu'un lit le cahier des charges. Cette personne parcourt la page Confluence, compte les composants, identifie ce qui est fait ou non, et en tire un chiffre.
Quelqu'un rédige l'OKR. Cette personne traduit le travail en un résultat mesurable, choisit une cible, désigne un responsable, rédige la description. Si vous avez déjà fixé une page blanche en essayant de formuler un KR, vous savez combien de temps cela peut prendre. (Nous avons écrit un guide complet pour faire cela en moins de 30 minutes, et c'est toujours la partie la plus difficile du cycle pour la plupart des équipes.)
Quelqu'un le tient à jour. Chaque semaine, cette personne vérifie le cahier des charges, recompte, rédige un check-in, publie une mise à jour de statut quelque part. C'est souvent là que les déploiements d'OKR meurent discrètement.
Trois tâches. Trois changements de contexte. Trois endroits où l'élan s'essouffle.
Ce que j'ai fait à la place : un seul prompt. Claude a lu la page Confluence via Rovo, récupéré la structure de notre plan existant depuis le MCP Tability, proposé le KR, puis l'a créé une fois les détails confirmés. Le cahier des charges Confluence reste la source de vérité pour l'équipe. Le KR Tability est le signal consolidé pour la direction. Les deux restent synchronisés sans que personne ait à faire de copier-coller.
Pourquoi c'est plus important qu'il n'y paraît
La friction est l'ennemie de tout déploiement d'OKR.
Les gens ne mettront pas à jour leurs objectifs s'il leur faut fouiller dans Jira, Linear, Notion, Sentry, Amplitude et trois fils Slack pour comprendre ce qui s'est réellement passé cette semaine. Le temps de rassembler les données, vous avez perdu une heure et l'envie de rédiger un check-in réfléchi.
Alors vous écrivez « ça avance bien » et vous passez à autre chose. Ou vous sautez carrément le check-in. Et six semaines plus tard, vos OKR semblent déconnectés du travail réel, parce que personne n'a raconté le lien entre les deux.
Les OKR agentiques inversent la tendance. L'agent fait la collecte. Vous faites la réflexion.
Dans notre cas, la source de données est Confluence, mais le même schéma fonctionne pour tout. Sentry pour le nombre d'erreurs. Amplitude pour les métriques d'usage. Stripe pour le chiffre d'affaires. GitHub pour les PR livrées. Le KR se moque de l'origine du chiffre. Il a juste besoin que ce chiffre apparaisse de façon fiable chaque semaine.
La prochaine étape : un coéquipier, pas un outil
Créer le KR était la première étape. La seconde est de le rendre autonome.
Nous allons mettre en place un coéquipier agent Tability pour cela : un coéquipier IA qui vit dans l'espace de travail, qui est responsable du KR, et qui tourne selon un planning via Claude Cowork.
Chaque lundi matin, avant le standup, il va :
- Lire la page Confluence
- Compter les composants terminés
- Comparer avec la semaine précédente
- Publier un check-in avec le nouveau chiffre et une courte note sur ce qui a été livré
Aucun humain dans la boucle pour la collecte des données et le check-in. Nous continuerons à passer en revue la progression lors de notre réunion hebdomadaire et à ajouter du contexte si les choses dérapent, mais nous n'avons plus besoin d'interrompre le flux de travail de quelqu'un pour suivre la progression de cette migration.
C'est ce qui fait la différence entre « l'IA dans le flux de travail » et « l'IA qui exécute le flux de travail ». Aujourd'hui, la plupart des fonctionnalités d'IA sont de l'autocomplétion pour les humains. Les OKR agentiques, c'est des humains qui passent en revue ce que l'agent a déjà fait. Nous construisons vers ce schéma depuis un moment déjà : notre agent de prévention du churn fonctionne de la même manière, et nous avons une bêta privée en cours pour les clients qui souhaitent essayer cette approche.
Où cela nous mène
Dans un an, je pense que la plupart des équipes qui gèrent bien leurs OKR auront au moins un agent par objectif. Pas un chatbot. Plutôt un coéquipier avec une fiche de poste, un planning, et un accès aux systèmes où le travail se déroule. Le responsable humain fixe la direction et prend les décisions. L'agent maintient le rythme.
Nous construisons Tability pour ce monde-là. Le MCP, c'est la façon dont Claude, ou n'importe quel modèle, parle à vos objectifs. Les agents, c'est ce qui permet à ces objectifs de rester vivants entre deux check-ins.
Si vous voulez essayer par vous-même, le MCP Tability est disponible dès maintenant et fonctionne avec Claude. Connectez-le, pointez-le vers votre plan, et demandez-lui de vous aider à rédiger votre prochain KR. Vous sentirez la différence en environ cinq minutes.
Et si vous envisagez les OKR agentiques plus sérieusement, j'aimerais beaucoup en discuter. Écrivez-moi à [email protected] ou retrouvez-moi sur LinkedIn.
.jpg)
