Gérer le glissement de périmètre : techniques et outils pour les chefs de projet

Qu’est-ce que la dérive du périmètre ?

La dérive du périmètre se produit lorsque les livrables ou les fonctionnalités prévues dans un projet dépassent ce qui avait été convenu à l’origine—mais que le calendrier du projet ou le budget n’est pas ajusté pour tenir compte de ces changements.

Cela diffère d’un changement de périmètre, qui implique des décisions officielles afin de modifier le périmètre initial du projet—son objectif, son budget, ses livrables, son calendrier, ses responsabilités, ou d’autres éléments.

La dérive du périmètre peut toucher tout projet à périmètre fixe. Elle peut survenir de manière intentionnelle ou non, et provenir de n’importe lequel des acteurs impliqués dans un projet.

La raison pour laquelle nous nous intéressons tant à la dérive du périmètre est qu’elle peut mener à l’échec du projet. Cela peut vous faire manquer une échéance, consommer (voire dépasser !) votre budget à cause de surcoûts, et, en plus, aboutir à livrer un résultat inadapté. Aïe !

3 types de dérive du périmètre

La dérive du périmètre peut se manifester sous différentes formes. Voici quelques causes fréquentes :

• Absence de prise de décision et/ou de documentation : les acteurs changent fréquemment d’avis ou ne parviennent pas à se mettre d’accord sur le périmètre du projet à cause de priorités organisationnelles changeantes
• Estimations trop optimistes : l’équipe sous-estime l’effort nécessaire pour accomplir les tâches et atteindre les jalons, et surestime donc ce qui peut être inclus dans le périmètre du projet (dans la réalité, cela peut parfois se traduire par une positivité toxique)
• Surenchère de fonctionnalités (« gold plating ») : ajout de fonctionnalités superflues au produit qui ne faisaient pas partie des exigences initiales.

Qui provoque la dérive du périmètre ?

Il est utile d’analyser votre projet pour identifier qui pourrait provoquer la dérive du périmètre. Savoir détecter ce phénomène tôt permet de définir la meilleure stratégie pour y faire face.

PS : Un dériveur du périmètre hante-t-il votre projet ?

Scope Creep Made Even Creepier: Keep Him Away from Your Projects

Membre de l’équipe projet

Parfois, des membres de l’équipe projet peuvent être à l’origine de la dérive du périmètre. Plusieurs raisons possibles :

1. Le membre de l’équipe ne comprend pas clairement le périmètre

Au début du projet, présentez toutes les exigences ou livrables dans une déclaration de périmètre, un plan de projet ou une structure de découpage du travail (WBS), et assurez-vous que tous les membres de l’équipe prennent connaissance de cette documentation. 

Si le périmètre est en cours de définition, impliquez au maximum l’équipe dans ces discussions. Si cela n’est pas possible, organisez a minima une réunion de lancement du projet pour garantir l’alignement. Pendant l’exécution, menez des points réguliers avec l’équipe pour que tout le monde demeure sur la même longueur d’onde.

2. Le membre souhaite faire ce qu’il veut plutôt que ce qui est prévu

Associer votre équipe à la définition du périmètre est utile pour obtenir leur engagement sur ce qu’ils vont concevoir et réaliser. Assurez-vous que chacun œuvre avec l’ensemble du groupe. Si quelqu’un se lance de son côté dans la production de quelque chose hors périmètre sur un simple caprice, cela engendre confusion et risques de conflits au sein de l’équipe.

3. Le membre prend des décisions isolément

Il arrive parfois qu’un membre de l’équipe choisisse une solution qui influe sur le périmètre, souvent sans en avoir conscience.

Même ajouter une demi-journée de travail supplémentaire pour faire quelque chose d’un peu différent pourrait impacter le reste de votre projet. Par exemple, si un designer décide d’inclure une fonctionnalité sur un site (comme une barre de recherche) sans en discuter avec le développeur, cela pourrait affecter le calendrier du projet.

