Contrat Agile… Attention vos clients ne sont pas dupes

Bonjour,

Ayant été des deux cotés de la barrière (prestataire et donneur d’ordre), je souhaitais faire un petit constat en réponse à de plus en plus de discours marketing rencontrés sur le web.

Je vois de plus en plus de web agencies, mais de plus en plus s’y mette, à vouloir vendre de la prestation agile opposant l’agile aux autres méthodes comme l’ultime solution.

1ère erreur : un bon professionnel adapte ses méthodes de travail en fonction du contexte, de la stratégie, de la demande, etc.
Il n’y a pas une voie possible, mais de multiple.

Le terme agile est certes à la mode, mais le discours qu’il y a derrière est beaucoup plus pernicieux que ça.
Car derrière ceci se cache un autre enjeu majeur, la contractualisation.

Car il sera question de ça, les contrats mode agile et non de la méthode en elle-même.

En France, il y a deux types de contrats que l’on rencontre dans 95% des cas : le forfait et la régie. Avec une très très grosse majorité de contrats forfaitaires.

Le contrat au forfait transfert entièrement le risque sur le prestataire.
En effet si le prestataire ne tient pas ses engagements, c’est pour sa pomme.

Le contrat en régie lui transfert entièrement le risque sur le client.
Le client paye à la journée, si le travail demandé va au delà du prévu… le client paye.

Et voilà, on essaye de nous faire passer des vessies pour des lanternes en réactualisant le contrat en régie sous le nom de contrat agile.

Mais, et c’est là que je lance mon petit avertissement pour ceux qui voudrait se lancer dans cette voie marketing: (c’est à dire essayer de vendre de la régie sous le terme agile)

Si les solo-entrepreneurs et jeunes start-up tombent facilement dans le panneau par inexpérience, ce n’est pas le cas des TPE, PME et filiales de grands compte (là ou se trouve la manne financière).

Chaque service d’une entreprise budgétise chaque fin d’année.
Il faut donc présenter sont budget pour l’année qui arrive, l’expliquer et le défendre car le gâteau à partager est limité.

Or on ne peut défendre son budget que si les dépenses sont connus à l’avance… et donc on ne prendra que du contrat au forfait.

Mais aussi, lorsqu’un prospect lance un appel d’offre, il s’attend à ce qu’un professionnel lui réponde.

C’est à dire quelqu’un qui a déjà réalisé ce type de prestation et qui est donc en mesure de chiffrer.

Tout ça pour expliquer que le contrat au forfait à de longues années devant lui et que le client n’est pas con : il choisira toujours le contrat le plus intéressant pour lui, quelque soit les modes.

Alors agile peut-être, mais dans un cadre au forfait… ne l’oubliez pas si vous visez des cibles à contrats juteux (grosse TPE, PME, filiale d’un groupe).

2 « J'aime »

Bonjour,
post très intéressant et vrai mais mon avis à moi est très tranché, et ça touche aux méthodes Agiles, mais ce n’est pas le fond du problème.

Celui qui choisit la « voie » Agile comme un outil marketing, n’a pas comprit ce que c’était, et se trompe.
L’Agilité n’est par une voie marketing ou commercial c’est une manière de dev (ou autre prestation adaptée).

Le dev agile (je parle de dev parce que c’est mon cas) a un objectif, satisfaire son client, produire le meilleur, et l’agilité est une méthode pour y arriver. On vends Agile parce qu’on est persuadé que c’est comme ça qu’on délivrera le meilleur travail comme prestataire sinon c’est que du commerce et ça s’éloigne de l’Agilité.

Je n’ai pas encore pris le temps de le lire, mais des contrats agiles existent
> https://github.com/tibastral/contrats-francais
( merci @tibastral )

Et dans un autre post une partie des questions soulevées par ton post https://forum.pragmaticentrepreneurs.com/t/comment-facturez-vous-en-agile/1847

Question : pourquoi ce post ? Une mauvaise expérience ?

3 « J'aime »

Le contrat au forfait est une hérésie absolue quand on fait du sur mesure.
un exemple :
pour moi, une des plus grosses valeur ajoutées en informatique est la capacité de supprimer purement et simplement des features inutiles. Comme au cinéma quand on coupe au montage des scènes inutiles.

