Pourtant agilité et contractualisation ne sont pas antinomiques. Il est tout à fait possible de fonctionner de manière agile avec des intervenants externes, tout en gardant un certain contrôle sur le résultat à atteindre mais aussi sur la manière de l’atteindre. Une telle approche permet d’ailleurs de minimiser les risques et les coûts associés à la réalisation, quelque part entre le projet forfaitaire et la régie, tout en étant bénéfique pour le prestataire. Une approche gagnant-gagnant est en effet possible, la clé est de placer la création de valeur et la collaboration active au centre de l’équation.

Le forfait ou la régie, les approches les plus courantes

De manière classique, on retrouve deux types de relations. Lorsque le périmètre est identifié, alors le commanditaire fait généralement appel au forfait, à savoir le paiement d’une somme définie pour un périmètre explicite et immutable. Il arrive régulièrement que cette approche soit choisie alors que le périmètre s’avère très large, augmentant fortement le risque pour le prestataire. Pour les autres situations, la mise à disposition de ressources en régie, c’est-à-dire en fonction du temps passé et des moyens mis en œuvre, est choisie. Dans ce cas, c’est le client qui supporte le risque dans sa globalité.

La régie est souvent perçue comme étant plus adaptée face à l’inconnu. Le forfait est plus adapté à des situations fortement maitrisées.

Un petit rappel sur l’agilité

L’agilité est bien plus large que la régie. Il est dès lors important de rappeler ce qu’est l’agilité : c’est s’adapter rapidement face à des évènements, tant à la suite de difficultés que pour répondre à de nouveaux besoins et opportunités. Pour y arriver, il est nécessaire de respecter 4 principes : des interactions, un produit fonctionnel, de la collaboration, et de la réactivité.

Les méthodes agiles permettent de respecter les principes d’agilité en définissant des cycles de création de valeur courts, ou inversement selon le point de vue. En effet, le tout forme un ensemble où les causes et les conséquences ne font qu’un. On retiendra l’aspect de cycle de vie itératif, incrémental et adaptatif basé sur du pragmatisme et de la réactivité pour tenir compte de besoins en évolution. L’agilité, c’est donc la capacité à accompagner la maturation des besoins et intégrer des changements de périmètre à tout moment. Intégrer la maturité projet dans la démarche permet de favoriser la capacité d’exécution et de maximiser la valeur produite en utilisant le produit au plus tôt.

Pour y parvenir, il existe de nombreux cadres de développement : Scrum, Extreme Programming, Development Lean, et de nombreux autres bien moins connus. Des méthodes issues du développement ou des approches spécifiques s’appliquent également à des projets d’infrastructure.

Avec un tel cadre de travail, il est possible de définir un contrat hybride, il est possible pour le demandeur de garder le contrôle, en s’assurant de la bonne collaboration et de l’engagement de l’ensemble des intervenants tout en créant de la valeur de manière régulière, permettant de s’arrêter à tout instant tout en profitant de la valeur créée jusque-là. Nous verrons un peu plus tard que le prestataire partage le bénéfice issu de cette méthode de travail avec le commanditaire, notamment dans la réalisation au quotidien mais aussi financièrement.

Comment réussir en étant agile ?

Tout d’abord, il s’agit d’avoir la vision produit et un backlog, c’est-à-dire une liste ordonnancée, de fonctionnalités à implémenter. Cette liste se doit d’être organisée en tenant compte tant de la valeur attendue de la réalisation, que de l’effort à produire pour obtenir cette valeur. Cette liste de fonctionnalités peut être modifiée à tout moment ou presque.

L’ordre est généralement orienté de sorte à avoir les fonctionnalités nécessaires en premier avant de mettre en place les fonctionnalités donnant un avantage compétitif pour finalement terminer avec les fonctionnalités considérées comme non nécessaires mais apportant un plus aux utilisateurs. De ce fait, la valeur ajoutée diminue généralement itération après itération :

La valeur à chaque itération diminue tandis que l’effort fourni durant une itération donnée est censé reste stable. Ainsi à un moment, par exemple après l’itération 8, il peut être nécessaire de s’arrêter, avant que l’effort à fournir pour créer de la valeur n’augmente de trop.

Concrètement, la valeur créée est estimée par le commanditaire tandis que l’effort sera convenu de manière concertée entre le demandeur et les personnes en charge de l’implémentation, du déploiement et de la maintenance de la fonctionnalité. L’effort se mesure en Story point, qui s’avère propre à chaque équipe. La lecture du guide Scrum[1] devrait donner quelques pistes intéressantes, que vous ayez de l’expérience ou non avec Scrum ou les autres méthodes agiles.