Préparez-vous au succès du projet en développant une culture de confiance et de transparence. Lorsque quelqu’un vous fait part d’un problème directement, partagez-le plus largement s’il s’agit d’une décision importante à prendre. Amenez les gens à travailler ensemble pour trouver des solutions aux problèmes. Assurez-vous que tout le monde soit en contact (en présentiel ou à distance) régulièrement. 

La majorité des projets réussis proviennent d’équipes qui collaborent efficacement.

Parties prenantes internes

Les parties prenantes clés au sein de votre organisation peuvent influencer le périmètre d’un projet. Elles peuvent avoir une vision pour l’organisation qui implique de livrer plus sur votre projet, ou vouloir faire avancer un autre objectif.

Par exemple, il arrive parfois qu’une relation client soit plus importante pour une organisation que de rester dans le périmètre défini de votre projet.

Assurez-vous que vos parties prenantes internes comprennent ce que vous essayez de livrer et dans quels délais. Si quelque chose risque d’avoir des répercussions sur votre projet, exposez clairement l’impact que cela aura — qu’il soit financier, réputationnel, ou autre.

Utilisateurs externes

Les tests utilisateurs devraient (idéalement) faire partie de la mise en place de votre projet ou produit. Les retours utilisateurs sur un produit peuvent influencer une série d’événements qui augmente finalement le périmètre. Que se passe-t-il si vous recevez un retour de vos utilisateurs qui révèle un point que vous ne pouvez pas ignorer ? Même si cela augmente votre périmètre, vous devrez y répondre.

Une fois les résultats des tests collectés, revoyez-les avec votre équipe pour identifier les modifications à apporter. Établissez des priorités pour comprendre quels changements auraient le plus d’impact sur l’expérience utilisateur. Ensuite, définissez les modifications que vous pouvez intégrer sans problème, sans affecter le périmètre.

Si l’une des modifications nécessaires entraîne une expansion du périmètre, parlez-en à votre client ou à la partie prenante concernée. Préparez-vous en comprenant ce qui se passerait si vous décidiez de ne pas réaliser le changement.

Parties tierces

Si vous dépendez de parties tierces pour livrer votre projet — que ce soit une entreprise externe, une API tierce ou un fournisseur de contenu — vous devez identifier ces dépendances au démarrage du projet. Réfléchissez à l’impact que ces dépendances pourraient avoir sur votre projet et comment elles pourraient influer sur votre périmètre.

Par exemple, que se passerait-il si votre fournisseur de contenu vous envoyait des éléments dans un format difficile à intégrer ou à télécharger sur votre site web ? Cela ajouterait-il du temps supplémentaire à votre planning ? 

Vous ne pourrez pas anticiper tous les scénarios, mais adopter une approche de gestion des risques pour soulever ces dépendances avec le client en début de projet vous aidera à comprendre leur impact potentiel avant d’avoir un problème sur les bras.

Chef de projet

Nous, en tant que chefs de projet, pouvons parfois être à l’origine d’un glissement de périmètre. Il est très tentant d’essayer de tout faire rentrer dans votre budget et votre calendrier existants, sans alerter le client.

Bien qu’il puisse être difficile d’annoncer que vous ne pouvez pas faire quelque chose sans une demande de modification, cette conversation est bien plus facile à avoir tôt que tard au cours du cycle de vie du projet.

Si vous ou votre équipe identifiez un problème, explorez des solutions possibles. Par exemple, si des travaux supplémentaires sont nécessaires, voyez ce qui peut être retiré du périmètre — y a-t-il des éléments dans votre projet qui ne sont pas essentiels à la première version ? 

Présentez ces options et une recommandation au client ou à la partie prenante.

Client

Nous ne pouvons pas conclure cette section sans mentionner un acteur clé du glissement du périmètre : votre client. Méfiez-vous des clients ou sponsors de projet qui ajoutent des demandes « petites » qui finissent par alourdir le périmètre d’origine, changent d’avis ou suggèrent de nouvelles manières de faire pouvant impacter le niveau d’effort requis. 

