[Fiche pratique] La contractualisation agile : pourquoi, comment ?

Aujourd'hui, après des années d'expérimentation des techniques agiles, 90% des sociétés disent avoir lancé des projets informatiques utilisant les techniques agiles. Les projets agiles sont bâtis sur un paradigme : gérer un périmètre non spécifié dans le détail au début du projet et permettre le changement en cours de projet. Si cette ouverture ravit le métier qui ne sait pas tout ce dont il aura finalement besoin, cela semble contraire à l'esprit d'une contractualisation maîtrisée où tout aura été prévu : périmètre précis, délai et charges financières.

Les acheteurs sont en droit d'attendre de leurs fournisseurs un engagement sur les résultats. Cet engagement est matérialisé par des livrables précis et des SLA. Or, la contractualisation avec "obligation de moyens" est aujourd'hui dépassée, ou en tout cas incompatible avec une gestion de projet agile dont la méthode, la plus utilisée étant Scrum, permet au produit d'évoluer pendant tout le cycle de construction. Les livrables ne sont définis qu'à chaque début de "Sprint".

Posons le problème simplement. Dans une méthode de gestion traditionnelle, en début de projet, tout est fixé : périmètre, coût et délai. Si tout se passe comme prévu, la résultante est une qualité maintenue. Une spécification technique ou fonctionnelle qui se révèlerait plus difficile à développer que prévue aurait une incidence sur le délai et donc le coût. Comme le client est en droit de refuser ce "dérapage" (obligation de résultat), la seule variable d'ajustement consiste à rattraper et "aller plus vite" sur le reste à faire. Et donc prendre un risque fort sur la qualité. C'est ainsi que selon le "Chaos Report 2015" du Standish Group, 84% des projets dépassent leurs délais et/ou leur budget. Plus précisément, 53% des projets coûtent finalement 2 fois plus (189% en moyenne) que l'estimation initiale.

Le même document rapporte que 30% de projets intègrent des changements d'exigences clients au cours du développement. La méthode de projet agile permet le changement d'exigences clients pendant le projet parce que 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. Et ces nouvelles "Features" remplacent celles qui ont une valeur métier moindre. La valeur d'ajustement devient donc le périmètre ; les données coût, délai et qualité restant fixes. Le budget du projet reste complètement sous le contrôle du "Product Owner" pour les changements mais aussi sous celui du "Scrum Master" pour la réalisation.

La contractualisation agile doit créer une situation Win-Win

Nous utilisons tous Microsoft Excel dont la première version est sortie en 1985. Depuis et régulièrement tous les 2-3 ans, Microsoft enrichit son produit de nouvelles fonctions. Et pourtant, quel pourcentage des fonctions l'utilisateur lambda utilise-t-il vraiment ? Une étude du Standish Group sur la fréquence d'utilisation des fonctions des logiciels montre que seules 20% des fonctionnalités commandées sont vraiment utilisées. Ce chiffre est cohérent avec le principe de Pareto voulant que 20% des fonctionnalités portent 80% de la valeur.

Partant de ce constat, on intègre dans le contrat agile une incitation à finir plus tôt. C'est la notion du "Money for Nothing" qui conduit à l'arrêt du projet dès que le ROI n'est plus suffisant. Pour que ce soit incitatif, 20% (classiquement) du budget économisé revient au fournisseur en tant que prime de performance (sauf si le fournisseur n'a pas tenu ses engagements).

L'auteur

Olivier Crouzet est directeur de programme au sein du Cabinet Sia Partners, cabinet de conseil en organisation et transformation des entreprises, et est coresponsable de l'offre Sourcing IT. Il intervient auprès des secteurs privés et publics sur la transformation des DSI et leur alignement à la stratégie Métier. Certifié COBIT, ITIL et SCRUM-Master, il enseigne les techniques de management et de gestion des projets.

Obligation de résultat et projet agile

Dans un contrat établi pour un projet traditionnel, l'obligation de résultat se traduit dans la présence de livrables et de services encadrés de SLA (Service Level Agreement). Or en agile on ne connaît pas au moment de contractualiser les livrables produits à chaque itération. Cependant l'équipe (le fournisseur) s'engage bien à chaque début d'itération à livrer un "Potentially Shippable Products" (produit fini) défini avec le "Product Owner". C'est la première obligation de résultat : livrer à chaque itération les produits commandés. Une fonction partiellement réalisée n'est pas livrée (notion agile du "Done") parce qu'elle n'est pas "Potentially Shippable".

Comme pour les projets en mode traditionnel, le prestataire agile s'engage à réaliser les prestations dans le respect des niveaux de service définis dans le plan qualité de service. Ces niveaux de service sont mesurés grâce aux indicateurs agiles (1) et peuvent donner lieu à l'application de pénalités lorsque la non atteinte du niveau de service est imputable à un manquement du prestataire à ses obligations contractuelles.

Considérant son rôle clef, le client a lui aussi des obligations au terme du contrat agile. La première concerne une participation active à la co-direction de la prestation avec son partenaire fournisseur. La seconde consiste à être présent auprès des fournisseurs pour que ces derniers ne perdent pas de temps et à traiter dans un délai imparti toutes les demandes de suppression d'obstacles qui lui seront soumises par le Scrum Master. La suivante consiste à prioriser le backlog produit à chaque itération. Enfin la dernière consiste à appliquer le principe de pénalités progressives pour favoriser l'apprentissage et sinon à faciliter l'arrêt de la prestation en cas de rupture de la confiance, situation préférable à l'application de lourdes pénalités systématiquement.

(1) Les indicateurs de performance agile, base des SLA sont : Prédictibilité, Productivité du sprint, Qualité Fonctionnelle & Technique, Motivation d'équipe et Satisfaction client

Lire la suite en page 4: La contractualisation agile doit créer une situation Win-Win

Que contient le contrat agile ?

Comme tout contrat, le contrat agile est fait d'un corpus juridique et d'annexes qui le complètent et le précisent. En voici la structure générale :

Le contrat : pose l'esprit de la collaboration agile. Il détaille également les définitions des termes utilisés, liste les documents contractuels utilisés, les acteurs nécessaires au bon fonctionnement du projet, les garanties, obligations, conditions financières, la propriété intellectuelle etc.

Annexe 1 : Méthodologie Scrum : rappel des principes des méthodes agiles et des droits et devoir de chaque partie ;

Annexe 2 : La vision du client : description de la cible à atteindre et des contraintes particulières du client ;

Annexe 3 : Estimations initiales, délais et charges du prestataire : Sur la base du cahier des charges, proposition d'un backlog VO valorisé en Story points, de l'équipe proposée et du nombre de sprints pressentis. Cette estimation de charge pourra être revue à l'issue du sprint 0 mais dans une limite définie contractuellement (conditions particulières, annexe 5).

Annexe 4 : Plan de qualité de service V0 (PQS)

Annexe 5 : Conditions particulières : limites d'ajustement des charges, structure et délais ; site d'exécution ; noms des interlocuteurs clefs du projet...

Annexe 6 : Annexe financière : base pour le calcul du Spint0 et le montant forfaitaire pour les autres sprints

Annexe 7 : Product backlog V0 : Version de départ qui sert de référence en storypoints. Le product backlog va varier pendant la durée du contrat, mais le total des storypoints, ne doit pas varier sous peine d'avenant.

Lire la suite en page 3: Obligation de résultat et projet agile