Migration des ressources : la planification de la capacité depuis Microsoft Project

Pour les PMO qui l'exploitent bien, la valeur de Project Server tient rarement aux plans de projet eux-mêmes. Elle tenait à la couche opérationnelle en dessous : un pool de ressources unique pour toute l'organisation dans lequel puisait chaque projet, des feuilles de temps valorisées qui alimentaient la facturation et la reconnaissance du chiffre d'affaires, des exceptions de calendrier qui se propageaient automatiquement et des vues multiprojets grâce auxquelles les gestionnaires de ressources décidaient chaque semaine des affectations sur des données réelles. C'est cette couche opérationnelle qui est en jeu. Les plans migrent. La couche opérationnelle, souvent non.

Trois modes de défaillance reviennent sans cesse quand les PMO sous-estiment ce point :

• Le piège « on ajoutera les ressources plus tard ». Une équipe migre proprement les plans de projet et prévoit d'ajouter le pool de ressources au sprint suivant. Le moment venu, les responsables de projet ont déjà créé des ressources en double dans leurs projets, et le gestionnaire de ressources a perdu la source unique de vérité qui faisait fonctionner les vues de capacité multiprojets.
• Le piège « les taux de coût ne sont pas critiques pour le démarrage ». Les taux standard sont reportés à un nettoyage en phase 2. Deux mois plus tard, la finance découvre que sa clôture mensuelle exige des données de feuilles de temps valorisées qui n'existent plus dans la nouvelle plateforme, parce que les taux n'étaient pas chargés au moment de la saisie. Les données ne peuvent pas être reconstruites après coup ; la reconnaissance du chiffre d'affaires est bloquée.
• Le piège « Planner Premium fera l'affaire ». Un PMO suppose que le produit cloud de Microsoft couvre les mêmes cas d'usage. Pour la modélisation des ressources, ce n'est pas le cas. Planner Premium n'offre ni pool de ressources à l'échelle de l'organisation, ni feuilles de temps valorisées, ni vue des ressources multiprojets. Le découvrir après la migration, c'est trop tard.

La raison structurelle des trois : le modèle de ressources est la partie de Project Server la moins visible dans une démonstration rapide et la moins couverte par les grilles de comparaison des éditeurs. Les plans de projet, les Gantt et les tableaux de bord se montrent bien. Les pools de ressources de l'organisation, mal. Les acheteurs sous-pondèrent donc la couverture du modèle de ressources dans le choix de la plateforme, puis découvrent le manque en production. Ce guide présente donc le modèle en premier, avant la tactique de migration, en partant du principe que la décision la plus importante est le choix de la plateforme cible.

Avant de décider quoi migrer, faites l'inventaire de ce que vous avez. Le modèle de ressources de Project Server compte six couches, et chacune migre différemment :

Tous les PMO n'utilisent pas toutes les couches. La bonne question d'inventaire est : « sur lesquelles notre équipe s'appuie-t-elle vraiment pour décider ? » Si vous n'utilisez pas de feuilles de temps valorisées, la couche des tables de taux est décorative ; vous pouvez la laisser de côté sans conséquence. Si vous n'utilisez pas les génériques pour modéliser la demande, vous pouvez les regrouper. Si vous les utilisez pour cela, cette capacité n'est pas négociable dans la plateforme cible.

Faites l'inventaire avant de comparer les plateformes. Son résultat est une liste des capacités indispensables de la plateforme cible, et cette liste façonne le reste de la migration. La section suivante suppose que vous l'avez en main.

Les comparaisons de plateformes se resserrent quand vous filtrez sur la couverture du modèle de ressources. Voici le tableau honnête, organisé selon les six couches ci-dessus. Oui, partiel ou non pour chacune :

Le produit cloud de Microsoft (Planner Premium / Project for the Web, le même produit sous des libellés de SKU différents) laisse de côté l'essentiel du modèle de ressources. C'est un choix de positionnement délibéré : c'est un outil de tâches d'équipe doté d'une couche projet, pas une plateforme de PMO. Les PMO qui utilisent sérieusement le modèle de ressources de Project Server ne peuvent pas le remplacer par Planner Premium sans perdre des capacités importantes.

