Surallocation des ressources et nivellement : la repérer et la corriger à la main, avec un exemple

Un planning peut respecter toutes les dépendances et rester irréalisable. Dans la sortie d’application qui sert d’exemple à ce guide, les dates sont justes, et pourtant les jours 8 et 9, Dana, la seule personne qui teste, a deux tâches de test à plein temps en même temps. Un diagramme de Gantt dessine une barre par tâche : les deux barres de Dana sur les mêmes jours ressemblent à n’importe quelle autre paire de barres qui se chevauchent.

Ce guide montre comment mesurer la surallocation des ressources jour par jour par rapport au calendrier de chaque personne, puis comment la supprimer à la main avec quatre leviers : lisser dans la marge, réaffecter, décaler et ajouter de la capacité. Chaque levier est testé sur la même sortie, avec le jour de fin qu’il produit et les jours de surallocation qu’il laisse.

Ce qu’est la surallocation des ressources#

La surallocation des ressources est une situation de planification dans laquelle une personne ou un équipement reçoit, sur une période, plus de travail que son temps de travail disponible ne le permet. Si on la laisse en l’état, elle se transforme en retard : dans l’exemple ci-dessous, deux jours à 200 % pour la personne qui teste repoussent la sortie d’une application du jour 12 au jour 14 quand personne d’autre ne peut reprendre un test. Elle reste aussi invisible. Le Government Accountability Office (GAO) américain en donne la raison dans son Schedule Assessment Guide : un planning sans affectation de ressources suppose un nombre illimité de ressources disponibles sans limite^[1].

La correction s’appelle le nivellement des ressources (resource leveling en anglais). Le GAO le décrit comme l’ajustement du début planifié des activités, ou des affectations des personnes, pour tenir compte de leur disponibilité, et précise qu’il peut suffire de transférer du travail d’une personne surallouée vers une personne sous-allouée ou de retarder un début jusqu’à ce que la personne soit libre^[1]. Le nivellement qui reste dans la marge, sans déplacer la date de fin, s’appelle le lissage des ressources ; Microsoft Project le propose avec l’option Level only within available slack (niveler uniquement dans la marge disponible)^[2].

Qui a besoin d’un contrôle de surallocation, et quand#

Un planning a besoin de ce contrôle à partir d’environ 3 personnes nommées et 15 tâches : c’est notre règle empirique pour le moment où une personne se retrouve avec deux tâches ouvertes le même jour. Le chef de projet fait le contrôle et prend les décisions de nivellement. Les responsables d’équipe lisent le résultat pour leurs propres équipes et, dans les équipes de 4 à 15 personnes, chacun lit sa propre ligne pour voir quelles tâches ont bougé. Le sponsor ne voit que la conséquence : une date de fin.

Faites le contrôle après la première version complète, une fois les dépendances, les durées et les personnes affectées renseignées, et avant d’enregistrer la référence. Puis refaites-le à chaque fois qu’une date bouge, car un glissement en amont pousse des tâches sur les jours de quelqu’un d’autre.

Deux situations peuvent s’en passer. Une personne qui travaille sur un seul flux à la fois, ou une équipe qui tire ses tâches d’un tableau avec une limite de travail en cours, ne peut pas être affectée deux fois par le planning, puisque la limite plafonne déjà le nombre de tâches que chacun porte. Un planning qui s’arrête aux phases n’a rien à niveler : le guide du GAO indique que le nivellement ne doit jamais être appliqué aux plannings de synthèse^[1].

Comment la charge se mesure, jour par jour#

La charge d’une personne un jour donné correspond aux heures de toutes les tâches qui lui sont affectées ce jour-là, chacune multipliée par son affectation, divisées par les heures qu’elle travaille ce jour-là ; au-delà de 100 %, la personne est surallouée. Dans ce guide, l’affectation est la part de temps qu’une personne consacre à une tâche (50 %, 100 %), et la charge est toujours ce ratio journalier.

Pour Dana au jour 8 de l’exemple, avec deux tâches à 100 % et une journée de 8 heures, la charge vaut (8 + 8) / 8 = 200 %.

Le calendrier change le dénominateur. Un jour non travaillé, il vaut zéro : tout travail planifié est donc de la surallocation. Une demi-journée de congé laisse 4 heures, et une seule tâche à 100 % devient 8 / 4 = 200 %. Une personne disponible à 80 % travaille 6,4 heures sur une journée de 8 heures : une seule tâche affectée à 100 % la met à 8 / 6,4 = 125 %.

Comptez par jour, puis faites la synthèse. Si le jour 1 est un lundi, la semaine de Dana du jour 6 au jour 10 contient 48 heures de test pour 40 heures disponibles, soit une charge de 120 %, et le mois de 20 jours ouvrés autour de la sortie contient 64 heures pour 160, soit 40 %. Une vue mensuelle montre Dana avec du temps libre. Microsoft Project permet au nivellement de rechercher les surallocations sur n’importe quelle période, de la minute au mois, et sa documentation prévient que, selon la période choisie, une ressource peut paraître surallouée sans être signalée^[2].

