Cette présentation a été réalisée dans le cadre du Printemps Agile 2017 de Caen. Matthieu SADOUNI et Marc HOUSSAYE y présentaient la manière dont ils établissent la relation contractuelle client-prestataire.
Vous trouverez ci-dessous une retranscription écrite de l’intervention réalisée par Marc Houssaye lors du Printemps Agile 2017.
Nous sommes heureux, Matthieu et moi-même, de vous accueillir pour parler d’agilité, au sein du Printemps Agile, événement que nous sommes fiers de soutenir depuis ses débuts. Je fais une petite parenthèse : je vois dans la salle des personnes qui nous connaissent et qui doivent se dire : “Je les connais mais c’est quoi ça « Imagile » ?”. Eh bien, désormais Imagile, c’est notre nouveau nom. Imagile c’est MH Communication, pareil comme avant, mais avec un nouveau nom. Et une nouvelle identité graphique 🙂
.
Bon, ceci étant dit, ce qui nous importe maintenant, c’est le contrat agile. Car, bien souvent, on se questionne sur la meilleure manière de contracter avec un client. Surtout lorsque l’on essaie de réaliser un contrat agile. Et comment faire pour que ce soit à la fois souple mais également sécure ? Il y a plein de questions qui se posent d’un côté comme de l’autre :
- Côté prestataire : qu’est-ce que le client va penser si je ne fais pas tout ce qui était prévu dans le nombre de jours envisagé ?
- Côté client : est-ce que le prestataire aura pensé à faire cette chose importante même si ce n’est pas écrit dans le cahier des charges ?
Pour que vous puissiez vous rendre compte que l’on peut réaliser des contrats agiles avec n’importe quel type de client, on va vous parler de nos clients. Chez Imagile, on travaille avec :
- Des startups, et malgré le terme « fun » de startup, croyez-moi ces start-ups sont aussi des sociétés proches de leurs sous. Surtout au début, quand il s’agit de réaliser des POC. Et qu’il n’y a pas encore d’investisseur…
- Des grands comptes et des ETI, c’est peut-être d’ailleurs ce type de client qu’il est plus facile de convaincre pour bosser en agilité. Encore que si la culture en interne n’y est pas, il y a pas mal d’éducation à faire avant…
- mais aussi des petites structures. Nous, on a commencé à un niveau régional et donc il a fallu que nous convertissions nos clients à budget serré mais régulier de passer au crédit-temps.
Nous travaillons avec quasiment toutes ces typologies de clients en agilité. C’est-à-dire que nous vendons du temps.
Il est essentiel de parler le même langage et d’avoir les mêmes étalons. Que le client comprenne que l’on va mesurer avec quelque chose qu’il connaît bien, parce que partagé par tous, et de manière assez égalitaire : le temps.
Donc on peut parler avec des petits clients et des gros clients, des clients pas pressés et des clients pressés de la même manière. Le temps. Y a que ça de vrai même si Einstein a démontré que même ça c’était relatif.
Si vous êtes intrigué par l’illustration de la slide, je vous en donne la référence : il s’agit du tableau synoptique de l’histoire du monde. De Louis-Henri Fournet. C’est assez fabuleux d’afficher cette illustration dans une pièce : c’est juste, résumé en un tableau, l’histoire des 50 derniers siècles ;-).
Enfin, tout cela pour dire qu’il est capital que le client et le prestataire comprennent qu’ils font partie du même monde, qu’ils sont semblables, et qu’ils ont des choses à combattre ensemble : à commencer par les ennemis de leur projet commun !
Avec cette base philosophique temporelle posée, on peut commencer à parler sérieusement avec le client. Lui dire par exemple que rédiger un cahier des charges pendant 3 mois, ça prend du temps, du temps que l’on pourrait consacrer à autre chose, pour que le projet avance. Lui dire aussi que l’on ne peut pas tout faire en même temps, parce que sinon on ne va pas tout faire proprement.
Et ce qui est important au début lorsque ce n’est pas encore un client, c’est de lui demander de parler de son projet. De visu. Ou par téléphone. Sans papier. Sans documentation. Sans cahier des charges. Pour que le client exprime les choses les plus importantes à ses yeux. Parce que les premières choses qu’il va évoquer – ou celles sur lesquelles il va s’attarder – sont généralement les plus importantes. Et on va pouvoir lui poser des questions. Il faut échanger. À bâtons rompus. Pour déceler la vraie question. Pourquoi il vient vous voir ? Alors que vous pourriez faire autre chose de plus essentiel.
On va lui dire aussi qu’en s’attaquant aux choses les plus urgentes dès maintenant, on va pouvoir lui livrer un outil fonctionnel très tôt. Peut-être même dans 2 semaines… Et le client de rétorquer : « Ouah deux semaines !? Je ne pensais pas que ce serait aussi rapide ! ». Eh oui mon bon monsieur, vous voulez avancer ? Eh bien avançons !
Et là, on voit bien que le client a envie d’avancer. Mais qu’il hésite. Comment ça ? On se lance, sans avoir signer en 3 exemplaires 20 pages de contrat et surtout les annexes paraphées pour rien oublier de la demande ?
Mais “on ne peut pas avoir le beurre, l’argent du beurre et le sourire de la crémière.” Soit on a un budget et dans ce cas on priorise les travaux. Soit on considère que tout est important et on ne tient pas compte du temps.
Bon généralement, ils ont un budget…
Pour mettre le pied à l’étrier, voilà ce que l’on peut dire assez facilement au client : « écoutez on va commencer par faire ces deux trois choses les plus importantes, ça va vous coûter 1/10ème du prix que vous comptiez y mettre. Et peut-être qu’à la fin de cette itération vous n’aurez même plus besoin de nous ! ».
Et pour vous illustrer cette ambivalence du contrat, je vais vous raconter deux histoires. Véridiques les histoires hein !
D’abord c’est l’histoire de Jean
Nous sommes client Agile pour l’entreprise dans laquelle travaille Jean. Et Jean il en est le responsable technique, il a l’habitude de faire le recettage, des specs, etc. Eux ne sont pas client Agile pour leur client. Nous, nous facturons au temps passé. Pas eux. Leur client demande régulièrement des modifications sur un cahier des charges resté flou. Et ça c’est embêtant parce que même si nous on continue de facturer chaque mois en fonction du temps passé, eh bien eux ils sont bloqués par un cahier des charges flou.
Et pourtant le plus dingue ne se situe pas à ce niveau car en fait le hic c’est que pour le client final il ne s’agit pas d’une problématique de budget; Si le budget avait été initialement doublé par deux, le projet se serait fait dans les mêmes termes. Mais avec plus de temps et donc plus d’argent. Non, en fait, ce qui bloque c’est la lourdeur administrative : refaire signer un contrat par les supérieurs, perdre du temps à expliquer, à se justifier, etc. Le contrat ici est un facteur bloquant.
Maintenant, je vous raconte l’histoire de Sylvain
Lui, il a un budget, il n’aime pas les cahiers des charges. Il veut faire un maximum de choses sur une durée précise. On ne se pose pas de question, on dit que l’on a un budget, ce qui correspond à X jours, et basta, on tamponne, on signe et hop ! c’est parti.
N’oubliez pas : un contrat est une chose qui lie ! Et ces liens peuvent être libérateurs, comme ils peuvent être emprisonnants. Il faut savoir s’entendre sur les paramètres du contrat afin de conduire à l’objectif : la réussite du projet.
C’est la liberté. Et l’efficacité. Et puis deux ou trois petites choses qui « enrobent » ces notions comme :
- Un outil qui fonctionne (cela peut paraître surprenant mais on est souvent étonné d’entendre certaines histoires informatiques rocambolesques),
- Être conseillé sur les bonnes pratiques,
- Qu’on lui dise ce qu’il faut faire, et ce qu’il ne faut pas faire (car pas rentable par exemple),
- Le faire grandir et qu’il se rende compte que le travail fourni est efficace et rentable.
À ce propos je vous invite à concevoir des indicateurs et à les suivre régulièrement avec vos clients pour étudier l’impact de tel ou tel opération, etc. Mais de cela, Matthieu en parlera mieux que moi.
On accorde beaucoup (trop) d’importance au contrat. Le contrat c’est du sérieux. Et c’est vrai qu’on y accole tout :
- La dimension technique,
- Les termes juridiques,
- Les aspects commerciaux.
- On peut en faire des tonnes et remplir des cahiers entiers.
Normalement, dans un contrat les parties peuvent décider de rompre si les promesses initiales ne sont pas respectées et c’est ça chez nous, en Occident, la manière dont on conçoit le contrat. Et le souci se situe bien souvent au niveau des promesses… non tenues et non tenables. Le problème se situe au niveau du contenu d’un contrat. Et non au niveau de la forme. On peut donc imaginer toutes les formes que l’on veut.
En Chine, on accorde plus d’importance à la relation et à la confiance qu’au contrat. En effet, il apparaît qu’en Chine, il existe plus d’esprit de conciliation et que les tribunaux, donc la justice, oriente beaucoup plus vers des résolutions amiables, quelle que soit l’existence ou l’absence de clauses particulières dans le contrat.
Pour nous, le contrat c’est le but et la relation n’est qu’un simple moyen pour l’atteindre. Pour les Chinois, c’est l’inverse : le contrat n’est qu’une étape, l’essentiel reste la relation.
En résumé, on voit bien que le fond et la forme du contrat sont établis en fonction de la manière dont on gère les litiges. Et de comment on se fait confiance. D’où l’intérêt de faire en sorte que le client soit content. Qu’il sache reconnaître le travail réalisé.
Chez Imagile, le contrat se résume à une feuille A4 composée des clauses suivantes :
- Des coordonnés des parties prenantes,
- Du périmètres des travaux,
- Des outils utilisés,
- De la période temporelle (date de début et date de fin du contrat), voire une date de début sans date de fin (renouvellement tacite chaque mois),
- Du nombre de jours alloués,
- Du tarif jour.
Suivent quelques pages expliquant notre méthode Agile, les outils qu’on utilise.
Et le cahier des charges me direz-vous ? Oui, il fait partie du contrat. Mais il est situé en annexe, il est une sorte de documentation, de backlog dans lequel seront puisées les différentes idées à discuter avec le client au fur et à mesure de l’avancement du projet.
Je considère qu’un contrat, même minime, est essentiel à signer car il fait acte d’engagement. Le client qui signe le contrat et qui vous le renvoie fait un grand pas en avant du point de vue financier, il a décidé de vous accorder la somme indiquée. Mais c’est surtout un grand pas vers la confiance qui se consolidera au fur et à mesure. Si par ailleurs, vous faite pour moins cher ou mieux avec la même somme il sera ravi et voudra à nouveau vous donner des sous.
Détrompez-vous !
Il y a un angle pour signer de l’agilité sur les petits volumes, c’est le contrat de maintenance. Même si cela représente 5 jours par an (par exemple pour mettre à jour les CMS et faire des ajustements). Voici les garanties que nous mettons en avant :
- sécurité technique pour le client : nous pouvons intervenir rapidement (sans obligation d’accord préalable) si besoin de combler des failles de sécurité,
- sécurité financière pour le prestataire qui peut ajuster en fonction des volumes signés les planning et la répartition des tâches.
Pour aller plus loin, je vous invite à envisager un nouveau concept : le contrat continu. Pour cela, il faut :
- réaliser régulièrement des points (courts) avec le client sur les fonctionnalités qui ont été produites, leurs apports, suivre quelques indicateurs, expliquer l’intérêt de telle ou telle chose envisager, écouter les nouveaux besoins du client, prioriser les futurs travaux,
- rendre des rapports réguliers sur le temps alloué restant,
Si le client est content de ce qui a été produit et qu’il en constate les bénéfices, il voudra en obtenir encore plus !
C’est de cette manière que l’on peut contracter un contrat agile avec un nombre de jours mensuel fixé sans date de fin…