Le forfait, c’est une liste de features, et c’est bien là le problème. C’est comme si tu allais voir un artiste et que tu lui disais exactement tous les traits que tu voulais sur ta toile.

1- tu perds toute la valeur ajoutée de l’artiste, car sans liberté, il ne peut pas apporter la valeur maximum de ce qu’il pourrait faire
2- tu te concentres sur des idées alors que ce qui compte au final, c’est ce que ce travail va te rapporter (en termes de cash flow, etc.)

Pour moi, il faut pouvoir pouvoir conseiller au client à tout moment, et surtout quand on s’attaque à des features inutiles (bien que voulues au début du projet), et au forfait c’est IMPOSSIBLE.

Si les grosses sociétés ne veulent faire que du forfait, c’est souvent parce qu’elles n’ont pas le choix ^^ La loi impose le forfait dans tous les services publics, et c’est souvent un gros gros problème pour eux.

J’explique tout ça dans mon cours sur le sujet, et et les contrats agiles que j’ai faits avec mon avocat (comme cités par Nicolas)

3 « J'aime »

Merci Nicolas pour ta réponse,

Toute les méthodes ont pour objectif de satisfaire le client et produire le meilleur… seul le contexte permet de dire si telle ou telle méthode est mieux adaptée, et parfois l’agile ne l’est pas du tout (pourtant j’utilise régulièrement scrum).
Bref, effectivement ce n’est pas le sujet.

J’ai lu un des contrats dont tu donnes le lien, et je vois ça:
Par le présent contrat, {{ company.name }} s’engage à concevoir et à réaliser pour le compte du Client un Livrable conformément à la méthode Agile.
Bref, ça veut tout et rien dire:
Et c’est risqué de dire que tu livres en utilisant telle ou telle méthode… si jamais tu dois la contourner et/ou en utiliser une autre pour quelque raison que ce soit, tu ne respectes plus le contrat et ton client peut se retourner contre toi.

Comme cette phrase:
Le presta s’engage à concevoir et à réaliser un Livrable fonctionnel par Itérations successives. Il devra ainsi apporter les solutions techniques.
Aucun engagement de la part du prestataire, tout le risque est reporté sur le client.

On ne vend pas une méthode, on vend un livrable… je ne comprends pas qu’on puisse dire à son client : je vous vends de l’agile.

Si j’ai fait ce post c’est parce que je commence a entendre parler de ça (la contractualisation agile) et j’ai parfois l’impression que mes interlocuteurs ne comprennent pas que c’est du contrat en régie qui se cache dessous.

En tant qu’AMOA, la moindre des choses est de conseiller mon client en lui expliquant dans quel guêpier il va se mettre.

Thibaut,

Les méthodes agiles ont été créés pour des contextes changeant ou des besoins mal définis (je te renvoie à la lecture du manifeste agile).
On adapte les livrables en fonction des changements lorsque l’environnement est très incertains.
Lorsque l’incertitude est maitrisée, les méthodes agiles ne sont plus nécessaires.

Si tu dois construire un pont, il n’y a aucune chance pour qu’on te dise au milieu de la construction: finalement on va faire un gros virage à partir de là parce que l’arrivée change d’endroit.

Toutes les prestations ne se font pas dans des environnements incertains.
La valeur ajouté d’un prestataire se trouve dans sa capacité à conseiller, guider et mener sa prestation… si tu veux faire de l’artistique il faut se lancer dans la musique ou le cinéma… pas la prestation de service.

Le but de la presta est connu depuis longtemps: réaliser une oeuvre, et non une oeuvre d’art
Je ne commandite pas un presta pour qu’il se prenne pour Andy Warhol

Mais j’ai bien compris que tu vendais de la régie, d’ou le discours.
Quant au mien, de discours, c’est pour protéger les intérêts de mon client… forcement on va pas être d’accord :slight_smile:

PS: je ne fais que du sur-mesure

La seule façon pour moi de protéger l’intérêt de mes clients, est de justement leur vendre du travail à l’heure. J’aimerais bien savoir la dernière fois que tu n’as pas dépassé ton forfait, et que ton client a été absolument ravi du résultat qu’il avait au forfait.

