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