La plupart des techniques d’estimation de projet reposent sur l’expérience passée ou le jugement collectif. L’estimation analogique compare le projet à des réalisations antérieures, le Planning Poker mobilise l’intelligence de l’équipe, et l’estimation bottom-up décompose le travail en lots. Toutes ces approches partagent une caractéristique: elles ne sont pas directement reliées aux exigences fonctionnelles du projet. Les Use Case Points (UCP) proposent une logique différente: déduire la taille du projet à partir de la description formelle de ce qu’il doit faire.
D’où viennent les Use Case Points?
Gustav Karner a développé la méthode UCP en 1993 chez Rational Software, dans le prolongement des travaux d’Ivar Jacobson sur les cas d’utilisation. L’idée fondatrice est que les cas d’utilisation (use cases), ces descriptions structurées des interactions entre un système et ses utilisateurs, contiennent suffisamment d’information pour en dériver une mesure de la taille du projet. Plus un système comporte de cas d’utilisation complexes et d’acteurs variés, plus l’effort de développement sera important. La méthode formalise cette intuition en un calcul reproductible.
Les UCP s’inscrivent dans la famille des estimations paramétriques, au même titre que les points de fonction (function points). Le Practice Standard for Project Estimating du PMI définit l’estimation paramétrique comme l’utilisation d’une relation statistique entre des données historiques et d’autres variables pour calculer une estimation. Dans le cas des UCP, les variables sont les cas d’utilisation eux-mêmes, leurs acteurs et un ensemble de facteurs d’ajustement.
La méthode en six étapes
Étape 1: pondérer les cas d’utilisation (UUCW). Chaque cas d’utilisation est classé selon le nombre de transactions qu’il contient. Un cas simple (1 à 3 transactions) vaut 5 points, un cas moyen (4 à 7 transactions) vaut 10 points, un cas complexe (8 transactions ou plus) en vaut 15. La somme donne le poids brut des cas d’utilisation, ou UUCW (Unadjusted Use Case Weight).
Étape 2: pondérer les acteurs (UAW). Chaque acteur qui interagit avec le système est classé selon la nature de son interface. Un acteur système communiquant par API (Application Programming Interface, soit une connexion directe entre deux logiciels) vaut 1 point, un acteur utilisant une interface texte vaut 2 points, et un acteur interagissant via une GUI (Graphical User Interface, soit une interface graphique avec boutons, menus et formulaires) vaut 3 points. La somme donne le UAW (Unadjusted Actor Weight).
Étape 3: calculer les points bruts (UUCP). UUCP = UUCW + UAW. Ce total brut reflète la taille fonctionnelle du système avant tout ajustement.
Étape 4: appliquer le facteur de complexité technique (TCF). Treize facteurs techniques (performance, sécurité, réutilisabilité, portabilité, etc.) sont évalués sur une échelle de 0 à 5. Chaque facteur est multiplié par un poids prédéfini, et la somme est intégrée dans la formule TCF = 0,6 + (0,01 x somme pondérée). Le résultat est un coefficient multiplicateur qui se situe typiquement entre 0,6 et 1,3.
Étape 5: appliquer le facteur environnemental (EF). Huit facteurs liés à l’équipe et au contexte projet (expérience de l’équipe, motivation, stabilité des exigences, familiarité avec la technologie, etc.) sont évalués de la même manière. La formule est EF = 1,4 + (-0,03 x somme pondérée), produisant un coefficient qui oscille entre 0,425 et 1,4.
Étape 6: calculer les UCP et convertir en effort. UCP = UUCP x TCF x EF. Pour traduire ce résultat en heures de travail, on multiplie par un ratio historique, généralement compris entre 15 et 30 heures par UCP selon les données de l’organisation.
Un exemple concret
Prenons un système de gestion de réclamations clients comportant quatre cas d’utilisation: soumettre une réclamation (5 transactions, moyen = 10 pts), consulter l’historique (2 transactions, simple = 5 pts), traiter une réclamation (9 transactions, complexe = 15 pts) et générer un rapport mensuel (3 transactions, simple = 5 pts). Le UUCW est de 35 points.
Trois acteurs interagissent avec le système: le client via un portail web (GUI = 3 pts), l’agent de support via une interface graphique (GUI = 3 pts) et le système comptable via API (système = 1 pt). Le UAW est de 7 points.
UUCP = 35 + 7 = 42 points bruts. En appliquant un TCF de 0,95 (complexité technique modérée) et un EF de 0,88 (équipe expérimentée dans un contexte stable), on obtient UCP = 42 x 0,95 x 0,88 = 35,1 points. Avec un ratio de 20 heures par UCP, l’effort estimé est de 702 heures. Sur la base d’environ 176 heures ouvrées par mois et par personne (22 jours x 8 heures), cela représente environ 4 mois de travail pour une équipe de 4 personnes.
Ce que les UCP exigent en amont
La méthode a un prérequis non négligeable: elle suppose que les cas d’utilisation existent et sont rédigés avec une granularité cohérente. Alistair Cockburn, dans Writing Effective Use Cases, insiste sur le fait que chaque cas d’utilisation doit correspondre à un objectif utilisateur (user goal level), ni trop large (objectif stratégique), ni trop fin (sous-fonction technique). Cette rédaction représente elle-même 10 à 20% de l’effort total du projet, ce qui signifie que les UCP ne sont pas une technique d’estimation rapide.
C’est aussi la raison pour laquelle la méthode est particulièrement adaptée aux projets où les spécifications sont un livrable attendu: appels d’offres publics, contrats à périmètre fixe, projets réglementés. Dans ces contextes, l’effort d’analyse a déjà été consenti, et les UCP valorisent directement ce travail en le transformant en estimation de charge.
Limites à connaître
La sensibilité au style de rédaction est le point faible le plus fréquemment cité. Deux analystes rédigeant les cas d’utilisation du même système peuvent produire des UUCW significativement différents selon leur manière de découper les transactions et les scénarios alternatifs. Les facteurs TCF et EF, évalués sur des échelles subjectives, introduisent une seconde source de variabilité. L’ISBSG (International Software Benchmarking Standards Group) recommande de calibrer les ratios de conversion sur les données historiques de l’organisation plutôt que de se fier aux moyennes publiées, précisément pour atténuer ces biais.
La méthode est également limitée aux projets informatiques comportant des interactions utilisateur-système clairement définies. Un projet d’infrastructure, de migration de données ou de transformation organisationnelle ne se prête pas au calcul d’UCP, faute de cas d’utilisation au sens strict du terme.