Le module Resource Management de Smartsheet et Workfront conservent tous deux la notion de pool à l'échelle de l'organisation. Ils diffèrent dans le détail : Smartsheet RM est un SKU distinct et ajoute un coût par poste notable ; le pool de Workfront est solide, mais son prix par poste est le plus élevé des quatre. Onplana n'a pas de pool de ressources distinct : chaque personne est un membre de l'organisation, et son modèle de ressources est la capacité hebdomadaire de cette personne sur tous les projets (à partir de l'offre Professional), des taux sur trois niveaux (personne, rôle, valeur par défaut de l'organisation) et des calendriers de travail avec exceptions nommées, sans module payant. Il n'a ni ressources génériques, ni calendriers par personne, ni RBS formelle. Le prix commence à 12 dollars par poste et par mois (Professional). La comparaison honnête avec Planner Premium se trouve sur notre page de comparaison avec Planner.

Une autre dimension tient mal dans un tableau : la qualité de la vue de capacité multiprojets varie beaucoup d'une plateforme à l'autre, même quand la fonction de base existe. Certaines ne montrent que les affectations directes aux tâches ; d'autres incluent les cumuls des sous-projets ; d'autres encore l'affectation des espaces réservés génériques. Si votre gestionnaire de ressources décide chaque semaine des affectations à partir de cette vue, faites une comparaison côte à côte pendant l'évaluation avec les 25 ressources ayant le plus d'heures affectées.

Avant d'exporter quoi que ce soit, dressez un inventaire complet du modèle de ressources. C'est un inventaire différent de celui de la liste des projets : celui-là catalogue les projets ; celui-ci la couche de ressources en dessous. Le livrable est un rapport de préparation à la migration des ressources qui liste chaque élément de ressources, où il se trouve aujourd'hui, où il va et qui porte le déplacement.

