La relation contractuelle dans un contexte de delivery agile – Partie 1 : Quel état d’esprit pour bien l’aborder ?

Au cours des formations que nous donnons sur les démarches et la culture agile, ainsi qu’au sein des missions de conseil ou de coaching sur lesquelles nous intervenons, et encore plus lors des discussions en avant-vente de nos missions, un sujet revient souvent… mais alors vraiment souvent !

Le contrat dans une démarche agile.

Nombreuses sont les marques qui font appel à de la prestation intellectuelle externe et qui souhaitent opérer en agile. Et forcément quand on parle de prestation (externe ou interne), on parle d’une relation qui passe par de l’achat/vente et qui se concrétise en un contrat. Et quand on parle de contrat, on parle de régie ou de forfait (avec plus ou moins la même compréhension de leurs modes de fonctionnement d’ailleurs).

Et alors ?

Et alors, comment peut-on gérer efficacement un contrat dans une démarche en Agile ?

Réponse: tu ne fais pas de forfait en Agile !

Fin de l’article :)

.

.

.

.

Allez, on se lance pour de vrai car cette réponse n’est pas satisfaisante, vous en conviendrez !

Note d’intention de cet article

Notre première conviction, c’est que le sujet du contrat n’est qu’une façade derrière laquelle se cachent les vraies questions à se poser, celles qui font peur, celles que nous devons vraiment affronter collectivement.

Nous vous proposons de creuser et d’y réfléchir ensemble.

En préambule, pourquoi on parle régie, forfait et engagement ?

Le modèle contractuel pose les bases de l’engagement mutuel entre des parties prenantes, un fournisseur (prestataire) et un client (bénéficiaire), ou entre deux filiales qui collaborent et se refacturent en interne.

• Le modèle régie implique un engagement de moyens de la part du fournisseur (au temps passé donc), dans des conditions précises, avec un mode opératoire défini.
  • Il est efficace pour assurer une certaine pérennité des personnes impliquées sur mon sujet.
  • Il est pertinent quand on ne délègue pas totalement l’engagement et que l’on souhaite conserver la main sur la démarche.
• Le modèle forfait implique un engagement sur résultat, sur un livrable, dans des conditions précises, avec un mode opératoire défini.
  • Ce type de contrat est par essence moins flexible et moins permissif.
  • Ce modèle implique un périmètre fixe et défini: “on veut ça, on paye pour ça, on vous délègue les moyens pour y parvenir”. Ça parait rassurant.
  • En Agile, la variable d’ajustement étant le périmètre, c’est potentiellement problématique car le périmètre fixe verrouille (au mieux limite fortement) la capacité d’adaptation au changement et la flexibilité.

Remarque: Attention, régie n’est pas égale à “assistance technique (AT) en logique de débordement”. L’AT suit souvent les règles de la régie mais l’inverse n’est pas vrai, on peut avoir un vrai mandat motivé par des objectifs précis dans une formule régie. On a donc des attentes sur des résultats même en régie, mais ça n’est pas encadré par le contrat.

Qu’en pense la communauté des Octos ?

Nous avons demandé aux Octos ce qu’ils pensaient du contrat en contexte de delivery agile. Voici quelques retours éclairants que nous avons sélectionnés pour étayer le propos  :

Basile détruit l’angoisse de la page blanche en répondant en premier

“Si on regarde du côté des valeurs Agile (Customer Collaboration Over Contract Negotiation / Responding to Change Over Following a Plan), on arrive finalement à quelque chose d'assez simple :

• Il n'y a pas de contrat Agile, il y a des contrats tout court
• Il y a de la collaboration et de la confiance au dessus des aspects contractuels
• La probabilité de changer le périmètre (plan) est de 100%

On pourrait en déduire qu'un contrat adapté à l'Agilité est un contrat classique avec quelques ajouts du type :

• Le client s'engage à collaborer à certains moments clés(cadrage, démo, refinement, feedback...) et le cas contraire est un motif de rupture
• Le fournisseur s'engage à mettre en condition d’opérabilité régulièrement et fréquemment un logiciel de qualité (DoD, CI/CD, tests automatisés, indicateurs ...) et le cas contraire est un motif de rupture
• Changer le périmètre en cours de route est normal et ne devra pas être payant
• Pénaliser des choses comme : le non accès aux utilisateurs (client), la non disponibilité quotidienne de nouvelles fonctionnalités (fournisseur), l’absence de mesure objective de la valeur/feedback (client), l’indisponibilité du produit (fournisseur), ...

Au final, si le client trouve que ce n'est pas assez bordé et qu'il ne comprend pas que “avoir un produit qui délivre de la valeur à J1 et l’adpater en continu” est un énorme avantage, c'est peut-être simplement qu'il n'est pas fait pour bosser avec un fournisseur Agile !”

Nicolas B. emboîte le pas et détricote les questions à se poser

