Lorsqu’il était question, pour nous, de créer ce qui est probablement aujourd’hui l’un des SIRH les plus complets disponibles sur le marché, nous avions bien compris qu’il fallait se demander quels étaient les « pain points » des DRH et des HRBP… Nous en avions naturellement fait la liste. Ensuite, nous nous sommes adressés aux DRH (lambdas), à qui nous avons présenté l’outil.
Ensuite, nous leur avons posé la question de savoir ce qu’ils aimeraient avoir et qu’ils n’ont pas dans la plupart des SIRH… Ils nous ont fait la liste, en disant : « Si vous pouvez le faire, vous allez vraiment nous soulager. » Nous nous sommes mis au travail et nous avons optimisé les fonctionnalités. Mais avant d’aller plus loin, je me suis imposé quelques règles pour chaque fonctionnalité :
1-Cette fonctionnalité est-elle aboutie ?
Elle permet de déclencher un processus, mais arrive-t-on à des traitements et à des livrables que les DRH et les HRBP peinaient à délivrer ? L’une des choses que j’ai remarquées avec les développeurs, c’est qu’ils sont capables d’intégrer une fonctionnalité sans se demander à quels livrables elle doit aboutir…
Si nous décidons d’intégrer la 9-BOX, par exemple, savons-nous ce que nous allons faire de la classification des talents ? Comment passer, par exemple, de la détection des talents à l’élaboration d’un plan de carrière, de développement et de promotion, puis à la confirmation ? Si nous ne précisons pas cela, nous développons des capacités (fonctionnalités) qui, à la fin, ne seront pas abouties, faute d’interconnexion et d’interopérabilité.
2-Cette fonctionnalité est-elle « nice to have » ou est-elle vraiment pertinente ?
Une fonctionnalité d’un outil peut parfois être « magnifique à avoir » (nice-to-have), mais si elle ne répond pas à des usages manuels « pénibles, chronophages et coûteux », il y a de fortes chances qu’elle ne serve pas à grand-chose. Imaginons que nous décidions d’inclure, dans un SIRH, la mobilité inter-pays et que cela n’arrive qu’une ou deux fois dans l’année : développer une telle fonctionnalité serait top (et certainement coûteux), mais vaut-elle la peine ?
Nous avons, par exemple, pensé à inclure une fonctionnalité pour élaborer des job descriptions, sans nous rendre compte de ce que cela allait nécessiter : utiliser des assistants IA intégrés, qui vont consommer des « tokens », alors qu’une IA générative classique (ChatGPT ou Claude) en consommerait moins pour le même résultat. Ce serait cool de dire que notre IA permet de générer des job descriptions, mais cela repose sur des prompts, et on peut très bien le faire en dehors d’un SIRH.
a-Cette fonctionnalité est-elle structurelle et contextuelle ?
Ce qui arrive une seule fois (ou très rarement), en principe, ne nécessite pas de fonctionnalité dédiée (sauf dans le cas des plans de continuité d’activité). On peut effectivement créer une fonctionnalité pour traiter des situations RH sur lesquelles on serait appelé à travailler. Mais si ce n’est pas un véritable élément de processus RH, pourquoi l’intégrer ?
Lors d’une présentation, un DRH nous a demandé si l’outil permettait de suivre le dialogue social. Après avoir suivi son développement, je me demandais si des outils classiques de gestion de projet ne devraient pas traiter cela… Avant de me rendre compte qu’en réalité, il s’agissait d’un programme (donc d’un processus RH) et que notre SIRH Targetym AI ne pouvait pas ne pas l’intégrer. En poussant plus loin la réflexion, mon équipe et moi avons compris que, structurellement et contextuellement, nous devrions intégrer une fonctionnalité permettant de créer et de gérer des programmes RH de façon générale.
3-Cette fonctionnalité est-elle intégrable ?
L’autre question que nous nous sommes posée en développant Targetym AI SIRH, c’est de savoir si nous avions besoin d’intégrer tous les modules, ou si nous pouvions compter sur des outils standalone existants, que nous allions simplement connecter.
À cet effet, nous voulions, par exemple, intégrer un LMS, avant de comprendre que nous allions alourdir l’outil pour rien. Un SIRH devrait être interconnectable à plusieurs LMS, plutôt que d’en intégrer un. Pareil pour un ATS… ce serait bien à avoir, mais si l’on doit multiplier les sources, un ATS unique ne suffirait pas… Il en faut peut-être plusieurs.
La fonction « Paie » fait partie des fonctionnalités que nous avons beaucoup hésité à intégrer, mais que nous avons fini par proposer en add-on, certainement parce que nous nous sommes dit que la question n’était plus aussi préoccupante (plusieurs outils de gestion de la paie étant disponibles sur le marché).
Nous nous sommes posé plusieurs autres questions, pour finir par aboutir à un outil agile, en optimisation continue, et qui est probablement l’un des SIRH les plus cohérents et les plus complets disponibles sur le marché.
