Comment faire une analyse de risques ?

Qu’est-ce que le risque ?

Rien n’est moins sûr que l’incertain.
Pierre Dac (l’os à moelle)

Définition : Le risque est un danger éventuel plus ou moins prévisible qui peut affecter l’issue du projet. Il ne sera pas possible de tous les éliminer, le risque zéro n’existe pas.
Source : Le chef de projet efficace

Toute la question repose sur la capacité d’anticiper le risque:
Somme-nous capables d’estimer la probabilité d’occurrence du risque et d’en anticiper les éventuelles impacts en terme de gravité si jamais le pire arrivait. Comment les prévenir ? Et, le cas échéant, comment y remédier pour amortir les impacts ?
Voilà des questions qui méritent des réponse précises.

Mais attention, tous les risques ne sont pas prévisibles, il faudra bien compter avec les impondérables.

Comment évaluer les risques ?

Bien entendu, il est inconcevable d’envisager de se prémunir de tous les dangers inhérents à la conduite d’un projet complexe. Il est toutefois indispensable de procéder à une étude complète et raisonnée des risques potentiels plus ou moins prévisibles, afin de dépasser le stade des croyances fondées ou non. Une analyse rigoureuse est une bonne garantie de réussite. la démarche la plus simple se déroule en cinq temps majeurs.

La carte de « chaleur » pour classifier

La table qui suit est un exemple de ventilation des risques inventoriés en tenant compte de la criticité ou impact et de la probabilité d’occurrence :

• La zone rouge, de haute chaleur répertorie les risques inacceptables à aucun prix.
• La zone orange, de chaleur élevée identifie ceux qui nécessitent des palliatifs urgents.
• La zone jaune, de chaleur moyenne identifie ceux qui nécessitent des palliatifs préalablement définis.
• Ceux de la zone verte sont acceptables mais à surveiller selon les conditions définis au moment de l’élaboration de la table, ceux en vert le plus sombre peuvent être ignorés.

Table de classification des risques

Les 5 étapes de la méthode d’Analyse

Voyons maintenant comment dérouler la démarche afin de démarrer le projet en limitant autant que faire ce peut les risques d’échecs. Cette démarche se déroule en 5 temps majeurs, tous aussi importants l’un que l’autre.

1. Établir l’inventaire des risques

Il s’agit de ratisser large et de considérer toutes les formes de risques (humain, financier, organisationnel, technologique…)

Type de risques potentiels pour un projet : financiers, organisationnels, techniques, sociaux, environnementaux sont pris en considération sans aucune exception.

• Sources d’information : Enquêtes de terrain, exploration des archives, analyse de la mémoire des réalisations antérieures, consultation d’experts, expérience du chef de projet. Une large consultation de tous ceux qui ont approché par le passé un projet similaire est une source précieuse d’information.
• C’est aussi lors de cette étude que l’on mesure l’importance d’établir une mémoire des projets réalisés qu’ils aient réussi ou échoué.

Tous les risques inventoriés seront placé dans une table avec leur description, la table sera ensuite complété tout au long de l’analyse.

2. Pondérer les risques

Tous les risques n’ont pas la même probabilité de survenance, tous les risques ne sont pas égaux en terme de criticité. Il s’agit au cours de cette étape d’effectuer un classement rationnel.

• Gravité ou Impact : Sur l’axe des ordonnés de la table de classification ci-dessus. Il s’agit évaluer la criticité de chacun des risques en terme d’impact, de dommages et de conséquences. Là encore on hésitera pas à explorer la mémoire collective des projets passés.
• Probabilité : Sur l’axe des abscises de la table de classification ci-dessus. Ensuite, on évalue la criticité en termes de probabilité d’occurrence. Cet exercice n’est pas le plus aisé, on s’en doute. la précision en est toute relative, là aussi l’xpérience du collectif peut s’avérer importante.

Chaque risque de la table doit donc être pondérer, chaque critère est évalué de 1 à 5, le poids du risque est calculé comme le produit des deux critères précédents, pour ensuie évaluer sa couleur dans la table de classification ci-dessus et en déduire l’action requise.

3. Définir les parades

Pour chacun des risques, on se posera ces 3 questions successives :
– Peut-on l’éliminer ?
– Peut-on en limiter les effets ?
– Doit-on modifier le déroulement du projet ?

• Éliminer le risque. Est-il possible de l’éliminer en augmentant les ressources ou en intégrant dans l’équipe de nouveaux intervenants spécialistes de la question et plus aguerris ? Le coût sera l’un des principaux critères de jugement.
• Limiter les effets dévastateurs des sinistres potentiels. De même, la solution est souvent du côté de l’optimisation de la gestion des ressources.
• Réviser le projet. Faut-il modifier les orientations, limiter les spécifications et trouver des alternatives plus paisibles quitte à modérer les ambitions et à procéder à des simplifications ? Une précaution à prendre au cas par cas.
• Il ne faut pas non plus hésiter à limiter le périmètre du projet pour gagner en visibilité. les projets courts et rapidement mis en oeuvre son plus aisés à gérer et à intégrer dans l’existant.

4. Identifier les points critiques

Une étape souvent oubliée dans les études de risques.

Les risques sont changeants. La probabilité et la criticité évoluent au fur et à mesure de l’avancement du projet. Certaines phases du projet sont plus à risques que d’autres. Il faut les identifier.