Soyez honnête et transparent avec eux s’ils demandent quelque chose qui va entraîner un glissement du périmètre. Aussi, formulez votre réponse de façon à ne pas simplement dire « non », mais à proposer une alternative. Par exemple :

« Cette nouvelle demande aura tel impact spécifique sur le temps/les coûts. Nous avons examiné les priorités — pourquoi ne pas remplacer ceci par cela à la place ? On obtient un résultat similaire car… »

2 exemples de glissement de périmètre

Maintenant que nous avons passé en revue les types et causes du glissement de périmètre, nous allons présenter deux études de cas illustrant comment ce phénomène peut apparaître sur vos projets.

Étude de cas #1 de glissement de périmètre

Vous pourriez penser que vous seriez suffisamment malin pour empêcher un glissement de périmètre avant qu’il ne se produise, mais ce serait sous-estimer ce qui rend ce phénomène si, eh bien, inquiétant.

Imaginez que vous travaillez à recueillir les retours des utilisateurs sur les performances de votre prototype. Vous vous étiez mis d'accord avec votre client sur le nombre d'utilisateurs à interroger, la nature des retours acceptés et la durée de la période de commentaires. Vous aviez également convenu de traiter les retours dans la limite d'un certain nombre d'heures nécessaires à la mise en œuvre des corrections.

Une fois la période de commentaires terminée, le client reçoit un appel d'une personne haut placée qui n'a pas participé au groupe de test et demande si cette personne peut être intégrée. Vous aviez fixé une limite au nombre de personnes pouvant commenter, mais en quoi cela serait-il problématique d'en ajouter une de plus ? De plus, vous souhaitez laisser une bonne impression auprès des cadres, alors vous acceptez cette demande de dernière minute.

Sans que vous vous en rendiez compte, cette personne haut placée a fait participer toute son équipe. Ils souhaitent une session de test séparée et sont mécontents que leur cas d'utilisation favori n'ait pas été pris en compte.

Même si vous parvenez à rester ferme et à empêcher une modification des exigences, le temps supplémentaire passé en négociation, sans parler des communications additionnelles avec les parties prenantes pour accorder les objectifs et raison d'être du projet, vous a coûté une semaine et demie sur un calendrier déjà serré. Encore une fois, le périmètre du projet s'est insidieusement élargi !

Cas d'étude sur la dérive du périmètre n° 2

Il est également important de reconnaître que la dérive du périmètre ne vient pas toujours d'une demande client.

Imaginez que vous êtes chef de projet et que vous héritez d'un projet structuré de façon classique en cascade, comprenant des maquettes filaires et une phase de design, suivis du développement.

Vous intervenez au début de la phase de développement. La tâche est simple : vous construisez l'interface frontale sur un backend en marque blanche fourni par une autre agence.

Vous aviez validé les maquettes et le design et tout vérifié avec le client et l'agence... Qu'est-ce qui pourrait mal tourner ? Eh bien ! Il s'avère que l'autre agence continuait de faire évoluer son backend et publiait souvent de nouvelles versions du code.

Ironie du sort, ils n'avaient pas pris en compte le fait que votre agence allait construire sur l'ancien code, si bien que le vôtre cesse de fonctionner à chaque nouvelle livraison.

Pour corriger cela, vous décidez que l'équipe doit repasser par le code pour le mettre à jour en fonction des évolutions continues de l'autre agence. Cela n'avait pas été prévu, mais c'était nécessaire.

Au début, le travail supplémentaire se limitait à quelques petits correctifs occasionnels, mais de plus en plus de problèmes sont apparus. Bien que vous en ayez informé le client, vous avez tenté de faire entrer ce travail additionnel dans votre projet au lieu de demander au client de définir une solution conjointe avant d'aller plus loin dans la réalisation.

Ah, la clairvoyance rétrospective ! Que s'est-il passé ? Vous vous êtes enlisé dans une refonte du code existant—les délais se sont allongés, vous avez raté votre date butoir et, à la fin du projet, votre agence était sous forte pression. L'équipe était démotivée, le client était mécontent et, finalement, le projet a pris deux mois de retard.

