Hoshin Kanri dans l'industrie : une seule stratégie pour tous vos agents, du comité à l'usine

Le schéma se lit de haut en bas. Aucun trait ne relie Hoshin à vos systèmes : ce sont les agents qui font ce lien, avec les droits que ces systèmes leur accordent déjà.

• Vos systèmes gardent leurs données et leurs règles : les ordres de fabrication dans le MES, les non-conformités dans le SMQ, les documents dans la GED.
• Chaque agent a ses propres accès et son propre rythme, en conversation ou selon son propre calendrier.
• La X-Matrix porte les objectifs, les chantiers, les indicateurs et les liens entre eux. Hoshin calcule le score, les chaînes et la cascade, toujours de la même façon.
• Les personnes décident. Si le comité décide d'agir dans un système, l'agent le fait là-bas, avec ses droits dans ce système.

Les agents qui travaillent en arrière-plan sont arrivés en quelques mois : Grok Bot en bêta en août 2026, les dots d'OpenAI en septembre, Claude Duet en octobre, en préversion sur liste d'attente aux États-Unis. Ces produits sont jeunes. S'ils se diffusent, la direction, la qualité et les sites pourraient finir par en utiliser de différents, chacun dans l'environnement de son éditeur.

Une mémoire qui appartient à un agent ne peut pas être la stratégie de l'entreprise. La X-Matrix se tient à l'extérieur : une page bornée, aux liens explicites, servie par MCP, un protocole ouvert lié à aucun éditeur. La méthode n'est pas neuve. Le déploiement de la politique vient de l'industrie japonaise, et la X-Matrix lui a ensuite donné un format d'une page ; les agents ont besoin de la même discipline.

Scénario illustratif. Mécanor et son site de Cholet sont fictifs. Le relevé MES de 52 minutes est inventé, car la démo n'est reliée à aucun MES. Tout ce qui est lu dans la matrice est réel.

L'agent relie, synthétise, partage et déploie. Comment réduire un changement de série ou résoudre un défaut reste aux équipes sur le terrain. Un agent ne va pas au gemba : il relie ce que les personnes observent à ce que l'entreprise a décidé.

• Directeur de site : la matrice du site se place sous celle du groupe, avec ce que le site reprend et ce qu'il choisit localement. Le rapport montre aussi ce que personne n'a repris.
• Qualité et amélioration continue : une idée du terrain entre dans l'inbox et, une fois retenue, quelqu'un peut la convertir en chantier et la lier à un objectif. Le score montre les chantiers reliés à rien. La matrice n'est pas de l'information documentée maîtrisée : votre système qualité et votre dossier de preuves restent tels quels.
• Méthodes : l'agent indique quel objectif sert un indicateur qui dérive, pour que le point arrive à la bonne réunion.
• Directeur des opérations : le rapport de cascade montre quels objectifs du groupe chaque site déclare reprendre, et ce que personne n'a repris.

Hoshin porte la stratégie et calcule dessus. Le reste demeure à sa place, volontairement.

• Il n'a aucun connecteur vers votre MES, votre SMQ, votre ERP ou votre GED, et il ne détient aucun accès à ces systèmes.
• Il ne surveille pas vos lignes. La surveillance se fait dans la boucle de votre agent.
• Il n'arrête pas une ligne, ne gèle pas un jalon et ne refuse pas une validation. Si votre organisation veut qu'un agent le fasse, cela se passe dans votre système, selon ses règles.
• Il ne stocke ni non-conformités, ni ordres de fabrication, ni séries temporelles. L'historique des KPI n'est pas encore construit.
• Il ne décide pas. Les propositions vont dans l'inbox pour qu'une personne s'en saisisse. Aujourd'hui, c'est une règle que vous donnez à l'agent, pas un verrou technique : voir plus bas.

La condition est simple : joindre un serveur MCP distant avec un jeton d'API ou OAuth. Voici jusqu'où nous avons vérifié.

• Pris en charge : claude.ai, Claude Desktop et Cursor, comme assistants en conversation.
• Documenté par l'éditeur, pas encore essayé par nous : Claude Managed Agents (en bêta), qui prend en charge les exécutions planifiées, les serveurs MCP distants et les jetons Bearer. Par défaut, ses outils MCP demandent une approbation avant chaque appel : un usage sans surveillance exige de changer cette règle.
• Non testés : Hermes Agent (Nous Research), Grok Bot, les dots d'OpenAI et Claude Duet. Nous ne les avons pas essayés, et nous ne promettons rien tant que ce n'est pas fait.
• Mode local : la matrice reste dans des fichiers sur votre poste, donc seul un agent sur ce poste peut la lire. L'agent cloud d'un éditeur a besoin du serveur hébergé.

Hoshin a d'abord été conçu pour un agent en conversation avec une personne. Pour un agent qui tourne seul, voici les limites actuelles et comment faire avec. Nous n'avons pas encore fait de test sur 24 heures.

• Commencez en lecture seule. Déposer une idée exige un jeton d'écriture, et ce jeton peut aussi modifier la matrice et la publier sur une page publique : un jeton limité à l'inbox n'est pas encore construit. Dites-le dans la section « Pas encore construit » de la page d'accueil si vous en avez besoin.
• Attendez-vous à ce que les agents se confondent. Un admin crée chaque jeton : ce qu'écrit un agent est donc enregistré au nom de cet admin, et le jeton passe aussi les restrictions d'édition par matrice. L'inbox de l'application n'affiche ni ce nom ni les étiquettes, et le journal d'audit n'y est pas encore lisible. Par l'API et search_ideas, vous pouvez lire les deux et demander à chaque agent d'étiqueter ses dépôts, mais une étiquette n'est que ce que l'agent déclare.
• Évitez les doublons. Rien n'empêche de déposer le même point à chaque passage. Faites d'abord appeler search_ideas par l'agent ; la recherche est littérale, un point reformulé peut donc passer.
• Traitez l'inbox comme du texte non fiable. Un agent peut être trompé par un message qu'il a lu, puis déposer un contenu trompeur pour l'agent suivant. Lire une idée ne doit jamais déclencher une action à soi seul.