• Lieux et/ou moments où la probabilité et/ou la gravité sont les plus importants, les instants du déroulement où il faudra redoubler de vigilance.

On le constate dans le cycle de vie d’un projet ci-dessous, à chaque jalon important une réévaluation des risques est réalisée :

Cycle de développement sécurité

5. Réviser la table des risques

La table des risques n’est pas statique, il faut la réviser régulièrement.

• Suivre l’évolution dans le temps de la criticité.
  Cette table n’est pas statique, elle n’est pas non plus une assurance.
  Prévoir un danger n’est pas s’en protéger !
• En outre, la dangerosité potentielle tout comme la probabilité d’occurrence évoluent au fil du temps et de l’avancement.
  Cette table sera soigneusement suivie et mise à jour très régulièrement.

Voici un exemple de table d’analyse des risques réalisée pur une salle informatique déportée :

Afficher ce document sur Scribd

Comment s’y prendre ?

Et bien en impliquant un maximum de monde, en fouillant dans les archives, en incitant « les experts du moment» à la communication quels qu’ils soient, où qu’ils se trouvent ? Toutes les péripéties des projets passés, comme les difficultés et la manière de les solutionner sont une mine de ressources pour la réflexion préalable à l’analyse de risques. Mais encore faut-il avoir pris le soin d’enregistrer les expériences passées…

Le soin apporté lors du déroulement de chacune des étapes l’analyse de risques est d’une importance capitale pour la réussite du projet.

Il existe des méthodes spécialisées selon le domaine d’activité, par exemple pour un projet de sécurité des SI on pourra utiliser les méthodes EBIOS (ANSSI) ou MEHARI (CLUSIF), mais dans leurs principe elles se déroulent comme indiqué ci-dessus.

Sécurité en développement logiciel

Développement et maintenance des systèmes

La stratégie d’une entreprise développant des logiciels se doit d’envisager les propriétés et les implications de la sécurité des applications, des systèmes et des services utilisés ou fournis par l’entreprise tout au long du cycle de vie d’un projet.

La charte de sécurité de développement des applications, systèmes et services de l’entreprise doit prévoir que les équipes et les personnes mettent en œuvre les mesures de sécurité appropriées dans les applications, les systèmes et les services en cours de développement, en fonction des risques et préoccupations de sécurité identifiés. La charte doit mentionner que l’entreprise dispose des rôles et des responsabilité de sécurité dont la mission est de fournir des lignes directrices de sécurité et d’assurer l’évaluation des risques.

L’entreprise doit mettre en oeuvre un certain nombre de mesures visant à garantir que les produits logiciels et services quelle propose aux utilisateurs soient conformes aux normes les plus strictes sur la sécurité logicielle. Cet article décrit une approche en matière de sécurité logicielle, celle-ci peut s’adapter et évoluer en fonction de l’organisattion et de la culture de l’entreprise.

Consultation et revue de sécurité

S’agissant de la conception, du développement et du fonctionnement des applications et services, les rôles de sécurité inclus les catégories principales de services de consultation suivantes aux équipes de développement, techniques et production :

• Revues de sécurité au niveau de la conception : évaluations au niveau de la conception des risques de sécurité d’un projet et mesures d’atténuation correspondantes, tout en considérant leur caractère approprié et leur efficacité.
• Revues de sécurité au niveau de l’implémentation : évaluation au niveau de l’implémentation des artefacts de code pour mesurer leur fiabilité par rapport aux menaces de sécurité applicables.
• Consultation de sécurité : consultation en continu des risques de sécurité associés à un projet donné et solutions éventuelles aux problèmes de sécurité, souvent sous forme d’exploration de l’espace de conception dans les phases initiales des cycles de vie des projets.

Une multitude de types de problèmes de sécurité peuvent intervenir au niveau de la conception du produit, c’est pourquoi ils doivent être pris en considération et résolus au plus tôt lors de la phase de conception du produit ou du service. La finalité essentielle de la revue de sécurité au niveau conception est de garantir la prise en compte de ces considérations. 

Dans ce cadre, la revue de sécurité au niveau de la conception se fixe les objectifs suivants :

• Fournir une évaluation de haut-niveau des risques de sécurité associés au projet, sur la base d’une recherche des menaces réelles en réalisant une analyse des risques.
• Procurer aux décideurs du projet les informations nécessaires afin qu’ils puissent faire des choix éclairés en matière de gestion des risques et intégrer les considérations de sécurité dans les objectifs d’un projet.
• Fournir des lignes directrices quant au choix et à la mise en œuvre correcte de contrôles de sécurité planifiés (par exemple : protocoles d’authentification ou chiffrement).
• S’assurer que l’équipe de développement dispose de la formation adéquate eu égard aux classes de vulnérabilités applicables, aux schémas d’attaque et aux stratégies d’atténuation appropriées.

Lorsque des projets impliquent des fonctionnalités ou des technologies innovantes, un des rôles de sécurité est chargé de rechercher et d’explorer les menaces, les schémas d’attaque potentiels et les classes de vulnérabilités spécifiques des technologies et fonctionnalités en question. Le cas échéant, l’entreprise peut sous-traiter à des prestataires la consultation de sécurité pour compléter les compétences de l’équipe de sécurité et obtenir une revue indépendante garante d’objectivité afin de valider les revues de sécurité internes.