Tes intérêts et ceux de ton client divergent dès que tu signes un forfait ! Ton intérêt est de finir le plus vite ton ‹ pont › en php alors que ton client, c’est d’avoir le produit le plus efficace et le mieux fait possible pour le budget qu’il a mis.

Une liste de features n’a RIEN d’équivalent à l’appel d’offre pour faire un pont !

Et pour moi, l’art et les sciences sont une seule et même chose, on a séparé ces 2 notions au XXe siècle, il serait peut-être temps de revenir là-dessus !

La prestation ne s’arrête pas au développement logiciel, il y a quantité d’autres métiers, y compris dans l’info, d’ou mon exemple de pont (fait de béton).

Forfait ou régie le but est le même:
Satisfaire la demande du client car un client satisfait est le meilleur ambassadeur qu’il soit et surtout, restera client.

Là tu galvaudes l’idée de départ (le premier post) pour défendre ta position en allant sur un terrain que je n’ai pas abordé.

Je n’ai a aucun moment critiquer le résultat final de la régie, ce que tu essayes de faire avec le forfait.

D’ailleurs pour répondre à ta question:
Je pense ne pas avoir dépassé un forfait depuis au moins 8 à 9 ans (mais je pense que c’est plus de 10).
Tout simplement parce que je vais en terrain connu (quand ce n’est pas le cas, je n’inclus pas la courbe d’apprentissage), je sais cadrer une prestation, mener un kick-off, une réunion de cadrage, accompagner les parties prenantes, gérer les demandes de changement, suivre le RAF, etc.
C’est pas arrivé comme ça, ça m’a demandé quelques années tout de même.
Quant à la satisfaction client, j’ai souvent dans mes recommandations « est allé au delà des attentes ».

Et c’est le cas pour tous les prestataires avec lesquels je travaille: tous ont entre 10 et 20 d’Exp.
Ca explique surement pourquoi.

Je pense qu’on peut clore ce chapitre HS est revenir à nos moutons.

C’est peut être une composante du dev web/mobile actuel, et donc des SaaS et autre, donc à peu près tous les logiciels actuels (peut être il faut enlever les trucs comme l’aviation, le médical, ou les risquent sont énormes, mais les délais de livraisons plus long).

Pour que les environnements soient certains, il faudrait que les clients maitrisent :

  • leurs besoins
  • la techno
  • le temps

De mon expérience, ils savent ce qu’ils veulent (ou pas) mais sont généralement en partie déconnecté de la réalité, ce qui se fait, ne se fait plus, doit se faire, devrait ne plus être fait… Ne connaissent peu ou pas la(les) technos nécessaires (ou en lisant un site généraliste informatique…) et sont pressés.

Il y a ici un paquet de gens intéressés ou proches du monde des startup ou plus généralement des gens qui entreprennent, mais c’est rare d’entreprendre dans un environnement maîtrisés, et tous ces gens ont besoin de services informatiques.

Le forfait, le temps nécessaire à faire le travail est plus impacté par le client, que par la tâche à mon sens.
Un seul forfait, se passera différemment 10 fois si tu as 10 clients.

Par contre, oui il faut vendre la presta et pas la méthode.

Je pense vraiment que ton post à vrai dans le sens où « prendre la voie marketing de l’agilité » c’est se planter.

Je ne suis pas sûr par contre d’une chose, tu dis Agilité = Régie.

Mais, une équipe Agile qui connaît son sujet, et qui connaît sa vélocité pour pouvoir faire des estimations type Story points assez précises, pourrais tout aussi bien conduire un projet Agile, en facturant les features au forfait, c’est un peu ce qui se passe quand on édite les factures après livraison des features.

Tu as découpé ton forfait global, tu peux être Agile et tu n’est pas à la régie.

D’autres équipes facturent le MVP au forfait et une fois le client convaincu ils passent à la régie.

Un autre avis sur le premier post, j’ai adapté mon discours commercial pour vendre mes prestations APRÈS être passé aux méthodes Agile, je n’ai pas adapté ma méthode de travail pour faire du marketing.

Je veux bien l’avis des autres là dessus, mais pour moi, bien que la régie soit le mode le plus naturel et pratique avec une méthode agile, ça n’est pas une obligation.

