SIRH et DSI : pourquoi le projet commence ensemble ou échoue séparément

Dans la majorité des appels d'offres SIRH, la DSI arrive trop tard. On lui demande de valider un choix déjà fait, en quelques jours, après des mois d'évaluation fonctionnelle menée par la DRH seule. Ce schéma produit presque toujours le même résultat : des frictions entre directions, des délais, et des risques techniques découverts au mauvais moment. Voici pourquoi la gouvernance du projet SIRH commence avant le premier contact avec un éditeur.

1. Pourquoi la DSI ne peut pas arriver en fin de processus

Le scénario classique : la DRH identifie un besoin, lance un benchmark, assiste à des démonstrations, réduit la liste à deux ou trois solutions favorites, puis sollicite la DSI pour validation technique. Confortable pour tout le monde dans un premier temps, ce schéma produit presque systématiquement les mêmes problèmes.

La DSI, mise devant le fait accompli, découvre des incompatibilités avec l’architecture existante, des lacunes dans la documentation des API, des zones grises dans le contrat de traitement des données. Elle ne peut plus vraiment bloquer le choix sans créer une crise entre directions. Alors elle valide, en formulant des réserves que personne ne consignera vraiment. Les problèmes se matérialisent pendant le déploiement, quand il est trop tard pour changer de solution et trop tôt pour les résoudre sans délai ni surcoût. Ce mécanisme rejoint les causes d’échec documentées dans notre analyse des 70 % de projets SIRH qui dérapent.

2. Un SIRH n’est pas un outil RH isolé

C’est l’erreur conceptuelle à l’origine de la plupart des tensions entre DRH et DSI. Un SIRH moderne n’est pas une application autonome : c’est un nœud dans un écosystème technique. Il doit dialoguer avec la paie, l’annuaire d’entreprise (Active Directory, LDAP), la signature électronique, les plateformes de formation, parfois le CRM ou l’ERP.

Chaque connexion est un point d’attention. Chaque interface mal paramétrée est une source potentielle de dysfonctionnement : données non synchronisées, doublons dans les référentiels, failles de sécurité aux points de jonction. La DSI est la seule direction à posséder la cartographie complète de cet écosystème. Elle doit donc être impliquée dès le cadrage des besoins, non pour poser un veto, mais pour signaler les contraintes d’intégration avant que le choix soit fait.

Les éditeurs présentent souvent leurs connecteurs comme des points forts. La réalité est plus nuancée : certains sont natifs et robustes, d’autres sont des développements spécifiques facturés à l’unité, d’autres encore reposent sur des API peu documentées. Seule la DSI peut évaluer la différence, en s’appuyant sur des critères d’architecture ouverte et d’interopérabilité.

3. Les critères techniques qui manquent souvent dans les grilles

Critère technique	Ce qu’il faut vérifier	Signal d’alerte
Architecture et déploiement	SaaS, on-premise ou cloud privé ; compatibilité avec la politique sécurité et la souveraineté des données	Serveurs hors UE sans justification
API et intégrations	Documentation, stabilité, versioning, support des connecteurs	API propriétaires fermées ou non documentées
Sécurité des données	Chiffrement au repos et en transit, ISO 27001 / SOC 2, habilitations, traçabilité	Certifications absentes, DPA non fourni
Authentification	SSO, MFA, intégration Active Directory / LDAP	Pas de SSO natif, MFA optionnel
Maintenabilité	Fréquence des mises à jour, charge interne générée	Mises à jour manuelles côté client
Réversibilité des données	Formats d’export, délais, coûts, assistance à la migration	Conditions de sortie absentes : risque de vendor lock-in

4. Le modèle de collaboration DRH-DSI en 4 temps

Temps 1 : cadrage commun avant tout contact éditeur