Sécurité dans le contexte du cycle de vie des logiciels

La sécurité est au cœur du processus de conception et de développement que l’on nomme cycle de vie des logiciels ou Software Devlopment Life Cycle (SDLC) en anglais. L’organisation technique de l’entreprise ne requiert pas que les équipes de développement de produits suivent un processus de développement logiciel particulier, au contraire, les équipes choisissent et mettent en œuvre des processus adaptés aux besoins du projet. Dans ce cadre, un certain nombre de processus de développement logiciel sont utilisés, allant des méthodologies de développement Agile aux processus plus classiques : par étapes, en V ou en cascade.

Sur les illustrations ci-dessous vous pouvez découvrir comment l’intégration de la sécurité se fait dans un cycle en V :

Les processus du développement logiciel

Cycle de développement sécurité

Les processus de revue de la sécurité sont prévus pour fonctionner dans la structure choisie. Leur réussite dépend de la culture technique en matière de qualité et de quelques exigences définies par la direction technique des processus de développement de projet :

• Documentation de conception revue par les pairs.
• Conformité aux lignes directrices de style de codage.
• Revue de code par les pairs.
• Tests de sécurité multi-couches.

Les exigences ci-dessus représentent la culture d’ingénierie logicielle, dans laquelle les objectifs clés sont la qualité, la fiabilité et la maintenabilité des logiciels. Tandis que la finalité première de ces exigences est d’encourager la création d’artefacts logiciels irréprochables en matière de qualité logicielle, les bonnes pratiques de sécurité suggèrent également qu’ils représentent des « moteurs » significatifs et évolutifs en faveur de la réduction de l’incidence de failles de sécurité dans la conception logicielle :

• L’existence d’une documentation de conception suffisamment détaillée constitue une condition préalable du processus de revue de sécurité au niveau de la conception, dans la mesure où lors des premières phases du projet, c’est en général le seul artefact disponible pour élaborer les évaluations de sécurité. Bon nombre de classes de failles de sécurité au niveau implémentation s’apparentent finalement à des défauts fonctionnels courants, à faible risque. La plupart des failles au niveau implémentation sont le résultat d’omissions très simples de la part du développeur.
• Avec des développeurs et des réviseurs de code formés aux schémas de vulnérabilité en vigueur et aux méthodes permettant de les éviter, une culture du développement basée sur la revue par les pairs, insistant sur la création d’un code de haute qualité est un moteur important et évolutif vers une base de code sécurisée.

Les développeurs logiciels de l’équipe de sécurité collaborent avec d’autres développeeurs de l’entreprise sur le développement et la validation de composants réutilisables conçus et implémentés pour permettre aux projets logiciels d’éviter certaines classes de vulnérabilités. Parmi les exemples figurent les couches d’accès aux données conçues pour résister aux failles d’injection de langage de requête SQL, ou les structures de modèles HTML avec défenses intégrées contre les vulnérabilités XSS.

Formation à la sécurité

Reconnaissant l’importance d’une main-d’oeuvre technique formée aux pratiques de codage sécurisé, le responsable sécurité met en place une campagne de communication et un programme de formation à l’intention des équipes, dont le contenu est le suivant :

• Formation des nouveaux développeurs à la sécurité
• Création et gestion d’une documentation complète sur les pratiques sécurisées de codage et de conception
• Références ciblées et contextuelles à la documentation et aux supports de la formation (par exemple, des outils automatisés de test des vulnérabilités fournissent aux ingénieurs des références à la documentation de formation et de fond en rapport avec les bugs ou classes de bugs spécifiques mis en évidence par l’outil)
• Présentations techniques sur les rubriques relatives à la sécurité
• Newsletter sur la sécurité distribuée à l’ensemble des équipes et destinée à informer la main-d’œuvre technique des menaces, schémas d’attaque, techniques d’atténuation, bibliothèques liées à la sécurité, meilleures pratiques et lignes directrices, etc. recensés récemment
• Ateliers sécurité, sous forme de conférences récurrentes à l’échelle de l’entreprise, qui réunit les développeurs des différentes équipes travaillant sur la sécurité et propose des présentations techniques détaillées sur les sujets de sécurité

Tests et revue de sécurité au niveau implémentation

L’entreprise doit appliquer un certain nombre d’approches pour continuer de réduire l’incidence de failles de la sécurité au niveau de l’implémentation dans ses produits et services :

• Revues de sécurité au niveau implémentation : réalisées par les rôles de sécurité, généralement lors des dernières phases du développement de produits, les revues de sécurité au niveau implémentation visent à valider la résistance d’un artefact logiciel aux menaces de sécurité applicables. Ces revues sont généralement constituées d’une réévaluation des menaces et contremesures identifiées lors de la revue de sécurité au niveau conception, de revues ciblées sur le code critique pour la sécurité, de revues de code sélectives permettant d’évaluer la qualité du code du point de vue de la sécurité, et de tests de sécurité ciblés.
• Tests automatisés des failles dans certaines classes de vulnérabilités pertinentes. Pour ces tests, il faut utiliser aussi bien des outils développés en interne que des outils disponibles sur le marché.
• Tests de sécurité réalisés par des ingénieurs de la qualité logicielle dans le contexte des actions menées en matière de test et d’évaluation de la qualité logicielle globale du projet.