« Tes intérêts et ceux de ton client divergent dès que tu signes un forfait ! Ton intérêt est de finir le plus vite ton ‹ pont › en php alors que ton client, c’est d’avoir le produit le plus efficace et le mieux fait possible pour le budget qu’il a mis. »

Remarque étonnante.

Typiquement, sur ce sujet quasi éternel du forfait vs. régie, le conflit d’intérêt est un argument soulevé à l’encontre de la régie, et non du forfait. Puisque le prix est proportionnel au temps, le client veut que vous passiez un minimum de temps sur le projet pour remplir le cahier des charges, et vous voulez y passer le maximum de temps pour augmenter votre facture.

L’échantillon d’avis que j’ai pu consulter sur ce sujet (Brennan Dunn, Patrick McKenzie, Thomas Ptacek sur Hacker News) aboutit toujours à la même conclusion : ne facturez jamais à l’heure.

Notez que le fait que le produit soit efficace et bien fait est orthogonal au type de contrat : c’est une question de cahier des charges.

Le problème sous-jacent est bien sûr une question de pricing qui est décorrelé de la valeur ajoutée réelle (tarification horaire arbitraire).

1 « J'aime »

On s’éloigne encore, mais les cahiers des charges sont à mon avis totalement inadaptés à la plus grosse partie des dev, encore une fois dans mon domaine, qui est en ligne (net, mobile etc).

Si tu prévois 3 mois de dev, je ne vois pas comment ce serait possible qu’en 3 mois le projet de dev n’ai pas évolué, vue la rapidité d’évolution du milieu.

Il faut arrêter de faire des logiciels sur cahier des charges, plus le projet et gros et plus c’est vrai, surtout si il faut qu’il soit rapidement confronté aux utilisateurs.

J’ajouterai une chose, j’ai plus l’impression qu’on se demande quelle formule va mieux à qui et pourquoi mais un client honnête, un presta honnête, c’est suffisant pour que le travail soit bien fait, et ça on peut chercher à contractualiser, mais le manque d’honnêteté est un fléau qui ne sera pas arrêté par telle ou telle approche contractuelle ou de facturation.

1 « J'aime »

Je suis désolé mais je suis obligé de te contredire David :slight_smile: J’ai discuté par skype avec Brennan, et il était d’accord sur le fait que si tu arrives à vendre des heures et pas du forfait, tu apportes beaucoup plus de valeur à ton client, car tu peux te concentrer sur l’essentiel. C’est pas pour rien qu’il a créé http://doubleyourfreelancing.com/rate/. Dans double your freelancing rate, il y a … rate.

L’efficacité d’un produit est tout sauf orthogonal au type de contrat… et en rien lié à un cahier des charges.

Exemple : avez-vous vu beaucoup de cahiers des charges de projets open source ?
Moi : jamais, et pourtant ce sont des produits très très efficaces…

Je suis ravi que ça marche bien pour toi en forfait, mais sache que ça marche aussi très bien en régie, et ça évite d’avoir à négocier 7 ans pendant tout le projet pour savoir si telle feature rentre ou pas dans le scope définit.

Mais pour moi en programmation (si on parle bien de programmation), à partir du moment où je sais chiffrer quelque chose, je suis capable de faire le travail en 1h maximum. À partir du moment où j’ai fait une chose une fois, refaire cette chose sera presque instantané.

Et chiffrage veut aussi dire gros projet avec grosse infra, etc. Comme personnellement j’utilise heroku + rails l’infra est déjà très très simplifiée, et j’ai tendance à réduire au max le scope du projet pour qu’on puisse kick off en 2 jours, c’est vrai que c’est souvent slim fast :slight_smile:

Aucun problème, je prétends pas avoir de réponse définitive à ce sujet et je suis ravi d’en discuter.

Juste un truc pour clarifier parce que sinon ça tourne vite au dialogue de sourds sans intérêt : il faudrait clairement distinguer « régie » (au sens de retainer en anglais, avec des prix fixés au mois ou à la semaine a minima) et la tarification à l’heure proprement dite.

