Il y a des noms qui circulent dans les couloirs d’atelier sans que personne ne sache vraiment d’où ils viennent. Christian HOHMANN fait partie de ceux-là. Quand je débarque chez un sous-traitant mécanique de 50 personnes pour cadrer un projet de GPAO, il n’est pas rare que le responsable méthodes me tende un ouvrage corné publié chez Eyrolles, ou m’avoue avoir regardé trois vidéos de sa chaîne la veille pour comprendre ce qu’était un goulot. Cet univers s’est construit sur un parcours simple à résumer : une vingtaine d’années de terrain industriel, dont des passages chez Alcatel puis Yamaha, un poste de manager de production, ensuite plus de vingt ans de conseil en performance opérationnelle avant de s’installer en indépendant. Le résultat, c’est un corpus qui va du SMED à la Théorie des Contraintes, du management visuel à la transformation numérique. Et parmi les notions qu’il s’attache à clarifier depuis des années, une revient avec insistance dans les projets Industrie 4.0 : le fameux « use case ». Tout le monde l’emploie, peu de gens savent le rédiger. C’est précisément là que sa pédagogie devient utile à un dirigeant de PME qui doit arbitrer un budget de 60 000 euros sur un capteur ou un MES.
Christian HOHMANN : le parcours qui donne du poids à ses œuvres
Ce qui m’a frappé en lisant ses publications, c’est l’absence de posture. On sent l’homme qui a piloté une ligne, subi un retard de livraison de trois semaines et négocié avec un chef d’équipe qui refusait de changer d’outil. Son passage dans l’industrie électronique et le deux-roues précède le conseil, jamais l’inverse.
Cette chronologie explique la nature de ses œuvres : des ouvrages d’ingénierie industrielle centrés sur la productivité, avec une réserve assumée envers le productivisme. La question qu’il pose en filigrane dans ses livres est celle que j’entends chaque semaine : comment gagner 15 % de capacité sans faire courir les gens plus vite ?
Sa production s’est ensuite déployée sur plusieurs supports, chacun avec son registre. Voici comment je m’y repère quand je cherche une référence précise :
- Les ouvrages chez Eyrolles et en format numérique : la partie structurée, adaptée à une lecture de fond sur le Lean, la TPM, le SMED ou la qualité.
- Le site personnel : des réflexions plus libres, y compris sur des sujets périphériques comme la critique, le rapport au temps ou sa relocalisation géographique.
- Le Blog de la Nouvelle Industrie : les thématiques émergentes, transformation digitale, usine du futur, avenir manufacturier européen.
- La chaîne vidéo : la vulgarisation, en français et en anglais, du management à la gestion de projet.
Cette dispersion apparente est en réalité une cohérence : un même sujet abordé selon quatre niveaux de profondeur, du concept académique à la mise en pratique dans un atelier de douze machines.
Une expression volontairement accessible, loin du jargon de cabinet
Son talent particulier tient à cette capacité à parler aux deux mondes. J’ai vu des consultants perdre une salle en quinze minutes avec un diagramme de Gantt en anglais. Lui construit ses explications sur des situations reconnaissables : un en-cours qui gonfle, un opérateur qui attend une pièce, un indicateur qui ne mesure rien d’utile.
Cette expression directe est un choix méthodologique, pas un effet de style. Dans un projet de digitalisation, le vocabulaire décide de l’adhésion. Si le régleur ne comprend pas ce qu’on lui demande, il ne dira rien en réunion et n’utilisera pas l’outil trois mois plus tard.
Le « use case » : la notion clé de son approche Industrie 4.0
Entrons dans le vif. En transformation numérique, le terme « use case » revient en boucle dans les comptes rendus. Traduit littéralement, c’est un cas d’usage : la description d’une situation concrète dans laquelle un système, un produit ou un service trouve son emploi et résout un problème identifié.
L’origine de la notion remonte à la fin des années 1980, dans le développement logiciel. Les concepteurs cherchaient une méthode pour capter les exigences réelles des utilisateurs avant d’écrire une seule ligne de code. Le format a ensuite migré vers l’industrie, le marketing et la conception de services.
Un cas d’usage bien construit décrit les interactions entre des acteurs et un système, les fonctionnalités déclenchées et la finalité visée. Il s’écrit sous forme narrative ou schématique, dans un langage plus proche de l’utilisateur que de l’ingénieur. J’ai détaillé cette mécanique dans une analyse consacrée aux cas d’usage en projet industriel, parce que la confusion avec le cahier des charges coûte cher.
L’anatomie d’un cas d’usage exploitable
Prenons un exemple réel dans sa structure, transposé chez un client fictif que j’appellerai Serrière Mécanique : 55 salariés, tournage-fraisage de précision, deux équipes, un projet de suivi de production à 45 000 euros. Voici comment nous avons formalisé un cas d’usage sur une seule page.
| Rubrique | Contenu chez Serrière Mécanique |
|---|---|
| Acteur principal | Le régleur de nuit sur le centre d’usinage 4 axes |
| Déclencheur | Fin de série, changement de référence à 2 h du matin |
| Scénario nominal | Il scanne l’OF, l’écran affiche la gamme et les outils, il valide le lancement |
| Variante | Outil manquant : le système alerte le magasin avant la prise de poste |
| Résultat attendu | Temps de changement passé de 52 à 30 minutes |
| Indicateur | Gain de 90 minutes par nuit, soit environ 340 heures machine par an |
Ce niveau de détail change tout dans une négociation avec un éditeur. Quand vous arrivez avec huit fiches de ce type, la démonstration commerciale s’organise autour de vos réalités, pas autour du module que le vendeur doit écouler ce trimestre.
L’art de faire émerger le besoin réel
La difficulté n’est pas la mise en forme, c’est la collecte. Demander à un opérateur « de quoi avez-vous besoin ? » produit rarement autre chose qu’un silence gêné ou une demande de nouvelle machine. La création d’un bon cas d’usage passe par l’observation directe, chronomètre en main, pendant deux ou trois postes complets.
C’est là que réside l’art du praticien : distinguer le symptôme de la cause. Un chef d’atelier me réclamait un écran tactile sur chaque poste ; après observation, le vrai irritant était l’absence de mise à jour des plans, réglée pour 1 200 euros de réorganisation documentaire.
Du cas d’usage au design du système : ce que j’en retiens sur le terrain
Une fois les cas d’usage écrits, ils deviennent la matière première du design de la solution. Chaque fonctionnalité doit pouvoir se rattacher à une situation décrite. Sans cette discipline, on achète un progiciel dont 40 % des modules ne seront jamais paramétrés, chiffre que je constate régulièrement dans les PME de 30 à 100 salariés.
Cette rigueur alimente aussi la culture interne. Faire rédiger les cas d’usage par les équipes elles-mêmes transforme un projet informatique subi en projet d’atelier assumé. Le taux d’utilisation réel après six mois n’a rien à voir : de l’ordre de 80 % contre parfois 30 % quand la spécification est descendue du siège.
Reste la question de l’inspiration. Où va-t-on chercher les idées d’usage quand on n’a jamais vu autre chose que son propre atelier ? Les publications de ce consultant remplissent exactement cette fonction de fenêtre : voir comment un problème comparable a été traité ailleurs, dans un autre secteur, avec d’autres moyens. J’ai réuni quelques repères complémentaires dans ce billet sur la formalisation des besoins avant l’achat d’un logiciel, à lire avant toute signature de devis.
Un usage raisonné, à contre-courant de la course aux outils
Le point commun entre son travail et ce que je défends chez mes clients tient en une phrase : la technologie n’est jamais le point de départ. En 2026, avec la maturité des capteurs à moins de 200 euros et des plateformes accessibles en abonnement mensuel, la tentation d’équiper d’abord et de réfléchir ensuite n’a jamais été aussi forte.
Or un atelier sur-instrumenté sans cas d’usage produit des tableaux de bord que personne ne consulte. Deux journées de travail collectif à formaliser dix situations concrètes valent mieux que six mois de déploiement à l’aveugle. C’est peu coûteux, c’est fastidieux, et c’est ce qui distingue un projet qui tient de celui qu’on enterre discrètement au bout d’un an.
