Lorsqu’une entreprise s’engage dans l’externalisation des développements et de la maintenance applicative, il est nécessaire de s’appuyer sur un abaque contractuel qui va permettre de calculer les prix des travaux sous-traités.

Dans cet article nous allons répondre aux questions suivantes :

• Quelles sont les caractéristiques d’un abaque efficace ?
• Quels sont les pièges à éviter ?

 

Quelles sont les caractéristiques d’un abaque contractuel efficace ?

Être en corrélation avec l’effort 

C’est la première des caractéristiques nécessaires. Si l’abaque ne corrèle pas avec l’effort, comment déduire le coût de chaque composant ? La preuve de la corrélation avec l’effort doit être apportée. C’est évidemment le cas des abaques normalisés (IFPUG, COSMIC, etc.), mais ce n’est pas toujours le cas des abaques fournisseurs ou des donneurs d’ordre. Les abaques maisons sont souvent construits à dire d’expert, et les mauvaises corrélations sont courantes.

Si l’abaque donne un effort absurde pour un travail à réaliser, c’est soit le fournisseur, soit le client qui sera perdant. Et cela peut entrainer des tensions dans la relation.

Être fonctionnel plutôt que technique

Une entreprise qui externalise les développements et la maintenance applicative rencontre nécessairement une perte des compétences en développement. Dans ces conditions, comment peut-on être en mesure de discuter les devis du fournisseur si les composants de l’abaque sont des composants techniques, c’est-à-dire, proches du développement logiciel.

Par ailleurs, si le composant est trop technique, il pourrait être tentant pour le fournisseur de livrer davantage de composants techniques que nécessaire. Par exemple, si l’abaque s’appuie sur le nombre de lignes de code livrées, le fournisseur pourra être tenté de faire plus de lignes de code.

Il vaut mieux s’appuyer sur un abaque fonctionnel consistant à évaluer la taille fonctionnelle de la demande de l’utilisateur, indépendamment des aspects programmation. Par exemple on parlera d’entrée, de sortie, de rapport, etc., auxquels on appliquera éventuellement des niveaux de complexité.

Être simple et documenté

Le nombre de composants devra être réduit. Plus il y a de composants, plus il sera difficile de comprendre l’abaque, de l’apprendre, de contrôler les devis. Tous les cas ayant entrainé des discussions devront enrichir la documentation de l’abaque. La multiplication des composants est à proscrire.

Être normalisé

L’idéal est de choisir un abaque normalisé s’appuyant sur la notion de Points de Fonction. Il existe plusieurs abaques comme IFPUG (International Function Point User Group), COSMIC (COmmon Software Measurement International Consortium), SiFP (Simple Function Point), NESMA, etc. Le travail de définition est déjà fait, les anomalies ont été corrigées par les utilisateurs, il n’y a plus qu’à l’utiliser.

Ces abaques normalisés présentent plusieurs intérêts. Ils ont été validés par de nombreuses instances, en plus d’être utilisés internationalement, d’être documentés en plusieurs langues, d’avoir des experts indépendants disponibles, d’avoir des données de benchmarking, et d’être fortement corrélés à l’effort.

Être formel

La qualité d’un abaque repose sur le fait qu’il soit formel, c’est-à-dire, non ambigu. S’il y a des ambiguïtés non levées entre les composants ou les cas d’application, cela va aboutir à des discussions interminables entre le client et son fournisseur. Le coût du devis et de son contrôle deviendront trop importants. Les risques de détérioration de la relation seront élevés.

Disposer d’un tiers indépendant pour les arbitrages

Quand un cas n’est pas clair, il faut pouvoir s’appuyer sur une personne extérieure, indépendante, et dont la compétence est avérée. La difficulté étant de trouver un indépendant disponible. On peut pour cela commencer par poser des questions dans un forum regroupant plusieurs experts.

Être automatisable (si possible)

Si la mesure peut être automatisée, le contrôle et les discussions sont évités grâce à un mécanisme indépendant. C’est la solution idéale, mais l’automatisation n’est possible que dans certains cas, et uniquement si les documents entrants sont de bonne qualité.

Quels sont les pièges à éviter ?

L’abaque « maison » vs l’abaque normalisé

Si vous prenez un abaque de l’une ou l’autre des parties prenantes, alors vous créer un déséquilibre dans la relation, car celui qui connait mieux l’abaque est mieux armé pour négocier. Pour contrebalancer cela, l’autre partie prenante devra nommer un expert chargé d’acquérir la compétence.

Si un abaque est proposé, il est important de bien vérifier qu’il est en corrélation avec l’effort.

L’abaque contractuel trop technique

Si l’abaque est trop technique, c’est-à-dire, trop proche du développement du logiciel, le risque est double :

• Le client perd petit à petit l’expertise en matière de développement de logiciel, et devra discuter technique avec des personnes dont c’est le métier. Il y a forcément un décalage de compétence en faveur du fournisseur.
• Le contrôle des devis est plus compliqué, et le client aura du mal à discuter les devis.

La granularité

S’il y a quelque chose qui doit être clair, c’est la granularité de détection des composants. Autrement dit, quel est le processus élémentaire au niveau duquel on dénombre les composants de l’abaque ? Si cette granularité est mal définie, il peut y avoir un risque de fractalisation, autrement dit, de décomposition abusive du processus élémentaire en sous-processus faisant apparaître une multitude de composants de l’abaque, et ainsi une explosion du coût du travail.

La traçabilité

Il faut que les devis soient autoporteurs, c’est-à-dire, que l’extrait de la demande de l’utilisateur qui justifie la détection d’un ou plusieurs composants de l’abaque apparaisse dans le devis. L’extrait doit être référencé dans le document (page, paragraphe).

C’est à cette condition qu’on peut éventuellement simplifier le contrôle des devis, voire de l’automatiser.

Clause de gain de productivité

Lorsque le contrat de sous-traitance s’étale sur plusieurs années, le sous-traitant doit prendre connaissance du contexte et des applications la première année, puis être plus efficace les années suivantes. C’est pour cela qu’apparaissent des clauses de gain de productivité dans les contrats.

Attention, il ne faut pas confondre gain de productivité (produire plus pour le même prix, ou produire la même quantité pour moins cher) et remise commerciale. En effet, vous pouvez bénéficier d’une remise commerciale de 10 %, mais si la productivité a baissé de 10 % parce qu’on a remplacé les développeurs confirmés par des débutants, alors vous n’avez rien gagné du tout, au contraire, vous allez perdre sur les délais de réalisation voire la qualité.

A contrario, vous ne pouvez pas augmenter la productivité de 10 % en prenant des débutants.

Il est donc important de bien négocier une clause de gain de productivité basée sur le volume, et non pas une remise commerciale sans gain de productivité.

La qualité d’un abaque contractuel va conditionner la nature de la relation. Si l’abaque est de mauvaise qualité, la relation s’en trouvera détériorée.

Le dénombrement de composants peut être une opération difficile, surtout si les exigences sont imprécises, voire changeantes. En évitant les pièges décrits ci-dessus, le contrat d’outsourcing aura plus de chances d’être solide, durable, et apaisé.