Le périmètre compte aussi. Une charge calculée dans un seul projet ignore le travail de la personne sur les autres projets : quelqu’un partagé entre trois plannings peut sembler libre dans chacun d’eux. Quand des personnes sont partagées, faites le contrôle sur l’ensemble des projets.

Un exemple détaillé : la sortie d’une application avec une seule personne pour les tests#

L’exemple compte 6 tâches, 4 personnes et un chemin critique de 12 jours. Une équipe prépare une version d’une application d’achat en ligne : Lena rédige les spécifications, Marco développe l’API de paiement, Priya développe les écrans mobiles et Dana est la seule personne qui teste. Les durées sont en jours ouvrés de 8 heures, toutes les dépendances sont de type fin-début et toutes les affectations sont à 100 %. Un détail se trouve dans un calendrier : Priya a posé un jour de congé au jour 9.

Le chemin critique passe par les spécifications, l’API, le test de l’API et la non-régression : 2 + 5 + 3 + 2 = 12 jours. La charge de Dana est de 100 % au jour 7, de 200 % aux jours 8 et 9, puis de nouveau de 100 % du jour 10 au jour 12. Rien dans les dates ne paraît anormal.

Une fois mesuré, le problème représente 2 jours de surallocation pour une personne, un pic à 200 % et 16 heures de travail en excès. Enchaîner les tests de Dana coûte 2 jours (levier 3 ci-dessous) : c’est le plafond de toute correction. Avancer le test de l’API ne sert à rien, car l’API de paiement n’est terminée qu’à la fin du jour 7 et le test, situé sur le chemin critique, n’a aucune marge à céder.

Quatre leviers pour niveler le planning à la main#

Essayez les leviers dans cet ordre et notez deux résultats pour chacun : le nouveau jour de fin et les jours de surallocation qui restent. Le lissage passe en premier parce qu’il ne coûte rien quand il fonctionne ; l’ajout de capacité passe en dernier parce qu’il coûte de l’argent.

1. Lisser dans la marge. Le test des écrans a 1 jour de marge : il peut glisser des jours 7–9 aux jours 8–10. Dana a alors les deux tests aux jours 8, 9 et 10. Pour libérer la place du test de l’API, le test des écrans devrait se terminer au plus tard au jour 7, donc commencer au jour 5, alors que Priya développe encore les écrans jusqu’à la fin du jour 6. Résultat : fin au jour 12, 3 jours de surallocation au lieu de 2. Rejeté.
2. Réaffecter. Priya termine les écrans au jour 6 et est disponible à partir du jour 7, sauf le congé du jour 9. Deux réaffectations sont possibles, et le calendrier les départage : - Priya prend le test de l’API. Il occupe les jours 8, 10 et 11, se termine au jour 11 et repousse la non-régression aux jours 12–13. Résultat : fin au jour 13, 0 jour de surallocation. - Priya prend le test des écrans. Il se déroule aux jours 7, 8 et 10 et se termine au jour 10, dans son jour de marge, tandis que Dana garde le test de l’API et la non-régression. Résultat : fin au jour 12, 0 jour de surallocation. Le prix à payer : les écrans sont testés par la personne qui les a développés.

Oubliez le congé et la première option paraît gratuite, avec Priya planifiée sur un jour non travaillé.

1. Décaler. Si personne d’autre ne peut tester, Dana enchaîne les trois tâches : test des écrans aux jours 7–9, test de l’API aux jours 10–12, non-régression aux jours 13–14. Le GAO observe que les activités décalées par le nivellement sont en général celles qui ont la plus grande marge libre^[1]. Ici, ce choix est pire : décaler plutôt le test des écrans laisse Dana sans travail au jour 7 et termine la non-régression au jour 15. Résultat : fin au jour 14, 0 jour de surallocation.
2. Ajouter de la capacité. Un testeur externe sur le test de l’API aux jours 8–10 maintient le jour 12 pour 3 jours payés plus une mise au courant ; le guide pour rattraper un projet en retard compare les renforts selon leur coût par jour gagné.

Notre recommandation pour cette version : confier le test des écrans à Priya, car un défaut de mise en page découvert après la sortie coûte moins cher à cette équipe qu’un jour de retard. Pour une modification du parcours de paiement, nous confierions à Priya le test de l’API en acceptant le jour 13. Par défaut, réaffectez d’abord et décalez ensuite. Inversez l’ordre quand la seule personne disponible testerait son propre travail sur un sujet à risque et que la date promise laisse de la marge : si la sortie était promise pour le jour 15, le levier 3 ne change rien de visible hors de l’équipe.

Avant de considérer le planning comme nivelé, vérifiez :