“Je rappelle que, d'après le manifeste, l'équipe doit prendre deux engagements cruciaux (c'est-à-dire contractuels) vis-à-vis du client, sur lesquels tout est basé :

• Accueillir favorablement les changements d'exigence, même tard dans le projet.
• Livrer régulièrement un logiciel fonctionnel, toutes les deux semaines à deux mois.

Ça n'a l'air de rien pour le juriste profane, mais dans la réalité peu d'équipes atteignent ce niveau d'agilité, donc à mon sens c'est la seule chose qui mérite réellement d'être contractualisée.

Cela tire bien sûr beaucoup de questions :

• DoR/DoD (Definition Of Ready / Definition Of Done)
• Caractéristiques des plateformes de dev/integ/qualif/preprod/prod
• Définition et suivi de la qualité
• Critères de mesure de la progression
• Conditions d'un rythme soutenable
• Conditions d'accès aux utilisateurs ou managers ou d'obtention des feedbacks
• Capacité de réorganisation de l'une et l'autre des parties
• etc.

Les réponses méritent elles-mêmes de figurer dans le contrat, qui doit être donnant/donnant.”

Nicolas K. surenchérit en se basant sur son expérience

“J’ai fonctionné en agile avec 5 équipes en prestation et j’en retiens les bonnes pratiques suivantes:

• Contrat en régie (long terme) quand cela est possible donc pas d’engagement sur livrable ou de facturation sur storypoint :/
• Engagement mutuel en terme de moyens et de processus
• Fort engagement client de disponibilité, partage d’infos, respect des process agiles (paye tes pseudo PO à temps plein, stables par équipe/projet) etc.
• Mise à disposition des mêmes outils
• Inclusion des "fournisseurs" dans les rituels de gestion de programme.

Les pratiques « gardiennes très relatives» de l’agilité peuvent être détaillées dans la partie relevant du PQP (Plan Qualité Projet) en particulier sur l’organisation de la gouvernance.”

Alexandre tente une percée

“On s'engage sur un dispositif stable (engagement de moyens).

Je ne vois pas comment s'engager sur des story points ou whatever. On a une reconduction tacite tous les deux ou trois sprints. De notre expérience, c’est sain et simple pour le client et c'est raccord avec nos valeurs de confiance.

Ensuite, point quotidien avec le client, démo et tout le tralalala. Le but est de tisser la confiance. Et le truc c'est de dire : tu paies tant que tu es satisfait de notre relation.”

Joseph relance

“On vend des itérations et le client nous challenge s'il est pas content (c'est ça la reconduction tacite dont parle Alex). Ça lui permet de limiter son risque si on est pas performant.”

Damien, l’historien d’OCTO

“Ça rassure les achats et le client de savoir qu'il a un engagement sur un "périmètre" surtout dans une culture habituée aux forfaits.

La complexité des stories était estimée par l'équipe de développement, négociée avec le client.

Sur l'exécution, on a parfois pas atteint la cible mais la proximité et la confiance ont permis de s'affranchir des négociations.”

Erwan a déjà sévèrement réfléchi au sujet

“Voici les takeaways de mon côté:

• agilité et fixed price (forfait pour les anglicistes :p ), on oublie!
• agilité et time&materials time bound, on oublie!
  • en tout cas pour les nouveaux clients tant que récurrente n'est pas démontrée
  • Idem pour les débuts de projet.
  • Pour un 1er PI SAFe par exemple, le scope est défini, on conseille donc de gérer comme un fixed price. Car le client s'attend au résultat.
• agilité et value added contract, why not, mais idem pas pour les nouveaux clients mais pas pour les mêmes raisons
• agilité et time&materials cap capacity, why not: le client s'engage sur une équipe pas sur un scope, mais souvent plus compliqué à mettre en place
• l'engagement sur des story points et également déconseillé, ils ne parlent à personne, ni au client ni à l'équipe surtout pour un nouveau client”

Cyrille, aka le directeur de mission

“Le modèle qui marche bien c’est:

• Engagement time&materials pour des durées de 3 mois

Tous les mois on fait un bilan sur l'avancement : nous sommes satisfait (ou pas), cela nous oblige à nous faire des feedbacks, de partager nos difficultés, nos ressentis et mettre en place des prochaines expérimentations.

Si le client n'est pas satisfait du fonctionnement de l'équipe, qu'il l'a remonté et que rien ne se produit, il garde la main pour sortir des personnes de l'équipe actuelle et faire rentrer d’autres personnes (même d’autres sociétés s’il le souhaite).

Cela permet au client de garder la main sur son budget et sur l'équipe.

Pour nous, cela nous permet de rester vigilant ("ne pas s'endormir sur la mission").

Reste à définir ensemble ce que l'on entend par “un bon mode de fonctionnement de l'équipe” : utilisez les 3 premiers mois pour construire le bon modèle est indispensable.

Cela permet de parler sur du concret et de ne pas construire des indicateurs qui seront hackés au détriment du produit ou des utilisateurs.”

On en a plein d’autres mais ça va globalement dans les mêmes directions, à quelques deltas près.

Le débrief

