Pour l'amour du risque

Dans un dernier article, le concept de Dette Technique était comparé à celui de risque. A cette occasion, la notion de risque était très brièvement introduite. Cet article se propose de revenir sur cette définition succincte et de la détailler pour montrer comment les risques techniques peuvent être gérés sur un projet et comment cette gestion peut être le levier d'une amélioration des pratiques de développement logiciel. 

Qu'est-ce qu'un risque technique ?

Un risque peut être défini comme la possibilité d'occurrence d'un événement indésirable. Dans le cadre d'un projet de développement logiciel, on pourrait compléter la définition en précisant que cet événement indésirable dégrade la qualité du produit logiciel ou l'efficacité de sa réalisation.

Sur la base de cette définition, un risque peut être caractérisé avec les informations suivantes :

• La description de l'événement redouté,
• L'évaluation de son impact,
• La cause de l'événement redouté,
• La probabilité d'occurrence de l'événement redouté.

Cette caractérisation fait apparaître deux éléments qui sont de nature descriptive et deux éléments qui relèvent d'une quantification. Compte tenu de la difficulté de quantification des risques, de nombreuses méthodes de gestion des risques proposent une échelle de valeur simplifiée proposant 3 à 5 niveaux.

Pour l'impact, on aura a par exemple par ordre croissant d'importance :

1. Négligeable,
2. Mineur,
3. Moyen,
4. Majeur,
5. Catastrophique.

Côté probabilité d’occurrence, on aura par exemple par ordre croissant :

1. Très improbable,
2. Improbable,
3. Possible,
4. Probable,
5. Presque certain.

Pour préciser l'échelle de valeur, il n'est pas rare d'y voir associés quelques repères numériques. Par exemple, on pourra indiquer qu'un niveau de probabilité "Presque certain" sera utilisé si on estime la probabilité supérieure à 90% et qu'un niveau "Probable" traduit une probabilité entre 70% et 90%. En ce qui concerne l'échelle d'impact, donner des repères suppose d'introduire une catégorisation du risque. Par exemple, on pourra considérer que l'impact d'un risque se traduit par un retard de livraison de certaines fonctionnalités, auquel cas l'unité des repères de mesure de l'impact peut être un nombre de jours ou de semaines. Parmi les catégories classiques d'impact, on trouvera par exemple : le planning, les efforts, le coût, la conformité fonctionnelle, la conformité technique (par exemple non-respect d'exigences de sécurité ou de performances), la satisfaction des utilisateurs...

Cette catégorisation n'est pas ce qui distingue les risques techniques d'une autre famille de risques, celle des risques organisationnels. C'est plutôt dans l'origine du risque qu'on doit chercher à préciser ce qui fait d'un risque, un risque technique. En effet, dans un projet de développement logiciel, on peut distinguer la définition du produit à réaliser de l'organisation qui permet de le réaliser. Il arrive fréquemment que ces risques soient gérés de manière séparée parce que les responsables de la définition du produit et de l'organisation relèvent de personnes différentes.

Comment gérer les risques techniques ?

La caractérisation des risques évoquée ci-dessus suggère qu'il est nécessaire d'identifier et de suivre les risques. Cette nécessité est basée sur le postulat qu'il est plus efficace d'anticiper un problème que d'en subir les impacts sans y être préparé.

Gérer les risques techniques commence par une activité d'identification et de valorisation des risques.