Dans ce contexte, on notera que l’on vise à ne mettre en place qu’un et un seul contrat régissant la relation. Attention donc aux contrats faussement agiles avec des accords signés sur le périmètre de chaque itération, ce qui en fait une série de contrats au forfait et non une approche forfaitaire agile.

Comment mettre en place de l’agilité en quelques étapes

Le périmètre n’étant plus fixe, le forfait est-il possible ? Presque. Le contrat agile porte sur un budget sous contrôle et pour lequel le risque financier n’est pas inexistant mais s’avère minimisé tandis que le périmètre sera réévalué régulièrement.

Ainsi, l’engagement porte sur la méthode et non sur un résultat bien que la notion de création de valeur soit l’élément clé de ce type de contrat. Pour y parvenir, il s’agit de mettre en place un travail commun avec le client avec revue régulière.

Par l’approche coopérative, il est nécessaire de construire la relation au travers de plusieurs phases :

1. Lancement : élaboration d’un Plan Qualité de Service, c’est-à-dire des indicateurs qui seront suivis tout au long de la relation 
2. Mise en place de la collaboration : durant quelques sprints, ajustement de la vision, du backlog, mais aussi estimation de l’effort d’implémentation des fonctionnalités du haut de la liste. On notera que malgré qu’on soit en phase de mise en place, il est d’ores et déjà attendu d’avoir des livrables à chaque itération
3. Implémentation : les itérations continuent, en utilisant les bases mises en place à l’étape 2, notamment autour de l’estimation de l’effort à produire 
4. Clôture : formation des intervenants et transfert de connaissance.

Dans certaines situations, il peut être intéressant de contractualiser après la 2^ème étape, ou tout du moins de laisser de la marge dans le temps pour l’estimation.

Ce qui doit être livré à chaque livraison

Pour les adeptes de Scrum, pas ou peu de surprises dans ce paragraphe. Il reste cependant intéressant d’énumérer ce qui est attendu après chaque itération. Chacun des éléments permet la couverture d’un des points importants à tenir compte lors de toute implémentation :

• Le besoin couvert : les exigences sous forme de user stories,
• La réponse au besoin : le code, dans sa version actuelle,
• La qualité : l’ensemble des tests portant sur le code ou les fonctionnalités et les rapports d’exécution de ceux-ci,
• Le déploiement : les scripts de compilation et de déploiement,

L’idéal est que cette documentation ne soit pas « externe » au package mais totalement intégrée dans le processus de livraison et accessible via les outils en place. Malheureusement, il s’avère que les clients sont souvent peu outillés pour cela et que les fournisseurs ne peuvent éternellement donner accès aux clients. Dans ce cas, il reste nécessaire de faire des livraisons incluant de l’information sous forme de documents.

[1] https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.pdf

La gouvernance autour des projets agiles

Quelle que soit la méthode de contractualisation, les projets agiles requièrent certains intervenants avec principalement un product owner (qui sera donc côté client) et un scrum master, bien souvent issus du fournisseur. L’ensemble des intervenants se rencontrent de manière même cyclique et chaque rencontre a des objectifs particuliers :

• Le daily standup permet quotidiennement de faire le point d’avancement et d’échanger en quelques minutes sur les difficultés rencontrées par rapport aux sujets en cours,
• Le backlog refinementpermet de revoir les éléments du backlog et de s’assurer de leur bonne compréhension,
• Le sprint planning durant lequel les éléments du backlog sont évalués en termes de points, correspondant à la difficulté de produire la valeur espérée,
• Le sprint review dont le but est d’obtenir des retours d’informations sur les nouvelles fonctionnalités,
• Et enfin la rétrospective qui s’avère clé dans ce contexte puisqu’il permet à chacun d’exprimer sur la période qui vient de s’achever.

Pour plus d’informations sur ces cérémonies, je vous renvoie vers le Scrum guide dont nous avons parlé précédemment.

Par l’aspect contractuel, il est également nécessaire de mettre en place un comité de pilotage portant sur la vie du projet en tant que tel, durant lequel les indicateurs présentés au paragraphe suivant seront présentés, en autres choses. Plusieurs profils sont importants au travers des cérémonies : le Product Owner, le Scrum Master. A ceux-ci s’ajoutent des profils qui ne sont pas directement liés à l’opérationnel : le gestionnaire du projet et le directeur de projet ou le sponsor.

Le pilotage par les indicateurs

La croyance populaire voudrait que le succès ne se mesure qu’au travers du succès de l’applicatif ou non. Bien que ce fondement fasse du sens puisqu’il s’agit de l’objectif final, il est utile de suivre un certain nombre d’indicateurs, tant dans le quantitatif que le qualitatif au travers du temps pour s’assurer que la collaboration est la plus efficace possible.

