Méthodes agiles : contrats fragiles !

Les méthodes agiles sont souvent présentées comme une panacée permettant d'échapper aux lourdeurs des phases de spécifications. N'en déplaise aux habiles commerciaux des SSII, les méthodes agiles induisent toujours d'importants risques supportés par les clients.

Pour mémoire, il convient de rappeler que l'approche agile est basée sur des pratiques itératives et collaboratives, dont les 4 valeurs fondamentales sont :

- les individus et leurs interactions plus que les processus et les outils

- les logiciels opérationnels plus qu’une documentation exhaustive
- la collaboration avec les clients plus que la négociation contractuelle
- l’adaptation au changement plus que le suivi d’un plan.

Pour autant, méthodes agiles ou pas, aucune entreprise ne peut renoncer au triptyque périmètre, délai, budget.

De sorte que, en présence d’une méthode agile, tout projet d’importance sera le théâtre d’une âpre lutte contractuelle entre la SSII et son client. Il n’y a ni vainqueur ni vaincu à ce stade. Un contrat finit toujours par être signé … d’autant plus que le prêt à porter contractuel est aujourd’hui abondant.

Traditionnellement, les méthodes agiles découpent le projet en itérations, ou « sprints », tandis que le « backlog » comptabilise ce qu’il reste à faire pour respecter le périmètre fonctionnel initialement convenu.

Et c’est là le premier germe de la discorde : la valeur d’une itération repose-t-elle sur la quantité de  travail fournie par la SSII ou s’apprécie-t-elle au regard de la progression vers l’atteinte du périmètre fonctionnel visé par le client ?

Bien entendu, la SSII demandera à être payée pour le travail accompli, c’est à dire en régie, plus ou moins bien dissimulée derrière « points de complexité », « vélocité » ou autres termes pompeux …

Face à cette demande, le client aura bien du mal à mesurer le bénéfice qu’il tire de l’itération et à la caractériser en termes de résultats, d’autant que - conformément au dogme de l'agilité -  il a accordé peu de temps aux spécifications, surtout s’agissant des livrables des itérations.

Le second germe de la discorde apparaît généralement au même stade : la collaboration et l’interaction entre les équipes étant au cœur des méthodes agiles, la SSII comme le client pourront s’incriminer  mutuellement en cas de retards, de difficultés de recettes, de manquements aux obligations de compétence, d’alerte …

Le client aura bien du mal à se prévaloir des obligations de résultats mises à la charge de la SSII. Chacun sait que l'immixtion du maître d'ouvrage permet à la SSII de s'exonérer de sa responsabilité. 

Moteur même de la démarche agile, l'interaction SSII-client sape ainsi directement les bases de la responsabilité du prestataire en matière d'obligations de résultats. Pire, le client peut se voir demander réparation du préjudice que la SSII pourrait prétendre supporter : équipes mobilisées pour ne faire qu'attendre ou se substituant aux carences du client, ...

Ultérieurement, en présence d’un litige, plusieurs questions additionnelles se poseront : résiliation ou résolution du contrat, jouissance des droits de propriété intellectuelle afférents aux programmes et/ou aux spécifications, réutilisabilité opérationnelle des livrables …

En définitive, il semble raisonnable de retenir que, en présence de méthodes agiles, le cadre contractuel SSII-client est particulièrement délicat. Il s’avère bien souvent un leurre, sauf à se satisfaire de l’achat en régie de prestations qu’il conviendra de piloter de très près - tout en sachant parfaitement où l’on souhaite arriver.

Ainsi, Sénèque a encore et toujours raison : « il n’est point de vent favorable pour qui ne sait pas où se trouve son port ». Les méthodes agiles nous le rappellent parfois cruellement. 

Michel PASOTTI - Paris, le 17 juin 2013