Algorithmes racistes, sexistes… les biais algorithmiques sont un risque pour la confiance envers le recours à l’intelligence artificielle. En quoi consistent-ils ?
Le 8 Avril dernier, le ‘High Level Expert Group on AI’, sorte d’Avengers de l’Intelligence Artificielle dépêchés par la commission Européenne, présentait ses recommandations en matière d’éthique de l’IA. Basé sur une consultation publique ayant recueilli plus de 500 commentaires, ce rapport pointe, entre autres, le sujet du biais algorithmique et met en garde les acteurs de l’IA sur les conséquences négatives que ce dernier peut entraîner, de la marginalisation des minorités vulnérables à l’exacerbation des préjugés et des discriminations. Il présente ainsi les systèmes d’IA comme devant être de véritables acteurs de la diversité en impliquant dans leur développement la totalité des parties prenantes.
Des algorithmes racistes ?
Il y a aujourd’hui quelques années, Propublica, média indépendant d’investigation américain, publiait une étude simplement intitulée “Machine Bias”. Son message : C.O.M.P.A.S. (pour Correctional Offender Management Profiling for Alternative Sanctions), un algorithme largement utilisé dans les cours de justice américaines, serait racialement biaisé, avec pour effet de désigner comme potentiels récidivistes un trop grand nombre de personnes noires. Par la suite, l’expérience a démontré que le nombre de faux positifs chez la population noire était bien plus élevé que celui constaté du côté de la population blanche, comme relaté ci-dessous :
Tim Brennan, professeur de statistiques à l’université et co-fondateur de l’algorithme C.O.M.P.A.S., expliquait déjà que le concept de ‘race’ était selon lui difficile à complètement exclure du calcul de score, car également corrélé à des indicateurs indispensables pour l’algorithme tels que le niveau de pauvreté du prévenu, le taux de chômage constaté dans son quartier, … Retirer également ce type de données du calcul de score entraînerait selon lui une chute de la précision du prédicteur, précision alors quantifiée à 68% (précision : nombre de véritables récidivistes / nombre de récidivistes désignés). En aparté, on s’interroge déjà sur cette valeur qui, en pratique, image le fait qu’une personne analysée sur 3 serait désignée comme récidiviste, à tort. Même si les cours pénales américaines n’appliquent pas à la lettre le résultat de l’algorithme, on imagine bien l’influence de ce dernier concernant la décision finale…
Une manière simplifiée d’expliciter un algorithme serait de le décrire comme une liste finie d’instructions s’enchaînant selon des conditions logiques, produisant potentiellement une sortie en fonction d’aucune, une ou plusieurs entrées. Ainsi, peuvent être considérés comme algorithmes une recette de cuisine, un itinéraire GPS ou un ensemble d’instructions médicales. Appliqués au monde informatique, on peut les qualifier d’algorithmes numériques, transformant une ou plusieurs données d’entrée en une ou plusieurs sorties numériques. Ainsi, une simple formule qui, en considérant l’âge, le statut de fumeur, la pression artérielle et quelques autres caractéristiques d’un individu afin de prédire un risque d’AVC est un algorithme.
De manière plus précise, les algorithmes que nous adresserons dans cette suite d’articles sont ceux relatifs au machine learning, littéralement « apprentissage machine ». Soit la capacité pour un programme d’apprendre d’expériences passées pour anticiper des événements futurs. Nous nous focaliserons sur les algorithmes supervisés : ils ont besoin d’un grand nombre d’exemples en entrée pour pouvoir exercer sur une nouvelle situation ou événement à prédire. On retrouve tout un ensemble de situations où l’apprentissage supervisé est utile : reconnaître des personnes sur une photo, filtrer des spams dans une messagerie ou encore prévenir d’un risque de défaut de remboursement de crédit.
Le phénomène de biais, quant à lui, peut prendre plusieurs significations selon le contexte dans lequel il est nommé. Nous nous concentrerons ici sur les définitions englobées dans le spectre “statistiques appliquées”, mais il faut savoir que ce terme, en plus d’être le nom de bourgades du Lot-Et-Garonne et de la Virginie Occidentale, est applicable à de nombreux domaines (électronique, psychologie, …).
De manière non exhaustive, en statistiques appliquées, ce biais peut être de plusieurs types :
biais d’échantillonnage (données en entrée non représentatives de la réalité),
biais de mesure (mesurer un résultat selon tel ou tel indicateur),
biais d’auto-complaisance ou de publication (directement lié au biais cognitifs humains, le fait de ne publier des résultats que s’ils sont en accord avec ses propres croyances personnelles),
et bien d’autres…
Quel rapport avec les systèmes d’IA ? Eh bien ce sont ces biais statistiques qui se trouveront exprimés dans les modèles, du fait de la sélection des données d’entrée, de l’expression plus ou moins marquée de certains features du modèle ou encore de l’interprétation des résultats. C’est ainsi que, fonctionnellement, des algorithmes peuvent “accoucher” de résultats fonctionnellement biaisés : biais raciaux, de genre, d’âge, …
Le risque ?
De plus en plus de décisions sont aujourd’hui prises par des algorithmes. De l’analyse automatique des CV à celle des dossiers de demande de prêts, de l’ordre des publications sur un réseau social à la liste de publicités affichées sur le net, ces algorithmes prennent une place de plus en plus importante dans nos vies quotidiennes. C’est pourquoi y inclure, volontairement ou non, des biais de toute sorte représente un danger important. Il est certain que ces décisions, autrefois prises par des humains, étaient déjà sujettes aux différents biais cognitifs. Mais c’est bien l’industrialisation de ces biais qui pose le problème.
Big data doesn’t eliminate bias, we’re just camouflaging it with technology
Cathy O’ Neil
En considérant un algorithme, régi par des préceptes mathématiques, on pourrait penser que ce dernier est objectif par définition et dénué des biais qui peuvent affecter les décisions humaines. C’est le principe du MATHWASHING, derrière lequel beaucoup de décisions algorithmiques ont été dissimulées.
Mais alors pourquoi cette objectivité algorithmique et mathématique serait-elle une illusion ?
Les algorithmes sont conçus par des humains
Leurs créateurs sont en charge de décisions structurantes telles que le périmètre de données à utiliser, les éventuels poids attribués à ces données, … Et, par définition, les décisions humaines sont biaisées, volontairement ou non. Par exemple, utiliser des données de genre pour déterminer quelles annonces d’emploi mettre en avant sur la page LinkedIn d’un individu a eu pour effet de recommander, en moyenne, des offres moins rémunérées pour les utilisatrices.
Les données en entrée sont également subjectives
Les algorithmes traitent les données qu’on leur présente en entrée. Ni plus, ni moins, sans avoir la possibilité d’évaluer leur caractère biaisé. En effet, les données reflètent toutes sortes de biais sociétaux bien ancrés, en plus d’en perpétrer des anciens. Quid de l’utilisation de données raciales dans un pays qui prônait la ségrégation raciale un demi-siècle plus tôt ? Quid de l’éradication du pay gap quand la plupart des données utilisées pour entraîner les algorithmes reflètent ce problème majeur de société comme une situation normale, ou au moins nominale.
Ainsi, cette amplification du biais peut être accidentelle (utilisation involontaire de données biaisées) mais également réalisée en toute connaissance de cause et d’effet, soit dans un but de manipulation de la décision algorithmique (ex : design de la ‘Gerrymandering map’ optimale), soit encore dans une optique de dé-responsabilisation : l’algorithme encaisse ainsi la responsabilité des décisions biaisées prises par les humains sur son bon conseil.
En résumé,
Ces considérations viennent alimenter un spectre plus large de problématiques relatives à l’éthique de l’IA. Il va sans dire que l’explicabilité de l’IA est un défi pour la suite de l’ère IA dans laquelle nous sommes entrés depuis quelques années. On connaissait le problème classique d’éthique de l’IA imagé par le MIT sur son site ‘Moral Machine’. Celui-ci permet, à l’aide d’une mise en situation, de sensibiliser les utilisateurs aux choix difficiles effectués par les IA embarquées dans les voitures autonomes. Dans le même esprit, myGoodness interroge sur l’attribution de sommes d’argent à des causes humanitaires ou avec objectif d’enrichissement personnel.
L’utilisation d’algorithmes d’intelligence artificielle est une forte opportunité de progrès technologique, et ce de manière très transverse. Toutefois, une perte globale de confiance en leurs résultats pourraient entraîner ce pan important de la recherche dans un nouvel hiver de l’IA si jamais leur caractère objectif venait à être décrié et leurs biais prouvés. Il en va donc de la responsabilité de leurs créateurs d’en faciliter la transparence, de leurs utilisateurs d’en vérifier l’accord avec les lois et de la totalité de la population d’exercer une pensée critique vis à vis des résultats obtenus.
Comprendre la limite des algorithmes aidera à juger leurs recommandations. De par leur définition, données et algorithmes réduisent une réalité complexe à une vision plus simple du monde. Seules les parties mesurables de cette vision devraient être utilisées. Il convient ainsi d’éviter la religion de l’algorithme et la vision réductrice inhérente, en gardant des décideurs humains dans la boucle du choix.
Dans une seconde partie, nous nous concentrerons sur les différentes approches existantes permettant de réduire voire d’éradiquer ces biais algorithmiques, pour des systèmes aux décisions plus justes et peut-être un jour réellement objectives…
Note : l’étude menée par Propublica sera par la suite fortement contestée par une étude gouvernementale. Indépendamment de la véracité des résultats, Propublica aura mis sur la table le sujet du biais algorithmique et l’aura rendu compréhensible (à minima accessible) au plus grand nombre.
Et si le client n’était que la partie visible de l’iceberg ? Pour tous les “transformers” digitaux des entreprises, l’objectif est de mieux connaître les clients. Imaginez cependant que vos clients vous écartent de votre véritable objectif : maîtriser la totalité de votre patrimoine de données.
Priorité client ne signifie pas priorité SI client
Les métiers expriment le besoin de mieux connaître les clients. Le premier réflexe est donc de lancer des projets sur les outils permettant de travailler étroitement avec les clients. Par SI orienté Client, nous entendons ainsi parler par exemple de CRM, Data lake client, DMP. La priorité est ainsi souvent donnée aux outils centrés sur la relation client et centrés sur les métiers en contact quotidien avec les clients.
Vous faites cependant face à des changements rapides du marché et à la transformation des habitudes des clients, liés aux opportunités du digital. L’évolution du seul SI client ne répondra pas à ces changements. L’approche client ne doit donc pas être uniquement synonyme d’évolution du SI client : elle doit piloter l’analyse de l’évolution du SI au travers de l’évolution des attentes des clients.
Connaître les attentes des clients avant tout
Prenons quelques exemples pour démontrer que bien connaître les attentes des clients permettra d’avoir le socle de votre transformation.
Le premier exemple concerne la confidentialité des données. Garantir la confidentialité et être transparent avec les clients, sont des sujets qui vont révolutionner la relation avec les clients. “Aujourd’hui 54% ¹ de la “GenTech” (génération Z) s’inquiètent quant à l’accès qu’ont les organisations à leurs données”. Les entreprises devront garantir et prouver à cette génération (les futurs clients) qu’ils répondent à la réglementation qui se développe sur le sujet.
Le deuxième exemple concerne le parcours d’un client qui cherche une assurance habitation. Suite à un ciblage et à une campagne par e-mail il est informé d’une toute nouvelle assurance habitation. Il ne donnera pas suite cependant car il n’a pas trouvé les informations détaillées sur la nouvelle assurance. Le parcours client ne comprend plus uniquement le fait de communiquer et de fournir un prix : il s’agit aussi de mettre à disposition les caractéristiques détaillées des produits pour faciliter l’acte d’achat.
Le dernier exemple concerne la disponibilité produit. Selon une étude PwC, “85% ² des enseignes françaises déclarent générer des revenus sur plusieurs canaux”. Cependant les clients souhaitent connaître la disponibilité d’un produit peu importe le canal. Intégrer tous les points de vente dans vos stocks est la réponse qu’attendent dorénavant les clients.
Ces quelques exemples montrent qu’il est primordial d’avoir une vision à 360° des attentes des clients pour capter l’exhaustivité des besoins. Cette exhaustivité est le socle pour opérer votre transformation. Comment alors ensuite construire ce socle? Le plus sûr chemin pour y parvenir est de travailler à l’échelle de vos données.
La capillarité des données, base de la Transformation
La donnée est présente dans tous les processus, en contact ou non avec le client. C’est la capillarité des données. Pour répondre à l’ensemble des attentes des clients, il faut donc préférer travailler les données au travers de leurs utilisations.
Ainsi par ricochet, de nombreux sujets SI transverses seront adressés grâce à la capillarité des données. Collecter les données, créer des référentiels, mettre en place une gouvernance pour garantir la mise en qualité des données, garantir des informations en temps réel, connaître l’état d’avancement de processus, sont des sujets transverses à adresser dont tous les clients bénéficieront.
La capillarité des données oblige en effet à se concentrer la maîtrise du patrimoine de données. L’analyse des attentes des clients au travers des données, va donc petit à petit faire émerger le SI permettant de maîtriser ces données : un SI Data Centric.
Être data centric est pérenne
Les bénéfices d’un SI Data Centric sont de construire un SI agile, évolutif et pérenne.
Définir au travers d’une approche “données” des principes de gouvernance et de mise en qualité, oblige à avoir des architectures SI orientées données, basées sur des “piliers SI” tels que les référentiels, les échanges, les outils de qualité de données et les workflows.
Cette transformation sera durable tout en étant évolutive. Peu importe le besoin, le référentiel client alimente les systèmes liés à ce besoin. De même, les outils de qualité sauront s’adapter à tous les sujets business. Pour finir, l’approche API, conçue à partir de vos données, des besoins, et s’appuyant sur une conception fonctionnelle transverse à votre entreprise, sera aussi un outil robuste face aux changements des habitudes de vos clients.
A chaque nouveau besoin, vous enrichirez un de ces “piliers SI”. Chacun vous sollicite et profite de l’approche et de la capillarité des données. L’effet en est ainsi démultiplié avec l’accumulation des projets.
Il reste cependant à savoir si vous avez la capacité à définir votre approche par les données et à mettre en place ces “piliers SI”.
L’expert en vaut la chandelle
De la collecte à la mise à disposition des données, les “piliers SI” doivent garantir la bonne gestion des données et permettre de mieux satisfaire les clients. L’enjeu business est donc important.
Pour cela, des experts sur les SI Data Centric sont indispensables. L’expertise garantit d’optimiser les coûts et les plannings de construction du SI Data Centric autour des “piliers SI”. D’ailleurs, maintenant qu’il est établit qu’un SI répondant aux besoins clients est un SI Data Centric, quels sont les “piliers SI” à construire ?
Le phénomène d’API GraphQL est en progression, aujourd’hui sommes-nous prêts à abandonner à nouveau tout ce qui a été fait sur les API ces 15 dernières années et passer à un nouveau concept d’intégration ? Le GraphQL est-il une option viable pour remplacer l’API telle que nous l’avons définie jusqu’à aujourd’hui ?
Qu’est ce que le graphql ?
Le GraphQL se résume par la mise à disposition d’une interface de requêtage qui s’appuie sur les mêmes technologies d’intégration utilisées par les API REST. Nous allons toujours passer par le protocole HTTP et par un payload de retour, préférablement au format JSON, mais la différence pour le client repose sur le contrat d’interface.
Si nous essayons de vulgariser, les réponses apportées par le REST et le GraphQL à la même question sont fondamentalement différentes.
Analysons la question suivante : qui es-tu ?
Voici comment elle serait abordée par Rest et par le GraphQL
Le REST :
QUESTION : qui es-tu ?
REPONSE : voici ma pièce d’identité (ni plus, ni moins)
Le GraphQL
QUESTION : quels sont ton nom, prénom, date de naissance, adresse de résidence, lieu de travail et tes coordonnées personnelles ?
RÉPONSE : voici toutes ces informations ciblés (et tu peux avoir encore plus de détails si tu veux, en une seule fois)
On a affaire ici à un changement radical dans la manière d’aborder les requêtes.
La DATA reste l’élément central de la réflexion autour du GraphQL. Sur ce point, nous pouvons voir l’héritage venant des paradigmes du REST, avec une focalisation sur la ressource. Alors que les pratiques précédentes, comme le SOAP, étaient plus axées “action”, le GraphQL est très axé sur la DATA, l’objectif primaire étant la manipulation de la donnée et pas l’exécution d’une opération.
Le concept de DATA est cependant présenté différemment. Elle n’est pas contrainte par une structure strictement définie à l’avance mais il est désormais possible de la naviguer par l’API GraphQL, ce qui change complètement le concept du contrat d’interface.
Il n’y a donc plus de contrat d’interface ?
Nous pourrions en déduire que le contrat d’interface, très cher aux démarches SOAP et REST, n’est plus d’actualité pour le GraphQL…
Notre vision se résume en une simple phrase : ”Le contrat d’interface change de forme. Il n’est plus centré sur la structure de l’information retournée par l’API mais s’intéresse au modèle de données lui-même”
Le contrat d’interface s’appuie sur le modèle de données qui devient encore plus crucial puisqu’il est maintenant directement exposé / connu par les clients de l’API. Pour rappel, nous avons défini le GraphQL comme un langage de requêtage qui s’appuie sur la structure de la donnée définie dans notre schéma de modélisation. Bien qu’une couche d’abstraction ne soit pas totalement à exclure, le modèle de données, défini dans nos bases de données et exposé aux clients (par introspection ou connaissance directe), devient le point de départ de toute requête.
Cela saute aux yeux, la flexibilité est le grand avantage apporté par le GraphQL. Nous ne sommes plus contraints par le retour de données défini par le fournisseur de l’API mais uniquement par la donnée qui nous est mise à disposition. Cela permet de réduire le phénomène de l’underfetching (obligation d’utiliser plusieurs appels car un seul ne permet pas de remonter la totalité des informations nécessaires) et de l’overfetching (récupération de plus de données par rapport au besoin réel), vrais casse-têtes lors de la conception des APIs.
L’autre vrai avantage est la rapidité de mise en œuvre. Sans vouloir rentrer dans la réalisation, la mise à disposition d’une API classique a toujours comporté des longues périodes de réflexion sur le périmètre, le découpage, la profondeur des données retournées. Ces phases de réflexion qui, sans un besoin clair en face, avaient tendance à se prolonger et à réduire le Time-To-Market des APIs. GraphQL permet de pallier ces problèmes :
En libérant le fournisseur de l’API de cette lourde tâche de conception,
En évitant la multiplication des APIs sur le même périmètre,
En facilitant le choix du périmètre de la part du consommateur, sans qu’il soit forcément obligé d’orchestrer plusieurs requêtes afin obtenir ce dont il a besoin, sans limites théoriques.
…mais aussi des contraintes
La liberté donnée au client de l’API est certainement un avantage pour les deux parties mais apporte également des contraintes de sécurisation et de gestion de la charge serveur.
La charge
Une API, REST ou SOAP, est globalement maîtrisée. Elle a un périmètre bien défini et donc la seule question à se poser porte sur la volumétrie et/ou la fréquence d’appel. Le GraphQL, par le fait que les requêtes sont variables, réduit la prévisibilité de la charge associée :
La non-prédictibilité des requêtes expose au risque de retours complexes et volumineux, sans pagination, ce qui pourrait mettre en difficulté une infrastructure mal dimensionnée ;
L’utilisation du cache est complètement révolutionnée / complexifiée, car la probabilité d’avoir la même requête de deux différents consommateurs est très faible et ne permet donc pas de s’appuyer complètement sur le cache pour décharger les machines.
La sécurité
Dans l’ancienne conception nous pouvions avoir des niveaux de sécurité induits par le périmètre restreint de l’API.
Le GraphQL, de par la liberté d’exploration des données, oblige à une réflexion plus profonde sur la question des habilitations et de l’accès aux informations. Cette sécurisation doit être garantie par une sorte de “douane” qui se définie comme la couche par laquelle nous devons transiter pour accéder aux données, et qui gère directement les droits d’accès par utilisateur.
Cette pratique n’est pas nouvelle, elle devrait accompagner toute démarche API, toutes technologies confondues. La couche de sécurisation et d’habilitations devrait toujours être indépendante de l’exposition de l’API. Parfois, un défaut de conception non identifié de cette couche de sécurité était pallié, tant bien que mal, par la limitation de périmètre imposé par l’API or cette limitation n’existe plus avec le GraphQL.
Conclusion
GraphQL représente la tentative la plus intéressante de “flexibiliser” la gestion des APIs et apporte une nouvelle dynamique à celle-ci, tout en respectant les contraintes induites par ce mode d’intégration.
Si l’objectif n’est pas forcément de “tout casser”, pour recommencer tout en GraphQL, cette approche devient une alternative concrète aux démarches API dites “classiques”.Exemple en est la mise en application de cette méthode d’intégration sur une plateforme de paiement, Braintree, filiale de Paypal.
Le marché du Serverless ou FaaS a bondi de manière importante en 2018, porté entre autres par la popularité grandissante de AWS Lambda, Azure Functions ou de Google Cloud Functions. Mais en quoi consiste une architecture Serverless ? Cela consiste à exécuter des fonctions sur le cloud sans se soucier de la conception de l’architecture technique et du provisionnement de serveurs. La facturation de ce type de service étant basée sur le temps que le traitement aura mis pour s’exécuter. Il y a donc toujours besoin de serveurs mais la conception et la gestion de ceux-ci sera réalisée à 100% par le fournisseur Cloud.
La différence avec une architecture basée sur des containers ?
La containérisation reprend les concepts de la virtualisation mais ajoute de la souplesse.
Un container est un sous-système pré-configuré par le biais d’une image. Celle-ci définit ce que le conteneur embarque à sa création (serveur d’application, application, etc.), normalement le minimum indispensable pour votre application (fonction ou micro-service).
Le Serverless est une architecture qui repose sur un concept simple : l’abstraction complète des ressources machine.
Il vous suffira par exemple d’avoir un compte AWS, cliquer “Create function” depuis la console, configurer quelques paramètres techniques comme la taille de la mémoire allouée et le temps de timeout maximum toléré, copier votre code et voilà !
Avantages et inconvénients
Le principal avantage de ce type d’architecture est le coût. Vous ne paierez que ce vous utiliserez basé sur des métriques à la seconde. Plus besoin de louer des ressources comme des machines virtuelles que vous n’utilisiez jamais à 100% ou de payer un nombre d’utilisateurs qui n’étaient pas connectés en permanence dans l’outil. Par exemple pour une fonction AWS Lambda à laquelle vous aurez attribué 128 Mo de mémoire et que vous prévoyez d’exécuter 30 millions de fois en un mois (pour une durée de 200 ms par exécution), vos frais ne seront que 10€/mois environ ! Si cela correspond à un pic saisonnier atteint en période de solde et que la moyenne d’exécution correspondra à la moitié de cette charge vous ne paierez que ce que vous aurez consommé. À titre de comparaison, un serveur virtuel de 1 coeur et 2 Go de RAM facturé au mois sera facturé 12€/mois, peu importe la charge. Et si un serveur de ce type ne suffisait pas, il faudra prévoir le coût d’une plus grosse instance ou d’une deuxième. Il est donc évident que le FaaS permet d’optimiser vos coûts par rapport à du IaaS ou du PaaS.
Le second avantage est qu’il n’y a pas besoin de gérer et maintenir l’infrastructure. Vous n’arrivez pas sur vos projets Agiles à anticiper vos besoins d’infrastructure ? Vous pensez qu’attendre 1 jour pour avoir une machine virtuelle c’est encore trop long ? Vous trouvez bien le principe des microservices mais vous trouvez compliqué de gérer une architecture technique distribuée ? Une architecture Serverless ou FaaS vous simplifiera la vie de ce point de vue.
Il y a cependant des désavantages. Les AWS Lambda et Azure Functions sont des technologies propriétaires qui vous rendront complètement dépendant de votre fournisseur. Si un jour vous désirez migrer sur une autre plateforme, il vous faudra revoir le code de votre application notamment si celui-ci fait appel à des services ou infrastructure propre à ce fournisseur (lire un fichier dans un container S3 par exemple ne sera pas de la même façon que de le lire sur un Azure Blob). L’autre point important aussi à surveiller est que ces services sont bridés en termes de ressources et ne conviendront donc pas pour des applications nécessitant des performances élevées.
Pour quels cas d’usage ?
Une architecture Serverless peut convenir lorsque les critères suivants sont réunis :
Cela peut être par exemple :
Le lancement d’une requête comme l’appel d’une API pour récupérer les données de météo et les déposer dans la base de données utilisée par une application mobile.
L’envoi de notification par messagerie pour prévenir un groupe d’utilisateurs d’un événement.
Le transfert et la vérification du format de fichiers multimédias pour un site permettant à des photographes de partager leur travail.
En résumé, il s’agit d’une nouvelle façon de concevoir votre architecture solution, pouvant vous permettre de réaliser des économies importantes mais qui vous rendra plus dépendant du fournisseur Cloud que vous aurez retenu.
En cette période de crise épidémiologique et de confinement, les approches PPM apportent chacune leurs qualités pour affronter les risques. Mais comment se distinguent-elles ?
Risque, incertitude, responsabilité : des visions distinctes selon deux approches
Les circonstances de la crise sanitaire actuelle, sont une occasion pour nous, professionnels des projets, d’être interpellés sur la dimension gestion des risques qui nous est essentielle. Comment est-elle appréhendée selon les approches Traditionnelle et Agile de gestion de produits, de projets et de portefeuilles ? En quoi ces approches sont différentes l’une de l’autre ?
Que l’on fasse cette observation au niveau opérationnel des projets ou au niveau de la supervision du portefeuille des projets, on constate que leurs notions « d’incertitude », de « risque », et de « responsabilité » les déterminent et les distinguent à la fois.
Que l’on parle d’une approche cycle en V, Cascade ou Stage/Gate applicable aux projets elles sont rattachées à une vision traditionnelle de la gestion qui se caractérise par une forte exigence d’anticipation des événements par la planification et le contrôle. A contrario, l’approche Agile est par définition une réponse à l’incertitude grandissante à laquelle font face les projets et portefeuilles de projets. Pour y parvenir, parmi les principes inscrits dans le manifeste Agile, on retrouve l’adaptation par rapport au plan et l’autonomie de décision. Cette posture d’adaptation aux circonstances implique celle de l’aptitude à agir en réaction aux événements et changements qui surviennent dans le déroulement des projets et des produits. Mais, face à la crise sanitaire du Covid-19 et à ses implications à la fois économiques, politiques et sociales que proposeraient ces approches en termes de traitement des risques ? La probabilité de la mise à l’arrêt de la société civile est allée grandissante en moins de deux mois, jusqu’à devenir une réalité aujourd’hui.
Un modèle du risque proactif ou réactif pour y remédier
Si nous sommes tous familiers avec la définition et les modalités classiques de gestion des risques, ce sont les divergences de considération de ce processus de gestion selon ces deux approches qu’il est intéressant d’analyser.
Classiquement, avec l’approche traditionnelle, l’identification, la qualification et la réduction des risques participent de la planification et du pilotage des projets et portefeuilles. Il est essentiel de s’appuyer sur une base de risques déjà identifiée et d’une taxonomie des risques la plus ouverte possible tout en étant spécifique à l’activité de l’entreprise. L’expérience vécue par la Chine et observée pendant les premières semaines de l’année a pu servir de référence à de nombreux chefs de projets pour deux raisons. Elle a relevé progressivement la probabilité de l’épidémie à son niveau maximum pour devenir la réalité que l’on connait. Mais, elle a aussi servi de modèle pour figurer et projeter les impacts de son expansion à un point que personne n’avait encore imaginé. La maturité de chacun face aux risques a donc permis d’atténuer les effets de la criticité de ceux identifiés à mesure que l’épidémie prenait place. Les plans de charge des projets et des portefeuilles ont été révisés et les calendriers aussi.
Pour ce qui est de l’approche Agile, la notion de risque est plus difficile à isoler, puisque son esprit pousse à la réactivité face aux événements. Sans intention d’anticipation dans les projets et les portefeuilles et la continuité de services des équipes produits, le parti pris est celui de traiter des problèmes par l’adaptation des méthodes et des livrables au fil des itérations sans que cela n’en dégrade la qualité, qui constitue son principal levier de décision. En l’absence de culture du risque, les acteurs des équipes Agile s’en remettent plus à l’intuition du groupe qu’à la raison des experts. Qu’en est-il lorsque un à un les membres de l’équipe deviennent indisponibles pour raison médicale ou privée ? Enfin les pratiques rigoureuses de cette approche se retrouvent mises à mal par la perte de l’unité de lieu des acteurs imposée par le confinement et le recours au télétravail. Le leitmotiv du « time to market » pour satisfaire le client est momentanément inaccessible.
La gestion du risque : extension de la responsabilité
La gestion des risques se définit par son exigence d’anticipation des événements pouvant faire obstacle aux objectifs visés. Pour ce faire, il faut convenir d‘hypothèses de réduction de son occurrence et de ses effets qui peuvent prendre la forme de contingences retranscrites dans la planification. Tout le travail des responsables tient à identifier, qualifier et envisager ces mesures de réduction en adéquation avec les moyens à leur disposition.
Dans le cas de l’approche classique, la responsabilité de la culture du risque est portée par la ligne managériale, puisque par délégation, il est du ressort du chef de projet de concevoir et d’animer la trajectoire du projet qui vise le résultat dans les termes annoncés au client. Cette forme de déclinaison de la prospective à l’exercice de la planification s’appuie sur la production de scénarios liés à des opportunités et à des risques auxquels des hypothèses de « survenue » sont associées. Lorsque cet exercice est entretenu tout au long des projets, il implique à son tour une révision régulière pour ajuster les hypothèses en privilégiant le levier de pilotage dominant : le temps, le budget, la valeur client. Reste qu’une telle démarche est très consommatrice de temps et se retrouve, dans les faits, incompatible avec l’accumulation des fonctions des chefs de projet. Néanmoins, dans les circonstances actuelles, la coordination des différentes activités et des prises de décisions, de plus en plus souvent réalisée à distance, ne souffre pas de la mise en place du télétravail comme solution de continuité des activités même si les contingences déterminées à l’engagement des travaux ne seront pas suffisantes.
A l’inverse, dans le cas de l’approche agile, la responsabilité est collectivisée au niveau de l’équipe. Les membres de l’équipe mis en situation d’autonomie basée sur la confiance, se retrouvent porteur chacun d’une part de responsabilité. Cette dernière intègre les considérations de l’incertitude, des évolutions de l’environnement interne et dans une moindre mesure externe. Cependant pour exercer cette responsabilité, c’est par leurs interactions en face à face que leur crédo « on fait avec et la vie continue » leur permet d’assumer et de résoudre les problèmes rencontrés. Dans les circonstances actuelles, le mode projet agile résiste bien de par sa capacité à gérer le chaos, au moins tant qu’il n’est pas rendu inopérant par trop de bouleversements.
Les 2 approches résistent à la crise
En fin de compte, aucun des deux modèles n’est pris en défaut. Si l’un privilégie l’anticipation des opportunités et obstacles à la planification en se donnant les moyens de les réduire, et si l’autre est focalisé sur la capacité à délivrer quelques soient les circonstances sans se préoccuper de prévoir des contingences. Ces deux modèles sont à même de faire face à des événements imprévus.
De son côté le Bureau des Projets compose son propre modèle de gestion de produits, de projets et de portefeuille. Historiquement géré en approche traditionnelle, il adopte quelques éléments des pratiques agiles « façon puzzle » (comme l’effort de développer l’autonomie ou la capacité à innover). Sans reprendre suffisamment les principes des approches dont il s’inspire, pour causes de manque de moyens, de temps, de conviction ou d’appui de la Direction, le bureau projet se contente de mettre en place quelques rôles, artefacts et cérémonies. Mais dans ces conditions sa transformation échoue à interpréter le changement de paradigme qu’elle recherche. Parce que, l’interprétation du traitement des risques dans toutes ses dimensions n’en deviendra ni cohérente ni complète. A qui la faute ?
Globalement, on peut donc être rassuré. Ces deux approches de gestion de projets et portefeuille projets peuvent faire face chacune à leur manière à la crise actuelle, comme les Etats le démontrent à leur niveau. La Chine a pris le parti de la planification de mesures jusqu’à effet complet. Tandis qu’en Europe et notamment en France, la résolution est préférée en réactivité aux constats avec des consignes révisées au fil des itérations de plus en plus rapide à mesure que les faits s’accélèrent.
Dans ces conditions, quel que soit l’approche choisie, il faut convenir qu’il est essentiel de développer collectivement et individuellement une culture du risque aussi légitime que le sont celles de la qualité ou de la valeur client. Elle est indispensable face à l’incertitude grandissante de nos sociétés qui perd jours après jours son insouciance.
