Kognetra

Le projet a commencé à l’atelier, pas dans un outil de design. Suivre le travail réel d’une équipe de maintenance a fait remonter partout le même motif : quand une machine s’arrête, le dépannage le plus rapide n’est dans aucun système, il est dans la tête du technicien chevronné qui se trouve être de garde. Les procédures dorment dans des PDF éparpillés, les dépannages ne s’écrivent jamais, et la vraie mémoire de l’usine part à la retraite une personne à la fois.

Le deuxième constat a fixé la barre de l’interface. Un technicien devant une machine à l’arrêt a quelques minutes, les mains grasses et, dans la moitié de l’usine, pas de signal. Ce que je construirais serait jugé à cet instant : si la réponse est plus longue à trouver que le vétéran à interroger, le système perd et la vieille habitude survit.

La plateforme est cadrée en quatre espaces sous une seule ossature, groupés comme une équipe de maintenance pense : Connaissances pour les procédures, les articles et la recherche ; Maintenance pour les équipements, les interventions et les retours d’expérience ; Communauté pour le fil, les espaces et la reconnaissance ; Administration pour les comptes et la qualité. Le tableau de bord s’adapte à qui regarde, un administrateur, un expert ou un technicien d’atelier.

La recherche est délibérément placée au-dessus de la navigation. Une palette de commandes globale couvre toute la base depuis n’importe où, parce qu’un technicien sous pression ne parcourra pas un arbre de menus : il tape « roulement grippé » et la procédure, l’incident passé et l’article reviennent dans une seule liste, en quelques millisecondes, en ligne ou hors ligne.

Les références évidentes existaient toutes, et toutes échouaient au test de l’atelier. J’ai fait passer le scénario de la machine à l’arrêt par trois formes : un wiki comme les intranets que les usines ignorent déjà, un module d’enregistrements comme les écrans de GMAO que les techniciens évitent déjà, et un compagnon de terrain bâti autour de la question plutôt que de l’archive, la recherche d’abord.

Le wiki organise le savoir pour ceux qui le classent, pas pour ceux qui en ont besoin ; cinq clics de profondeur, c’est cinq de trop quand une ligne est à l’arrêt. Le module d’enregistrements traite le savoir en lignes : exactes, complètes et jamais lues. Le compagnon de terrain inverse les deux : un seul champ de recherche, des réponses classées pour la machine en face, et la navigation reléguée en chemin secondaire.

Le cœur maintenance est spécifique au métier, pas un wiki générique. Les procédures portent leurs étapes de consignation (LOTO) au grand jour, là où un technicien pressé ne peut pas les manquer ; un registre d’équipements ancre chaque savoir à un actif réel ; et les retours d’expérience capturent les pannes avec des méthodes structurées, cinq pourquoi et Ishikawa, pour qu’un incident devienne un savoir réutilisable plutôt qu’un texte libre.

La chaîne du REX est l’endroit où concevoir le processus comptait plus que l’écran. Une panne ne devient un savoir que si elle est capturée à chaud, analysée avec une méthode et classée contre la machine ; le rapport guide le technicien exactement à travers cela, et le résultat est retrouvé par la personne suivante, à l’équipe suivante.

Le problème le plus dur de tout système de connaissances n’est pas la lecture, c’est l’écriture. La couche vivante existe pour le résoudre : un espace d’articles éditorial qui rend les dépannages durement acquis dignes d’être publiés, un fil communautaire, des espaces et une boîte à idées qui animent la base, et une gamification légère, points, badges et palmarès, qui rend la contribution visible.

La reconnaissance est conçue comme le moteur, avec le contrôle qualité autour : la modération et une console d’administration maintiennent le niveau, pour que le palmarès récompense l’écriture utile plutôt que le volume. Et tout le produit est conçu en clair et en sombre depuis un même système de tokens, pour que le bureau de l’usine comme la salle de contrôle tamisée se sentent chez eux.

Kognetra a été livré comme un concept de qualité production, conçu et développé de bout en bout, du front au back, quatorze modules en clair et en sombre. Travailler seul du design au code a gardé la boucle honnête : chaque structure que je dessinais, je devais ensuite la construire et chercher dedans, ce qui a tué plusieurs taxonomies élégantes en quelques jours.

La leçon que je garde porte sur l’endroit où les produits de connaissances échouent. Ils n’échouent pas à la base de données ; ils échouent au moment d’écrire et au moment du besoin. Concevoir pour ces deux moments, la reconnaissance d’un côté, une machine à l’arrêt de l’autre, est ce qui porte tout le système.