Dev
L’Agile au forfait, comment changer la posture des Achats ?
Par La rédaction, publié le 04 mars 2020
De nombreux DSI évoquent la contractualisation comme un frein au déploiement de l’Agile. Après des décennies de contractualisation au forfait, l’expérience a montré les limites du modèle.
Par Thierry Cartalas, Associé, TNP Consultants
et Mejdi Hizem, Expert Agile, TNP Consultants
Historiquement, les directions Achat privilégient la contractualisation au forfait pour obtenir un engagement de résultat au meilleur coût (à travers le mécanisme de mise en concurrence).
Or l’achat de livrables définis à l’avance sur la base d’un cahier des charges n’est pas compatible avec l’approche agile. De plus, l’expérience a montré les limites des forfaits dans la maîtrise effective des délais et des coûts.
En effet, d’une part le cahier des charges initial n’est jamais exhaustif et suffisamment détaillé pour être univoque. D’autre part, dans un monde en évolution constante, les besoins métier évoluent au cours du projet. Dès lors, quelle posture adopter pour contractualiser une prestation agile ?
Reprenons les fondamentaux. Dans un projet agile, le Product Owner (représentant du métier) a pour objectif d’optimiser la valeur métier (par exemple l’expérience client) en procédant à une révision régulière des cas d’usage à développer. Il a donc besoin d’une « usine » lui offrant une grande prédictibilité dans l’implémentation des fonctionnalités. La fonction Achat se doit, donc, de décliner les attendus de cette usine en engagements de productivité, de qualité, de capitalisation, de sécurité… que les soumissionnaires à l’appel d’offres devront prendre – la logique du « mieux-disant » primant sur celle du « moins-disant ».
Contractualiser un engagement de productivité
Dans un contrat Agile, le fournisseur s’engage à livrer un volume fixe de fonctionnalités (par exemple un nombre de points de complexité) par sprint de durée fixe (par exemple 3 semaines), après une phase d’étalonnage. Charge à lui de dimensionner ensuite son équipe et d’en assurer la stabilité dans le temps. En cas de non-livraison du volume attendu pour un sprint donné, l’écart est reporté au sprint suivant. Le prestataire est alors tenu de renforcer son dispositif pour absorber ses retards, sans impact de coût supplémentaire ou de qualité pour le client.
Pour les programmes de grande taille faisant intervenir plusieurs équipes agiles, le fournisseur devra prendre un double engagement. Le premier est sur la productivité de chaque usine agile. Le deuxième portera sur sa capacité à intégrer régulièrement (par exemple, lors des incréments tous les 3 mois) les livraisons de chaque usine pour fournir un produit complet.
Contractualiser un engagement de qualité
Avec l’Agile, une application évolue en continue, ce qui contraint à porter une attention particulière sur sa qualité. Cette dernière peut être mesurée par différents indicateurs, les plus communs étant le niveau d’automatisation des tests et la qualité intrinsèque du code source de l’application (son évolutivité, sa résilience aux cyber-attaques…). Dans une logique d’engagement Agile, un niveau cible pour chaque indicateur de qualité (par exemple le nombre d’anomalies) devient engageant pour le prestataire et sujet à pénalités.
Formaliser l’engagement du métier, sponsor du projet
Pour que le projet soit efficient, une usine agile performante devra être alimentée en exigences bien formalisées et en nombre suffisant en amont de chaque sprint. En pratique, le Product Owner doit s’assurer, en permanence, qu’il y a suffisamment de « User Stories » pour alimenter l’équipe de développement lors du sprint suivant. De plus, il est recommandé d’intégrer au contrat la notion de « Ready for development » qui définit les critères que doit respecter chaque exigence embarquée dans un sprint. Ces critères peuvent être de forme, de complétude (par exemple en matière de structure de données) ou de délais de validation à respecter.
Après des décennies de contractualisation au forfait, l’expérience a montré les limites de ce modèle, notamment vis-à-vis des utilisateurs dont les besoins évoluent plus vite.
Dans un contrat Agile, l’accent est mis sur les engagements du prestataire pour réaliser une « usine » agile garantissant au client la livraison prédictible et de qualité des cas d’usage qu’il priorise tout au long du projet.
Par conséquent, la fonction Achat doit désormais comprendre les mécanismes qui font la performance d’une « usine » agile pour contractualiser de nouveaux engagements basés sur des indicateurs contractuels de maîtrise du delivery, d’automatisation (DevOps) et de fiabilité du produit IT final en résultant (solution).
A lire également dans notre série thématique sur l’Agile :
Comment impliquer le Métier dans les projets Agile ?
Être Agile sans « soft skills », est-ce possible ?
L’Agile a-t-il besoin d’un chef de projet ?
L’automatisation, une nécessité pour créer de la valeur en Agile
Transformation Agile à l’échelle : quelle stratégie pour votre entreprise ?
Le bien-être de l’équipe, l’autre vertu de l’Agile
Convertir son entreprise à l’Agile… en douceur
Méthodes agiles : il est temps de passer à l’échelle !