• L'identification s'appuie le plus souvent sur les retours d'expérience des projets précédents. Outre un plaidoyer en faveur de la valorisation de l'expérience des profils techniques, cette proposition doit aussi nous motiver à partager nos retours d'expérience, en particulier ceux qu'on tire de nos échecs plutôt que de nos réussites.
• La valorisation du risque peut aussi largement tirer parti de l'expérience de celui qui l'identifie, mais elle pourra aussi s'appuyer plus globalement sur des retours d'expérience de l'organisation (projet ou entreprise) et mobiliser des activités d'analyse détaillée auprès de l'ensemble des membres de l'équipe (par exemple en faisant une estimation des travaux à mener pour remédier à la survenue d'un risque).

Une fois le risque identifié et caractérisé, se pose la question de la façon de le gérer. Plusieurs options s'offrent à nous :

1. Accepter. La quantification de la probabilité du risque et de son impact permet de caractériser son importance. Chaque organisation établit en général une matrice à deux dimensions permettant de définir l'importance d'un risque en fonction de sa probabilité et de son impact. Ainsi, un risque très improbable avec un impact négligeable pourra être qualifié d'acceptable. Et accepter un risque signifie qu'on ne fait rien. On attend qu'il se produise ou non. Attention néanmoins, le risque doit être suivi dans le temps : la probabilité d'occurrence ou l'estimation de l'impact peuvent être révisés et conduire à un changement d'importance au cours du projet.
2. Eviter. Si le risque n'est plus "acceptable", on peut alors décider de chercher à l'éviter. Eviter un risque consiste à travailler sur sa cause pour réduire sa probabilité d’occurrence. On cherche ainsi à jouer sur l'une des deux dimensions de la matrice de caractérisation pour ramener le risque dans une zone d'acceptabilité, voire à la supprimer. Prenons l'exemple de la réutilisation d'un composant logiciel fourni par un tiers et dont on identifie qu'il pourrait ne pas être maintenu sur la durée de vie du produit développé. Eviter le problème consiste à étudier les pistes alternatives, plus pérennes, pour remplacer le composant avant même son intégration.
3. Mitiger. Alors que l'évitement joue sur la probabilité du risque, la mitigation joue sur l'autre axe de caractérisation de son importance : l'impact. Mitiger vise à réduire l'impact du risque s'il devait survenir. Pour reprendre l'exemple du composant logiciel tiers dont la maintenance est incertaine, une action de mitigation consiste à concevoir une solution technique permettant de remplacer le composant s'il devait ne plus être maintenu. Contrairement à l'approche précédente, on accepte de garder le facteur de risque sur le projet, mais on cherche à amortir son impact.

Notons que les stratégies d'évitement et de mitigation peuvent être complémentaires : on peut chercher à la fois à réduire la probabilité d'occurrence du risque et son impact s'il était avéré. En jouant sur ces deux axes, on peut ainsi ramener un risque d'importance élevée dans une zone d'acceptabilité.

Prioriser et exécuter un plan d'actions

Les options évoquées ci-dessus pour gérer un risque donnent lieu à des actions : accepter, éviter ou mitiger. Ces actions alimentent un plan d'actions qui va devoir être géré. En effet, si une action d'évitement ou de mitigation d'un risque a un impact sur son importance, il vient aussi avec un coût comprenant au moins l'effort de mise en oeuvre. Les questions qui vont alors se poser sont :

• Dois-je réellement mener cette action ?
• Dans quel ordre dois-je lancer mes actions ?

Les actions identifiées pour éviter ou mitiger les risques doivent ainsi être traitées comme toute activité du projet : on doit en estimer l'effort, identifier les compétences requises pour la mener, vérifier la disponibilité des ressources et évaluer les coûts complémentaires (par exemple l'achat de licence d'un outil, ou la sollicitation d'une expertise externe à l'équipe). Une fois les actions du plan caractérisées, on peut alors mesurer leur ROI ("return on investment" ou retour sur investissement) pour vérifier que le jeu en vaut la chandelle. Même si nous sommes républicains, nous pouvons ici accepter que le ROI désigne les actions à réaliser et dans quel ordre.

Mais la question du ROI est loin d'être simple à adresser. A ce stade, j'ai en effet introduit des éléments non directement comparables. Si on reprend l'exemple proposé ci-dessus, le risque pèse sur la maintenabilité de la solution et est susceptible de mobiliser des actions se traduisant par des efforts supplémentaires et éventuellement par le prix d'une licence d'un logiciel tiers. Comment comparer maintenabilité, efforts et prix de licence ? Ma position sur ce sujet (dont je suis assez convaincu qu'elle ne fait pas consensus) consiste à tout ramener sur la même unité : l'Euro.

Je pense en effet que la plupart des critères de gestion des risques peuvent se ramener d'une manière ou d'une autre à une question financière. C'est évident si on parle d'acheter une licence. Mais c'est assez facilement transposable si on parle d'efforts et compétences à mobiliser puisque nos organisations valorisent un coût journalier moyen des collaborateurs. Dans le cas d'un décalage planning, il est aussi possible de projeter l'impact en euros si on considère l'impact financier d'un décalage d'un jalon de paiement, ou si le décalage induit une pénalité de retard. Dans le cas d'une non-conformité fonctionnelle, on peut évaluer l'impact sur la rentabilité du service rendu par le logiciel développé.

On peut également jouer sur des risques dérivés pour caractériser l'impact financier d'un risque technique. Dans le cas du problème de maintenabilité évoqué plus haut, on peut en effet le traduire par une perte fonctionnelle qui ne serait plus résolue sur la durée de vie complète du logiciel. Et si cette situation est inacceptable, par une estimation des coûts de remplacement du composant logiciel concerné.

Si on parvient à quantifier l'impact d'un risque et les actions associées, on peut alors évaluer leur ROI en pondérant l'impact du risque par sa probabilité d'occurrence. Si un risque présente 50% de chances de produire un événement dont l'impact est estimé à 10k€, alors l'impact pondéré est de 5k€. Si j'identifie une action de mitigation, dont la mise en oeuvre me coûte 1k€, mais qui permet d'amortir l'impact du risque de 5k€, alors je peux investir pour ramener mon risque à 2,5k€. Dans ce cas le ROI est de 1,5k€. Cette action pourrait par ailleurs être mise en balance avec une action d'évitement de 2k€ permettant de ramener la probabilité du risque à 10%. Dans ce cas, le risque pondéré est révisé à 1k€ et mon ROI est de 2k€.