Services de consulting

Nous menons les projets de conseils en sécurité avec une offre de services très diversifiée et adaptée à vos besoins, par exemple :

• Audit des processus de développement logiciel
• Rédaction d’une charte sécurité pour les développeurs
• Sensibilisation à la sécurité des développements et du SI
• Mise en oeuvre des processus de revue de la sécurité
• Réalisation d’analyse de risques projet et produit

Les enjeux de la conformité RGPD

Quelle conformité pour les organisations ?

Le Règlement européen impose une prise en compte accrue de la protection des données à caractère personnel : « Protection des données dès la conception » et « Protection des données par défaut ».

L’urgence est de prendre en compte les exigences du RGPD dans les contrats au plus tôt et en particulier sur le changement du statut du sous-traitant en termes de responsabilités (article 26 et article 28).

L’ampleur des sanctions (article 84) en cas de non conformité va de 10 M€ ou 2% du CA mondial consolidé à 20 M€ ou 4% du CA mondial consolidé. Le montant le plus élevé étant retenu comme sanction maximale possible.

Lorsque des transferts d’information hors Union Européenne sont effectués, des BCR ou Binding Corporate Rules peuvent constituer une solution juridique de mise en conformité et de maintient d’exploitabilité.

Le chapitre IV section 4 concerne le Délégué à la Protection des Données (DPD) ou Data Privacy Officer (DPO). L’obligation de la désignation d’un DPO ne concerne pas toutes les structures, bien que la CNIL recommande fortement sa désignation, y compris dans les cas d’exceptions. Le DPO peut être un rôle interne porté par un salarié ou externalisé chez un prestataire.

Preuves de la responsabilité opérationnelle et juridique de l’organisation, le corpus documentaire exigé est constitué :

• d’un registre des activités de traitements qui permet de recenser les traitements de données et de disposer d’une vue d’ensemble de ce qui est fait avec les données personnelles,
• d’une Etude d’Impact sur la Vie Privée (EIVP ou PIA) pour les traitements décrit à l’article 35 du règlement susceptibles d’engendrer un risque élevé pour les droits et libertés des personnes physiques,
• de la réalisation d’un rapport annuel d’activité.

En synthèse les exigences du RGPD sont :

• Protection des données dès la conception (Privacy by Design).
• Protection des données par défaut (Privacy by Default).
• Représentant dans l’organisation (Data Protection Officer).
• Registre des traitements.
• Coopération avec l’autorité de contrôle.
• Notification à l’autorité de contrôle.
• Notification des personnes concernées.
• Analyse d’impact (Privacy Impact Assessment).

En cas de défaut la sanction prévue est de 2% du CA consolidé ou 10 M€.

La suite des exigences :

• Respect des principes de base d’un traitement (Licéité, loyauté, légitimité, consentement, données sensibles …).
• Respect du droit des personnes (Droit d’accès, de rectification, d’effacement dit « Droit à l’oubli », à la limitation du traitement, à la portabilité et d’opposition).
• Respect des règles relative au transfert de données (Privacy Shield / Binding Corporate Rules).

Dans ces cas le non respect peut être sanctionné par 4% du CA consolidé ou 20 M€.

La mise en conformité n’est pas un simple projet, il s’agit plus d’un changement de culture dans les organisations quelques soient leurs tailles.

Méthodologie

Pour qu’une organisation se mette en conformité, il faut qu’elle se prépare en 6 étapes selon les conseils de la CNIL :

1. Désigner un pilote,
2. Cartographier les traitements de données personnelles,
3. Prioriser les actions,
4. Gérer les risques,
5. Organiser les processus interne,
6. Documenter la conformité.

Pour rester dans l’esprit de ces étapes nous proposons de vous accompagner sur un projet de mise en conformité en 5 phases comme suit (cliquer sur l’image pour l’agrandir) :

Ce type de projet vous permet d’obtenir une évaluation de votre conformité au Règlement européen, d’avoir une cartographie complète de vos traitements et un plan d’action d’amélioration pour être en conformité. L’ensemble des résultats obtenus permet au DPO ou au responsable de traitement de prendre en charge immédiatement le maintien de cette conformité et le pilotage du plan d’action. Il est conseillé de réévaluer la démarche au moins une fois tous les 3 ans.

Services de consulting

Nous menons les projets de mise en conformité RGPD avec une offre de services très diversifiée et adaptée à vos besoins, par exemple :

• Évaluation flash de maturité au RGPD et à la sécurité des données.
• Pilotage complet du projet de mise en conformité RGPD.
• Établissement et documentation du registre des traitements.
• Sensibilisation au Règlement et aux bonnes pratiques de sécurité.
• Analyse de risques et évaluation d’impact sur la vie privée (PIA).
• Coordination du plan d’amélioration des processus et de la sécurité du SI.
• Aide au déploiement des processus de sécurité des données.

Amélioration continue

Démarche d’amélioration continue

Mener une démarche d’amélioration continue ou de résolution de problème selon le cycle du « Plan-Do-Check-Act » ou PDCA permet d’avoir une méthode structurée pour mettre en oeuvre des solutions les plus adaptées et surtout pérennes.

