Dérive du périmètre : comment l'éviter dans un projet logiciel
La dérive du périmètre est la croissance discrète d'un projet après son lancement. Périmètre écrit, demandes de changement et validation la maîtrisent.
Équipe rabbitclipPublié: 6 min de lecture
En bref
La dérive du périmètre, ou scope creep, désigne ce qui se produit lorsqu'un projet logiciel dépasse, une fois le travail commencé, ce que décrivait le devis, alors que le calendrier et le budget ne sont pas mis à jour en conséquence. Elle ne vient pas d'une grande décision, mais de petits ajouts accumulés : un écran de plus, un rapport de plus, une option supplémentaire dans ce champ. Pour l'éviter, il ne faut pas interdire les ajouts, mais mettre en place une procédure de changement qui rend visible par écrit l'effet de chacun sur le délai et le coût.
La dérive du périmètre vient rarement de la mauvaise foi. Le client comprend mieux ce qu'il veut à mesure qu'il voit le produit prendre forme, et l'équipe, de bonne volonté, exécute une petite demande sans la signaler. Le problème est qu'aucun de ces ajouts n'est consigné quelque part. Trois mois plus tard, chaque partie a compris un projet différent, et la discussion porte sur qui se souvient de quoi.
Pourquoi la dérive du périmètre se produit-elle ?
La cause la plus courante est un périmètre rédigé de façon floue au départ. Le devis mentionne site vitrine d'entreprise, mais on ne sait pas combien de pages, quelles langues ou quels formulaires sont visés. Une phrase floue permet à chaque partie de l'interpréter en sa faveur.
La deuxième cause tient au fait que de nouvelles idées surgissent au moment où le produit apparaît pour la première fois sous une forme concrète. C'est naturel : dès que le client voit la maquette ou la première démonstration, les lacunes deviennent évidentes. La troisième cause est un décideur mal identifié. Si plusieurs personnes transmettent chacune leurs demandes séparément, chacune étire un peu le périmètre.
Comment rédiger le périmètre pour limiter la dérive ?
Un bon document de périmètre dit non seulement ce qui sera fait, mais aussi ce qui ne le sera pas. Écrire noir sur blanc les travaux exclus évite dès le départ la plupart des litiges ultérieurs. Il faut aussi des formulations mesurables : non pas 'page produit', mais 'modèle de page produit, dix champs produit au plus et une seule langue'.
Le document de périmètre ne doit pas être écrit une fois puis oublié. Il doit être l'unique papier auquel les deux parties se réfèrent pendant tout le projet. Quand le client et l'équipe regardent la même page, la phrase 'Je pensais que c'était inclus' devient bien plus rare.
- Écrivez chaque livrable par son nom et par son nombre.
- Indiquez les travaux hors périmètre sous leur propre intitulé.
- Rédigez les critères d'acceptation : que faut-il voir pour que le travail soit considéré comme terminé ?
- Nommez la personne unique, côté client, qui décide du périmètre.
- Listez les hypothèses : qui fournit les contenus, et pour quand ?
Comment mettre en place une procédure de demande de changement ?
Une demande de changement est une simple fiche qui fait suivre à chaque nouvelle demande le même chemin. La demande est consignée, l'équipe évalue son effet sur le délai et le coût, et si le client l'approuve, elle rejoint le périmètre, sinon elle est reportée à une phase ultérieure. L'essentiel est que le processus ne soit pas lourd. Un formulaire d'une page ou un court échange de courriels suffit.
Cette procédure est la manière douce de dire non. L'équipe ne refuse pas la demande. Elle en montre simplement le prix. Dès que le client voit que chaque demande a sa contrepartie, il se met à fixer des priorités sans qu'on le lui demande.
Tout changement est-il mauvais, et quand faut-il de la souplesse ?
La gestion du changement existe pour garder le changement sous contrôle, non pour l'empêcher. Si le marché, la réglementation ou le comportement des utilisateurs évoluent pendant le projet, modifier le périmètre est la bonne décision. Un périmètre rigide peut revenir à livrer, pile à l'heure, un produit qui ne convient plus à l'entreprise.
La souplesse fonctionne à l'intérieur d'un cadre écrit. Dans certains projets, l'ordre des priorités peut être modifié à budget et à calendrier fixes : si une nouvelle fonctionnalité entre, une fonctionnalité de même taille sort. Cette approche maintient constante la valeur plutôt que le périmètre.
Quelles erreurs sont fréquentes dans la gestion du périmètre ?
L'erreur la plus fréquente consiste à accepter de petites demandes à l'oral. Chacune paraît anodine, mais ensemble elles représentent des semaines. La deuxième est que l'équipe ne garde pas non plus de trace. Une équipe qui ne sait pas quel écran a changé à quelle date et pourquoi n'a aucune donnée en main lorsqu'un désaccord survient.
La troisième erreur est de repousser la discussion sur le périmètre à la fin du projet. Si l'écart n'apparaît qu'à la livraison, chaque partie se sent dans son droit et la relation en souffre. Le périmètre a sa place à l'ordre du jour de chaque réunion, sous la forme d'un court point.
- Travailler sur accord verbal : chaque demande supplémentaire devrait être mise par écrit.
- Ne pas revoir régulièrement le périmètre : un court point toutes les deux semaines suffit.
- Ignorer les retards sur les contenus et les retours : le retard allonge aussi le calendrier.
- Livrer sans critères d'acceptation : le sens de terminé reste flou.
Que faire une fois la dérive du périmètre commencée ?
Lorsque la dérive est remarquée, la première étape consiste à placer ce qui a été fait à côté du périmètre initial. Listez ce qui a été ajouté et ce qui a été déplacé. La liste ne sert pas à accuser quelqu'un. Elle sert à voir le terrain d'entente.
Ensuite, l'une de deux voies est choisie : les ajouts sont formellement intégrés au périmètre et le délai et le coût sont mis à jour, ou bien les ajouts sont reportés à une seconde phase. Il n'y a pas de troisième voie. Les extras avalés en silence abîment la confiance sur le projet suivant.
La dérive du périmètre n'est pas un problème de caractère. C'est un problème de traçabilité. Un périmètre écrit, une liste de ce qui est hors périmètre, un seul décideur et une procédure simple de demande de changement protègent la plupart des projets de cette querelle. Si vous souhaitez clarifier ensemble le périmètre de votre projet avant le début des travaux, vous pouvez organiser un entretien de découverte avec rabbitclip.
Questions fréquentes
Qu'est-ce que la dérive du périmètre ?
C'est lorsqu'un projet dépasse, une fois le travail commencé, ce que décrivait le devis, sans que le délai et le coût soient mis à jour en conséquence. Elle se construit généralement par de petits ajouts qui n'ont jamais été consignés par écrit.
Une demande de changement signifie-t-elle toujours un supplément ?
Pas toujours. Certains changements n'ont aucun effet sur le délai ou le coût, et d'autres sont compensés par le retrait d'un autre morceau de travail. L'essentiel est que l'effet soit rendu visible par écrit.
Le périmètre doit-il figurer dans le contrat ou dans le devis ?
Il doit figurer dans le document que les deux parties signent ou approuvent, ce qui, dans la plupart des projets, est le devis et son annexe de périmètre. Pour le détail juridique, il est judicieux de consulter un juriste.
N'y a-t-il pas de dérive du périmètre dans le travail agile ?
Si. Le travail agile est ouvert au changement, mais pas sans limite. Sans liste de priorités, sans périmètre de sprint fixe et sans cadre de temps et de budget, le travail agile peut lui aussi dériver.
Qui doit gérer le périmètre ?
Chaque partie devrait avoir une personne responsable. Un décideur unique côté client et un chef de projet côté équipe qui garde le périmètre consigné facilitent considérablement le travail.