1. Liste des ressources avec leurs attributs. Exportez le pool complet de ressources de l'organisation avec le nom, le type (nominative/générique/coût), l'e-mail (pour les nominatives), les unités maximales, le taux standard, le rôle ou titre et le chemin dans la RBS. Le point de terminaison OData /Resources est la source de référence ; la Reporting Database a davantage de champs dérivés, mais seulement avec Project Server sur site.
2. Tables de taux de coût. Microsoft Project accepte jusqu'à 5 taux de coût par ressource (taux A à taux E) avec des plages de dates d'effet. Exportez chaque niveau de taux et chaque ligne de date d'effet. Si votre PMO n'utilise que le taux A, vous pouvez ignorer B–E, mais vérifiez-le avant de le supposer.
3. Exceptions de calendrier. Pour chaque ressource, exportez la liste des exceptions de calendrier avec leur nom, leur plage de dates et l'horaire modifié. Si votre plateforme cible ne préserve pas les exceptions nommées, consignez les noms dans un CSV d'accompagnement pour que la justification (« Semaine du congrès », « Fermeture annuelle ») survive.
4. Hiérarchie RBS. Exportez la structure de découpage des ressources : chaque nœud, les liens parent-enfant et les ressources rattachées à chaque nœud. C'est la hiérarchie qui permet aux gestionnaires de ressources de filtrer les vues de capacité selon leur structure hiérarchique.
5. Affectations actives. Prenez un instantané de chaque affectation active dans chaque projet actif : quelle ressource, quel projet, quelle tâche, heures affectées, heures réelles, début et fin planifiés. C'est la base de la validation ; après la migration, vous comparerez l'affectation entre source et cible.
6. Champs personnalisés des ressources. Si votre PMO a défini des Enterprise Custom Fields sur les ressources (niveau d'habilitation, indicateur facturable, type de contrat), exportez-les avec la liste des ressources. Certaines plateformes cibles les modéliseront comme champs intégrés, d'autres comme champs personnalisés, d'autres pas du tout ; c'est ce qui décidera plus tard du mappage des champs.

Le rapport de préparation terminé est la base du reste de la migration. Pour vérifier la qualité de l'export avant de vous engager, passez un pool d'échantillon dans l'outil d'aperçu de migration : chargez une tranche représentative du pool de ressources et voyez exactement quels champs, taux et exceptions passent proprement.

Cinq phases, chacune avec un livrable et un point de décision go/no-go. La durée totale est généralement de 3–5 semaines pour un pool de 100–250 ressources, davantage si vos tables de taux de coût sont très personnalisées ou votre RBS étendue.

Phase 1 : Inventaire et décisions (1 semaine)

Terminez l'inventaire préalable ci-dessus, puis choisissez la plateforme selon les couches du modèle de ressources qui ne sont pas négociables pour votre équipe. Documentez la décision et sa justification ; c'est la section que vous relirez quand quelqu'un demandera pourquoi la plateforme choisie n'a pas la fonction X.

• Mener l'inventaire sur le locataire en service
• Noter chaque plateforme cible au regard de votre liste de couches indispensables
• Choisir la cible et documenter la justification
• Obtenir la validation de la direction du PMO sur le choix de la plateforme

Point de décision : rapport de préparation signé ; plateforme cible choisie.

Phase 2 : Exporter le pool (2–3 jours)

Exportez depuis Project Server tant qu'il fonctionne encore, puis vérifiez que l'export contient chaque couche ci-dessous. Ne comptez pas sur les exports de fichiers .mpp pour le pool de ressources ; ils ne contiennent que les affectations de ressources locales au projet, pas le pool de l'organisation avec ses taux, ses calendriers et sa RBS.

• La liste des ressources, depuis /Resources
• Les exceptions de calendrier, depuis /Resources/Calendars
• Les tables de taux de coût (ou la Reporting DB, sur site)
• La RBS, depuis les points de terminaison de l'API SOAP, qui n'ont pas d'équivalent OData
• Les affectations actives, depuis /Assignments
• Des décomptes qui correspondent au rapport de préparation

Point de décision : le décompte exporté correspond à celui du rapport de préparation pour chaque couche.

Phase 3 : Remodeler dans la cible (3–7 jours)

Importez le pool dans la plateforme cible, puis traitez couche par couche les écarts de transposition révélés par la comparaison des plateformes. Les génériques qui ne se transposent pas sont remodelés en espaces réservés nominatifs. Les noms d'exceptions de calendrier qui ne se transposent pas sont archivés. Les champs personnalisés des ressources sont mappés vers des champs intégrés ou des définitions de champs personnalisés dans la cible.

• Importer la liste des ressources (import en masse ou API de la cible)
• Recréer la hiérarchie RBS et rattacher les ressources aux nœuds
• Charger les taux standard et les tables de taux de coût avant toute donnée d'affectation
• Appliquer les exceptions de calendrier par ressource
• Transposer les ressources génériques selon le modèle de la plateforme
• Mapper les champs personnalisés des ressources

Point de décision : le décompte du pool, la hiérarchie RBS et le nombre de tables de taux correspondent à la source.

Phase 4 : Affecter et valider (1 semaine)

Migrez les affectations de tâches projet par projet, par vagues regroupées par équipe responsable. Après chaque vague, l'équipe destinataire valide sous 48 heures l'affectation dans la cible par rapport à la source pour ses projets. N'avancez pas tant que la vague n'est pas validée sans écart ; traquer une dérive d'affectation accumulée sur de nombreux projets est bien plus difficile que de la corriger projet par projet.

• Migrer les affectations par vagues de 10–25 projets
• Écart d'affectation par ressource et par projet : source contre cible
• Examiner tout écart > 5%
• Rapprocher les calculs des feuilles de temps valorisées sur un échantillon de feuilles passées

Point de décision : écart d'affectation par ressource < 5% sur tous les projets.

Phase 5 : Vues de capacité et rapprochement (1 semaine)

Recréez les vues de capacité que les gestionnaires de ressources utilisent vraiment, puis exécutez-les en parallèle de Project Server pendant au moins 5 jours ouvrés. Les rapports d'écarts quotidiens signalent chaque endroit où le calcul de capacité de la nouvelle plateforme diffère de l'ancienne. Examinez chaque écart. Documentez les vraies différences comme des limites connues.

• Reconstruire les 5 principales vues de capacité dans la cible
• Produire des rapports d'écarts quotidiens pour les 25 ressources ayant le plus d'heures affectées
• Examiner les écarts > 5% ; documenter les vraies différences de plateforme
• Former les gestionnaires de ressources à la nouvelle interface des vues de capacité
• Basculer : la cible devient la source de vérité, Project Server passe en lecture seule

Point de décision : 5 jours ouvrés consécutifs de rapports d'écarts quotidiens sans écart ; les gestionnaires de ressources ont validé la nouvelle interface des vues de capacité.

Les cinq modes de défaillance du modèle de ressources les plus fréquents, avec la prévention de chacun :

Le point commun aux cinq : chacun est une décision du type « on verra plus tard », bon marché sur le moment et coûteuse en production. Le travail de rapprochement fait partie des coûts les plus souvent sous-estimés dans les budgets initiaux ; dans le calculateur de coût de migration, il relève de l'exploitation en parallèle.

La phase de validation comprend trois contrôles, chacun produisant une preuve. Classez-les avec le rapport de préparation ; ensemble, ils forment la piste d'audit de la migration.

1. Rapprochement de l'affectation par ressource. Pour les 25 ressources ayant le plus d'heures affectées sur les 90 prochains jours, comparez l'affectation entre source et cible. Tolérance : ±5%. Un écart plus grand signifie que la migration des affectations a perdu des données ou que le calcul de capacité de la cible diffère structurellement de celui de Project Server. Les deux doivent être examinés. Preuve : un rapport d'écarts par ressource.
2. Rapprochement d'un échantillon de feuilles de temps valorisées. Prenez les 10 feuilles de temps clôturées les plus récentes de 5 ressources différentes. Recalculez le coût dans la cible sur les mêmes saisies. Tolérance : ±1% (ce sont des dollars ; la tolérance est plus serrée que pour l'affectation). Un écart > 1% indique un taux erroné, une exception de calendrier perdue, ou les deux. Preuve : les calculs de coût côte à côte.
3. Parité des vues de capacité multiprojets. Reproduisez les 3 vues de capacité que les gestionnaires de ressources utilisent le plus. Comparez-les côte à côte avec la dernière exécution de Project Server sur la même période. Des différences dans la façon dont les deux vues classent l'affectation (directe ou de sous-projet, nominative ou générique) sont attendues. Documentez-les comme des différences de plateforme connues dans le guide d'exploitation après migration. Preuve : des captures d'écran côte à côte avec les écarts documentés.