Le PDCA est une démarche d’amélioration continue symbolisée par la roue de Deming.

Méthodes

Le PDCA se déroule en quatre grandes étapes.

Plan = Planifier ou Prévoir

La première étape est très importante, car elle consiste à bien définir le sujet ou le problème, on parle de périmètre ou de scope. Ceci afin d’identifier des solutions pérennes qui devront être évaluées et déployées. Cette étape est finalisée par un plan d’actions, incluant leur planification et les acteurs.

Do = Développer ou Réaliser

Cette étape consiste en la mise en oeuvre des actions définies précédemment. La rigueur dans le suivi du plan d’action au travers de mesures d’avancement et de jalons est un gage important de réussite.

Check = Contrôler ou Vérifier

Il s’agit de vérifier l’efficacité des actions menées. Ceci peut se faire par le biais de mesures, d’indicateurs, ou d’observations. Un délai peut-être défini selon la nature de l’action, un cas classique est d’évaluer les actions à 30,60 et 90 jours après le déploiement. Lorsque des actions se révèlent inefficaces suite aux vérifications, des ajustements pourront être réalisés, si nécessaire, en revenant à l’étape Plan dans une nouvelle itération.

Act = Ajuster, Assurer, Améliorer

Cette étape permet de finaliser la démarche afin d’assurer la pérennité des résultats des actions mises en oeuvre. Il s’agit le plus souvent d’élaborer ou mettre à jour des documents, tels que procédures, processus, guides de bonnes pratiques, ou formulaires.

Il s’agit également d’identifier des améliorations , en revenant à l’étape Plan dans une nouvelle itération pour les mettre en oeuvre. On peut ainsi exécuter plusieurs fois le cycle pour bien ancrer les changements.

Autres méthodes

Il existe d’autres méthodes d’amélioration continue des processus comme le DMAIC de Six Signa ou le Kaizen du Lean.

On peut aussi mettre en oeuvre des méthodes plus détaillées et expertes comme l’évaluation et l’étude d’impact, la résolution de problèmes ou un cycle de gestion de projet pour piloter des changements de grande échelle. Ou plus simplement des bonnes pratiques pour assurer le succès du changement.

Mission du responsable

Dans le cadre du déploiement d’un plan de progrès, la mission principale du responsable de l’amélioration consiste à piloter le projet et accompagner les managers opérationnels dans la mise en oeuvre et le suivi des chantiers de progrès avec des pilotes terrain, tout ceci en lien avec le programme global d’amélioration. Ceci est possible en :

• en établissant le plan d’action correspondant et en suivant son exécution au travers des revues et à l’aide d’indicateurs,
• en veillant au déploiement et à l’appropriation des objectifs de progrès,
• en animant la communication sur les démarches de progrès et d’amélioration continue,
• en rendant compte de l’efficacité des processus mis en place,
• en faisant la promotion des bonnes pratiques entre entités.

Le sens du relationnel, l’autonomie et la rigueur sont des qualités essentielles pour cette fonction, complétées par :

• Dynamique.
• Curieux.
• doté d’un bon sens de l’écoute.
• Affirmé.
• Force de conseil et de proposition.

Exemple de procédure d’Amélioration Continue

Cas du traitement des Actions Correctives et des Actions Préventives :

Afficher ce document sur Scribd

Services de consulting

Pour définir et déployer un processus d’amélioration continue efficient et pragmatique dans votre organisation nous pouvons vous accompagner sur :

• Évaluation ou audit de processus opérationnels existants.
• Assistance à la définition et au déploiement de plans d’action d’amélioration.
• Définition du processus opérationnel d’amélioration continue.
• Coaching du responsable de l’amélioration.

MPP Management Par Projet

Cet article vous présente les définitions principales et le référentiel d’un système de gouvernance de projet au sein d’une DSI en charge du développement d’applications logiciel et de la mise en production des Systèmes d’Information résultants. Ce référentiel complet, dont j’ai coordonné le développement et le déploiement avec le soutien de ACDE Conseil, a été évalué et reconnu CMMI niveau 2.

Définitions

Le Management Par Projet est un ensemble de processus destiné à assurer que les projets sont entrepris en adéquation maximale avec les objectifs stratégiques de la société et que les risques encourus sont identifiés et contrôlés.

Un projet se caractérise par une existence limitée dans le temps, un début, une fin et un objet parfaitement identifiés.

Lui est affecté un chef de projet ou Project Manager, responsable de la coordination de la production de l’ensemble des livrables, de l’organisation et de la bonne exécution de l’ensemble des tâches et intervenants concourant à la réalisation du projet, depuis son initialisation jusqu’à sa clôture.

Implicitement cela signifie qu’un projet inclue non seulement des travaux ayant trait au développement de logiciels, pour le cas qui nous intéresse, mais aussi toutes les activités de communication, de documentation et d’industrialisation du système d’information se tenant en amont ou en aval de la production du logiciel.

La décomposition en phases conclues par un jalon ou milestone permet d’évaluer les avantages potentiels et le niveau de risque des projets, de définir des responsabilités claires, de segmenter et d’organiser le travail à effectuer, d’impliquer avec pertinence l’intégralité des acteurs concernés, de maîtriser les engagements de ressources, de valider les travaux accomplis, de prononcer les arbitrages attendus, de décider de poursuivre, de stopper, de différer ou de recadrer certains projets.