Tout d’abord, notre premier constat est qu’à travers cette discussion autour du mode de contractualisation, on parle en réalité et avant tout du mode de collaboration avec le client et de comment on va le mettre en œuvre.

Deuxième constat, les Octos nous disent indirectement : lâchez-vous sur les contrats en engagement de moyens mais soyez précautionneux sur le mandat et la clarté de ces engagements de part et d’autre. Une mission sans mandat clair, c'est souvent un fiasco.

Un cadre pour favoriser une collaboration saine

La composante principale et fondamentale d’une collaboration qui se passe bien c’est la confiance qu’on s’accorde.

Quand la confiance est là, le modèle contractuel va naturellement s’appuyer dessus et devient un outil constructif, un allié, un levier.

Quand la confiance n’est pas là, le contrat cadre les engagements et on prévoit tout ce qui peut mal se passer pour ne jamais être dans l’impasse ou pour en tirer le plus d’avantages, c’est une lutte qui favorise une des parties. Cela ne va en aucun cas permettre de construire cette confiance, car le contrat va poser les bases d’un modèle opératoire où chacun va chercher à en respecter scrupuleusement les termes pour être au rendez-vous et ne pas avoir à sortir du cadre (même quand c’est pertinent). Le contrat peut donc devenir un outil de contrôle et de protection dans certains cas. On pourrait probablement mesurer un contrat qui n'est pas construit sur la confiance par les indemnités qu’il comprend ou par le nombre d’avenants qu’il génère, ou peut générer, pour faire avancer la mission.

Exemple : dès qu’il y aura un changement de scope, on fait un avenant -> le contrat devient alors un outil d’administration et moins un levier de création de confiance. Et évidemment, ce n'est pas ce que nous recherchons.

L’objectif des collaborations successives devrait toujours être de faire grandir cette confiance pour faire évoluer notre efficacité commune et donc se reposer de moins en moins sur le contrat comme un outil de protection.

La confiance n'exclut pas le résultat

La confiance s’adosse à un grande variété d’éléments dont le plus notable est notre capacité à obtenir des résultats ensemble. Et plus on collabore, plus on a d’occasions de démontrer des résultats impactants :  un produit qui sort, des utilisateurs contents et impliqués, des livraisons sans bug, des déploiements simples et rapides etc… Vos résultats et apprentissages communs doivent être visibles et partagés, c’est crucial ! C’est bien ces éléments qui initieront ou développeront un climat de confiance.

Take Away

Le contrat ne peut pas être la composante fondamentale de notre réflexion : il est l’appareil du mode de collaboration, il l’accompagne et favorise des conditions de réussite en restant honnête avec les enjeux manipulés et l’expérience des parties prenantes.

L’Agile ça se vit mais quand on parle de contrat ça veut dire que ça se vend et que ça s’achète aussi. Le contrat est le reflet de la relation : il s’appuie donc sur la compréhension mutuelle, et à nouveau sur la confiance qu’on s’accorde et l’expérience des parties prenantes.

Côté Acheteur/Client

Le client porte les enjeux de l’entreprise et à donc la responsabilité d’acheter de la meilleure des façons de la prestation intellectuelle. Ceci implique de comprendre pourquoi l’entreprise a besoin de l’agilité, qu’est ce que cela tracte comme changements et comme besoins, et de mettre le contrat au service de cela. Le client est également responsable de gérer et de favoriser la confiance mutuelle avec ses partenaires. Le type de contrat va donc devoir traduire ces engagements et accompagner la relation avec chaque partenaire.

Côté Vendeur/Fournisseur/Partenaire

• Il faut vivre l’Agilité avant de la vendre sinon il sera difficile de démontrer de l’honnêteté sur le sujet.
• L’expérimentation rapide est la clé pour obtenir des premiers résultats et tester une première collaboration.
• L’échec est permis et, surtout, permet d’apprendre et d’améliorer le mode de collaboration ; l’échec doit être borné et mesuré (n’importe quel échec n’est pas source d’apprentissage) il est un premier pas potentiel vers la confiance. Même si on lui préfèrera la réussite, l’échec arrivera un jour ou l’autre, et c’est là qu’on va tester la résilience de la relation de partenaires. Il est donc préférable de voir en l’échec un levier de mise en mouvement, pour échouer au plus tôt, réagir au plus tôt et réduire les risques.
• Être honnête et transparent, c’est difficile, mais votre approche business ne peut pas supplanter la pertinence de votre accompagnement, de votre honnêteté intellectuelle et de votre intégrité.

Pour les clients et fournisseurs, le challenge sera donc de générer de la confiance et de la nourrir pour favoriser des modes de contractualisation moins contraignants et donc plus agiles.

Et à la question, est-ce qu’il y a un remède magique, une façon de faire plus efficace que les autres pour construire une relation de confiance, poser des bases solides et donc faire du contrat un allié puissant ?

Réponse: oui, on a des pistes à vous montrer, mais ça, c’est dans le deuxième article sur la relation contractuelle en contexte de delivery agile.

Stay tuned