Le résultat de la phase de validation est un rapport de résultat de migration : ce qui a migré, ce qui n'a pas migré et ce qui reste ouvert. Avec le rapport de préparation de la phase 1, les deux documentent la piste d'audit complète.

Le PMO porte le guide de migration, mais le modèle de ressources a des conséquences que les équipes financières découvrent après la bascule si personne ne les soulève en amont. Trois tendances reviennent dans chaque migration impliquant des ressources valorisées, et chacune frappe autrement que les problèmes côté PMO.

Trois notions de taux souvent confondues

Project Server gère trois taux différents par ressource qui se ressemblent et ne sont PAS interchangeables : le taux standard (le coût d'une heure interne pour modéliser l'affectation, souvent le coût complet de la main-d'œuvre), le taux de coût (le taux qui sert à calculer le coût comptable d'une feuille de temps, parfois réparti dans les tables de taux A à E selon le type d'activité) et le taux de facturation (le taux facturé au client pour les heures facturables d'une mission). Certains PMO utilisent un seul taux pour les trois notions ; d'autres des taux distincts par notion ; d'autres des niveaux de tables de taux au sein de chaque notion.

Avant l'export, demandez à la finance quelles notions de taux elle utilise vraiment, quels niveaux de tables correspondent à quelles activités et quels champs de la plateforme cible chaque taux alimente. L'export est une ligne par taux et par ressource ; l'import est une décision de mappage qui détermine si les rapports de reconnaissance du chiffre d'affaires du trimestre suivant tombent juste. Une erreur courante et récupérable consiste à charger les taux de facturation dans le champ du taux de coût. Les feuilles de temps valorisées se calculent alors sur le taux de facturation, les comptes de résultat affichent des coûts gonflés, et la correction est un nouvel export suivi d'un nouveau chargement. Une erreur plus grave et plus difficile à corriger consiste à charger les taux de coût dans le champ du taux de facturation. Les factures émises au mauvais taux doivent être réémises, et la conversation de correction avec le client n'est pas gratuite.

Les règles de capitalisation ne suivent pas toutes seules

Les PMO des organisations réglementées ou à forte intensité d'investissement ont souvent des règles de capitalisation de la main-d'œuvre du type « les heures d'ingénierie sur les projets capitalisables alimentent un actif du bilan plutôt qu'une charge ». Dans Project Server, ces règles vivent généralement sous forme de vues ou de rapports construits sur le flux OData, parfois avec un indicateur par projet et un autre par tâche. Rien de cette infrastructure ne migre automatiquement. Les indicateurs s'exportent (valeurs de champs personnalisés), les vues et les rapports non. La finance doit reconstruire de zéro le reporting de capitalisation sur la nouvelle plateforme, à partir des mêmes données marquées.

Le risque est un trimestre silencieux où le reporting de capitalisation n'a pas été reconstruit, où des heures qui auraient dû être capitalisées ont été passées en charge et où la période se clôt sur de mauvais chiffres. Des erreurs significatives sont ici une observation de contrôle interne. Demandez à la finance de prévoir la reconstruction de la capitalisation comme un chantier parallèle à la migration, pas comme une suite, et conditionnez la bascule à au moins une période clôturée de reporting de capitalisation côte à côte qui se rapproche.

