Français
Phone: + 33 (0) 9 80 89 99 65 - Email: contact@estimancy.com
Site logo
Sticky header logo
Mobile logo
Français
  • Solutions
    • Gestion de la sous-traitance applicative
    • Estimation des charges des projets logiciels
    • Tagger, gestion des exigences
  • Services
    • Mesure et Estimation de projets logiciels à la demande
    • Contre-chiffrer les projets logiciels à la demande
  • Formations
    • Cours gratuit : introduction à la mesure et à l’estimation de projets logiciels
    • La mesure logicielle COSMIC
    • La mesure logicielle avec IFPUG – Parcours avancé
    • Formation : La méthode de mesure logicielle SiFP
    • Les bases de l’estimation des projets logiciels avec IFPUG
  • Ressources
    • Blog
    • Webinaires
    • Vidéos
    • FAQ
  • À propos
    • Recrutement
  • Contact
  • Webdemo
  • Blog

Quel abaque contractuel choisir pour la sous-traitance applicative ?

Abaque contractuel

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é.

Pour en savoir plus sur les bonnes pratiques de la construction d'abaques contractuels, prenez rendez-vous avec l'un de nos consultants.

Nous contacter
  • Projet logiciel
  • Sourcing IT
  • sous-traitance

Related posts

Blog Livre blanc : le contre-chiffrage des projets logiciels
16 septembre 2020in Blog 0 Comments 0 Likes

Livre blanc : le contre-chiffrage des projets logiciels

Blog Webinaire : l’offre d’Estimancy pour le contre-chiffrage des projets logiciels
3 septembre 2020in Blog 0 Comments 0 Likes

Webinaire : l’offre d’Estimancy pour le contre-chiffrage des projets logiciels

Blog Webinaire : Quelle organisation pour contrôler les prix des fournisseurs de projets applicatifs ?
3 septembre 2020in Blog 0 Comments 0 Likes

Webinaire : Quelle organisation pour contrôler les prix des fournisseurs de projets applicatifs ?

Blog Webinaire : Quelles connaissances faut-il avoir pour contre-chiffrer un projet logiciel ?
2 septembre 2020in Blog 0 Comments 0 Likes

Webinaire : Quelles connaissances faut-il avoir pour contre-chiffrer un projet logiciel ?

Blog Webinaire : les bases du contre-chiffrage de projets logiciels
2 septembre 2020in Blog 0 Comments 0 Likes

Webinaire : les bases du contre-chiffrage de projets logiciels

Blog Webinaire : Comment réaliser un contre-chiffrage sur un projet logiciel
19 mai 2020in Blog 0 Comments 0 Likes

Webinaire : Comment réaliser un contre-chiffrage sur un projet logiciel

Blog Webinaire : Les fondamentaux de l’estimation des charges de projets logiciels
30 avril 2020in Blog 0 Comments 0 Likes

Webinaire : Les fondamentaux de l’estimation des charges de projets logiciels

Blog Webinaire : Comment calculer la productivité des projets logiciels
20 avril 2020in Blog 0 Comments 0 Likes

Webinaire : Comment calculer la productivité des projets logiciels

Blog Abaque contractuel
26 février 2020in Blog 0 Comments 0 Likes

Webinaire : Abaque contractuel et sous-traitance applicative

Blog Estimation des projets logiciels
5 février 2020in Blog 0 Comments 0 Likes

Estimation des projets logiciels : 20 jours pour mettre en place un processus d’entreprise

Blog Livre Blanc : Quelle méthode choisir pour mesurer la taille d’un logiciel ?
24 janvier 2020in Blog 0 Comments 0 Likes

Livre Blanc : Quelle méthode choisir pour mesurer la taille d’un logiciel ?

Blog Webinaire : Estimer les charges des projets logiciels avec l'IA
8 janvier 2020in Blog 0 Comments 0 Likes

Webinaire : Estimer les charges des projets logiciels avec l’IA

Blog Valeur d'un projet
8 janvier 2020in Blog 0 Comments 0 Likes

Comment définir la valeur d’un projet logiciel ? – Livre Blanc

Blog Le processus d'estimation des projets logiciels
18 décembre 2019in Blog 0 Comments 0 Likes

Livre blanc : le processus d’estimation d’un projet logiciel

Blog Webinaire : les équations de l'estimation des projets de développements informatiques
31 mai 2019in Blog 0 Comments 0 Likes

Les équations de l’estimation des projets de développements logiciels

Blog Estimancy participe à la journée française des mesures informatiques organisée par l’ASSEMI
30 avril 2019in Blog 0 Comments 0 Likes

Estimancy participe à la journée française des mesures informatiques organisée par l’ASSEMI

Blog turnover des équipes
5 mars 2019in Blog 0 Comments 0 Likes

Projet logiciel : quel est l’impact du turn over des équipes sur les coûts ?

Webinaire Points de fonction complexité moyenne
14 novembre 2018in Webinaire 0 Comments 0 Likes

Webinaire : estimation des projets logiciels avec les Points de Fonction complexité moyenne

Blog Livre blanc : Comment simplifier l'externalisation des projets logiciels avec les Points de Fonction
12 novembre 2018in Blog 0 Comments 0 Likes

Comment simplifier l’externalisation des projets IT avec les Points de Fonction ? – Livre Blanc

Blog illustration de la mesure de la taille du projet logiciel en points de fonction
10 octobre 2018in Blog 0 Comments 0 Likes

Les 7 étapes de la mesure de la taille logicielle en Points de Fonction

Blog Story Points
7 août 2017in Blog 0 Comments 3 Likes

Story Points vs Points de Fonctions, lesquels choisir ?

Contre-chiffrage COSMIC Estimation Exigences fonctionnelles IFPUG Mesure logicielle Points de Fonction Projet logiciel Software Sizing sous-traitance

Categories

  • Blog
  • Événements
  • Livres blancs
  • Webinaire

Estimancy est un éditeur de logiciel spécialisé dans le calcul et le contrôle automatique des coûts des projets logiciels.

  • enAnglais
  • frFrançais

Estimancy

Gestion de la sous-traitance de projets logiciels

Estimation des coûts et délais des projets logiciels

Mentions légales

La société

À propos

Blog

Webinaires

Recrutement

 

Contact

Estimancy

contact@estimancy.com

Cookies

Ce site utilise des cookies : En savoir plus.