Accueil Management Stratégies et Organisations

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.
Voici pourquoi.

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.

Michel PASOTTI - Avocat au Barreau de Paris

Recommandez-vous cet article ?

Donnez une note de 1 à 5 à cet article : L’avez-vous apprécié ?

80 votes

Vos commentaires

Commenter cet article
  • Le 3 août 2015 à 18:05 , par un client de prestations informatiques

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

  • Le 17 juin 2014 à 09:25 , par Thierry Cavrel
    Chacun son point de vue ... ;-)

    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

  • Dernière réponse : 8 mai 2014 à 19:27
    Le 8 mai 2014 à 02:09 , par Jérôme Avoustin

    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 !

    • Le 8 mai 2014 à 19:27 , par Michel PASOTTI
      Bien vu : l’agile est - par nature - incompatible avec le forfait !!!

      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 !

  • Dernière réponse : 15 août 2013 à 20:09
    Le 6 août 2013 à 11:48 , par Lawyer01
    Méthodes agiles : contrats fragiles !

    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 :

    • Le 13 août 2013 à 17:22 , par Michel PASOTTI
      Méthodes agiles : contrats fragiles !

      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 !!!

    • Le 15 août 2013 à 20:09 , par Lawyer01
      Méthodes agiles : contrats fragiles !

      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.

  • Dernière réponse : 18 juillet 2013 à 10:44
    Le 14 juillet 2013 à 10:05 , par etienne
    Méthodes agiles : contrats fragiles !

    Le parfait article scandale, basé manifestement sur un seul cas non représentatif.

    Ecrire « 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. »
    c’est d’une part ne pas s’être documenté sur les méthodes agiles convenablement, pourtant la littérature de qualité ne manque pas
    d’autre part insinuer que le forfait n’est pas le théâtre d’une âpre lutte contractuelle, ce qui doit faire marrer tous ceux, clients et prestataires, qui le pratiquent.

    Je peux vous présenter des entreprises qui ont renoncé à ce fameux triptyque avec plaisir pour travailler dans un objectif de "qualité", un mot pas une seule fois cité dans votre article, et qui est pourtant à la base des méthodes agiles.

    Il est évident que dans les milieux SS2I le terme "agile" est déjà galvaudé. L’affaire qui vous a menée à écrire cet article est probablement un mauvais exemple de cette pratique, le mot "agile" aura servi d’argument marketing pour mieux déplumer le client.

    En revanche, je peux vous assurer que des centaines d’entreprises, dont la mienne, pratique l’agilité avec conviction et je ne vois vraiment pas comment un client pourrait s’en plaindre, n’en tirant que des avantages immédiats et de valeurs.

    Le problème de votre article est qu’il stigmatise la pratique plutôt que les gens qui usurpent son nom. En ce sens, il est mauvais. Il aurait été plus intéressant de savoir comment protéger son contrat agile par exemple. Mais c’est sur que cette pratique limite les litiges, donc l’intervention des avocats...

    • Le 15 juillet 2013 à 16:41 , par Michel PASOTTI
      Méthodes agiles : contrats fragiles !

      Bonjour,

      Je vous remercie pour votre commentaire.

      Bien que “mauvais”, il nous permet d’apprendre que votre entreprise pratique l’agilité avec “conviction”.

      Nous nous en réjouissons.

      Cordialement.

      Michel PASOTTI

    • Le 15 juillet 2013 à 17:58 , par etienne
      Méthodes agiles : contrats fragiles !

      (...)
      Notons toutefois, pour les gens qui ignorent ce qu’est l’agilité (...), que le client est livré de l’avancement de son produit à intervalles réguliers (entre 1 et 4 semaines généralement) et qu’il peut arrêter la prestation à tout moment.
      Un client mécontent peut donc arrêter très vite la collaboration au moindre doute sur des faits concrets sans faire appel à un avocat. Et oui la confiance est à double sens.
      Il a également le devoir d’être impliqué dans son projet et de tester ces fameuses livraisons, de manière à ne pas pouvoir dire 6 mois après qu’il s’est fait arnaquer.

    • Le 16 juillet 2013 à 11:34 , par Michel PASOTTI
      Méthodes agiles : contrats fragiles !

      Bonjour,

      Merci pour votre intérêt.

      Il me semble que votre réponse met en exergue l’une des difficultés propres aux méthodes agiles.

      Exemple : un projet de 990 jours et 11 itérations (ou sprints ...).

      Un client peut s’avérer très satisfait suite aux recettes des itérations 1 à 4. (So far, so good ... dixit Arlequin tandis qu’il chutait avant de percuter le sol).

      Le client paie donc régulièrement son fournisseur.

      Arrivé à l’itération 8, le client considère (à tort ou à raison - la confiance est rompue) qu’il n’obtiendra pas le résultats final qu’il escomptait à la fin de l’itération 11, donc du projet.

      Les difficultés commencent ...

      Je présume que vous n’aurez pas de difficulté à les concevoir.

      Cordialement.

      Michel PASOTTI

      PS : l’exemple fait référence à un projet de 990 jours ... taille assez moyenne ... il est bien évident que les risques augmentent plus que proportionnellement avec la taille du projet ... ce qui soulève la question du domaine d’éligibilité des méthodes agiles ... VRAI sujet par ailleurs ...

    • Le 16 juillet 2013 à 12:56 , par etienne
      Méthodes agiles : contrats fragiles !

      Bonjour

      Effectivement la durée du projet impacte la visibilité finale.Cependant, 990 jours (/homme je suppose) c’est plutôt un gros projet !!! Quand bien même, les plus grandes entreprises passent à l’agile (AIR FRANCE, EADS, CNRS source EKITO). D’ailleurs l’agilité les aide à passer au lean ou autres méthodes de développements produits rapides. (au passage : http://www.journaldunet.com/management/expert/50957/quand-l-agilite-fait-son-retour-dans-le-discours-des-entreprises-francaises.shtml).
      Il s’agit d’optimiser son organisation, l’intelligence collective et la façon d’arriver à un résultat sans avoir tous les besoins au démarrage, et justement pas de respecter un délai ou un prix. La durée du projet est certainement un facteur prédominant car sur la durée les besoins évolueront et le forfait empêchera toute évolution avec son effet tunnel, ou nécessitera une paperasse abondante et contre-productive.

      Et justement, en agile on ne s’engage pas sur un délai ou un prix, preuve que dans votre dossier le prestataire n’a d’agile que l’étiquette commerciale, ou que le client n’a pas compris ce que proposait son prestataire.
      Si le client pense ne pas atteindre l’objectif qu’il s’est donné au départ, il a néanmoins pu tester régulièrement son produit et modifier son besoin tant qu’il a voulu pour arriver plus vite à la qualité souhaitée qu’il aurait été incapable de spécifier en avant-projet.
      Si vous donnez au client toute liberté pour changer les fonctionnalités à tout moment, il doit aussi admettre que tout changement impactera le délai et le prix par rapport à l’estimation initiale.
      Il ne peut pas donc à la fois jouir d’un contrôle permanent sur son développement et maintenir un cap délai / prix immuable, ou malgré tous les changements et ajouts qu’il aura demandé, avoir au même prix toutes les fonctionnalités prévues initialement. Effectivement, pour le client qui émet des besoins fonctionnels sans en connaître de suite les impacts en terme de développement, il a parfois du mal à accepter qu’une chose toute simple soit en fait complexe à coder, et la confiance peut se perdre. Mais le prestataire doit être en mesure de prouver et expliquer sur quoi il a passé du temps, les imprévus, etc...

      Je ne dirais pas que c’est une difficulté propres aux méthodes agiles. Il s’agit plutôt que le client comprenne bien ces méthodes littéralement différentes du forfait et que le prestataire soit vraiment agile.
      Alors, dans une relation de confiance mutuelle qui est à la base de la collaboration, les résultats seront décuplés par rapport au forfait, y compris sur les délais et les coûts. Et pour le coup c’est justement bien plus facile !
      Quel client peut affirmer qu’il a eu, au budget initial, dans les délais prévus, un développement conforme aux specs et fonctionnel ? Sincèrement ? Est-ce facile de terminer les projets quand tout est bloqué partout ?
      Si votre client a subitement perdu la confiance alors que tout allait bien, il pouvait :

      • faire un point pour comprendre ce qui n’allait pas, tenter de renouer la confiance par l’échange humain et non contractuel
      • s’arrêter de suite pour continuer avec un autre, pas facile certes, mais plus logique que d’aller jusqu’au bout.

      Ce qui reste gênant dans votre article c’est le dédain pour les termes agiles (exemple "(...)plus ou moins bien dissimulée derrière « points de complexité », « vélocité » ou autres termes pompeux ...").
      Ces métriques et unités ont été inventée par des personnes réellement soucieuses d’apporter une façon de faire plus saine, transparente et juste. C’est leur manquer de respect et remettre en cause toute une pratique pourtant de plus en plus utilisée avec résultats probants que de faire d’un cas de discorde spécifique le procès de l’agilité. Finalement vous criez au loup mais ne conseillez personne concrètement.

      A nouveau, puisque vous semblez bien connaître le monde de l’IT (échange de visite VIADEO), il serait génial pour tout cet écosystème d’avoir des conseils constructifs pour sceller un projet agile de la part d’un avocat !
      Plusieurs démarches existent déjà : http://www.contrat-agile.org/ - https://github.com/tibastral/contrats-francais
      Qu’en pensez-vous ?

    • Le 18 juillet 2013 à 10:44 , par Michel PASOTTI
      Méthodes agiles : contrats fragiles !

      Bonjour,
      Merci pour votre réponse.
      J’avais bien connaissance des travaux impulsés par XEBIA et CELLENZA.
      Un modèle de contrat est rarement neutre ...
      Souvent s’applique l’adage : "dis moi qui a financé le contrat, je te dirai qui il sert ..."
      Quant à la seconde source, il me semble qu’elle ne peut se décliner sur des projets importants, qui précisément justifient des contrats à l’épreuve des difficultés au fil des trimestres.
      Cordialement.