Ces cinq dernières années ont vu l’inéluctable progression des méthodes Agile au sein des SSII, au prix d’un nouveau chamboulement des modèles de production, pourtant eux-mêmes mis en place avec force et rigueur durant une décennie d’industrialisation de l’ingénierie logicielle. Cette période tendait en effet à apporter la fiabilité, la sureté et la maturité promise par l’industrie logicielle. Par Sébastien Lachèvre, Directeur de projet Banque & Assurance chez Gfi Informatique.

Pourtant c’est un autre concept fortement industriel lui aussi, puisqu’issu du Lean Management, qui entend y opposer de nouveaux paradigmes de développement : proximité des utilisateurs plutôt que centre de service, interaction plutôt que spécification, équipe plutôt que spécialisation, souplesse plutôt que contrat. Autant de contradictions qui bousculent un modèle de production et de business pourtant bien établi.

Une nouvelle opportunité de création de valeur

On pourrait assimiler le modèle de progression des méthodes Agile à celui du monde open-source qui l’a précédé de quelques années. Dans les deux cas il s’agit en effet de la diffusion d’un modèle de rupture, bousculant son écosystème. Des acteurs nouveaux créent leur business model en se reposant sur cette nouvelle différenciation. Finalement les grands comptes investissent le domaine, entrainant avec eux les grands acteurs historiques de l’intégration.

Pour autant le besoin ne dit pas le comment. La première tentation des grands comptes a été, et est toujours en partie, de traiter tout nouveau projet Agile sur un mode d’assistance technique. Cela résout bien sûr l’exigence de proximité et évite de se poser la question du périmètre, tout au moins vis-à-vis du prestataire. Les mesures qualitatives rejoignent alors celles imposées à un centre de ressources ou de compétences. Mais finalement la notion d’engagement, qui est pourtant le cœur de sa valeur ajoutée en termes d’ingénierie, est complètement éludée.

Cette situation, aussi confortable qu’elle puisse paraitre, ne peut constituer une solution en soi. Il est nécessaire de se poser la question de la prise en compte du risque à s’engager en mode Agile et à appréhender la difficulté d’évoluer dans un périmètre fonctionnel flou. L’objectif est justement de positionner des offres dont la valeur est aussi portée par l’ingénierie et le mode d’engagement.

Une méthode structurée propice à l’engagement

Avant d’envisager de promouvoir la valeur apportée par un engagement Agile, il faut d’abord tordre le coup à certains lieux communs. On associe souvent Agilité et manque de vision fonctionnelle, absence de pilotage, développement quick and dirty (littéralement « rapide et sale ») ou encore possibilité d’en faire plus pour moins ! L’Agilité répond pourtant à des enjeux strictement inverses.

La méthode Agile est structurée par des actes de pilotage quotidiens, assurant la transparence de l’avancement et du contenu. Elle est rythmée par des boîtes de temps fixes (timebox), ce qui signifie que chaque période de développement est intégrée dans un délai rigoureusement contraint et donc fixé à l’avance. Elle détermine l’ensemble des exigences qualitatives au travers de la définition du fini, permettant ainsi de fixer ce qu’est un livrable pouvant être soumis à validation. Enfin elle cadre les exigences, en associant un système de valorisation par « points de complexité » qui implique l’engagement de l’ensemble de l’équipe et non le seul chef de projet.

Nous avons là l’ensemble des ingrédients de base permettant de déterminer une nature et un terme d’engagement.

Une pluralité de modèles de contrats

Ces propriétés de la matière Agile permettent d’élaborer un certain nombre d’outils qui serviront à la construction d’offres de service adaptées aux contextes les plus variés. Nous pouvons présenter quelques-uns de ces outils en les scindant en deux catégories : les outils de forfaitisation et les outils d’engagement.

Les outils de forfaitisation

• Prix fixé. C’est la clause qui rassurera tous les acheteurs. L’engagement, au travers de l’évaluation de la backlog, est ferme en termes de nombre de points de complexité et donc, par transitivité, en terme de coût !

• Délai fixé. Dans la mesure où le dispositif mis en place est évalué pour permettre de produire un ensemble de points déterminés et que les sprints respectent les boîtes de temps, le délai peut être considéré comme fixe.

• Le bonus/malus. Il s’agit d’un système d’évaluation du niveau de la qualité. En évaluant un certain nombre d’indicateurs de qualité, on construit une part de variable sur le coût de développement initial. Les formules et indicateurs pris en compte peuvent varier en fonction des clients et de leur niveau de maturité à les mesurer.

Les outils d’engagement sur la valeur produite

• Engagement sur la production de 80 % du nombre de points de complexité initialement évalué lors de la constitution de la backlog. L’objectif de la règle est d’induire un certain niveau de variabilité sur le contenu fonctionnel en acceptant que le changement puisse provoquer un écart de plus ou moins 20% par rapport à l’évaluation de départ. En somme il s’agit de partager le risque inhérent à la gestion de spécifications émergentes.

• Clause de changement gratuit. C’est le pendant de la règle précédente, l’intégrateur accepte les demandes de changement, propres à la construction de spécifications émergentes. Evidemment ces changements sont conditionnés d’une équivalence de points de complexité entre les demandes sortantes et les demandes entrantes. Mais la variabilité de 20 % induite par la règle précédente permet de s’assurer du risque.

• Partage des gains et des pertes. Cette règle, couplée à la première, est attachée à la notion de facturation de la valeur et non de la dépense. Elle se propose de reporter, sur le coût global du projet, l’écart entre la valeur évaluée dans la backlog de départ et la valeur réellement produite. Cela peut être assimilé à la notion de bonus/malus appliqué au périmètre fonctionnel.

• Clause Gagnant-Gagnant. Cet outil permet au client d’arrêter le projet après la production d’un sprint, considérant que le logiciel lui suffit en l’état, ou que finalement il n’a plus d’intérêt au regard de l’enjeu de départ. Le fournisseur se trouve dédommagé en touchant 20 % du montant restant à produire. L’objectif est de limiter les risques pour le client, notamment dans le cadre d’une innovation, et de lui permettre de garder la main sur la continuité du dispositif mis en place.

Une stratégie portée sur la valeur

A partir de ces éléments il est possible de définir un mode de contractualisation prenant en compte le niveau de maturité des acteurs et les risques associés. On le voit, les possibilités sont nombreuses et n’ont pour seule limite que l’imagination des acheteurs et contractants.

Néanmoins, et au regard de la pluralité des solutions, le monde des Agilistes s’interroge encore sur la maturité des modèles d’engagement possibles. L’impression dominante reste que le Graal du contrat type, adapté à tous les projets, n’existe pas (encore ?). Mais est-ce réellement là un manque de maturité ?

On peut d’ores et déjà arguer que les contrats Agiles apportent une vraie rupture dans l’usage : ils valorisent le prix de la valeur métier plutôt que le coût des ressources nécessaires à la produire. De ce point de vue, au moins, les outils de contrat sont parfaitement en ligne avec la méthode !

En conclusion, on retiendra que la possibilité d’utiliser des outils de contractualisation multiples et divers constitue un important levier de différenciation. L’intelligence et la pertinence du choix de l’engagement conduit bel et bien à donner une valeur supplémentaire aux offres, ce qui constitue en définitive une excellente nouvelle pour les intégrateurs et leurs clients.

Sébastien Lachèvre, Directeur de projet Banque & Assurance chez Gfi Informatique