On regardera ainsi 4 indicateurs quantitatifs, ayant pour objectif de promouvoir la pérennité des fonctionnalités livrées et de donner un aperçu sur le niveau de contrôle du projet. Pour ce qui est du code en tant que tel, on mesurera la qualité technique (la couverture de code, la complexité du code, etc.) mais aussi la qualité fonctionnelle (le nombre d’anomalies et de régressions par exemple).

En plus de la qualité, 2 indicateurs de prédictibilité et de productivité seront présents. Le premier permet d’évaluer la cohérence entre ce qui est livré et ce qui était planifié, notamment grâce à la vélocité. La productivité est fonction du nombre de points délivrés par rapport à un nombre d’intervenants, de toutes les parties.

Le niveau qualitatif portera généralement sur l’implication et la satisfaction des parties. L’implication se base sur les contributions à tout moment, tant durant les estimations que les rétrospectives, pour ne citer que ces moments. La satisfaction, bien plus classique, permet de valoriser un sentiment de satisfaction.

Ces indicateurs peuvent d’ailleurs servir de base contractuelle afin de favoriser une relation collaborative ou même permettre aux parties de quitter ladite relation.

L’impact sur la responsabilité

L’approche agile et itérative permet de faire en sorte que chaque cycle génère un produit directement utile. Une telle approche basée sur des retours dynamiques et en temps réel s’avère très utile pour le projet. La responsabilité partagée est, dès lors, clé du succès de tel projet.

Avec le niveau collaboration induit lié au changement d’approche, la responsabilité d’un échec ne peut être imputée exclusivement au prestataire. La responsabilité est alors partagée entre les intervenants. La responsabilité en cas de succès l’est également, ce qui s’avère bien plus intéressant. D’ailleurs le modèle participatif et actif du client dans le projet est alors une opportunité de transformer une gageure en une opportunité.

L’aspect financier

L’aspect financier des projets s’avère plutôt important pour les différents intervenants. Le coût pour l’un correspond aux rentrées pour l’autre et de ce fait il est fréquent de penser à mettre en concurrence des organisations qui doivent pourtant collaborer pour le bien être des projets. La collaboration nécessaire à l’agilité doit permettre à l’ensemble des parties de trouver un terrain d’entente dans un but commun : maximiser le retour sur investissement.

Pour se faire, nous l’avons vu, le projet peut s’arrêter après chaque itération en tenant compte de la période de préavis. Dans un tel contexte, il s’agit alors de trouver un modelé de facturation tenant compte du second facteur « valeur produite », le premier étant le coût. Différentes approches sont alors possibles pour établir le coût d’une fonctionnalité ou d’un ensemble de fonctionnalités. La facturation peut se faire par exemple sur base d’un mix entre taux horaire et nombre de points (ex : 35€/h + 200€/point). On se rappellera que la notion de point est définie dans les premiers sprints, la notion de coût associée est ainsi variable d’un projet à l’autre et d’une équipe à l’autre. C’est pour cela que chaque partie doit pouvoir sortir de la relation si le product backlog n’est pas acceptable par toutes les parties.

L’approche basée sur un taux fixe et un taux variable a plusieurs vertus positives. Le fait de livrer la même qualité en un temps moindre est économiquement plus intéressant que de miser sur la même livraison plus tard, tant pour le prestataire que le client.

Enfin, en clôturant le projet plus tôt, le client peut faire le choix d’interrompre les investissements s’il estime que ceux-ci ne produisent plus la valeur suffisante. Pour éviter un impact trop important pour le fournisseur, il souvent prévu de payer une indemnité équivalente à un certain nombre d’itérations calculées sur la partie fixe. Le nombre d’itérations couvertes est bien souvent défini sur base d’un pourcentage du temps qui était initialement planifié. A l’inverse, en cas de dépassement du planning initial, le tarif journalier peut être revu à la baisse, pouvant même descendre jusqu’à 50% de celui-ci. Dans un tel cas, le calcul n’est pas intéressant ni pour le fournisseur qui verra fondre sa marge sur le projet ni pour le client qui continue à payer pour des fonctionnalités qui étaient initialement prévues pour un moindre coût, c’est ce qui motivera l’ensemble à délivrer le nécessaire et s’arrêter à temps.

En résumé

Selon le manifeste, l’agilité repose sur les individus et leurs interactions, un logiciel fonctionnel, l’adaptation au changement et la collaboration avec les clients. Pour ce dernier, le manifeste précise d‘ailleurs que la collaboration est à préférer à la négociation contractuelle.

Pourtant le contrat est nécessaire selon la loi. Ce qu’il faut retenir c’est que la contractualisation doit alors porter sur l’approche, la mesure et les responsabilités de chacun. Une fois ce cadre contractuel en place et en s’assurant de la collaboration, l’agilité peut alors s’exprimer et de la valeur est créée à chaque itération.

Smart DSI N°28