Le franchissement du jalon marquant la fin de chaque phase est conditionné à l’approbation par la direction, ou par des instances agissant par délégation, d’un certain nombre de documents de gestions et livrables attestant que le travail convenu a été réalisé conformément aux objectifs fixés, dans les règles de l’art en terme de qualité, dans les limites de temps, de budget ou de charge convenus.

Remarque : Le processus global de management par projet se nourrit d’autres processus tels que les processus d’assurance qualité ou les processus d’ingénierie et de support.

Présentation du processus

Le processus global de Management Par Projet (MPP) se décompose en sept phases essentielles. Chaque phase se conclut par une réunion de revue évaluant la performance du projet en regard de ses objectifs et statuant sur sa continuation. Cette revue est marquée par le franchissement d’un jalon traduisant l’état de maturité du projet.

Le franchissement de chaque jalon est conditionné à :

• La production de certains livrables ou documents de gestion,
• L’approbation d’une autorité prédéterminée (GO/NOGO).

Tous deux dépendant des caractéristiques du projet : produit, maîtrise d’ouvrage, catégorie, criticité.

Les phases d’un projet classique sont les suivantes :

1 – INITIALISATION

Cette phase a pour objet de préciser les raisons prévalant à l’engagement potentiel du projet. Elle se conclut par le jalon « Business Review » marquant l’accord sur la pertinence économique du projet.

2 – ÉVALUATION

Cette phase a pour objet d’apprécier la faisabilité du projet en regard des orientations stratégiques de l’organisation, de ses capacités et du retour sur investissement envisageable. Elle se conclut par le jalon « Faisibility Review » marquant l’accord sur la faisabilité du projet.

3 – SPÉCIFICATION ou  DÉFINITION

Cette phase a pour objet de définir le contenu précis et d’arrêter les choix techniques du projet, elle est l’occasion de développer les exigences avec le client ou la maîtrise d’ouvrage. Elle se conclut par le jalon « Definition Review » marquant l’accord sur la définition du projet.

4 – RÉALISATION ou CONSTRUCTION

Cette phase recouvre la plupart des opérations de réalisation des composants (logiciels et non logiciels) du projet. Elle se conclut par le jalon « Realisation Review » marquant l’accord sur la réalisation du projet.

5 – PRÉPARATION ou VALIDATION

Cette phase recouvre l’ensemble des opérations intermédiaires séparant la production d’un code testé de sa mise à disposition des clients sous forme d’un produit fonctionnel, maintenable, documenté et supporté. Elle inclut les dernières étapes de documentation et la plupart des étapes de recette, d’industrialisation, de production, de mise en exploitation, de mise à disposition à des clients-tests (partenaires de développement, beta-tests), de transferts de connaissance et de responsabilité envers les divisions opérationnelles. Elle se conclut par le jalon « Validation Review » marquant l’accord sur la validation du projet et sur le fait que l’organisation dans son ensemble est prête pour la commercialisation et le support de la version.

6 – LANCEMENT ou PRODUCTION

Cette phase recouvre l’ensemble des opérations marketing, commerciales et de relation client entourant la mise sur le marché d’un nouveau produit ou d’une nouvelle version : actions presse, conférences, formation des utilisateurs. Elle se conclut par le jalon « Launch Review » marquant l’accord sur le fait que les opérations de lancement sont terminées et que la version est maintenant pleinement en exploitation.

7 – CLÔTURE ou BILAN

L’objet de cette phase est d’effectuer un bilan technique et organisationnel du projet afin principalement de recenser les difficultés rencontrées et de suggérer des axes d’évolution ou d’amélioration pour de futurs projets. Elle se conclut par le jalon « Final Project Review » marquant l’accord sur la fin du projet.

Le cycle de vie projet

Ce cycle d’enchaînement de phases et de jalons se nomme Cycle de Vie Projet, il a été synthétisé dans un poster que chaque membre de l’équipe projet peut afficher comme aide mémoire pragmatique pour les prises de décision et les livrables attendus. Dans cette version du poster la définition et le nommage des phases du projet ont été adaptés à un cycle de vie de développement logiciel (SDLC).

Afficher ce document sur Scribd

Une autre représentation de ce cycle de vie peut être faite à l’aide du référentiel générique et intégré CpMM, les différents processus à mettre en place se répartissent tout au long du cycle Phases/Jalons sur une disposition classique en « V » entièrement couvert par le processus PM :

Cliquez sur l’image pour agrandir

Le déploiement pratique de cette cartographie de processus en procédures opérationnelles standards peut être représenté comme suit :

Cliquez sur l’image pour agrandir

Organisation

Le choix a été fait de mettre en place une structure matricielle ou structure par projet, c’est une structure temporaire limitée à la durée d’un projet.

Son principe est le suivant : les services permanents, organisés par fonctions techniques (les ex silos), affectent leur personnel dans des équipes projet en fonctions de besoins. Quand le projet est achevé, chacun rejoint son service d’origine en attente d’une nouvelle affectation. Une ressource peut être affectée à plusieurs projets selon sa charge.

Dans une structure matricielle, la fonction de management n’est plus dans les mains d’une seule personne, mais d’au moins deux. Il est ainsi primordial que le partage des responsabilités, mais aussi et surtout de l’autorité, entre les managers soit clair et précis.

