Pourquoi et comment contractualiser en Agile

POURQUOI LES ENTREPRISES PEINENT A CONTRACTUALISER EN AGILE ?

Idées reçues et changement de mindset pour réussir - Article publié le 15 Mars 2019

Aujourd’hui encore, 90% des projets informatiques sont gérés en méthode traditionnelle. En effet, il est plus sécurisant pour un grand groupe de penser, de sécuriser, de planifier exhaustivement toutes les composantes futures d’un projet de développement plutôt que de s’en remettre à ce qu’on appelle : la contractualisation agile. Mais de nombreuses idées reçues demeurent et bloquent l’émergence plus rapide d’une culture Agile. Cet article vise donc à rappeler l’état d’esprit nécessaire à une bonne contractualisation Agile.

xEn effet, contractualiser en Agile suppose une acceptation préalable du fait que le périmètre ne sera pas complétement spécifié, et surtout qu’il va évoluer en cours de projet. En effet, en management Agile, souvent adossé à l’application des méthodes SCRUM, les livrables ne seront définis qu’au début de chaque sprint. En méthode classique, tout est fixé à l’avance : le périmètre, le coût, les jalons, etc… Sauf qu’entre le moment où on initie le cahier des charges et le moment où il est prêt à être transmis au prestataire, alors le besoin a lui-même évolué…Impossible donc d’être Time To Market.

Pire encore, lorsque le périmètre évolue en cours de projet, les itérations de contractualisation viennent polluer l’avancée technique du projet au point qu’on passe finalement plus de temps à tenter de se mettre d’accord sur le contenu qu’à réellement le produire sans compter la durée du processus achats qui peut atteindre quelques semaines voire quelques mois dans certains grands groupes. Il est aussi bon de rappeler que plus de 50% des projets informatique finissent à plus de 190% de leurs budgets initiaux et plus de 30% d’entre eux intègrent des changements d’exigences en cours de développement.

L’intérêt de la contractualisation Agile est donc d’accepter culturellement l’inconnu et d’axer la collaboration sur ce changement de paradigme pour susciter une meilleure collaboration. En fonctionnement Agile, le périmètre est réactualisé à chaque itération. Les nouvelles exigences sont intégrées dans le « Backlog Produit » qui est repriorisé à chaque itération. La seule variable d’ajustement est donc le périmètre Le coût, les délais et la qualité restent inchangés contrairement aux nombreuses idées reçues.

Management en Agile ne signifie pas Management sans cadre ou plus populairement « à l’arrache ».

Le budget du projet reste parfaitement sous le contrôle du « Product Owner » pour les changements et du « Scrum Master » pour la réalisation. Dans un contrat Agile, on va retrouver des composantes classiques comme par exemple les garanties, les obligations, les conditions financières, la liste des documents contractuels, etc… On va y retrouver également quelques annexes qui viendront détailler la méthodologie Scrum, la vision du client avec les contraintes, les estimations initiales en termes de charge ou de délai, le plan d’assurance qualité (PAQ) ou plan qualité de service (PQS), les conditions particulières, les conditions financières plus précises et surtout souvent en dernier annexe le product backlog dans sa version initiale (V0).

Le product backlog est estimé en storypoints : unité de mesure de la charge ou plutôt devrions-nous dire plus correctement de la difficulté de réalisation. Différentes méthodologies peuvent être utilisées pour chiffrer/évaluer le niveau de difficulté d’une brique à développer. Personnellement, nous recommandons d’utiliser la suite de Fibonacci (1,2,3,5,8,13…) qui a le mérite d’être suffisamment étalonnée pour bien positionner les items sur plusieurs niveaux de difficultés.

La notion d’obligation de résultat est incompatible avec l’application des méthodes Agiles : c’est faux !

En méthode classique : l’obligation de résultat est matérialisée par la présence de livrables encadrés avec des SLA (Service Level Agreement).

En méthode agile : on ne connait pas les livrables à l’avance puisqu’ils seront définis après la contractualisation et systématiquement au début de chaque sprint. Néanmoins le prestataire s’engage au début de chaque itération à livrer un « Potentially Shippable Produt (produit fini qu’on peut plugger dans le système et le rendre fonctionnel) : cela constitue de fait sa première obligation de résultat. Un livrable qui ne serait pas potentiellement opérationnel n’est pas un livrable et le prestataire peut être soumis à des pénalités s’il ne respecte pas le jalon de l’itération.

Ainsi le prestataire est tenu de respecter certaines obligations qui peuvent faire l’objet d’un pilotage avec l’aide de plusieurs indicateurs comme par exemple : la productivité d’une itération, la qualité technique ou fonctionnelle du livrable intermédiaire, de la satisfaction du client (basée sur un sondage régulier par exemple) ou sur la capacité du prestataire à prédire des difficultés ou des opportunités. Il est utile de rappeler qu’on peut parfaitement déclencher des pénalités sur la base de ces indicateurs.

En dehors des ses obligations en termes de résultats objectivables techniques, le prestataire doit aussi s’engager à respecter des modes de collaboration bien définis comme par exemple : assister à tous les comités de co-direction, être présent sur site lorsque l’équipe est en difficulté ou lors des ateliers de priorisation avec le client, à toujours maintenir un climat de confiance avec devoir d’alerte systématique, etc…

En conclusion, la principale difficulté à la contractualisation en Agile repose non pas sur une technicité accrue dans la rédaction des contrats, mais plutôt sur l’acceptation d’un état d’esprit qui vise à maîtriser davantage le cadre & la manière que le contenu à l’instar des méthodes plus traditionnelles.

Donnez-nous votre avis :

Auteur: Philippe JOUANNO
CEO & Founder d'ACEONE


Paris 7ème

Aceone Business Consulting

Nous aidons les entreprises à retrouver de l'agilité et de l'efficience opérationnelle. En effet, les entreprises font face à une vraie complexité générée par le fait que 54% des managers n'ont pas souhaité le devenir, que seulement 11% des collaborateurs sont activement engagés et que des réorganisations de directions importantes ont lieu tous les 3 ans...


Articles les plus lus



Abonnez-vous gratuitement !

Votre message a bien été envoyé. Merci!