Gestion de Projet Informatique :
Comment Analyser et Gérer les Risques ? 

La culture du risque n’est plus un sujet confidentiel dans les entreprises. L’actualité révèle chaque jour son lot de menaces dont les conséquences peuvent être lourdes pour le fonctionnement et la pérennité des organisations.  

Assez logiquement, puisque la digitalisation est croissante, les DSI sont en bonne place pour jouer un rôle clé dans la gestion de ces risques, d’autant que les risques purement IT (cybercriminalité, défaillance d’un datacenter, prestataire qui fait défaut…) sont crédibles et font courir des menaces tangibles. 

Mais derrière des concepts généraux, c’est la réalité opérationnelle de tous les projets informatiques qui doit faire l’objet d’une analyse et d’une gestion des risques. Forcément avec des nuances, tous les projets IT ne pouvant être mis sur un pied d’égalité.  

Alors comment piloter efficacement les risques dans une direction informatique ? De l’identification à l’analyse, de l’évaluation au traitement du risque, comment s’armer avec pragmatisme et discernement ? Éléments de réponse. 

Qu’est ce qu’un risque ? 

Il s’agit d’un problème potentiel qui pourrait intervenir dans l’exécution d’un projet ou d’une activité, identifié en amont. Dit autrement, un risque est un point de faiblesse dont la survenue pourrait avoir un impact négatif et entacher la bonne marche ou le bon déroulement d’un projet, en l’éloignant du scénario initial imaginé lors de son lancement.  

Quels sont les risques possibles dans un projet informatique ? 

 On peut regrouper les risques en 3 grandes catégories :  

• Risques liés au produit : le livrable peut comporter de manière inhérente des difficultés techniques ou fonctionnelles, ou encore des lacunes de sécurité ; il s’agit donc d’évaluer quelles sont ces complexités. 
• Risques liés aux moyens consacrés ou dévolus au projet : il peut s’agir aussi bien de ressources humaines que matérielles. Exemples de risques assez classiques : budget qui dérape ou qui est insuffisant, pénurie de compétences, manque de disponibilité des équipes. 
• Risques liés à la conduite du changement : mise en run, mise à disposition, gestion des utilisateurs. 

 Si dans ces 3 catégories, un point ressort comme saillant lors de la phase d’analyse, c’est qu’il constitue un risque potentiel. Tout l’enjeu consiste alors à évaluer sa gravité et la probabilité qu’il intervienne. 

Quelle méthode pour évaluer les risques ? 

Il existe de nombreuses méthodologies de cartographie et d’évaluation et des risques ; leur finalité : ne rien écarter et mettre au point un scoring pour hiérarchiser. Pour un non expert, cette gestion des risques peut faire peur, car on a rapidement l’impression qu’elle mobilise des compétences avancées, difficiles à maitriser correctement sans une formation dédiée.  

Pour autant, faut-il faire l’autruche ? Certainement pas. Ayons plutôt en tête qu’il n’existe pas de recette toute faite pour identifier les risques d’un projet informatique, ni de formation magique. Par nature, un risque va être dépendant de nombreux facteurs tant internes qu’externes à l’entreprise. C’est avant tout une bonne connaissance de ce contexte qui permettra de les détecter avec discernement en veillant à ne pas passer à côté de quelque chose.  

Ainsi, à défaut d’une maitrise parfaite de méthodologies « certifiées » pour cartographier et évaluer les risques, commençons donc par considérer qu’au sein d’une DSI, gérer les risques relève d’abord et avant tout d’un management de projet sain et concret, ouvert et à l’écoute des aléas qui pourraient avoir un impact sur le cours des choses. 

Les directions informatiques sont plutôt en bonne place pour assurer ces missions : « culturellement », une DSI cultive naturellement un savoir-faire d’analyse et d’évaluation parfaitement en phase avec l’approche de gestion des risques. Ainsi, un incontournable une fois le risque identifié consiste à l’évaluer sur la base d’un scoring. Un risque avec un score élevé devra faire l’objet d’un suivi. Un risque mineur pourra être mis de côté. Or savoir scorer un risque pour le hiérarchiser n’est pas si différent de savoir scorer un projet pour l’arbitrer. Les deux situations font appel à l’objectivité et au pragmatisme de modèles mathématiques. 

Exemple de matrice de criticité des risques : 

Comment mettre en place une gestion pragmatique des risques ? 

Selon sa taille, une DSI gère une volumétrie de projets souvent conséquente, mais tous les projets ne se valent pas : tous n’ont pas la même sensibilité, la même criticité, la même ampleur (en termes de moyens mobilisés, de durée, etc). La gestion des risques se doit donc d’être pragmatique.  