Les avantages de la structure matricielle par projet sont de:

• permettre une grande flexibilité dans la gestion des ressources humaines et le management,
• développer l’innovation par l’émulation des idées entre des profils différents,
• favoriser la collaboration,
• ouvrir des nouveaux champs de communication entre les fonctions.

Bref, elle est bien adaptée à un monde économique complexe qui exige adaptation, innovation, réactivité des entreprises.

Le référentiel MPP

Vous trouverez ci-dessous la documentation en anglais du référentiel de Management Par Projet tel qu’il a été utilisé pour l’évaluation CMMI, en particulier vous y découvrirez les instances de pilotage et de direction à mettre en place, ainsi que les rôles et responsabilités de tous les acteurs du projet. Enfin l’ensemble des processus et des livrables pour réaliser le projet est décrit.

Afficher ce document sur Scribd

Comment standardiser sans uniformiser ?

J’ai contribué au Club PMO animé par ACDE Conseil en faisant un retour de mon expérience de standardisation pragmatique de processus au sein d’une organisation de services spécialisée en développement et hébergement de logiciels pour le monde de la santé.

Cegedim a souhaité définir un référentiel commun de bonnes pratiques, propre à l’entreprise, construit à partir de plusieurs méthodologies et référentiels : CMMI, Prince 2, ITIL, ISO 2701, ISO 9001, etc.

Cette approche de rationalisation interne des référentiels sert également à montrer aux clients de l’organisation comment sont gérés les projets et les services, cette standardisation aide à vendre la démarche de définition des processus internes aux Managers opérationnels.

Un point de vigilance qu’il ne faut pas négliger dans ce type de projet, c’est de rechercher et trouver le bon niveau de détails dans la définition des processus sans nuire à l’innovation.

Vous pouvez retrouver cette présentation sur le site du Club PMO ou directement en la téléchargeant ici.

Management Équitable

A la différence d’autres référentiels portant sur les pratiques de Management d’une organisation, la Charte du Management Équitable® et ses pratiques se veulent intrinsèquement porteuses d’une démarche de progrès. Permettant aux organisations de générer une plus grande performance économique durable en engendrant une forme de projet d’entreprise qui mobilise positivement les managers, la direction, les collaborateurs et les partenaires.

Concrètement, le Management Équitable® consiste à mettre en place et entretenir au sein de l’entreprise :

• une dynamique collective ambitieuse et porteuse de sens,
• une organisation claire, adaptée, cohérente et évolutive,
• un management propre à développer les énergies et les talents,
• des relations interpersonnelles fondées sur le respect mutuel et la reconnaissance,
• une gestion proactive et performante du changement,
• un comportement éthique et citoyen.

J’ai contribué depuis sa création à la définition et à la mise en oeuvre du référentiel de labellisation Management Équitable® et à la formation des experts et auditeurs en capacité de l’évaluer.

Les principes du Management Équitable®

Avec ce référentiel il ne s’agit pas de sanctionner une organisation, mais de servir de catalyseur de performance sur la durée. La progressivité du mise en euvre des pratiques, au travers des indicateurs et des différents niveaux, participe à cette inscription dans la durée.

Les principes sont inscrits dans la Charte du Management Équitable®

Le terme Management Équitable® est une marque déposée de la société ACDE Conseil.

Intérêt d’une évaluation

L’organisation engagée dans une démarche d’évaluation de ses pratiques bénéficie de toutes les expertises et expériences des experts et des autres membres, individuels ou sociétés, qui enrichissent les mesures et les benchmarks du référentiel.

Autre spécificité, l’organisation s’approprie ce référentiel et vient elle-même soutenir son dossier devant le Comité de Labellisation. Chaque candidat au label a accès à des formations régulières, des conférences, et contribuera à enrichir les débats, indicateurs, forums et groupes de réflexion de l’association.

Mes contributions au Management Équitable®

Une grande partie de mes articles sur le Management Équitable® soutient qu’en adoptant à tous les étages de l’entreprise ou de l’association et de manière concrète les valeurs de la charte du Management Équitable®, il est possible de prévenir les risques dans tous les domaines de l’organisation.

En bref, développer partout dans l’organisation l’intelligence collective permettant de faire face aux enjeux et de réconcilier l’économique, l’objectif, le produit et l’humain.

La labellisation ou l’évaluation permettent de mesurer l’adoption de ces pratiques dans une organisation pour mettre en place une démarche de progrès vers le niveau de maturité le plus élevé du référentiel, c’est à dire le niveau équitable.

Ma présentation

Je suis consultant et je souhaite accompagner les structures travaillant sur les données de Santé dans la recherche de solutions organisationnelles, managériales et stratégiques. Pour cela j’ai développé une méthodologie pour réaliser des prestations d’audit, de diagnostic, de conseil et de formations adaptées à ces structures et à leur secteur d’activités.

Une organisation efficace en terme de gestion de la sécurité des SI et de la qualité doit s’appuyer sur trois piliers : la Technologie, ses Processus et ses Ressources humaines. Mon activité de conseil met l’accent principalement sur le rééquilibrage de ces piliers au sein de l’organisation, en particulier sur l’axe humain, pour rendre la prévention des risques plus efficiente et pérenne.

