La Méthode Ingénieur-Logicien

Je regarde les données, les processus, la technologie, l’organisation et les personnes qui devront réellement faire fonctionner l’ensemble. Avec le temps, j’ai commencé à appeler cette façon de travailler la Méthode Ingénieur-Logicien.

Ce n’est pas un produit et il n’y a rien de propriétaire là-dedans. Cela vient d’avoir fait le métier depuis trois positions différentes : construire des systèmes RH dans mes premières années, diriger un département RH qui dépendait de systèmes conçus par d’autres, et porter aujourd’hui la responsabilité commerciale et la delivery d’une activité de transformation.

Avant de proposer une solution, je cherche à comprendre où se situe réellement le problème. Il est rarement là où se trouve la plainte. Un souci de reporting se révèle souvent être une question de responsabilité sur la donnée. Ce qui ressemble à un rejet d’un nouvel outil est souvent un processus que personne n’a simplifié.

Je passe donc à chaque fois par les mêmes cinq domaines, en évitant de m’arrêter à la première explication convaincante.

Une fois le problème clair, je travaille la façon dont les processus, les systèmes, les données et les responsabilités doivent s’articuler. C’est la partie que l’on comprime quand un programme a pris du retard, et elle coûte cher à refaire.

Ce que je cherche, c’est une conception assez précise pour être chiffrée, discutée et refusée. « Une RH plus proche du business » est une intention. Un modèle de service, avec des responsabilités nommées et un modèle de données derrière, est quelque chose qu’un comité peut valider.

Une bonne conception ne suffit pas. Il faut encore que quelqu’un s’en serve, l’exploite et prenne des décisions avec. D’expérience, cette partie reçoit beaucoup moins d’attention que la course à la mise en production, et c’est pourtant là que les bénéfices se gagnent ou se perdent.

Concrètement, cela reste assez simple : une instance qui continue à décider après le départ de l’équipe projet, des responsabilités écrites avant d’être contestées, des compétences acquises avant d’en avoir besoin, et quelques indicateurs validés à l’avance, y compris ceux qui diraient que cela ne fonctionne pas.

Un ingénieur demande si le système tient. Un dirigeant RH demande si les équipes vont vivre avec. Celui qui porte le budget demande si les chiffres tiennent. J’ai occupé les trois sièges, et les programmes se compliquent quand une seule de ces questions est prise au sérieux.

Appliquée au talent, aux compétences et à l’IA, la même façon de travailler donne les frameworks et, à l’échelle d’un livre, La Mort des Skills.