• que la charge de chaque personne est inférieure ou égale à 100 % chaque jour, avec les congés et les jours à temps partiel dans son calendrier ;
• le jour de fin par rapport à celui d’avant le nivellement ;
• que chaque tâche déplacée à la main porte une dépendance ou une note qui explique pourquoi, pour que la prochaine mise à jour ne l’annule pas (le GAO demande que les modifications faites pour résoudre les conflits de ressources soient documentées et comprises de tous^[1]) ;
• les personnes partagées, sur l’ensemble de leurs projets.

Erreurs fréquentes#

• Fractionner l’affectation pour faire disparaître l’alerte. Mettre Dana à 50 % sur les deux tests efface les cellules rouges alors que chaque test garde ses 3 jours : sur le papier, la moitié des heures de test disparaît. Fait honnêtement, chaque test à 50 % dure 6 jours.
• Laisser les congés et les jours à temps partiel hors du calendrier. Dans l’exemple, le jour 9 de Priya est le seul élément qui distingue une réaffectation qui coûte 1 jour d’une réaffectation qui ne coûte rien.
• Affecter toute l’équipe à une seule tâche. Cinq noms à 100 %, c’est la charge de cinq personnes sur toute la durée. Découpez la tâche en sous-tâches avec un responsable chacune, ou donnez à chaque personne sa part réelle.
• Niveler un planning de phases. Une barre « Tests » de 15 jours affectée à deux personnes ne dit rien sur qui est occupé quel jour.
• Niveler une seule fois. Le GAO recommande de comparer la date du dernier nivellement avec la date de la dernière modification des ressources et de leur disponibilité^[1]. Refaites le contrôle après chaque glissement.

Les limites du nivellement#

Le nivellement, à la main ou par logiciel, compte des heures et traite comme interchangeables des personnes qui ont les mêmes heures. Dana est peut-être la seule personne qui a accès au parc de terminaux de test, et Marco va peut-être deux fois plus vite que n’importe qui sur l’API ; aucun de ces faits n’apparaît dans un pourcentage de charge. Quand les compétences décident de qui peut faire quoi, fixez d’abord les affectations et nivelez ensuite.

Le nivellement automatique échoue autrement. Le GAO demande aux planificateurs d’examiner le résultat des routines de nivellement automatique et de l’ajuster si nécessaire, et prévient qu’une routine peut se révéler inefficace en retardant des activités pour attendre une personne qui n’est disponible qu’en partie^[1]. Dans l’exemple, une routine qui refuse de fractionner le test de l’API autour du congé de Priya le fait commencer au jour 10 et termine la sortie au jour 14, un jour plus tard que le fractionnement fait à la main.

À la main, les leviers cessent de converger à partir d’une certaine taille. Notre avis : au-delà d’environ 5 personnes partagées entre 3 projets ou plus, chaque correction dans un planning ouvre un conflit dans un autre, et un moteur de nivellement automatique comme celui de Microsoft Project vaut le temps passé à vérifier son résultat.

Les données d’entrée fixent aussi un plafond. Si les estimations de durée sont fausses, la surcharge se déplace avec elles. Le guide du GAO ajoute que le nivellement peut avoir peu ou pas d’effet sur un planning, ou retarder fortement la date de fin prévue, selon la marge disponible, et que lorsqu’il retarde l’achèvement, les ressources sont une vraie contrainte et le planning demande une autre approche^[1]. Règle empirique : si la même personne dépasse 100 % sur plus de 10 jours ouvrés dans un trimestre, déplacer des dates ne suffira pas ; réduisez le périmètre ou ajoutez une personne.

Comment faire dans Planitude#

Affectez des personnes aux tâches (clic droit sur une barre, puis Affecter des personnes) avec la part de temps que chacune y consacre. La vue Charge affiche la charge de chaque personne par jour, par semaine ou par mois, mesurée par rapport à son calendrier et à sa disponibilité. Les cellules surallouées passent en rouge avec une icône d’alerte, une cellule de semaine ou de mois passe en rouge si l’un de ses jours est suralloué et indique le nombre de jours et le pic, et un clic sur une cellule liste les tâches qui en sont la cause. Le diagramme de Gantt nomme les personnes surallouées dans une alerte.

Le portefeuille additionne la charge de chaque personne sur tous les projets que vous pouvez voir. Quand l’assistant propose une modification, l’aperçu signale toute personne qu’elle surallouerait, avec le pic et sa disponibilité. Un planning importé depuis un fichier .mpp conserve le retard de nivellement que Microsoft Project a enregistré pour chaque tâche, c’est-à-dire le temps pendant lequel elle est retenue après son début au plus tôt^[3], et les dates en tiennent compte.

Planitude ne nivelle pas automatiquement. Il ne calcule pas non plus de nouveaux retards de nivellement : il montre la surcharge, et vous la résolvez avec les leviers ci-dessus.

Questions fréquentes#