Philo SI

En société de service informatique (SSII) il y a deux modes de prestation. La régie ou assistance technique est simplement de la délégation de personnel. L'engagement au forfait quand à lui est donné sur un résultat, il repose sur l'ancrage selon 3 composantes: un périmètre, une date et un budget. La pratique agile n'est pas compatible avec ce triptyque, on ne sait pas s'engager sur tout ça à la fois.

Lorsque la réalisation d'un projet est confiée à une société extérieure, les engagements sont contractuellement forts et marqués par des pénalités de retard. Celui qui passe le contrat veut s'assurer qu'il aura bien son produit comme prévu, celui qui réalise veut s'assurer qu'il ne dépensera pas plus que prévu pour le réaliser.


Avant de réfléchir à la façon de contractualiser pour une réalisation en mode agile, il est intéressant d'observer comment les choses se passent en forfait traditionnel.

Avant la signature du contrat, des choses ce sont passées. Le métier a travaillé pour murir et définir ses besoins d'une part, il y a eu appel d'offre et mise en concurrence de prestataires potentiels d'autre part.
Dans le cas des projets informatiques portant sur de la prestation intellectuelle il n'y a (souvent) pas de coût matériel et finalement tout se résume à un nombre de jours de travail et a des coûts de main d'oeuvre.
Le contractant a souvent fait le choix d'un partenaire parmi les moins chers il a nécessairement un doute (d'autres avaient pu estimer le travail de façon plus réaliste, avoir des équipes plus qualifiées ?).
Le prestataire a du baisser ses prix, peut-être réduire les temps estimés, il a nécessairement un doute (est on capable de tenir le budget ?).

Ces doutes vont se traduire par une surveillance réciproque tout au long du projet. L'un va chercher à tracer les gains que l'autre est soupçonné de vouloir faire en baissant le temps passé et la qualité de la prestation. L'autre va tracer tout ce qui peut ressembler à une augmentation de périmètre pour justifier de prestations hors budget initial.
Tout cela est fait à petite dose au cours des divers comités de suivi et servira au moment du round final si le projet ne s'est pas déroulé pas comme prévu. Les 2 mâles alpha, représentants du contractant et du prestataire, s'affronteront alors pour justifier qu'ils n'ont pas tout à fait perdu (les équipes auront entre temps été pressées de "fournir les billes").

On a donc de part et d'autre des pratiques assez classiques dans le monde de la production en général. C'est un peu la loi du marché.

On a pas parlé du logiciel jusqu'ici. Fondamentalement il n'est pas essentiel dans ce jeu. Coté contractant, on fait tourner une entreprise qui produit, doit rester concurrentielle et baisser ses prix. On a donc des acheteurs dont le travail est d'obtenir des prestations à coût moindre.
Coté prestataire, on fait tourner une entreprise qui produit de la prestation intellectuelle et doit dégager une marge maximale. On a donc des vendeurs qui doivent rentrer des affaires. L'acheteur ne s'intéresse pas vraiment à ce que fait ce logiciel, le commercial non plus.

Les acteurs intéressés par le logiciel existent mais ils n'ont pas en général la capacité à mettre en avant sa valeur. Les utilisateurs ont souvent la réputation de vouloir des choses inutiles et les chefs de projets et développeurs de faire de la "sur qualité".

Les méthodes agiles reposent sur ces acteurs intéressées par la valeur. Scrum donne les moyens aux équipes de la produire rapidement et au métier de piloter sa création.
La contractualisation au forfait classique n'est pas seulement inadaptée aux méthodes agiles, elle ne donne pas la main aux acteurs qui ont un intérêt dans la finalité du projet mais seulement à ceux qui ont un intérêt dans une équation commerciale.