Pour mémoire, il convient de rappeler que l’approche agile est basée sur des pratiques itératives et collaboratives, dont les quatre 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.
Discussions en cours :
Bonjour,
J’accompagne l’organisation du travail de petits et grands groupes depuis quelques années avec notamment la culture agile. Je suis toujours surpris de voir à quel point ce domaine est régulièrement malmené. Je ne me permets personnellement pas de critiquer des domaines que je ne maîtrise pas, et j’aimerais assez qu’on fasse de même avec l’agilité. L’agilité possède ses outils, sa littérature et sa communauté. Au lieu de lancer des anathèmes, merci de bien vouloir vous documenter.
étant côté client, je me retrouve tout à fait dans les dangers évoqués dans cet article ... bien réels dans mon expérience, dans certains cas ayant été jusqu’à la rupture de contrat en cours de prestation.
On pourra citer comme effet pervers la tendance de certains prestas à sous chiffrer leurs propositions commerciales et à s’imaginer que tout se règle sous forme d’avenant .. ou leur incompétence en méthode agile, bien masquée dans leurs réponses, ..
je n’ose imaginer que les critiques si bien intentionnées soient côté prestataires ...
ceci dit, les liens mentionnés dans une des réactions sont aussi tout à fait intéressants..
Cher Maitre,
Que vous ne soyez pas convaincu par l’adéquation du mode forfait avec une approche Agile, soit.
Que vous estimiez le risque trop important et que vous appeliez vos clients à la prudence, je serai bien évidemment d’accord avec vous.
Mais de grâce, épargnez nous vos affirmations excessives, vos nombreuses approximations et surtout, votre ironie mal placée. Vous ne citez aucune source sérieuse pour étayer votre discours. C’est dommage.
Apprenez que l’Agilité peut se révéler être la base d’un modèle Gagnant-Gagnant même si cela peut vous surprendre (particulièrement en mode forfait). Non, tous les contrats ne donnent pas lieu à une foire d’empoigne même si un grand nombre le sont encore, j’en conviens.
Cela fait maintenant plus de quinze ans que j’exerce mon métier dans ce domaine en tant que Directeur de projet et Coach . Je constate à mon humble niveau qu’une relation de confiance a toujours été un gage de réussite avec mes Clients. Mais la confiance ne se décrète pas, elle se bâtit. Elle s’appuie, entre autres, sur la transparence et la sécurité. Au Fournisseur de faire ce qu’il faut pour cela en montrant l’exemple. Au Client de vouloir progresser avec son Fournisseur. En s’appuyant sur un contrat Agile en mode forfait, bien sûr ;-)
Bonne continuation
C’est marrant, mais à l’inverse des autres commentaires, je suis assez d’accord avec l’argumentaire. L’agile est totalement incompatible avec le forfait (en tout cas avec les contrats types en France).
Bon, ceci-dit, je suis totalement en désaccord avec la conclusion, puisqu’elle est basée sur le fait que le forfait est sacro-saint, alors que je pense que c’est justement le problème. On continue de faire croire qu’en informatique, l’industrie qui évolue le plus vite au monde, il est encore possible de ne pas pouvoir "renoncer au triptyque périmètre, délai, budget." Tryptique totalement aberrant, puisqu’établi au moment où on a le plus d’incertitude et de risque... (cône d’incertitude, tout ça...)
Bref, je raconte pas les dégâts quand on passe en TMA (je le sais, c’était mon boulot ces 6 dernières années d’expliquer aux gens comment ils peuvent faire pour rattraper le coup dans ces situations... un peu...)
Donc comment fait-on ? Ben c’est simple. Plus de forfait. Donc de l’embauche interne, ou de la régie, et on avance en Agile. Et là évidemment, tous les arguments énoncés sont balayés. On maitrise son projet, le niveau de qualité, etc. Royal. C’est ce que je fais maintenant que je suis passé de l’autre côté.
Sinon juste une remarque, je suis étonné, surtout de la part d’un avocat, d’évoquer les difficultés réelles d’une relation "de confiance" quand elle est d’abord établie par contrat (et donc par défiance), sans évoquer que des solutions juridiques ont déjà été éprouvées à l’étranger, comme par exemple le 50/50. Le principe : "ya un problème ? un retard ? OK, le contrat indique que les torts sont partagés. Ca c’est réglé, comment on avance maintenant ?". Et ça change tout. Plus d’avocat (ah mince ! désolé !... :) Car du coup, qui serait tenté de faire échouer/retarder le projet sachant qu’il a autant de tort que l’autre partie ?
Bon sur ce, bonne nuit !
Bonjour,
Merci pour votre commentaire, à la fois teinté d’humour et de bon sens.
Il me semble que nous nous rejoignons sur l’essentiel : c’est aller contre nature que de faire cohabiter forfait et méthodes agiles ...
Après, c’est un challenge amusant que de ne pas faire un chèque en blanc à son prestataire ...
Bonne journée !
Aux approximations de cet article, rédigé par quelqu’un qui n’a manifestement qu’une connaissance superficielle des Méthodes Agiles, et qui fait preuve d’une paresse intellectuelle coupable alors que les projets Agiles se multiplient et que les juristes doivent s’en saisir, on préférera la lecture d’articles nettement plus informés et proactifs :
Enfin une critique argumentée et de bonnes adresses que nous livre un rigoureux juriste, modeste au point de rester anonyme.
Chapeau bas et merci !!!
L’ironie ne changera rien à votre approche superficielle, mais je salue le fair-play qui vous fait reconnaître que les articles en lien dans mon premier message sont nettement plus rigoureux et équilibrés que le vôtre... Salutations.