Mon activité de conseil a pour ambition d’accompagner ces organisations dans leurs projets d’évolution en développant par exemple : la définition de structure de gouvernance, la conduite du changement, la mise en place ou l’amélioration du Système de Management de la Sécurité des SI et de la Qualité, le conseil en gestion du système intégré QSE et en gestion de projet, etc.

Parce que vos engagements seront aussi les miens, mes prestations de conseil et de formation/coaching sont conçues pour vous aider à accroître la performance de votre organisation de façon pérenne et opérationnelle.

Mon expérience

Depuis mon diplôme d’Ingénieur Arts & Métiers de l’ENSAM en 1986, j’ai travaillé pour le groupe Cegedim, leader mondial du CRM pharmaceutique, également fournisseur de logiciels et de données pour les professionnels de santé. Au cours de ma carrière j’ai tenu successivement les responsabilités de : Manager d’équipe de développement logiciel, Responsable Qualité et Sécurité IT et Directeur de la Compliance au sein de l’Excellence Opérationnelle.

Dans le cadre de cette dernière responsabilité j’ai coordonné plusieurs projets d’agrément d’hébergement de données de santé au sein du groupe Cegedim et contribué à la création et la gestion de l’association des Hébergeurs de données de santé AFHADS comme trésorier.

Je suis membre fondateur et Président de l’association du Management Équitable AFraME, j’oeuvre activement depuis sa création pour la promotion du label Management Équitable auquel j’ai activement contribué.

Mes domaines d’expertise

• Manager une équipe internationale d’experts pluridisciplinaires dans tous les domaines transverses de l’organisation : Qualité, Sécurité, Processus, Pratiques RH, Environnement, Audit, Conformité…
• Définir et déployer la politique Qualité, Sécurité et Environnement (QSE).
• Revoir les contrôles et les processus internes, se traduisant par une analyse complète des écarts par rapport au référentiel interne ou externe, suivi de la mise en place des plans d’actions pour réduire ces écarts.
• Proposer et activer la politique et l’agenda de la gouvernance et les méthodologies métiers de l’entreprise. (CMMI, ITIL, Sécurité…)
• Supporter les équipes métiers et des équipes de support technique IT de l’entreprise pour renforcer l’adoption des bonnes pratiques, règles, standards de gouvernance et de conformité informatique.
• Suivre et documenter les activités de gouvernance et de conformité, alignées sur les standards Qualité et Sécurité, développer le modèle de maturité des processus internes.
• Manager les revues internes et les formations sur les politiques et standards métiers et IT.
• Gérer les audits internes et tierces parties, les plans d’actions d’amélioration continue suite aux non conformités détectées, ainsi que les recommandations d’amélioration.
• Participer aux audits tierces parties pour identifier et évaluer les risques clefs de l’organisation globale.
• Gérer les revues et évaluations des changements de processus et de leur déploiement sur l’organisation, gérer la communication et l’accompagnement sur les projets de changement.

Mes spécialités

• CMMI/PRINCE2 pour le Management de Projet et le Développement Logiciel.
• ITIL/ISO20000 pour le Management des Services IT (ITSM).
• ISO27001 pour la gestion de la Sécurité des Systèmes d’Information (PSSI).
• ISO9001/GAMP/LEAN/KAIZEN pour le Management de la Qualité (QMS) et l’amélioration de processus.
• ISO31000/EBIOS/EvRP pour la Gestion des risques SI/IT et du Document Unique de Prévention des Risques.
• ISO22301 pour la Gestion de la Continuité d’activité (PCA/PRA/BCP/DRP)
• SOC/SSAE16/ISAE3402 pour l’audit de Conformité à la loi US Sarbanes-Oxley

Mes valeurs

Pour soutenir cette ambition dans mes missions de conseil, mes valeurs sont :

Le réalisme : Il est au cœur de l’action. Il doit conduire à ne prendre en compte que les faits existants pour faire croître les activités de ses partenaires et surtout ses bénéfices. La conduite des projets doit se faire de manière rationnelle et objective, c’est dans la conduite des hommes que le cœur a toute sa place, mais avec discernement.

L’esprit entrepreneur : Il faut vouloir entreprendre. Cela implique de prendre des risques, d’être créatif, de se faire confiance et d’être mis en confiance. Cela nécessite de se sentir responsable. Pour s’exprimer pleinement, cet esprit nécessite une organisation décentralisée avec un niveau juste d’autorité et une responsabilisation poussée.

L’humilité : C’est la seule valeur qui permet de grandir. Elle implique de reconnaître qu’il existe toujours meilleur que soi et que l’on peut apprendre d’autrui. Elle pousse à ne pas se glorifier d’un succès et à ne pas s’en accorder tout le mérite. Elle conduit à ne pas considérer et ce quel que soit son titre ou sa fonction qu’il existe des petites tâches et de grandes tâches.

Le respect : C’est la base de toute relation humaine. Le respect de ce qui a été entrepris, de ce qui est en cours et de ce qui reste à faire. Le respect de son propre travail et de celui de l’autre. Le respect du caractère unique de chaque individu. Après le respect, vient la confiance puis le partage et enfin la reconnaissance.

Ces valeurs sont convergentes pour former les fondations des pratiques de Management Équitable.

Translation in English