Gestion pragmatique des risques
Gestion pragmatique des risques

"La principale fonction du chef de projet est la prévention des risques"

Le pilotage du risque consiste en premier lieu à répertorier et analyser les risques pouvant affecter le déroulement du projet et les événements susceptibles d’en déclencher l’apparition.

Le pilotage du risque recouvre ensuite la justification et l’élaboration d’un plan d’action.

Le plan d’action consiste à mettre en œuvre des actions préventives, à surveiller l’évolution et la matérialisation du risque, et à engager, si nécessaire, des actions curatives.

Le niveau de pilotage des risques est dépendant du type de projet.


Le livret : Techniques de pilotage du risque en projet de développement   (150 Ko)

Calibrage du risque et pilotage

Le pilotage du risque doit être envisagé suivant le principe économique du " nécessaire et suffisant "  en fonction de la taille et de la typologie de chaque projet.

Ce chapitre constitue une initiation et permet d’atteindre un niveau de levée de risque suffisant pour la plupart des projets. Dans le cas où votre projet nécessiterait un suivi des risques plus soutenu que celui proposé, ou si vous souhaitez des informations sur l’identification des risques, reportez-vous à mon dernier livre.

Comparer une méthode de conduite de projet classique avec les principes du RAD, sous l'angle de la gestion du risque projet (délais, qualité, etc.) par exemple, peut être édifiant pour un cartésien :

  • l'approche classique tente de réduire les risques par une démarche spécifique et déterministe dont les coûts préventifs (analyse, détection, suivi et correctif ) ne sont pas négligeables ;

  • toujours pragmatique, le RAD s'appuie sur la compétence de l'équipe SWAT qu'il engage dans des pratiques permanentes orientées " performance " et " validation " afin d'éviter naturellement la concrétisation du risque (figure 1, tableau 1).

  • Figure 1. — Décroissance des risques par type de développement

    Principes simplifiés de pilotage

    Principes du suivi de risque

    1. Identifier le risque

  • Répertorier les risques potentiels.

  • Déterminer les déclencheurs (événements ou conditions).

  • Evaluer la probabilité d'apparition.

  • Estimer les impacts (coûts, délais, qualité).

  • Calculer la gravité du risque (probabilité + impact).

  • Définir les actions correctives (préventives et curatives).

  • 2. Evaluer le coût de suivi du risque

  • Traduire le risque en coûts.

  • Evaluer les coûts des suivis et des actions.

  • Décider de l’opportunité de suivi.

  • 3. Surveiller le risque

  • Déterminer les indicateurs d'alertes.

  • Déterminer les fréquences de surveillance.

  • 4. Réduire le risque

  • Mettre en œuvre les actions prévues.

  • Classification basique des risques

    Type de risques  " stratégique et financier "

  • Stratégiques.

  • Financiers " développement " et financiers " exploitation ".

  • Les risques de ce type sont généralement répertoriés et levés lors des phases d’initialisation et de Cadrage. Les dirigeants doivent être informés du suivi de cette classe de risques.

    Type de risques " développement " 

  • Technologiques (émergence, obsolescence).

  • Contraintes (délais, budget, visibilité).

  • Ressources (nombre, compétences, motivation).

  • Méthode (par phase).

  • Qualité Fonctionnelle (adéquation, couverture, évolution).

  • Qualité Technique (interruption).

  • Qualité Documentation.

  • Qualité Tests (ressources, suivi, impact).

  • Qualité Formation.

  • Déploiement.

  • La levée des risques de ce type est liée à la qualité de la conduite de projet durant les phases de DESIGN et de CONSTRUCTION.

     

    Tableau 1. — Facteurs d'échecs en développement

    Ces facteurs occasionnent :

    Retard

    Dérive

    Qualité

    Les utilisateurs réels ne sont pas impliqués dans les spécifications

     

    x

    x

    Les concepteurs ne développent pas

     

    x

    x

    Les Focus de présentation ne sont pas respectés

    x

     

    x

    Les ressources sont affectées à temps partiel

    x

       

    Le reste de l’organisation refuse le " mode projet "

     

    x

     

    La structuration des phases n’est pas respectée

    x

     

    x

    Les livrables intermédiaires ne sont pas réalisés et validés

     

    x

    x

    La dimension temporelle (120 jours) n’est pas respectée

    x

       

    L’équipe ne travaille pas en synergie et complémentarité

    x

    x

    x

    La modélisation est absente ou inadaptée

    x

    x

    x

    L’équipe projet n’est pas isolée des perturbations

    x

       

    Le matériel est sous dimensionné ou inadéquat

    x

     

    x

    Les outils (modélisation, développement) ne sont pas homogènes et universels

    x

       

    Type de risques " exploitation "

  • Evolution organisationnelle.
  • Fiabilité de l’exploitation.
  • Sécurité des données (*).
  • (*) Ce type de risques découle de la qualité de la production générale informatique.

    Le tableau 2 qui se trouve généralement associé à la fiche d’un risque permet un suivi temporel de l’évolution de la gravité d’un risque.

    Tableau 2. — Evolution de la gravité du risque

    Inacceptable

    Critique

    *

    *

    Tolérable

    *

    Significatif

    *

    *

    *

    Mineur

    *

    Lorsque l’application manipule des données dites " sensibles " ou est ouverte sur l’extérieur de l’organisation, une étude complémentaire des risques liés à la sécurité doit être menée. C’est fréquemment le cas lors du développement d’applications de communication ou de commerce électronique. Si vous ne disposez pas d’un outil spécialisé, utilisez la fiche standard (tableau 3) pour répertorier un risque. Une fiche permettant de récapituler les risques suivis se trouve en annexe.

    FICHE DE RISQUE

    Tableau 3. — Fiche simplifiée de gestion d'un risque

     

    Levée des risques " développement "

    L’analyse des principaux facteurs négatifs en matière de conduite de projet (tableau 3) confirme les conséquences évidentes de situations tout aussi évidemment dangereuses (de l’avis partagé des professionnels de bon sens). Pourtant, dans la réalité des projets, ces évidences se trouvent régulièrement ignorées. Il est possible d’appliquer le RAD sur un projet de dix ou quinze jours, comme sur un projet de trente années-homme ou plus. Néanmoins, au-dessous d’un certain seuil de quelques dizaines de jours, seule une organisation disposant déjà de l’expertise et de l’environnement de travail RAD peut obtenir des bénéfices immédiats avec cette méthode.

    Tableau 4. — RAD : levée du risque en Construction

    Validation permanente : intervention systématique et planifiée de l'utilisateur réel dans la validation de sa future application qu'il s'approprie.

    Jalons zéro-défaut : étape planifiée de la réalisation où l'application est garantie validée techniquement et fonctionnellement.

    Focus : exercice planifié de visibilité et de validation visant à faire reconnaître l'avancement du projet et la qualité de l'application par le plus grand nombre d'acteurs impliqués dans le projet.

    Etat de livraison permanente : conservation de l'état stable de l'application après un Focus, permettant son exécution, pour présentation impromptue, validation, ou livraison partielle.

    Livraison en fonctionnalités réduites : application partiellement achevée, mais ayant atteint par une planification adaptée (souvent par thèmes), un niveau d'utilisation possible, par des utilisateurs conscients des limites d'un produit à l'élaboration duquel ils ont participé.

    Identification des risques pour chaque phase

    La liste suivante est constituée de points à vérifier. Elle doit être considérée avant tout comme un outil de sensibilisation à la potentialité du risque.

    Chaque point doit être considéré mais ne nécessite pas obligatoirement l’ouverture d’une fiche de risque. Il faut toujours respecter le principe du " nécessaire et suffisant " dans la mise en œuvre d’une gestion minimale du risque.

    Risques en phase INITIALISATION

  • L’application est-elle stratégique pour l’organisation (avantage concurrentiel) ?
  • L’utilisation de l’application peut-elle affecter l’image de l’organisation ?
  • L’application s’inscrit-elle prioritairement dans le plan directeur de l’organisation ?
  • Le périmètre du projet identifie-t-il exhaustivement les domaines impactés ?
  • La mise en service de l’application aura-t-elle un impact organisationnel ?
  • Les acteurs sont-ils représentatifs de l’ensemble des métiers concernés ?
  • Les structures projet sont-elles clairement définies (comités, acteurs, etc.) ?
  • Les objectifs sont-ils connus de tous et diffusés à tous les acteurs concernés ?
  • Un examen des autres projets a-t-il dégagé les interactions à considérer ?
  • La planification de la phase Cadrage est-elle approuvée ?
  • Les participants de la phase Cadrage sont-ils identifiés et disponibles ?
  • Le pilote et les coordinateurs MOA sont-ils suffisamment expérimentés ?
  • Les représentants de l’informatique et des utilisateurs travaillent-ils en synergie ?
  • Les calculs de budget et de délais sont-ils réalistes dans le contexte du projet ?
  • Les performances attendues sont-elles réalistes en regard de la solution envisagée ?
  • Risques en phase CADRAGE

  • Les acteurs ont-ils les compétences et l’expérience requises pour un Cadrage ?
  • Les décisionnaires disposent-ils formellement de pouvoirs suffisants ?
  • Les concepteurs ont-ils une bonne pratique de l’identification des exigences ?
  • Tous les domaines et métiers impactés sont-ils pris en considération ?
  • Tous les acteurs actuellement recensés ont-il été interviewés ?
  • L’existant (organisation, éléments techniques, etc.) est-il répertorié
  • Les exigences sont-elles clairement définies et validées ?
  • Les évolutions possibles sont-elles clairement identifiées ?
  • L’architecture fonctionnelle de l’application est-elle stabilisée ?
  • Le volume des données à traiter est-il estimé ?
  • La conception technique garantie-t-elle l’obtention des résultats escomptés ?
  • Les choix d’environnement technique sont-ils compatibles avec le budget ?
  • La maîtrise d’ouvrage a-t-elle défini la future organisation ?
  • Le scénario de transition a-t-il été approuvé ?
  • Les contraintes de changement sont-elles identifiées et maîtrisées ?
  • Les solutions proposées ont-elles été validées par tous les acteurs ?
  • Les solutions proposées sont-elles cohérentes avec le plan directeur ?
  • Les techniques et outils de développement prévus sont-ils maîtrisés ?
  • Les techniques et solutions innovantes bénéficient-elles d’un support adéquat ?
  • L’estimation des coûts est-elle basée sur une évaluation détaillée et complète ?
  • Les choix fonctionnels sont-ils compatibles avec le budget et les délais ?
  • Risques en phase DESIGN

  • Les acteurs ont-ils les compétences et l’expérience requises pour un Design ?
  • Le Modèle des Communications (MCC) est-il complet ?
  • Le niveau de description des données est-il satisfaisant (MCD) ?
  • La description des traitements est-elle satisfaisante (MCT / MOT / DFD / HF) ?
  • La modélisation est-elle clairement comprise par la maîtrise d’ouvrage ?
  • L’ergonomie du poste est-elle acceptée par les utilisateurs ?
  • Les traitements prévus permettent-ils de satisfaire les exigences ?
  • Les écarts entre exigences et possibilités sont-elles identifiés et acceptés ?
  • La cohérence entre les modèles est-elle vérifiée ?
  • Le premier niveau de prototype est-il validé ?
  • Le Design ne modifie-t-il pas le volume de données prévu en Cadrage ?
  • Le Design ne modifie-t-il pas la charge de travail prévue pour la Réalisation ?
  • L’environnement technique est-il confirmé viable ?
  • Les choix techniques sont-ils compatibles avec les projets parallèles ?
  • La mise en place de l’environnement technique est-elle compatible avec le planning ?
  • La stratégie de reprise des données est-elle prise en compte ?
  • Les contraintes d’organisation sur la reprise des données sont-elles acceptées ?
  • Les sous-projets et les lots sont-ils planifiés sans dépendances coûteuses ?
  • L’intégration des sous-projets est-elle prise en compte dans les estimations ?
  • Les estimations de charges sont-elles validées et réalistes ?
  • Risques en phase CONSTRUCTION

    Réalisation et mise au point

  • L’environnement de développement est-il opérationnel et dimensionné ?
  • La compatibilité et la stabilité des versions de logiciels est-elle garantie ?
  • L’environnement de développement est-il maîtrisé par les développeurs ?
  • Les règles de programmation sont-elles publiées et respectées ?
  • Des revues de code sont-elles organisées en préalable aux Focus ?
  • Les jeux d'essais ont-ils été préparés par la maîtrise d'ouvrage ?
  • La Construction se réalise-t-elle en " prototypage actif - validation permanente " ?
  • Les cas particuliers ont-ils été recensés, et leur réalisation a-t-elle été planifiée ?
  • Les données prises en compte pour les validations sont-elles homogènes et complètes ?
  • Les règles de gestion et de contrôle sont-elles définies ainsi que leurs interactions ?
  • Les demandes n’induisent-elles pas de difficultés techniques imprévues ?
  • Les documentations produites seront-elles utilisables pour la suite du projet ?
  • L’enchaînement des écrans correspond-t-il au mode organisationnel prévu ?
  • Les imprévus n’accroissent-ils pas la charge prévue pour le projet ?
  • Les problèmes techniques rencontrés sont-ils résolus sans dégradation du code ?
  • La couverture des tests unitaires est-elle jugée comme suffisante (MOE et MOA) ?
  • Les défauts relevés en tests unitaires sont-ils corrigés en " validation permanente " ?
  • Cheminements fonctionnels et intégration

  • Les performances sont-elles mesurées et satisfaisantes ?
  • Les scénarios des tests d’intégration ont-ils une couverture fonctionnelle complète ?
  • L’avancement des tests est-il connu et satisfaisant ?
  • Les évolutions et corrections sont-elles réalisées en qualité standard ?
  • Des tests de non-régression sont-ils effectués régulièrement ?
  • Les contraintes de délai n’ont-elles pas entraîné d’impasses sur les tests ?
  • Les outils de reprise de données sont-ils testés et fiables ?
  • La documentation de réalisation est-elle suffisante et intégrée au code ?
  • Risques en phase FINALISATION

    Finalisation RAD standard

  • Le Plan de formation est-il compatible avec le planning du projet ?
  • Les moyens de formation sont-ils disponibles (salle, matériels, supports) ?
  • Les formations sont-elles planifiées en fonction des besoins de l’utilisateur ?
  • Les formations respectent-elles les possibilités et les connaissances des utilisateurs ?
  • Les dates des sessions sont-elles compatibles avec les contraintes opérationnelles ?
  • Les supports de formation sont-ils produits par des spécialistes qualifiés ?
  • Les supports de formation ont-ils été validés par des utilisateurs significatifs ?
  • Les pratiques actuelles des utilisateurs ont-elles été prises en compte ?
  • La complétude du Manuel Utilisateur a-t-elle été vérifiée (cas d’exception) ?
  • Le Manuel Utilisateur recense-t-il les messages d’erreur prévus ?
  • Le Manuel Utilisateur fait-il état des limites de l’application ?
  • Le vocabulaire et les exemples sont-ils totalement compréhensibles ?
  • Finalisation RAD étendue

  • Les procédures d’organisation sont-elles cohérentes avec les choix et orientations ?
  • La transition entre les procédures actuelles et les nouvelles procédures est-elle préparée ?
  • Les obligations de service de l’exploitant sont-elles liées à des indicateurs vérifiables ?
  • Les engagements mutuels de la maîtrise d’ouvrage et de l’exploitant sont-ils précisés ?
  • L’exploitant a-t-il les moyens (matériels, techniques, humains) de remplir ses obligations ?
  • La montée en charge est-elle délimitée dans le temps et définie en termes d'objectifs ?
  • Les habilitations sont-elles effectuées et validées ?
  • Le manuel d’exploitation est-il approuvé par les exploitants ?
  • Le manuel d’exploitation prend-il en compte l’ensemble des traitements de l’application ?
  • Le manuel d’exploitation est-il cohérent avec l’environnement technique prévu ?
  • Le manuel d’exploitation est-il basé sur les volumes d’information réels à gérer ?
  • Le plan d’information sur le démarrage opérationnel (objectifs, calendrier) est-il communiqué ?
  • Les contrôles de données reprises manuellement ont-ils été réalisés ?
  • Les moyens de vérification de la qualité des données reprises sont-ils opérationnels ?
  • Les travaux d’infrastructure et les achats de matériels sont-ils lancés ou prévus ?
  • Les manuels et des support sont-ils reproduits et distribués en nombre suffisant ?
  • Le plan de déploiement est-il cohérent avec les choix d’environnement technique ?
  • Le plan de démarrage est-il construit en prenant en compte toutes les activités ?
  • Le plan de démarrage est-il connu et approuvé par les utilisateurs ?
  • Les volumes de données à migrer sont-ils connus ?
  • Les procédures de vérification et correction des données reprises sont-elles prévues ?
  • La charge et la durée de la reprise des données sont-elles évaluées ?
  • Les traitements faisant l’objet de la recette sont-ils clairement identifiés ?
  • Les conditions de la recette sont-ils connus : couverture, complétude, utilisation ?
  • Les rôles pour la recette et la préparation de la recette sont-ils connus et acceptés ?
  • Les conditions de la recette sont-ils connus et acceptés ?
  • La durée prévue de la recette est-elle réaliste au regard des difficultés classiques ?
  • Les utilisateurs qui réalisent la recette sont-ils formés à ses principes ?
  • Les utilisateurs qui réalisent la recette ont-ils une disponibilité suffisante ?
  • L’environnement de recette est-il opérationnel ?
  • Les tests et les données de recette sont-ils préparés pour être réutilisables ?
  • Les données employées pour la recette sont-elles représentatives et suffisantes ?
  • L’applicatif vérifié en recette sera-t-il l’applicatif opérationnel ?
  • L’avancement de la recette (essais, divergences détectées et corrigées) est-il maîtrisé ?
  • Les contraintes de délai n’ont-elles pas entraîné d’impasses sur la recette ?
  • Les divergences détectées sont-elles correctement caractérisées par les utilisateurs ?
  • Le processus de correction des divergences est-il maîtrisé ?
  • Les demandes d’évolution sont-elles recensées et maîtrisées (impact en charge et délai) ?
  • Le manuel utilisateur a-t-il été employé dans un contexte opérationnel  ?
  • Le procès-verbal de recette est-il basé sur des mesures objectives de qualité ?
  • La version de l'applicatif livrée à l’exploitation est-elle celle qui a été complètement testée ?
  • Démarrage de l’application et maintenance

  • Les procédures d’exploitation sont-elles conformes aux normes en vigueur ?
  • Les procédures d’exploitation sont-elles livrées, documentées, testées, intégrées ?
  • L’environnement d’exploitation a-t-il été contrôlé (aspects secours et reprise) ?
  • L’applicatif est-il opérationnel dans son environnement d’exploitation ?
  • Les outils et manuels d’administration et de pilotage de l’application sont-ils prêts ?
  • L’exploitant a-t-il intégré la charge d’exploitation de l’applicatif dans son planning ?
  • La cellule d’assistance Utilisateurs est-elle opérationnelle ?
  • Le niveau de préparation de l’environnement applicatif est-il correct ?
  • La reprise des données est-elle mesurée dans son avancement ?
  • La complétude des données reprises est-elle contrôlée ?
  • Le service est-il ouvert dans des conditions d’exploitation acceptables ?
  • Le service est-il accessible à l’ensemble des utilisateurs dans les conditions prévues ?
  • Les sauvegardes et les archivages de l’ancien applicatif garantissent-ils qu’il peut être réellement réutilisé pour reprise ou recherche d’informations ?
  • La synchronisation de l’ouverture du service aux utilisateurs et de la mise en œuvre des nouvelles procédures organisationnelles est-elle suivie et satisfaisante ?
  • L’assistance utilisateurs est-elle suffisamment préparée et dimensionnée pour résoudre dans un délai normal les difficultés de démarrage ?
  • Une première vérification du niveau de service (conformément aux règles du contrat de service) est-elle réalisée ?
  • La documentation technique et les sources du logiciel et des procédures sont-elles à jour ?
  • La configuration exacte de l’environnement de développement et de test est-elle recensée ?
  • Les jeux d’essais sont-ils archivés, ainsi que leurs résultats ?
  • Les équipes d’évolution sont-elles formées aux procédures de modification, de recherche d’informations, de corrections et de tests ?

  • www.RAD.fr ® © Jean-Pierre Vickoff