Préparer une revue stratégique en 30 minutes au lieu d’un après-midi
Presque rien du temps passé à préparer une revue stratégique n’est passé sur la stratégie. Tout part en collecte : relancer huit porteurs pour un statut, ouvrir Linear pour vérifier si le projet a réellement avancé, retaper des chiffres dans un support, et découvrir une heure avant la réunion que deux chantiers n’ont pas de porteur et qu’un indicateur n’a pas bougé depuis mars.
Ce travail est mécanique, et c’est précisément ce qu’un agent ayant accès à la fois à votre stratégie et à vos outils d’exécution sait faire sans supervision. L’enjeu n’est pas de récupérer l’après-midi — c’est que lorsque la collecte devient gratuite, la revue peut se tenir tous les mois au lieu de tous les trimestres, et la réunion commence au désaccord au lieu de commencer par le tour de table des statuts.
Ce qui mange réellement l’après-midi
Quatre choses, d’après notre expérience et les récits des équipes que nous avons observées : savoir ce qui a bougé depuis la dernière revue ; réconcilier ce que les gens disent avec ce que montre l’outil d’exécution ; repérer les problèmes de structure (un chantier relié à aucun objectif, un objectif sans mesure) ; et écrire un ordre du jour qui place en tête les deux décisions qui comptent au lieu de dérouler chaque ligne dans l’ordre.
Rien de tout cela ne demande un jugement sur la stratégie. Tout cela demande un accès simultané à plusieurs systèmes — ce qu’un agent possède et qu’un support de présentation n’a pas.
La boucle, concrètement
hoshin.app la livre sous forme de prompt guidé nommé `weekly_sync`, pour que le protocole ne soit pas à réinventer ni à réexpliquer chaque fois. Il encode la séquence et, surtout, la règle de routage.
L’agent lit les chantiers du quadrant Sud de la X-Matrix. Chacun peut porter un `external_ref` — l’URL du projet Linear, de l’epic Jira ou du jalon GitHub qui l’implémente. L’agent suit cette référence à travers le serveur MCP de l’outil d’exécution, lit l’avancement réel, et le réécrit avec `update_element_status`. Puis il recalcule le score de complétude et rédige l’ordre du jour à partir de ce que le score signale, plutôt qu’à partir de l’ordre des lignes.
La règle de routage compte plus qu’il n’y paraît : la stratégie et les revues appartiennent à la mémoire stratégique, les tâches et les tickets appartiennent à l’outil d’exécution. Personne ne devrait maintenir une copie du sprint dans un outil de stratégie. Le `external_ref` est la jointure, et c’est la seule duplication que nous autorisons.
- Lire les chantiers et leurs références externes.
- Tirer l’avancement réel de Linear, Jira ou GitHub via leur propre serveur MCP.
- Réécrire statuts et valeurs d’indicateurs avec `update_element_status`.
- Recalculer le score de complétude et le laisser nommer les trous de structure.
- Rédiger un ordre du jour trié par ce qui a dérivé, pas par l’ordre de la matrice.
Les trois questions auxquelles une revue doit répondre
Qu’est-ce qui dérive, pourquoi, et quelle décision prendre maintenant. Une revue qui répond à ces trois questions a mérité son heure ; une revue qui égrène douze statuts, non.
Le score de complétude est ce qui rend la première question répondable sans opinion. Il rapporte la couverture, la densité des corrélations, les éléments orphelins, les chaînes complètes de la vision jusqu’à un indicateur, et l’équilibre entre indicateurs avancés et de résultat — et il nomme les éléments fautifs. Un chantier relié à rien. Une vision qui n’atteint aucune mesure. Un objectif suivi uniquement par des indicateurs de résultat, ce qui signifie que vous l’apprendrez trop tard par construction.
La deuxième question — pourquoi — est celle où les humains sont irremplaçables, et où la réunion doit passer son temps. Le rôle de l’outil est de vous y amener dès la troisième minute.
Pour un consultant qui suit plusieurs clients
La valeur se multiplie par le nombre de stratégies que vous entretenez. Une équipe de direction a une revue à préparer ; un consultant en stratégie en a huit ou douze, chacune avec son outillage, sa cadence et son niveau d’hygiène.
Deux choses comptent à cette échelle. D’abord, la préparation doit être reproductible sans vous : un prompt que votre agent exécute sur la matrice de n’importe quel client, pas un rituel personnel. Ensuite, le matériel client doit pouvoir rester dans votre environnement — c’est la raison d’être du mode local souverain, un répertoire de données par mission, sans compte et sans réseau.
Questions fréquentes
Faut-il connecter hoshin.app à Jira ou Linear ?
Aucune intégration à construire de notre côté. Votre agent parle déjà à votre outil d’exécution via le serveur MCP de cet outil ; nous stockons seulement le `external_ref` qui pointe vers le bon projet. C’est volontaire — une intégration que nous maintiendrions casserait, et elle nous pousserait à dupliquer votre backlog.
Et si nos chantiers ne sont dans aucun outil ?
La boucle est plus courte mais reste utile : l’agent met à jour statuts et valeurs d’indicateurs d’après ce que vous lui dites dans la conversation, recalcule le score et rédige l’ordre du jour. Le `external_ref` rend la collecte automatique ; ce n’est pas un prérequis.
L’agent peut-il écrire, ou faut-il mettre la matrice à jour à la main ?
Il écrit. `update_element_status` déplace statuts, avancement et notes, et depuis juillet 2026 `create_matrix`, `upsert_element` et `set_correlation` lui permettent de construire et restructurer la matrice elle-même — y compris transformer un document de stratégie en matrice scorée en une conversation.
Trente minutes, c’est une promesse. D’où vient-elle ?
De la nature du travail plutôt que d’un benchmark que nous pourrions vous fournir : la collecte est la part qui prend des heures et c’est la part que l’agent fait. Il reste à lire un diagnostic et à décider de quoi débattre. Si votre matrice n’a jamais été entretenue, la première passe sera plus longue — elle fera remonter tout d’un coup.