Comment éviter la dérive du périmètre

Voici quelques stratégies pour réduire les risques que le périmètre de votre projet ne s'élargisse :

• Définissez clairement le périmètre de votre projet dès le départ, idéalement en impliquant l’équipe projet pour obtenir leur adhésion. Utilisez une déclaration de travail pour préciser ce qui est inclus ou exclu du périmètre. Ensuite, communiquez ce périmètre aux membres de l’équipe et aux parties prenantes du projet, y compris le client.
• Impliquez toute l’équipe pour établir des estimations solides basées sur les exigences. Pour réduire le risque d’erreurs d’estimation : 1) prévoyez une période de découverte pour déterminer ce que vous allez construire, 2) utilisez un contrat en régie plutôt qu’à prix fixe, et 3) soyez moins prescriptif sur les fonctionnalités à réaliser. Concentrez-vous sur les résultats attendus.
• Prévoyez des plans de contingence afin d’allouer suffisamment de temps pour l’assurance qualité. Envisagez également d’utiliser des tests automatisés pour gagner du temps — les articles Avantages et inconvénients des tests manuels et automatisés et Meilleurs outils d’automatisation sont des références utiles.
• Créez un plan de gestion des changements dès le début du projet pour définir comment vous gérerez les évolutions du périmètre. Si vous prévoyez d’utiliser des demandes de changement, détaillez le processus de contrôle des changements à suivre.
• Collaborez étroitement avec votre client pendant la réalisation du projet. Partagez avec lui l’avancement du projet ou un rapport d’avancement projet, itérez et impliquez-le tout au long du parcours afin d’éviter toute surprise.
• Soyez proactif dans la remontée des problèmes, soit dès qu’ils surviennent, soit idéalement avant (à condition d’avoir pensé à une solution !). Utilisez un plan de gestion des risques pour documenter votre approche. Tenez à jour et révisez un registre des risques pour suivre les risques potentiels.
• Posez des questions pour hiérarchiser les demandes entrantes. Assurez-vous que ces demandes n’augmentent pas le périmètre de manière imprévue, ne créent pas de doublons ou n’ajoutent pas de fonctionnalités superflues. Échangez avec l’équipe pour comprendre chaque demande, son impact sur le budget et le planning du projet, ainsi que l’effet attendu pour les utilisateurs, afin de les prioriser correctement.
• Impliquez les utilisateurs dès le début. Il est tentant de croire que nous (clients, entreprise, équipe) connaissons suffisamment les utilisateurs pour éviter de les consulter. Or, si vous n’intégrez pas tôt les retours des utilisateurs, vous risquez de perdre du temps à suivre une direction qui n’apporte aucune valeur. À ce stade, le périmètre peut vite déraper.

More Articles

• Comment gérer les changements de périmètre en gestion de projet
• Qu’est-ce que le périmètre d’un projet ? Définition, guide et exemple
• Comment rédiger facilement un énoncé de portée de projet : 5 étapes + conseils 2026

Comment gérer le dérapage de périmètre

Si votre projet est victime d’un dérapage de périmètre (ou si vous reprenez un projet dont le périmètre s’est trop élargi), ne paniquez pas. Vous avez encore la possibilité de vous remettre sur les rails. 

Voici les étapes que j’ai suivies en reprenant un projet en difficulté ayant subi un dérapage de périmètre :

