Le Workforce Engineering a toujours existé. On ne l'avait juste jamais nommé.
Sur cette page
Toute discipline commence pareil. Les gens font le travail pendant des années avant que quelqu’un pense à le définir. Le génie logiciel existait avant le terme. Le DevOps était une pratique avant d’être une catégorie. Le FinOps, c’était un tableur et une prière, jusqu’à ce que quelqu’un décide que la gestion des coûts du cloud méritait un nom et une conférence.
Le Workforce Engineering, c’est pareil. Tous les dirigeants qui ont un jour essayé de savoir si leur équipe était bien déployée, si les bonnes personnes travaillaient sur les bonnes choses au bon coût, ont fait du Workforce Engineering. Ils ne l’appelaient juste pas comme ça. Ils parlaient de planification trimestrielle, de revue des effectifs, ou du tableur qu’ils refaisaient tous les trois mois en le détestant à chaque fois.
J’en fais depuis la majeure partie de ma carrière. Je suppose que toi aussi.
Ce qui se passait vraiment
Repense à toutes les discussions sur les ressources que tu as eues. Quelqu’un demande : ce projet a-t-il les bons effectifs ? Cette équipe nous apporte-t-elle de la valeur ? Si on déplaçait deux personnes de l’équipe A vers l’équipe B, qu’est-ce qui changerait ? Tu déplaces deux ingénieurs seniors vers la nouvelle initiative d’IA, mais comme tu ne voyais pas les dépendances en aval, la sortie de ton produit principal glisse d’un mois. Tout le monde a vu le mouvement. Personne n’a vu la conséquence avant qu’elle tombe.
Ce ne sont pas des questions de RH. Ce sont des questions de systèmes. Tu essaies de modéliser un système (entrées, sorties, contraintes, arbitrages) et de prendre des décisions qui optimisent les résultats. Que les entrées soient des personnes plutôt que des serveurs ne change pas la nature du travail.
Pourtant, on ne l’a jamais traité comme une discipline d’ingénierie. On l’a traité comme une intuition habillée d’un tableur. Tu prends les effectifs, tu les multiplies par des grilles de salaires, tu divises par le nombre de projets actifs, et tu obtiens un chiffre qui semble à peu près juste jusqu’à ce que quelqu’un parte ou qu’une nouvelle priorité tombe du conseil d’administration.
Le problème a toujours été la mesure. Tu ne peux pas piloter ce que tu ne peux pas instrumenter. Et dans la plupart des organisations, les équipes sont restées presque entièrement non instrumentées. Tu sais ce que tu paies. Tu as une vague idée de ce sur quoi les gens travaillent. Le lien entre les deux, quel effort a été déployé sur quels résultats et à quel coût, est resté une boîte noire.
C’est ce vide que comble le Workforce Engineering.
La définition
Le Workforce Engineering est la discipline qui consiste à concevoir, mesurer et optimiser délibérément la façon dont une organisation déploie sa main-d’œuvre pour produire des résultats.
Il traite les équipes comme un système. Comme tout système, on peut l’instrumenter, le modéliser, le prévoir et l’améliorer. Le but n’est pas la visibilité pour la visibilité. C’est de pouvoir prendre de meilleures décisions, plus vite, avec moins de devinettes. Et pour être clair : il ne s’agit pas de presser les gens davantage. Il s’agit de les protéger de l’agitation, de l’épuisement et des priorités mal alignées, en s’assurant que le système autour d’eux est équilibré.
Il repose sur six pratiques :
Mesurer. Instrumenter correctement les équipes. Qui travaille sur quoi, à quel coût, pour quels résultats ? C’est la fondation. Sans elle, tout le reste n’est qu’estimation.
Attribuer. Relier l’effort aux résultats au niveau du projet. Pas « on a dépensé 400 k£ sur cette équipe le trimestre dernier », mais « ces 400 k£ se répartissent sur ces cinq projets, avec cette production et ce facteur de levier de l’IA ».
Optimiser. Décider activement à partir des données. Réaffecter la capacité là où on en a besoin. Couper les dépenses qui ne rapportent rien. Repérer où l’IA accélère vraiment la livraison et où elle brûle du budget sans rien changer.
Prévoir. Se projeter avec confiance. Modéliser l’effet des embauches, des changements d’équipe et des investissements en IA avant de les faire, au lieu d’expliquer les conséquences après coup.
Améliorer. Le traiter comme une discipline itérative, pas comme un événement trimestriel. Le plan que tu construis en janvier est faux en février. Un système vivant qui reflète la réalité vaut mieux qu’un plan parfait qui périme.
Récupérer. Un bon Workforce Engineering se rembourse tout seul. Quand tu vois clairement ce que font tes équipes et où l’effort atterrit, tu débloques une valeur financière qui était toujours là mais invisible : crédit d’impôt recherche, classification en CapEx, suppression des outils en double. La plupart des organisations laissent beaucoup d’argent sur la table, non par négligence, mais parce qu’elles n’ont jamais eu la visibilité pour le réclamer.
Pourquoi maintenant
Le Workforce Engineering a toujours existé dans les faits. Mais là, il devient urgent. L’IA a fait tomber l’idée que gérer une équipe, c’est un problème d’effectifs. Une équipe de quatorze personnes qui détenait autrefois un pan de produit peut aujourd’hui avoir la production effective de vingt, ou de huit, selon la façon dont elle utilise les outils d’IA. L’unité de base de la planification, le poste, ne te dit plus ce que tu obtiens.
Le rôle de l’ingénieur est passé de contributeur individuel à chef d’orchestre d’agents d’IA, mais nos modèles d’organisation les traitent encore comme des effectifs ordinaires. Pendant ce temps, les dépenses d’IA des entreprises croissent plus vite que prévu et atterrissent dans le budget sans responsable clair. On prévoit une hausse de 36 % par an des dépenses d’IA en entreprise. La plus grande part va dans les outils, les assistants, les API de LLM et l’infrastructure d’agents, dans toutes les fonctions, et la plupart des directions financières n’ont aucune idée de ce que ça produit. Ça se situe quelque part entre un abonnement logiciel et un coût d’infrastructure, classé de façon incohérente, revu une fois par trimestre au mieux.
Les CTO et les directeurs financiers à qui on parle ne posent pas de questions abstraites sur la stratégie d’IA. Ils demandent : qu’est-ce qu’on obtient vraiment pour ça ? Notre investissement en IA accélère-t-il la livraison ou ajoute-t-il seulement du coût ? Si on doublait le budget, qu’est-ce qui changerait ? Ils n’ont pas de réponses, parce que les outils pour y répondre n’existaient pas jusqu’à maintenant.
C’est un moment charnière. Les entreprises qui construisent dès maintenant l’infrastructure pour mesurer et gérer l’IA comme une forme de main-d’œuvre auront un avantage structurel sur celles qui s’en occuperont dans deux ans, une fois les dépenses montées en charge et le gaspillage accumulé. On parle à des organisations qui dépensent des centaines de milliers par an en outils d’IA sans aucun moyen de les relier à un projet ou à un résultat. Ce n’est pas un petit problème. C’est une crise de gouvernance au ralenti.
Les anciens indicateurs (effectifs, taux d’utilisation, production par tête) étaient déjà insuffisants. Ils sont maintenant carrément trompeurs. Il te faut un autre système.
Pourquoi on l’a nommé
Quand Oliver et moi construisions Flowstate, on revenait toujours à la même tension. Le produit avait une valeur claire : relier les données d’effort humain aux résultats des projets, intégrer les dépenses d’IA, permettre de vraies décisions sur les équipes. Mais la catégorie pour le décrire n’existait pas.
Workforce Management, c’est le mauvais cadre. Ça, c’est la planification, le temps de présence, les travailleurs postés. C’est Workday, ADP et des outils conçus pour un monde où l’unité de travail est une personne qui pointe.
FinOps, c’est le mauvais cadre. Ça, ce sont les coûts du cloud. Une catégorie vraiment utile, mais pour un autre problème.
Engineering Management, c’est le mauvais cadre. Trop opérationnel, trop centré sur les responsables d’ingénierie, il ne capte pas la dimension financière.
Aucun ne décrit ce qu’on fait vraiment : traiter les équipes, humaines et IA, comme un système à concevoir.
Alors on l’a nommé. Workforce Engineering. Pas parce qu’on a inventé la pratique (comme je l’ai dit au début, des gens la font depuis des années), mais parce que nommer compte. Les noms créent des catégories, et les catégories créent des marchés.
On définit celle-ci délibérément, parce qu’on pense que les entreprises qui adoptent le Workforce Engineering comme pratique, et pas seulement en achetant un outil, prendront de bien meilleures décisions sur la façon de déployer leur ressource la plus chère et la plus précieuse.
À quoi ressemble la réussite
Tu fais du bon Workforce Engineering quand :
- Tu peux répondre à « est-ce qu’on gagne en efficacité ? » avec des données plutôt qu’une impression
- Chaque livre sterling de travail, humain ou IA, est rattachée à un projet et à un résultat
- Les décisions d’effectifs se prennent avec la même rigueur que les décisions d’investissement
- Tu peux prévoir le coût de livraison avant qu’un projet démarre, au lieu d’expliquer les dépassements après sa fin
- Les décisions de réaffectation se prennent à l’avance plutôt que lors du post-mortem
- La direction fait assez confiance au plan pour avancer plus vite au lieu de réclamer un autre cycle de revue
- Tu arrêtes de perdre de bonnes personnes à cause d’une mauvaise affectation, parce que tu vois le problème avant qu’elles aillent passer des entretiens ailleurs
La plupart des organisations en sont très loin. Mais celles qui y sont arrivées n’y sont pas arrivées en achetant un outil ou en adoptant un framework. Elles y sont arrivées parce que quelqu’un a décidé de traiter le problème sérieusement, de le nommer, de l’instrumenter et d’itérer dessus comme sur n’importe quel autre défi d’ingénierie.
Voilà tout ce qu’est le Workforce Engineering. Un nom pour la discipline que tu pratiques probablement déjà sans en avoir.
Je suis cofondateur et CTO de Flowstate, la plateforme de Workforce Engineering pour les organisations modernes. On aide les entreprises à relier l’effort humain et les dépenses d’IA aux résultats des projets, pour qu’elles prennent de meilleures décisions sur la façon de déployer leurs équipes.