De nombreuses entreprises font le choix d’externaliser le développement de leurs projets logiciels pour diverses raisons. L’outsourcing applicatif présente de nombreux avantages, comme la disponibilité des ressources ou la réduction des coûts, mais a un gros inconvénient : la perte d’une partie du contrôle sur les projets en cours, aussi bien au niveau du déroulement du projet, des délais, mais surtout du prix. Il existe pourtant des méthodes permettant aux entreprises de suivre et de contrôler les travaux de ses sous-traitants.

Facturation au temps vs facturation au volume

Très souvent les contrats de sous-traitance liant les entreprises aux SSII sont établis à partir d’unités d’œuvre basées sur le temps passé et non sur le volume de logiciel livré.

Par analogie, c’est comme si l’essence à la pompe était facturée en fonction du temps que le pompiste met à faire le plein, au lieu la quantité versée. La facturation au volume, qui parait pourtant évidente dans beaucoup de domaine, ne l’est pas encore dans le domaine du développement logiciel. Pourtant il est assez facile d’établir des contrats de sous-traitance reposant sur des unités forfaitaires et cela présente de nombreux avantages. Il suffit d’utiliser la mesure de la taille du logiciel, et ainsi d’associer un prix à un volume livré.

La mesure logicielle

La mesure logicielle consiste à mesurer la quantité de fonctionnalités livrées dans un logiciel. L’unité de mesure utilisée est le Point de Fonction. C’est une mesure ISO équivalente au litre de l’exemple de l’essence ou au m² dans le secteur du bâtiment.

Comment contrôler les fournisseurs à l’aide de la mesure logicielle ?

Les entreprises externalisant leurs développements logiciels cherchent à suivre et contrôler les devis de leurs fournisseurs. Dans ce cadre, deux questions reviennent souvent :

Le prix facturé par mon sous-traitant est-il stable dans le temps ?

Pour s’assurer de la stabilité des prix de mon fournisseur, il suffit de procéder par échantillonnage, et d’évaluer le coût par Point de Fonction sur un ensemble de demandes. Un « cotateur Point de Fonction » va mesurer la taille de ces demandes, par exemple 1200 PF. Si on additionne les coûts de ces demandes, par exemples 240 k€, on peut en déduire que le coût par PF est de 200 €. En répétant ce processus de temps en temps, on s’assure que le prix reste stable.

Le deuxième intérêt de cette procédure est de pouvoir contractualiser ensuite avec un prix par PF.

En effet, il arrive que des fournisseurs cassent les prix sur un Appel d’offres pour obtenir un marché à prix forfaitaire, car ils savent qu’il y aura des avenants sur lesquels ils vont pouvoir se rattraper.

En négociant à l’avance le prix du Point de Fonction, vous vous protégez contre ce genre d’avenants abusifs.

La quantité de logiciel livrée par « sprint » (projet agile) est-elle stable dans le temps ?

Dans ce cas, il faut être vigilant afin de ne pas opposer l’agilité à la mesure de la performance.

Les projets agiles utilisent généralement une mesure en Story Point, au cours de séances de Planning Poker, afin d’évaluer la quantité de travail à produire au cours d’un sprint. La valeur du Story Point est une valeur spécifique à l’équipe, et elle peut évoluer dans le temps. Dans ces conditions, comment contrôler la performance ?

Une approche consiste à mesurer la taille des sprints et à la rapprocher du coût et de l’effort dépensé sur le sprint. Par exemple, sur un sprint de 6 semaines, 450 PF ont été livrés avec 5 personnes. Cela représente un effort de 150 jours.hommes, nous avons donc une productivité de 450/150 = 3 PF par jour et par personne. Nous pouvons faire un calcul analogue pour connaitre le coût par PF.

Pour conclure

Que ce soit dans le monde agile ou non, il est possible de garder le contrôle sur les développements de logiciels sous-traités. Avec la méthode évoquée ci-dessus, vous pouvez vous assurer que les prix ou la productivité sont stables dans le temps. Rappelons néanmoins qu’il est utile d’associer ces indicateurs à d’autres comme la qualité. En effet si la productivité se maintient mais que la qualité décroit, cela revient à une perte de productivité.