D’autant que nombre de DSI et plus globalement de PME et ETI n’ont pas une culture du risk management aussi élaborée que celle que l’on peut trouver dans des entreprises de taille plus conséquente – avec des directions dédiées, ou dans des secteurs d’activité réglementés. Il serait donc vain voire contre-productif d’envisager de suivre dans le temps l’exhaustivité des risques identifiés et encourus. Seuls les risques majeurs devront faire l’objet d’un suivi. 

Concrètement, il faut considérer que même simple, un projet n’est jamais exempt de risques ; mais il n’est pas pour autant nécessaire d’ambitionner de tous les suivre. Identifier les 3-4 risques vraiment saillants est en règle générale suffisant. 

Comment piloter les risques ? 

Les risques les plus critiques doivent évidemment faire l’objet d’un plan d’actions dédié visant à les traiter et à éviter qu’ils ne surviennent ou ne s’aggravent. Potentiellement, ces actions auront un impact sur le déroulement initialement envisagé du projet et viendront modifier le scénario initial. Objectif : désamorcer ces risques. 

Mais il faut surtout garder en tête que le scoring des risques établi au lancement du projet est mouvant et dynamique : À chaque revue de projet, à chaque nouveau reporting, toute la liste initiale des risques doit être revue, repassée au radar afin de réévaluer l’incidence potentielle de chaque « danger » qui pourrait percuter la bonne marche du projet. Le risque A, B, ou C est-il toujours aussi critique ? Quelle est la probabilité qu’il intervienne ? 

 Aussi, ce pilotage dynamique a tout intérêt à être historisé pour pouvoir conduire une analyse rétrospective si besoin. Il est dans ce cadre pertinent d’avoir recours à des outils de suivi des portefeuilles projets qui apportent un cadre commun à tous les projets de la DSI. Cela permettra par exemple, lors des revues de projet, d’identifier les dérives, risques et difficultés grâce à des indicateurs de suivi communs et des points d’alertes remontés explicitement par les flashs reports. De même, plus la gestion des projets est finement intégrée aux autres composantes du management de la direction informatique (budget, équipes, fournisseurs par exemple), meilleure sera la capacité d’identification et de suivi du risque : un dérapage budgétaire, un sur-staffing ou une alerte sur un prestataire pouvant ainsi être remonté et partagé en temps réel pour adapter sans délai la décision si nécessaire. 

Vers un pilotage macro des risques 

Le pilotage des risques inhérents à chaque projet est bien souvent la responsabilité du chef de projet. Pour le DSI, il est intéressant d’avoir une vision plus macro de tous les risques identifiés et encourus au niveau d’un portefeuille projets par exemple. Cette vision consolidée, cumulative, peut permettre de faire émerger des thématiques qui ressortent fréquemment ou quasi systématiquement. Elles sont alors révélatrices d’une tendance de fond qui n’est plus conjoncturelle mais bien structurelle. Et qui pourra alors faire l’objet d’un plan d’actions dédié pour modifier plus en profondeur un système. 

L’enjeu d’insuffler la culture du risque et de responsabiliser tous les acteurs

Dernier point, mais il n’est pas à négliger : Un écueil classique du management du risque consiste à considérer que parce qu’un risque est identifié, consigné, suivi, parce que l’on s’est doté des outils adéquats pour le traiter, le sujet de la gestion des risques est correctement et suffisament adressé et maitrisé.  

Cela n’est pas suffisant. Au contraire, face à l’ensemble des vulnérabilités et des menaces potentielles, la vigilance doit être de mise pour tous les acteurs de la DSI, et même au-delà. 

Chaque collaborateur doit être sensibilisé, acculturé à la gestion des risques, qui ne doit, du reste, pas rester l’apanage de la Direction des Systèmes d’Information et dédouaner les autres directions de l’entreprise d’une vigilance accrue à ce sujet.  

Ainsi, au sein d’un projet, s’il est normal qu’une personne – souvent le chef de projet – soit responsable de la cartographie des risques, il ne peut y avoir de bonne gestion des risques si elle n’est pas pleinement intégrée à la réalité opérationnelle du projet. Et partagée par l’ensemble de l’équipe. Concrètement, cela implique que dans l’entreprise, chaque acteur du projet soit conscient des enjeux liés à ces risques et capable de modifier ses actions ou comportement en conséquence. Et que cette sensibilité aux risques soit suffisament partagée, et s’inscrive dans un système global de collaboration et de communication, pour que le chef de projet, le manager d’équipe, le DSI lui-même, soient en capacité de capter les signaux faibles qui peuvent gonfler, dégonfler ou engendrer de nouveaux risques. Une capacité d’écoute qui jouera beaucoup dans la capacité à gérer les risques de manière performante, au sein de la DSI, et au-delà.  

À bon entendeur… 

Bien gérer les risques au sein d’un portefeuille projets avec Abraxio