Avant le moindre RFI ou benchmark, DRH et DSI co-construisent l’expression des besoins. La DRH apporte les processus à couvrir, les usages attendus, les populations concernées. La DSI apporte les contraintes d’intégration, les standards de sécurité, les exigences de souveraineté. Ce cadrage définit des critères d’éligibilité qui filtrent les éditeurs avant même les démonstrations, et évite de perdre des semaines sur des solutions incompatibles avec l’architecture existante.

Temps 2 : grille d’évaluation co-construite, avec une pondération réelle

La grille doit intégrer des critères fonctionnels (portés par la DRH) et techniques (portés par la DSI), avec une pondération négociée entre les deux directions. Le point clé : les critères techniques doivent peser réellement dans la décision. Un éditeur excellent sur le fonctionnel mais défaillant sur la sécurité ou l’intégration doit pouvoir être écarté. Cantonnés à une colonne accessoire, ils ne servent à rien.

Temps 3 : la DSI dans les démonstrations, pas après

Les démonstrations sont souvent réservées à la DRH, la DSI étant convoquée pour une session technique séparée une fois la shortlist arrêtée. Plus efficace : des sessions mixtes où les deux directions évaluent simultanément comment la solution répond à leurs exigences respectives. Cela évite les malentendus, accélère la convergence et réduit les allers-retours.

Temps 4 : contractualisation des engagements techniques

Le contrat ne se négocie pas uniquement sur le prix et les fonctionnalités. La DSI doit s’assurer que les engagements techniques sont formalisés noir sur blanc : niveaux de service (SLA), conditions de réversibilité des données, politique de mise à jour, DPA conforme au RGPD, procédures de gestion des incidents de sécurité. Ces éléments, souvent négligés quand l’enthousiasme du choix prédomine, sont décisifs en cas de problème.

5. Les signaux d’une DSI insuffisamment impliquée

Si plusieurs de ces points sont vrais, le projet démarre avec un risque élevé :

• La DSI n’a pas participé à la rédaction du cahier des charges.
• La grille d’évaluation ne contient pas de critères techniques pondérés.
• L’éditeur retenu n’a pas fourni de documentation sur ses API.
• Le DPA n’a pas été demandé, ou n’a pas été relu par la DSI avant signature.
• Les conditions de réversibilité des données ne figurent pas au contrat.
• La DSI a découvert des incompatibilités techniques après la décision finale.
• Le SSO et le MFA n’ont pas été discutés pendant l’évaluation.

Avant d’en conclure que l’outil actuel est le problème et de relancer un appel d’offres, il vaut d’ailleurs la peine de vérifier si les difficultés viennent de l’outil ou de l’usage : une gouvernance défaillante produit les mêmes symptômes qu’une solution inadaptée.

6. Ce que ça change concrètement quand ça marche

Les organisations qui réussissent leurs projets SIRH traitent le choix de la solution et la gouvernance du projet comme deux faces d’un même sujet, dès le premier jour. Concrètement : des projets mieux cadrés (moins de périmètre qui dérive), des déploiements plus courts (moins de problèmes techniques à résoudre en urgence) et des solutions mieux adoptées, car techniquement viables dans l’environnement réel des utilisateurs.

Conclusion : l’appel d’offres SIRH est un projet d’entreprise, pas un projet RH

Les fonctionnalités s’évaluent en quelques semaines ; les conséquences d’un mauvais choix technique se paient pendant des années. Un SIRH mal intégré, mal sécurisé ou non maintenable finit par freiner les ambitions RH qu’il était censé servir, et les collaborateurs en paient le prix : expériences dégradées, données peu fiables, processus figés.

Impliquer la DSI tôt n’est pas une contrainte procédurale, c’est la condition pour que la solution retenue soit réellement viable, sécurisée et pérenne. Et parce que l’appel d’offres SIRH est un projet d’entreprise, le sponsoring de la direction générale doit être assuré au plus haut niveau, du début à la fin : il impacte directement le retour sur investissement. Enfin, si votre entreprise est une ETI, gardez un cadrage à votre échelle : c’est tout l’objet d’un SIRH pensé pour les ETI.