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 »