• Commencez par expliquer la situation à votre client ou à la partie prenante. Décrivez comment vous en êtes arrivé là et quelles sont vos solutions pour y remédier. Inutile d’édulcorer la réalité. La situation est ce qu’elle est.
• Proposez des moyens de gagner du temps sans sacrifier la valeur. Cela peut signifier de déprioriser certaines fonctionnalités ou de reporter les « nice-to-have » jusqu’à une livraison ultérieure rapide. Préparez une présentation à l’intention de votre client exposant clairement les compromis de chaque option.
• Ajustez la taille de l’équipe. Cela peut vouloir dire remplacer un membre sous-performant ou substituer une ressource coûteuse par une ressource moins chère pour préserver le budget. Ces discussions sont désagréables, mais l’alternative peut être la perte de votre client, avec davantage de conséquences pour l’organisation.
• Gérez les conséquences. Parfois, redresser un projet en difficulté exige de ravaler sa fierté et de sacrifier la rentabilité globale du projet pour préserver une relation client précieuse. Cela peut aussi vouloir dire travailler plus afin de boucler une livraison plus tôt que prévu, comme geste réparateur. L’important est de cantonner ce sacrifice à une courte période pour éviter que cela ne devienne une habitude néfaste.

Gardez également à l’esprit que le dérapage de périmètre peut parfois être bénéfique. Plutôt que de le voir comme un ennemi sournois, vous pouvez le considérer comme un changement. Et ce changement peut être très profitable au produit que vous développez. C’est la façon de gérer ce changement qui impacte le projet, et non la demande de modification elle-même.

Vous devez simplement veiller à le détecter dès qu’il survient, surtout lorsqu’il n’est pas évident, et à le signaler avant qu’il ne s’enlise sans reprise de planification.

Comment gérer le périmètre dans l’Agilité

Le dérapage de périmètre concerne généralement les projets au périmètre fixé. Mais que faire si vous appliquez une méthodologie agile ?

Eh bien, l’agilité adopte le changement — et, à vrai dire, il en devrait être de même pour les chefs de projet agiles. Comme l’un des principes fondamentaux de l’agilité le stipule :

Accueillez favorablement l'évolution des exigences, même à un stade avancé du développement. Les processus agiles exploitent le changement pour offrir un avantage concurrentiel au client.

Par exemple, si vous travaillez selon la méthodologie scrum, lorsqu'une nouvelle exigence apparaît, ajoutez-la au backlog afin de la prioriser avec le product owner et l'équipe. Si cette exigence est intégrée dans le sprint lors de la réunion de planification de sprint, dépriorisez alors une autre tâche.

Le principe d'agile consiste à itérer, ce qui signifie concevoir, développer, tester, apprendre, puis recommencer le cycle. Comme les projets agiles ne détaillent pas tout à l'avance, cela laisse de la place pour le changement — on peut échanger une user story par une autre nécessitant le même niveau d'effort. Le changement permet d'obtenir le meilleur produit possible dans le temps imparti.

Alors, qu'est-ce qui constitue un dérapage de périmètre dans un projet agile ? Le scope creep peut survenir si votre product owner ne dépriorise pas des fonctionnalités ou des tâches lorsqu'une nouvelle exigence est ajoutée.

Il se peut également qu'il ne prenne pas en compte l'effort requis entre la nouvelle tâche et celle qui est dépriorisée, ce qui pourrait conduire à entasser des efforts supplémentaires dans un cycle déjà trop serré.

Veillez à toujours décomposer les nouvelles fonctionnalités ajoutées au backlog en user stories et à bien comprendre le niveau d'effort pour pouvoir les prioriser en conséquence.

En général, il est beaucoup plus simple de limiter le scope creep dans un projet agile, précisément parce que la méthode agile encourage le changement et l'intègre dans sa structure même.

Dans un projet en cycle en V (waterfall), votre produit sera probablement construit étape par étape jusqu'à finaliser la nouvelle solution brillante à la fin. Cela peut amener à penser que tout est prioritaire.

Si vous n’avez pas de priorités claires entre les fonctionnalités, il est difficile de savoir quoi retirer du périmètre lorsque les ajustements de besoins commencent à apparaître.

Quelle est la suite ?

Vous souhaitez échanger avec d'autres chefs de projet digital pour partager des ressources et des bonnes pratiques ? Rejoignez notre communauté de membres et accédez à plus de 100 modèles, exemples et échantillons, et discutez avec des centaines d'autres chefs de projet digital sur Slack.