Les rapports de taux de facturation demandent une configuration explicite

Les PMO de services professionnels vivent du taux de facturation (heures facturables divisées par heures payées, par ressource et au total). Project Server le produit en combinant les données des feuilles de temps et un indicateur « facturable » au niveau de l'affectation ou de la tâche. L'indicateur s'exporte proprement ; le rapport non. Comme le montre la matrice de comparaison ci-dessus, la prise en charge native des rapports de taux de facturation varie selon la plateforme cible. Onplana, Smartsheet RM et Workfront fournissent tous le rapport comme un élément à part entière ; Planner Premium de Microsoft n'a aucune notion de facturable.

Pour les PMO qui migrent vers une plateforme prenant en charge le taux de facturation, conditionnez la bascule à un rapport côte à côte sur les 4 dernières semaines qui se rapproche à ±2%. Tout écart plus grand pointe vers une erreur de mappage des taux, un indicateur facturable manquant ou une affectation non migrée. Pour les PMO dont la plateforme cible ne prend pas en charge le taux de facturation nativement, prévoyez d'alimenter un outil décisionnel en aval (Power BI, Looker, Sigma) avec l'instantané OData et d'y reconstruire le rapport. Dans les deux cas, la finance doit valider l'exactitude du rapport avant l'arrêt de l'ancienne plateforme. Sinon, c'est à la première clôture mensuelle sur la nouvelle plateforme que le manque apparaît, soit au pire moment possible.

Pourquoi la finance doit être dans la salle avant la bascule

Dans chaque migration où la finance a été associée tard, les trois mêmes problèmes reviennent : les mappages de taux sont à refaire parce que la finance ne partageait pas la lecture du PMO sur quel taux est lequel ; le reporting de capitalisation n'a pas été reconstruit et la première clôture trimestrielle sur la nouvelle plateforme a mal déclaré la main-d'œuvre capitalisée ; l'écart du taux de facturation dépassait la tolérance du PMO parce que la finance applique d'autres règles. Aucun n'est un problème de plateforme ; tous sont des défauts de coordination. La solution est peu coûteuse : faites de la finance un approbateur nommé en phase 1 (inventaire) et en phase 4 (affecter et valider). Sa validation boucle le mappage des taux, le reporting de capitalisation et la tolérance du taux de facturation. Sans elle, le PMO livre la migration et la finance découvre le coût des semaines plus tard, presque toujours à une clôture mensuelle, presque jamais à un moment qui permette de refaire le travail sereinement.

La migration est l'événement déclencheur ; la question de long terme est de savoir si la pratique de planification de la capacité de votre PMO fonctionne encore sur la nouvelle plateforme. Quatre habitudes distinguent les équipes qui gardent la rigueur de celles qui dérivent :

• Une source unique de vérité, appliquée. Le pool de ressources de l'organisation fait foi ; la création de ressources locales à un projet est un signe avant-coureur de dérive. Certaines plateformes permettent de verrouiller le droit de création par projet. Utilisez-le s'il existe ; sinon, faites chaque semaine un contrôle qui compare les listes de ressources des projets au pool de l'organisation.
• Une revue trimestrielle des taux. Les taux standard qui restent 12+ mois sans revue s'éloignent du coût complet réel de la main-d'œuvre. Les feuilles de temps valorisées s'éloignent alors de la réalité financière. Fixez un rythme trimestriel pour revoir les tables de taux et les réétalonner.
• De la discipline sur les exceptions nommées. Les exceptions de calendrier s'accumulent sans bruit. Une ressource avec 30 exceptions nommées sur 3 ans, c'est normal ; sans revue régulière, les exceptions se figent. Chaque année, passez en revue le nombre d'exceptions par ressource et supprimez tout ce qui dépasse la durée de conservation fixée par la politique.
• Faire évoluer la RBS. La hiérarchie de reporting qui était juste au moment de la migration vieillit à mesure que l'organisation se restructure. Prévoyez une revue de la RBS tous les 6 mois dans le cycle général de revue de l'organisation, pour que le découpage des vues de capacité garde son sens.

Les questions que les PMO posent le plus souvent sur la migration du modèle de ressources. Le schéma FAQPage complet figure dans les données structurées de cet article, pour que ces questions apparaissent dans la fonction « Autres questions posées » de Google.

Expand