Cette approche de la gestion de risque suppose de s'appuyer sur estimation du risque qui va au-delà de la caractérisation de la probabilité et de l'impact sur une échelle à 5 niveaux. Il faut en effet se projeter sur des valeurs absolues qu'il n'est pas toujours simple d'évaluer. Cette réserve appelle ainsi deux remarques :

• La première est qu'il faut accepter de consentir un effort permettant de mener une analyse affinée du risque. Pour que cet effort ne soit pas consenti sans espoir de contrepartie significative, il ne faut pas la mener sur les risques qu'on juge acceptables, et il ne faut pas la mener à court terme sur les risques les moins importants.
• La seconde est qu'il faut garder à l'esprit que les estimations de probabilité, d'impact et d'efforts sont soumis à une marge d'erreur qui peut être assez importante. Seules les conclusions nettes doivent être considérées comme valides. A l'inverse, un ROI très faible pourra être considéré comme nul et deux actions avec un ROI très proches pourront être considérés comme identiques.

Le Software Craftsmansip et le risque

L'analyse de risques permet de faire émerger des actions techniques qui vont dans le sens d'un produit de qualité et pérenne. En ce sens, c'est une activité convergente avec les valeurs du Software Craftsmanship, en particulier pour ce qui concerne nos ambitions de réaliser des logiciels bien conçus et d'apporter de la valeur en continu. Le partage des retours d'expérience, comme moyen d'identifier et caractériser les risques, est aussi vertueux du point de vue de la volonté de créer une communauté de professionnels. Mais, il n'est en général pas bien difficile de se convaincre entre crafters de la nécessité de mener telle ou telle action pour répondre à ces enjeux. Là où la gestion des risques peut en revanche aider, c'est dans la capacité qu'elle apporte à convaincre les parties prenantes moins sensibles aux enjeux techniques.

Le recherche d'excellence qui motive le Crafter se heurte souvent à une objection de sur-qualité de la part des parties prenantes qui tiennent les cordons de la bourse. Cette objection est parfois tout à fait justifiée. Mais lorsqu'elle ne l'est pas, le Crafter peine à convaincre du bien-fondé de ses propositions. Le pilotage par le risque peut alors être un levier de conviction essentiel : argumenter sur la plus-value des propositions de manière rationnelle, idéalement de manière chiffrée. Cette remarque doit se comprendre à la fois du point de vue des pratiques que l'on associe au Software Craftsmanship et du point de vue des choix techniques.

• Si on prend l'exemple du "Pair Programming", on reçoit souvent l'objection classique consistant à dire "Pourquoi mobiliser deux ingénieurs sur une tâche qu'un seul peut mener ?" Face à cette objection, on apporte notamment des arguments sur le niveau de qualité de ce qui est développé ou sur le partage de connaissances qui contribue à la polyvalence des membres de l'équipe. Pour que ces arguments portent, il me semble opportun de les mettre en regard de risques identifiés. Si un composant est identifié comme critique dans le logiciel et que sa défaillance éventuelle a des impacts importants, il peut être intéressant de le développer en binôme. Si une seule personne de l'équipe dispose de compétences clés pour la réussite du projet, travailler en binôme permet de mitiger le risque de perdre cette compétence unique. Et même s'il est difficile d'estimer l'impact du Pair Programming sur le niveau de qualité ou sur la polyvalence de l'équipe, les arguments auront plus de poids en étant associé à un risque qui a été reconnu par l'ensemble des parties prenantes.
• Un autre exemple serait celui du choix d'une structure logicielle pour un composant. Par exemple, une architecture hexagonale peut se voir reprocher d'être complexe et de nécessiter des efforts de développement supplémentaires (par exemple pour le développement des "mappers"). Mais une telle architecture permet aussi de réduire les adhérences technologiques qui peuvent faire l'objet de risques vis-à-vis de certaines réutilisations, ou de réduire les adhérences à des contrats d'interfaces mouvants. Découpler la logique métier d'un module réutilisé ou d'une API externe peut s'avérer utile pour mitiger certains risques, et le surcoût du style d'architecture peut être négligeable en comparaison des bénéfices escomptés.

Une gestion rigoureuse des risques est un atout précieux pour le Crafter qui souhaite argumenter en faveur des solutions qui lui semblent les mieux adaptées au contexte de ses réalisations. Et si cette gestion n'est pas toujours placée sous sa responsabilité, il lui sera utile de s'y intéresser et d'y contribuer dès qu'il le peut. Pas seulement Pour l'Amour du Risque.