Dans la majorité des appels d’offres SIRH, la DSI arrive tard. Elle est consultée pour valider le choix technique, parfois en quelques jours, après que la DRH a déjà évalué les solutions et préféré l’une d’entre elles. Ce schéma produit à peu près toujours le même résultat : une tension entre les deux directions, un délai supplémentaire, et parfois un projet qui démarre sur de mauvaises bases.
Pourtant, la question de savoir quel SIRH choisir ne peut pas être déconnectée de la question de savoir comment il va s’intégrer dans le système d’information existant, comment les données vont être sécurisées, et qui va maintenir la solution dans le temps. Ces questions appartiennent à la DSI. Et elles se posent dès le cadrage, pas après la signature.
Cet article détaille pourquoi la DSI doit être impliquée dès le début du processus de sélection, quels critères elle doit évaluer, et comment organiser la collaboration avec la DRH pour que l’appel d’offres aboutisse à un choix solide.
Pourquoi la DSI ne peut pas arriver en fin de processus
Un SIRH n’est pas un outil RH isolé
Un SIRH moderne s’intègre dans un écosystème technique existant : annuaire d’entreprise, logiciel de paie, outil de signature électronique, Active Directory, infrastructure cloud ou on-premise. Chaque connexion est un point d’attention pour la DSI. Chaque interface mal paramétrée est une source de dysfonctionnement potentiel.
Si la DSI n’a pas été consultée pendant l’évaluation des solutions, elle ne peut pas anticiper ces points de friction. Elle les découvre au moment de l’intégration, quand il est trop tard pour changer de solution et trop tôt pour les résoudre sans délai.
Les critères métier et les critères techniques sont indissociables
La DRH évalue les fonctionnalités, l’ergonomie, la couverture des processus RH. Ces critères sont légitimes et indispensables. Mais ils ne disent rien sur la manière dont la solution va s’intégrer dans le SI, sur les contraintes de sécurité qu’elle va imposer, sur la capacité de l’éditeur à maintenir ses engagements techniques dans le temps.
Un SIRH qui répond parfaitement aux besoins métier mais qui nécessite une architecture incompatible avec les standards de l’entreprise crée plus de problèmes qu’il n’en résout. La DSI est la seule à pouvoir évaluer ce risque.
Le coût de l’exclusion
Quand la DSI est exclue du processus de sélection, elle est quand même impliquée dans le déploiement. Mais en position réactive, pas pro-active. Elle gère les problèmes qu’elle n’a pas pu anticiper, avec des contraintes qu’elle n’a pas pu négocier. C’est une source de tension durable entre les deux directions, et un facteur de rallongement des projets.
C’est ce que nous détaillons dans notre article sur la collaboration DRH–DSI dans les projets SIRH : la gouvernance du projet commence avant le choix de la solution.
Les critères techniques que la DSI doit évaluer
L’architecture et le modèle de déploiement
SaaS, on-premise, cloud privé ou hybride : le modèle de déploiement a des implications directes sur la sécurité, la conformité et la maintenabilité. La DSI doit évaluer si le modèle proposé par l’éditeur est compatible avec la politique de sécurité de l’entreprise et ses contraintes réglementaires.
Pour le secteur public ou les entreprises soumises à des exigences de souveraineté des données, la localisation des serveurs et le statut du sous-traitant sont des critères non négociables.
Les capacités d’intégration
Un SIRH s’intègre rarement seul. Il doit dialoguer avec la paie, l’annuaire, les outils de formation, parfois le CRM ou l’ERP. La DSI doit évaluer la qualité des APIs proposées par l’éditeur, leur documentation, leur stabilité dans le temps, et la facilité avec laquelle elles permettent de connecter les systèmes existants.
Un éditeur qui ne propose pas d’APIs robustes ou qui facture les connecteurs à l’unité crée une dépendance technique et financière à long terme. C’est un risque que la DSI doit identifier pendant l’appel d’offres, pas après la signature.
La sécurité des données
La donnée RH est sensible. Elle est encadrée par le RGPD et exposée à des risques de fuite ou d’accès non autorisé. La DSI doit évaluer les mécanismes de sécurité proposés par l’éditeur : chiffrement des données au repos et en transit, gestion des habilitations, traçabilité des accès, certification de sécurité (ISO 27001, SOC 2).
Elle doit également vérifier les conditions contractuelles liées à la sous-traitance des données et la gestion des incidents de sécurité. Ces éléments sont documentés dans le DPA (Data Processing Agreement) que tout éditeur sérieux doit fournir. Voir notre article sur la sécurisation des données RH dans le SIRH pour les points de contrôle essentiels.
La maintenabilité et l’évolutivité
Un SIRH s’utilise sur plusieurs années. La DSI doit évaluer la capacité de l’éditeur à faire évoluer sa solution dans le temps, sa politique de gestion des versions, la fréquence des mises à jour et les modalités de migration. Elle doit également évaluer la charge de maintenance interne que la solution va générer pour ses équipes.
Un SIRH SaaS bien conçu doit libérer la DSI de la maintenance de l’infrastructure, pas lui en ajouter. C’est un critère qui se négocie en amont.
L’authentification et la gestion des accès
SSO (Single Sign-On), MFA (authentification multi-facteurs), intégration avec l’Active Directory ou l’annuaire LDAP existant : la DSI doit vérifier que la solution s’intègre dans les standards d’authentification de l’entreprise. Un SIRH qui impose un annuaire utilisateurs séparé crée une charge de gestion supplémentaire et multiplie les risques de sécurité.
Comment organiser la collaboration DRH–DSI dans l’appel d’offres
Définir les rôles avant de lancer le processus
Un appel d’offres SIRH bien organisé commence par une répartition claire des rôles entre DRH et DSI. La DRH pilote l’expression des besoins métier et l’évaluation fonctionnelle. La DSI pilote l’évaluation technique et la grille de critères IT. Les deux directions co-décident du choix final.
Cette répartition ne signifie pas que la DSI n’a pas son mot à dire sur les fonctionnalités, ni que la DRH ne peut pas évaluer l’ergonomie technique. Elle signifie que chaque direction est responsable de son périmètre et qu’aucune ne peut trancher seule.
Construire une grille d’évaluation commune
La grille d’évaluation est le document central de l’appel d’offres. Elle doit intégrer des critères métier (portés par la DRH) et des critères techniques (portés par la DSI), avec une pondération négociée entre les deux directions.
Les critères techniques doivent avoir un poids réel dans la décision finale — pas être une case à cocher après que le choix fonctionnel a déjà été fait. Un éditeur qui obtient une excellente note fonctionnelle mais qui échoue sur les critères techniques doit pouvoir être écarté. C’est la seule façon de garantir que le choix final est réellement équilibré.
Impliquer la DSI dans les démonstrations
Les phases de démonstration sont souvent réservées à la DRH et aux utilisateurs métier. La DSI n’est pas invitée, ou arrive pour une session technique séparée en fin de parcours.
Une approche plus efficace consiste à impliquer la DSI dans les démonstrations métier, et à organiser des sessions techniques conjointes où les deux directions évaluent simultanément comment la solution répond à leurs exigences respectives. Cela évite les malentendus et accélère la prise de décision.
Négocier les conditions techniques dans le contrat
Le contrat avec l’éditeur 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 : SLA (niveaux de service), conditions de réversibilité des données, politique de mise à jour, conditions du DPA, gestion des incidents et des failles de sécurité.
Ces éléments sont souvent négligeables en phase d’euphorie du choix, et décisifs en cas de problème. Les formaliser avant la signature est une condition de sérénité pour les années qui suivent.
Les signaux qui indiquent que la DSI a été insuffisamment impliquée
Certains signes doivent alerter pendant ou après un processus de sélection SIRH :
- 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 APIs
- Le DPA n’a pas été demandé ou n’a pas été relu par la DSI
- La DSI a découvert des incompatibilités techniques après la signature
- Les conditions de réversibilité des données ne sont pas définies dans le contrat
Si plusieurs de ces signaux sont présents, le projet SIRH démarre avec un risque élevé de tension entre DRH et DSI pendant le déploiement. Il est encore temps de corriger le tir avant que les problèmes techniques ne deviennent des problèmes organisationnels.
Conclusion
Choisir un SIRH est une décision stratégique qui engage l’entreprise sur plusieurs années. Elle ne peut pas reposer uniquement sur des critères fonctionnels, aussi pertinents soient-ils. L’architecture technique, la sécurité des données, les capacités d’intégration et la maintenabilité de la solution sont des facteurs tout aussi déterminants pour la réussite du projet.
La DSI n’est pas là pour ralentir le processus. Elle est là pour garantir que le choix final est techniquement viable, sécurisé et pérenne. Impliquée tôt et structurément, elle accélère la décision et réduit les risques du déploiement.
Les entreprises qui réussissent leurs projets SIRH sont celles qui ont compris que le choix de la solution et la gouvernance du projet sont deux faces d’un même sujet. Et que DRH et DSI doivent être assises à la même table dès le premier jour.
Vous préparez un appel d’offres SIRH ?
Notre guide « Aide au choix SIRH » détaille les critères à évaluer, les questions à poser aux éditeurs et la méthode pour construire une grille d’évaluation DRH–DSI.