Ayant lu DYFR et des tas d’autres ressources au-delà de la pratique concrète du problème, je n’y ai pas vu beaucoup d’arguments qui soutiennent ton hypothèse, nonobstant ce que Dunn en pense en dehors de ce qu’il écrit. En fait, l’idée centrale de DYFR (qui n’est par ailleurs par forcément très originale) c’est qu’il faut un prix qui colle à la valeur ajoutée (value driven pricing). Tout ça ne me semble pas avoir d’implication par rapport à la façon dont le prix est payé in fine.

Dunn lui-même dans son dernier article sur le sujet (ici http://doubleyourfreelancing.com/new-agency/) montre clairement qu’il se déplace vers un modèle de pricing au mois.

Et là finalement on tombe dans un truc hybride, qui est un package de services avec un scope défini de façon suffisamment précise mais suffisamment flexible aussi, livré sur une période définie. Est-ce que c’est de la régie ? Du forfait ?

Pour finir, je ne comprends pas ton exemple qui me semble être un homme de paille caractérisé, même si j’ai peut-être utilisé le terme de cahier des charges de façon trop informelle. Je ne disais que la chose suivante : il est parfaitement possible de travailler au forfait et d’offrir au client un produit qui soit le meilleur possible, et ça repose sur une gestion intelligente de tout ce qui est spec/scope (problème lui aussi indépendant et inévitable).

Donc on parle bien de régie mais masqué sous le vocable marketing « contrat agile »

Voilà l’objet de mon 1er post (certes provocateur): le pourquoi de ce vocable et dans quel but.

Ça n’a rien de masqué :slight_smile: c’est dit ouvertement même ! Et le marketing n’est pas une bête noire réservée aux gens qui sortent de HEC ! Pour moi, un des plus grands marketeux de tous les temps est @fat, le créateur de twitter bootstrap !

De plus l’agilité sans contractualisation agile ne fonctionne pas bien, pour moi. Il faut pouvoir être en direct avec le client pour pouvoir lui apporter un maximum de valeur sans intermédiaires.

Si tu savais le nombre de clients lassés du forfaits qui viennent me voir parce que justement quand on leur vend un site ou une appli iOS 30k alors qu’au final ils ont juste une déclinaison d’un truc existant ou pire un truc fait par un stagiaire à qui on a donné des cacahuètes… Et avant même qu’ils me disent qu’ils sont lassés, je leur raconte leur histoire :slight_smile: Un truc du genre :

Vous avez fait un appel d’offre pour votre V1, et là un commercial vous a fait une offre alléchante. Il vous a dit qu’il allait vous faire votre projet pour 12k, et qu’il ferait tout ce qui était écrit dans votre cahier des charges. Ensuite il a effectivement fait TOUT faire par un ‹ développeur expert › que vous n’avez jamais rencontré, et il vous a livré le … machin (pour pas dire autre chose) au bout de 2 mois (avec 1 mois de retard). Ça respecte au pied de la lettre votre cahier des charges, mais par contre c’est

  • pas évolutif
  • moche
  • plein de features ne sont pas utilisées par les utilisateurs finaux
  • et le commercial vous propose déjà une v2 à … roulement de tambour ^^ 20k ?

Et là le mec me répond en général : Mais vous êtes devin ? Vous les connaissez ?

Pour les gens de chez Thoughtbot, un des fleurons du développement web, et des ayatollahs du contentement client, les fixed bid (ce qu’on appelle forfait en France) sont MAUVAIS AUSSI POUR LES CLIENTS, http://robots.thoughtbot.com/why-fixed-bids-are-bad-for-clients-too (article très intéressant et récent de surcroit)

D’autres ressources sur le sujet (plus anciennes):
https://www.scrumalliance.org/community/articles/2007/september/why-fixed-bids-are-bad-for-clients

Une dernière chose, je n’utilise jamais le vocabulaire « donneur d’ordre » et ‹ prestataire ›. Pour moi, quand je travaille avec un client, nous sommes d’égal à égal, et j’essaye de lui apporter un maximum de valeur, que ce soit sur du développement ou du conseil en stratégie.

2 « J'aime »

Excellente « technique » de vente. De l’or en barre. Le storytelling du projet en V qui n’a pas marché.
Tu dois faire mouche plus de 50% du temps étant donné le taux d’échec des projets informatiques.

(PS =>
http://www.developpez.com/actu/68561/Pourquoi-les-projets-IT-echouent-si-souvent-Le-manque-de-ressources-serait-la-principale-cause-selon-une-etude/

Si les gens basculent en Agile c’est pour évidement partager le risque il ne faut pas faire les bisounours. Mais aussi pour livrer le meilleur produit pour l’argent dépensé par le client. Enfin il faut être pragmatique. Le développement logiciel ce n’est pas une activité comme une autre. Il faut de la collaboration. Le CDC balancé et pouff 3 mois on a le projet dans les grandes ou les petites structures cela ne marche pas souvent. Alors on fait quoi? Comme des Shadocks on dit plus sa rate plus sa a de chance de fonctionner? ou alors on procède à une autre méthodologie?

Comment vendre un développement agile. D’autres arguments en faveur de l’agilité.

Même si on est complètement hors sujet depuis un moment, l’agile n’est absolument pas la méthode miracle, on ne fait pas mieux avec:

D’après une études réalisé auprès de 1200 developpeurs sur 3 continents:

« Plus surprenant, explique Evans Data, l’agilité, qui aujourd’hui occupe une place de plus en plus importante dans les phases de développements et dans l’ensemble du cycle de vie du projet, ne semble pas, pour autant, être le remède adéquate. »

http://www.lemagit.fr/actualites/2240196765/Developpement-seulement-36-des-projets-livres-dans-les-delais

L’agile n’est qu’une méthode parmi d’autres, seul le professionnalisme permet de reconnaitre quelle méthode est mieux adaptée au contexte.

Mais bon, ça c’est impossible à faire comprendre au mono-maniaque de l’agilité.

Je pensais que c’était un manque d’éthique, je vais finir par croire que c’est par manque de professionnalisme.
Bref, le « think out of the dev box » c’est pas pour demain.

Merci pour ce moment

Une remarque écrite pour les graphistes mais qui est valable pour n’importe quelle prestation facturée au temps :

  • si le prix est fixe : la satis­fac­tion du client est garan­tie contrac­tuel­le­ment. Plus tôt le client aura obtenu satis­fac­tion totale, plus la marge du pres­ta­taire sera inté­res­sante. Les deux par­ties ont donc un même inté­rêt : abou­tir rapidement.
  • si le prix est en fonc­tion du temps : plus de temps passé à satis­faire le client génère plus de reve­nus. Pourquoi se pres­ser ? Le seul inté­rêt direct du pres­ta­taire est d’augmenter son revenu puisque sa marge est fixe (le taux horaire est le même, que le pres­ta­taire tra­vaille 1h ou 200h). Le pro­chain client payera le même taux horaire et si ce pro­jet est fini en avance, le pres­ta­taire n’a plus de reve­nus entre les deux contrats. Le pres­ta­taire a donc inté­rêt (théorique) au gas­pillage ! (Par exemple 6 allers-retours au lieu de 3).

Bien-sûr le code est une discipline complexe et il y a d’autres facteurs à considérer. Mais d’un point de vue théorique les intérêts ne sont jamais alignés.

Enfin, pour les adeptes du Lean thinking, l’idée de Valeur est centrale.
Et le temps n’a AUCUNE valeur intrinsèque. L’effort et la valeur sont deux variables décorélées.

En tant que client je n’achète pas des jours de cerveau mais un outil qui me permet d’automatiser une activité commerciale.

Un apôtre : Value-Based Fees par Alan Weiss

Qu’on appelle ça Agile ou autre chose, personnellement je m’en contrefiche :slight_smile: J’ai lu beaucoup de trucs sur les méthodes agiles (et compagnie) aux alentours de 2007 / 2008, aujourd’hui, ce courant de pensée est loin d’être le seul qui m’intéresse, et ce que je fais avec mes clients (et ce que j’enseigne en formation) et que je fais sur mes projets persos est un mixe de plein d’idées, et je parle assez peu d’agile d’ailleurs, car ce terme est maintenant galvaudé, et souvent utilisé par de nombreuses personnes sans en comprendre réellement le sens.

Dans tous les cas, ce qui m’anime, c’est que le client soit satisfait du résultat, qu’il soit prêt à nous recommander, et surtout que les end users utilisent le produit qu’on a créé pour le client. En un mot, que le projet vive.

2 « J'aime »