Débat sur la paie en double

Sur tout projet SI, la phase de recette revêt une importance considérable.

Sur un projet paie en particulier, on s’interroge parfois sur la manière de sécuriser le projet : quelle approche retenir en matière de test pour assurer un démarrage optimal ?

Deux experts apportent des éléments de réponse. Julien nous explique en quoi le recours à la paie en double peut sécuriser un projet, tandis que Stéphanie met en garde contre ces tests trop consommateurs de ressources et générateurs de retard.

 

Julien, Manager SIRH et Pilotage de projet

« D’un point de vue qualitatif, je défends le recours à la paie en double.

Les enjeux d’une phase de test (ou de recette) sont multiples :

  • Enjeu contractuel, lié à la signature du PV de recette qui déclenche, en général, une tranche de paiement de l’intégrateur
  • Enjeu métier, puisque la mise en production doit garantir le maintien en condition opérationnelle
  • Enjeu financier, car les coûts de correction en phase de Production sont nettement plus élevés qu’en phase de recette
  • Enjeu humain, puisque cette phase permet en général de faire monter en compétences les acteurs clés de la future solution

Aussi, il est nécessaire de mettre cette étape parfaitement sous contrôle, par une préparation méthodique et une définition en amont de l’ensemble des cas de tests à vérifier. Mais ces tests ne visent qu’à contrôler les cas les plus probables : on ne peut pas tout tester, les combinaisons sont trop nombreuses. Dès lors, où placer son exigence en matière de conformité des résultats ? Ces tests sont ils suffisants ?

C’est pourquoi, sur des sujets aussi sensibles pour l’entreprise que la paie du personnel, on muscle parfois les contrôles. En adjoignant à la phase de recette proprement dite, une phase de paie en double, qui permet de faire tourner la paie d’un même mois avec les même éléments de paie sur les 2 systèmes (actuel et cible), on sécurise au maximum son démarrage.

Cela représente un investissement, certes, mais présente 3 avantages majeurs :

  • On sécurise le passage en production, puisque pour réaliser la paie, on réalise l’ensemble des étapes préalables (reprises de données, mise en place d’interfaces, outil de contrôle,…)
  • On met sous contraintes de volume le système, et on contrôle ainsi ses temps de réponse
  • On rassure les DRH, en identifiant et en expliquant les écarts constatés, gage d’un climat social préservé »

 

Stéphanie, Manager SIRH et Paie

« Même si la phase de conception reste pour moi la pierre angulaire de tout projet d’implémentation de SI, il est indéniable que la recette est la phase la plus critique de ce type de projet.

En effet, elle concrétise tous les travaux menés au cours des phases précédentes et permet de mesurer l’écart entre l’attendu par l’utilisateur et le réalisé par l’intégrateur, écart qui devra bien sûr être comblé complètement ou du moins en grande partie pour le démarrage.   

Dans ce contexte, je rejoins bien évidemment Julien sur l’importance de l’exhaustivité et de la qualité de la recette. En revanche je suis plus sceptique sur le fait que la paie en double, telle qu’elle est souvent mise en œuvre chez les clients, réponde de manière appropriée à cet objectif.

Ceci pour 3 raisons principales :

  • La préparation de la paie en double sur la totalité de la population et la justification des écarts entre paie du système source et paie du système cible sont très chronophages et consommatrices de ressources
  • La majorité des anomalies de paie détectées en paie en double auraient dû l’être avec des tests fonctionnels plus poussés. En outre, beaucoup d’anomalies détectées dans cette phase proviennent finalement d’anomalies de reprise de données et non d’anomalies de paie !
  • Enfin les écarts entre les deux paies, même s’ils sont justifiés, ont tendance à inquiéter les décideurs qui hésitent à donner leur validation pour le démarrage et demandent souvent la réalisation d’une autre paie en double, allongeant ainsi la phase de recette sans réel gain de qualité  

 Alors « oui » à la paie en double (qui reste quand même un outil intéressant et complémentaire des tests fonctionnels), mais en appliquant les bonnes pratiques en termes de gestion de projet :

  • Limiter le périmètre de la population concernée à un échantillon représentatif qui couvrirait  tous les cas généraux et spécifiques
  • Limiter le nombre de paies en double (2 run de paie est un maximum)
  • Bien distinguer la phase de recette de la reprise de données et la phase de paie en double
  • Poser comme pré requis à la paie en double, la validation de la recette de la reprise de données et la validation des tests fonctionnels »

3 thoughts on “Débat sur la paie en double

  1. La paie en double est beaucoup moins chronophage que la recette sur scénario de tests si et seulement si elle est associé à des outils :
    – d’alimentation des données de paie (fichiers de reprise)
    – de contrôle des résultats de paie (contrôle du nombre de payés, contrôle des bruts des nets etc)

    Attention de plus au calendrier : la paie en double pour un démarrage en janvier sera programmé sur le dernier trimestre (charges en plus de bilans) + la fatigue du projet

  2. En ce qui concerne le calendrier, on peut se poser la question : démarrage en janvier ou en cours d’année ?

    On part souvent sur janvier à cause des reprises de cumuls et compteurs, mais effectivement, il faut se poser la question par rapport à l’équipe projet :
    – quand se fait la recette => pendant les vacances
    – quand se fait le démarrage => en janvier, en pleine édition des bilans et déclarations…

    D’autant qu’anticiper un démarrage en cours d’année, permet de gérer plus facilement un décalage car alors, on ne remet pas en cause toute la stratégie de bascule

  3. Je rejoins les remarques précédentes concernant les aspects fastidieux et long de la procédure de paie en double et de la nécéssité de disposer d¹outils adaptés. Des outils maison existent, quelques éditeurs disposent de solutions spécifiques à leur logiciel mais les fonctionnalités sont souvent réduites. On m’a parlé d¹un outils utilisable quel que soit l¹éditeur du logiciel de paie. Il s¹agit d¹un comparateur de données de paie nommé hubox http://www.hubox.net
    L¹outils fonctionne à partir des données de paye des deux systèmes source et target et permet de visualiser les écarts facilement et rapidement.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Back to top