Le choix d’un système d’information RH engage l’entreprise pour plusieurs années. Au-delà du prix des licences, il conditionne la production de la paie, la fiabilité des données sociales, les circuits de validation, l’expérience des collaborateurs et la capacité de la direction RH à produire des indicateurs utiles. Une erreur de sélection se corrige difficilement : les données doivent être reprises, les interfaces reconstruites et les utilisateurs de nouveau formés.
Les projets les plus fragiles présentent souvent le même défaut initial. L’entreprise choisit un éditeur avant d’avoir défini ce qu’elle souhaite réellement transformer. Elle reproduit alors dans le nouvel outil des procédures devenues inutiles, des validations trop nombreuses ou des fichiers parallèles. La technologie automatise l’existant sans régler ses incohérences.
Le cahier des charges ne doit donc pas être traité comme une formalité d’achat. Il constitue le document de référence du projet. Il relie la stratégie RH, les besoins des utilisateurs, les contraintes réglementaires, l’architecture technique et les engagements futurs du prestataire.
Le diagnostic des processus précède la consultation
La première phase consiste à décrire le fonctionnement réel de l’organisation. La procédure officielle ne suffit pas. Il faut observer les pratiques : qui saisit l’information, dans quel outil, à quel moment, avec quel contrôle et pour quel destinataire ? Un processus de congé apparemment simple peut mobiliser un portail RH, un échange de courriels, un fichier Excel tenu par le manager et une ressaisie dans la paie.
Cette analyse distingue la conception logique de la conception physique. La conception logique précise ce que le système devra accomplir : automatiser une règle, supprimer une double saisie, sécuriser une validation, conserver une preuve ou produire un indicateur. La conception physique répond ensuite à la question du moyen : solution SaaS ou installation interne, logiciel unique ou architecture modulaire, connecteur standard ou interface spécifique.
Commencer par la marque du logiciel inverse cet ordre. L’entreprise adapte alors son besoin au produit déjà présélectionné. Elle risque également de confondre une fonction visible pendant la démonstration avec une fonction réellement utilisable dans son contexte. Un écran de gestion des absences ne prouve ni la conformité des règles, ni l’intégration avec la paie, ni la qualité du circuit de validation.
L’audit doit couvrir les principaux processus RH, leurs volumes et leurs exceptions. Il doit aussi mesurer la situation de départ : délai de clôture de la paie, nombre de corrections, temps de traitement des demandes, volume de saisies manuelles, qualité des dossiers collaborateurs ou fréquence des écarts entre systèmes. Ces indicateurs serviront ensuite à évaluer le résultat du projet.
| Processus à auditer | Question de diagnostic | Indicateur de départ |
|---|---|---|
| Paie | Où apparaissent les corrections et les ressaisies ? | Délai de clôture et nombre de bulletins corrigés |
| Temps et absences | Combien d’étapes séparent la demande de sa validation ? | Délai moyen et demandes en attente |
| Recrutement | À quel moment l’information candidat est-elle ressaisie ? | Délai de recrutement et taux d’abandon |
| Dossier collaborateur | Quelle application détient la donnée de référence ? | Taux de dossiers complets et écarts entre bases |
| Reporting | Combien de manipulations précèdent la production d’un indicateur ? | Temps de production et nombre de fichiers sources |
Tableau 1 : Les premières mesures à collecter avant de formaliser le besoin SIRH.
Pour formaliser l’audit de votre propre système, une grille structurée documente les applications utilisées, la cartographie des dix processus RH principaux (dossier collaborateur, paie, temps, recrutement, onboarding, formation, performance, rémunération, reporting, départs) et l’analyse détaillée des processus prioritaires — avec pour chacun le déclencheur, les étapes, les règles, les données et les problèmes observés.
📎 Télécharger la Fiche outil — Audit de l’existant SIRH
Transformer les besoins en exigences testables
Un cahier des charges efficace n’est ni une liste de souhaits ni la copie du catalogue d’un éditeur. Chaque exigence doit décrire un besoin métier, une règle, un volume, un résultat attendu et une méthode de vérification. La formulation « le logiciel doit gérer les congés » reste trop générale. Elle ne précise ni les populations concernées, ni les règles d’acquisition, ni les niveaux de validation, ni l’incidence sur la paie.
Une exigence exploitable pourrait être formulée ainsi : « Un collaborateur affecté à l’établissement A doit pouvoir soumettre une demande depuis son téléphone. Le manager dispose de deux jours ouvrés pour répondre. Après validation, le solde est mis à jour et l’absence est transmise à la paie sans ressaisie. Le test est réalisé avec trois profils et deux calendriers de travail. » L’éditeur peut alors démontrer la couverture standard, identifier un paramétrage ou chiffrer un développement.
Les spécifications fonctionnelles décrivent les opérations attendues : paie, gestion administrative, recrutement, formation, performance, rémunération ou tableaux de bord. Les spécifications non fonctionnelles encadrent la qualité du service : disponibilité, temps de réponse, sécurité, authentification, traçabilité, accessibilité mobile, sauvegarde, continuité et réversibilité. Ces dernières sont souvent moins visibles pendant la vente, mais elles déterminent la fiabilité du système une fois déployé.
La hiérarchisation empêche également le projet de devenir une addition de demandes individuelles. Les exigences peuvent être classées en quatre catégories : indispensables au démarrage, importantes mais planifiables, utiles si le budget le permet et exclues du périmètre initial. Cette règle oblige le comité de projet à arbitrer avant la consultation.
Associer les parties prenantes sans diluer la responsabilité
La direction RH doit rester propriétaire du besoin, mais elle ne peut pas rédiger seule le cahier des charges. La DSI évalue l’architecture, les interfaces, la sécurité et l’exploitation. La direction financière précise les attentes relatives à la masse salariale, à la comptabilité et au contrôle budgétaire. Le juridique, la conformité et le responsable de la protection des données examinent les traitements, les contrats et les transferts éventuels. Les achats structurent la consultation et la négociation.
Les managers et les collaborateurs apportent une autre information : l’usage réel. Un workflow peut être juridiquement correct et techniquement fonctionnel tout en étant inutilisable sur le terrain. Des entretiens courts, des ateliers de parcours et l’observation de situations concrètes permettent d’identifier les contraintes mobiles, linguistiques, organisationnelles ou liées aux horaires.
Cette participation ne signifie pas que chaque demande doit être retenue. Un comité de décision doit arbitrer selon la stratégie, le risque, le coût et la fréquence d’utilisation. Le DRH garde la responsabilité du périmètre. Sans cette gouvernance, les demandes s’ajoutent après la signature et provoquent des développements supplémentaires, des reports et des désaccords sur les responsabilités.
Les critères éliminatoires dans le contexte marocain
La conformité de la paie constitue le premier filtre. Le prestataire doit prouver sa capacité à paramétrer les règles légales et conventionnelles applicables, à mettre à jour les taux, plafonds et barèmes, à tracer les modifications et à produire les fichiers nécessaires aux déclarations sociales et fiscales. Une mention commerciale telle que « paie Maroc » ne remplace pas une démonstration effectuée à partir de cas représentatifs de l’entreprise.
Le deuxième filtre concerne les données personnelles. La loi 09-08 encadre les traitements RH et la CNDP prévoit des formalités pour les traitements ainsi que pour les transferts de données à l’étranger. L’hébergement hors du Maroc n’est donc pas, à lui seul, un motif automatique d’exclusion. L’entreprise doit toutefois connaître les lieux de stockage et de sauvegarde, les sous-traitants, les pays concernés, les mécanismes de sécurité et les formalités requises. Certaines activités ou catégories de données peuvent imposer des exigences supplémentaires.
Exigence de conformité
Le cahier des charges doit obliger le prestataire à préciser la localisation de la production et des sauvegardes, les transferts éventuels hors du Maroc, la liste des sous-traitants, les mesures de chiffrement, les profils d’accès, la journalisation, la notification des incidents, les durées de conservation et la procédure de restitution puis de suppression des données.
L’intégration représente le troisième filtre. Le SIRH doit échanger avec la comptabilité, l’ERP, le pointage, les outils de recrutement, les annuaires et, selon le périmètre, les plateformes déclaratives. Il faut identifier pour chaque flux le système de référence, la fréquence, le format, le responsable et le traitement des erreurs. Une interface annoncée comme disponible doit être distinguée d’une interface déjà déployée et maintenue.
Le support local complète ces critères. La présence d’une équipe au Maroc ne suffit pas si aucune compétence fonctionnelle n’est mobilisable pendant les périodes critiques. Le cahier des charges doit demander l’organisation du support, les horaires, les niveaux de priorité, les délais de réponse et de résolution, le dispositif de remplacement des consultants et les modalités d’escalade.
Comparer le coût total et la capacité d’exécution
Le prix de l’abonnement ne permet pas de comparer les offres. Le coût total de possession doit réunir les licences, le cadrage, le paramétrage, la migration, les interfaces, les développements spécifiques, la formation, le support, les mises à jour, la charge interne et la sortie du contrat. Les hypothèses doivent être identiques pour tous les candidats : effectif, nombre d’entités, modules, environnements, volume de données et durée de comparaison.
Formule de référence : TCO sur trois ans = licences + implémentation + migration + interfaces + formation + support + évolutions + charge interne + réversibilité.
La notation doit ensuite croiser qualité et coût. Un prix inférieur ne compense pas un écart sur la paie, la sécurité ou la restitution des données. À l’inverse, une suite très complète peut être surdimensionnée si l’entreprise n’utilise qu’une faible partie de ses fonctions. Les pondérations doivent être arrêtées avant l’ouverture des offres afin d’éviter qu’elles soient modifiées pour favoriser un candidat.
| Famille de critères | Pondération indicative | Preuve attendue |
|---|---|---|
| Couverture fonctionnelle | 20 % | Démonstration sur les scénarios de l’entreprise |
| Paie et conformité marocaine | 20 % | Cas de paie, calendrier de mise à jour et références |
| Intégration et qualité des données | 15 % | Documentation des API et stratégie de migration |
| Sécurité et protection des données | 15 % | Architecture, habilitations, audits et continuité |
| Ergonomie et adoption | 10 % | Tests utilisateurs sur ordinateur et mobile |
| Déploiement et support | 10 % | Équipe nommée, planning et engagements de service |
| TCO, contrat et réversibilité | 10 % | Chiffrage sur trois ans et scénario de sortie |
Tableau 2 : Exemple de pondération à adapter aux priorités et aux risques de l’entreprise.
Faire démontrer, tester puis contractualiser
La présélection peut être réalisée sur dossier, mais la décision finale doit s’appuyer sur des scénarios imposés. Chaque candidat reçoit les mêmes données, les mêmes rôles utilisateurs et les mêmes résultats attendus. L’équipe projet note ce qui est couvert en standard, ce qui nécessite un paramétrage et ce qui dépend d’un développement.
Un environnement d’essai ou un pilote limité permet ensuite de vérifier les fonctions critiques : reprise de données, calcul de paie, workflow, export, droits d’accès et reporting. Les références clients doivent être comparables par taille, complexité et secteur. Il est également utile d’interroger les entreprises sur la période suivant la mise en production, lorsque les demandes de correction et les coûts d’évolution apparaissent.
Le contrat doit reprendre les engagements déterminants du cahier des charges. Il doit préciser le périmètre, les livrables, les critères de recette, les responsabilités, le calendrier, les niveaux de service, les conditions tarifaires, la propriété des développements et les modalités de réversibilité. Une promesse formulée pendant la démonstration mais absente du contrat ne protège pas l’entreprise.
Le temps consacré au cadrage n’allonge pas inutilement le projet. Il déplace les arbitrages vers la période où ils coûtent le moins cher. Le DRH peut alors choisir une solution proportionnée à ses besoins, expliquer la décision au CODIR et piloter le déploiement avec des critères de réussite définis avant la signature.
Pour traduire vos besoins en exigences comparables et outiller les démonstrations, une trame consolidée structure trois volets : le registre des exigences (20 lignes avec priorité I/P/O/H et couverture standard/configuration/développement), les huit scénarios de démonstration à imposer à tous les candidats et le procès-verbal de démonstration à contresigner.
📎 Télécharger la Fiche outil — Exigences testables et scénarios de démonstration SIRH
À retenir pour les DRH
- Auditer les processus et les données avant de consulter les éditeurs.
- Rédiger chaque exigence avec un résultat attendu et une méthode de test.
- Arrêter les priorités et les pondérations avant l’ouverture des offres.
- Faire démontrer les scénarios réels de l’entreprise.
- Intégrer au contrat la sécurité, le support, le coût total et la réversibilité.
