Maîtrise des risques dans les projets : le rôle des métiers

Rédaction

La démarche de gestion des projets doit intégrer les points-clés de la qualité et de la sécurité au sens de la maîtrise des risques métiers et informatiques. Avec, au final, des bénéfices en termes de charges, de délais, de coûts et d’amélioration des objectifs de qualité et de maîtrise des risques sécurité.

Le cahier des charges d’une application informatique est élaboré pendant les phases amont des méthodes de conception d’un projet informatique, en général au stade appelé « avant-projet », dont le livrable est le cahier des charges. Ce document permet aux métiers d’exprimer leurs besoins de la manière la plus complète et la plus compréhensible possible. Cette action essentielle est l’une des tâches les plus difficiles à réaliser.

Qui n’a pas entendu, au cours de sa carrière, les informaticiens expliquer : « L’échec du projet vient de la mauvaise définition des besoins par les utilisateurs » ? Ou encore les utilisateurs affirmer que « cela relève en réalité de la non compréhension par les informaticiens. »

Une méthode adaptée et rigoureuse de conduite d’avant-projet est donc nécessaire pour guider les utilisateurs dans leur démarche, éviter les manques et les éventuelles incompréhensions, voire des conflits futurs avec les équipes de développeurs. La formalisation des besoins se caractérise par quatre actions : décrire l’objectif, mettre en place le processus de gestion de projet, analyser l’existant et décrire les évolutions de la future application.

Décrire l’objectif

Décrire l’objectif revient à préciser les éléments suivants :

  • les finalités de la future application,
  • le périmètre et les interfaces,
  • les processus liés à l’application,
  • les contraintes à respecter : organisationnelles, réglementaires et légales, budgétaires, de planification et de charges…

Mettre en place le processus de gestion du projet

Cette étape consiste, tout d’abord, à identifier les acteurs du projet et à prévoir les comités (chefs de projet, correspondants informatiques, experts et spécialistes en qualité et sécurité…). Il s’agit, ensuite, d’assurer un suivi et un contrôle : planning prévisionnel, tableaux de bords, dispositif de validation, plan de gestion de la qualité du projet… Enfin, on s’attachera à mettre en place les moyens nécessaires : partenaires, ressources humaines et matérielles, formateurs…

Analyser l’existant

L’analyse de l’existant correspond, d’une part, à la réalisation et à la planification des interviews. D’autre part, il s’agit de collecter les informations : recenser les activités, les fonctions et règles de gestion associées, les données et les divers documents, les fichiers, les traitements et les ressources utilisées, les dysfonctionnements organisationnels, fonctionnels, qualitatifs (manque de performance, difficulté d’utilisation, mauvais fonctionnements, …) et de sécurité (absence de disponibilité générant mécontentement ou désorganisation du travail dans les métiers, résultats erronés produits par l’application, manque de confidentialité, absence de preuve ne permettant pas la compréhension exacte du dysfonctionnement…).

Décrire les évolutions de la future application

Les besoins fonctionnels, traitements et règles de gestion

La description des besoins fonctionnels doit se faire en s’appuyant, à chaque fois que cela est possible, sur une modélisation des processus, afin de faciliter les liens avec la maîtrise des risques (risques opérationnels en milieu bancaire) et de décrire les fonctions attendues, c’est-à-dire ce que doit produire le futur système indépendamment du comment. Ces fonctions doivent recouvrir les besoins fonctionnels en maîtrise des risques et qualité du produit, par exemple les fonctions de contrôle de la qualité des données et les contrôles d’accès renforcées pour certaines fonctions applicatives.

Les besoins sur les données et relations

La description des données doit se faire, à chaque fois que cela est possible, en s’appuyant sur une modélisation, par exemple, le diagramme entités-relations. Il importe de bien distinguer informations et données. Par exemple, dans le domaine bancaire : M. Pierre, dont le solde débiteur est de 150 euros, sur le compte N° xxxx, est une information pour le chargé de clientèle, en revanche le nom, le montant et le N° de compte sont des données, elles se définissent en général par un nom et une valeur.

Les utilisateurs doivent préciser globalement, pour les données ou ensembles de données, le niveau de maîtrise des risques à atteindre, par exemple :

  • le niveau de confidentialité (public, confidentiel, secret),
  • l’exhaustivité et la fiabilité attendue des données (besoin significatif ou fort),
  • la disponibilité en cas de dysfonctionnement (niveau de perte des données et durée d’indisponibilité acceptable),
  • la nécessité de disposer d’une trace et/ou d’un dispositif de non-répudiation.

Les besoins organisationnels

Il s’agit de déterminer, s’il y a lieu, les conditions de changement de l’organisation des utilisateurs et de la mise en œuvre du projet, en particulier :

  • les évolutions éventuelles au sein de l’organisation existante,
  • les nouveaux échanges et circuits internes et externes,
  • la capacité d’adaptation du personnel,
  • la normalisation des procédures,
  • les formations à prévoir.

Dans le cas d’une approche basée sur un progiciel, il faut retenir qu’un compromis dans l’expression du besoin sera nécessaire, car le progiciel ne prend pas toujours en compte la spécificité totale du besoin. Il a en effet été conçu pour traiter des besoins communs à plusieurs entreprises sur un thème donné (par exemple : la comptabilité).

Il est toutefois possible, et c’est souvent le cas, de créer des interfaces pour répondre à certaines spécificités du besoin utilisateur. Il faut alors avoir conscience que c’est souvent au détriment de la cohérence et de la maîtrise des risques, en termes de qualité et de sécurité du produit fini. Ces points sont importants pour élaborer les solutions les mieux adaptées au métier (infrastructure, poste de travail, liaisons Internet)

Les besoins appréhendés par les utilisateurs

Ces besoins concernent tous les aspects liés à la maîtrise des risques en sécurité et de la qualité de la future application, en particulier les éléments suivants :

  • La disponibilité de l’application : le seuil d’indis­ponibilité, au-delà duquel les métiers sont atteints et l’image de l’entreprise détériorée, et la durée de reprise acceptable, suite par exemple à des pertes de données.
  • L’intégrité : le niveau de fiabilité des traitements de l’application et la validation lors des phases de recettes utilisateurs, exactitude et exhaustivité des ensembles de données.
  • La confidentialité : les niveaux de confidentia­lité et les profils à prévoir pour l’application, par exemple : public, confidentiel, très confidentiel, secret.
  • La preuve et le contrôle : il s’agit de disposer des traces des traitements effectués et des ensembles de données manipulés, ainsi que la non-répudiation, par exemple lors d’échanges via Internet avec l’étranger.
  • La performance attendue : exprimée en taux de service, temps de réponse acceptable, volumes de transactions…
  • La convivialité : la facilité d’emploi des menus déroulants.
  • La maniabilité : la facilité d’apprentissage, de mise en œuvre, de préparation des entrées et d’interprétation des résultats.
  • L’évolutivité : la facilité d’évolution des fonc­tions selon les changements de périmètres.

Les choix de scénarios de développement du projet

Ils sont élaborés avec le concours de la DSI et regroupent les aspects fonctionnels, processus, données, organisationnels et informatiques. Pour chaque scénario, on doit trouver les éléments suivants :

  • l’énoncé des fonctions,
  • leurs modes de traitement,
  • les performances attendues,
  • la maîtrise des risques, la sécurité et la qualité attendues,
  • le bilan économique.

Après le choix de scénario acté en comité de pilotage, la maîtrise d’ouvrage a, en général, construit son cahier des charges et les informaticiens peuvent se lancer dans la conception du projet (étude globale et détaillée, fonctionnelle et technique…) ou préparer un appel d’offres.

Règles générales de maîtrise des risques

Règle 1 : réaliser périodiquement des revues qualité et un audit de la cohérence des systèmes de contrôle mis en place :

  • vérifier la cohérence,
  • vérifier les redondances,
  • vérifier les incompréhensions,
  • vérifier l’application ou la non-application,
  • vérifier les liens avec la réglementation en matière de contrôle.

L’application des contrôles par les métiers n’est souvent pas optimale, ils sont perçus, dans de nombreux cas, comme synonymes de perte de temps et de manque de performance.

Règle 2 : concevoir et élaborer les contrôles avec la parti­cipation active des métiers et mettre en place une convention de contrôle acceptée par les différentes parties prenantes, notamment celles qui auront à l’appliquer.

Règle 3 : bien maîtriser les risques ne résulte pas d’un empilement ou d’une démultiplication des couches de contrôle.

Règle 4 : la participation des DRH à l’élabo­ration et à l’application des contrôles de maîtrise des risques est une exigence incontournable, cela concerne notamment :

  • la séparation des pouvoirs entre les contrôles et les activités opérationnelles des différents métiers,
  • le recrutement et l’évaluation régulière du profil des candidats qui travaillent sur des fonctions à risque, avant tout changement
    de poste de travail, absences prolongées ou congés.

Règle 5 : les référentiels de maîtrise des risques existent dans la majorité des entreprises, notamment dans les établissements financiers, mais ils sont parfois méconnus et souvent inappliqués, voire inapplicables. L’application de ces référentiels doit être auditée et mise à jour par des retraits et/ou modifications des normes inapplicables, l’ajout de nouvelles normes…

Cet article a été écrit par René Hanouz, consultant.

Les points-clés d’un plan d’assurance qualité

  • But, domaine et responsabilité de l’élaboration, du contenu, du suivi et de
    la cohérence d’ensemble.
  • Documents applicables et documents de référence (manuels, procédures…).
  • Terminologie (concepts, termes et abréviations…).
  • Organisation ; qui fait quoi, avec les rôles et les responsabilités au sein du projet.
  • Démarche de développement (méthode de conduite du projet, avec les différentes phases, documents, tâches, livrables…).
  • Documentation technique ou de gestion (nature et contenu…).
  • Gestion de la configuration (composants de l’application, règles de formation, versions…).
  • Gestion des modifications (procédures de demandes, d’évaluation d’impact et des composants modifiés…).
  • Méthodes, outils et règles (analyse, conception, programmation, tests, langages, outils…).
  • Contrôle des fournisseurs (exigences de qualité, modalités d’audit…).
  • Reproduction, protection, livraison (vérification de la conformité, sécurité…).
  • Suivi de l’application du PAQ (organisation : qui, quoi, quand, comment).

Exemple de système de classification pour évaluer la gravité d’un risque

Critique : tout événement susceptible de provoquer des pertes financières inacceptables, une nuisance grave à l’image de marque de l’entreprise, une perte importante de marchés ou de clients, une infraction majeure à la législation ou aux réglementations, une nuisance organisationnelle jugée importante pour plusieurs activités métiers…

Sensible : tout événement susceptible de provoquer des pertes financières limitées, une nuisance à l’image de marque, une perte possible de clients, une nuisance organisationnelle jugée significative par le métier, un manque de conformité à la réglementation comptable et/ou fiscale, la non-atteinte des objectifs visés par un projet important.

Faible : tout événement susceptible d’occa­sionner de faibles nuisances, internes au domaine considéré et peu gênantes pour l’utilisateur.

Quelques exemples de règles opérationnelles de sécurité

  • Tout ensemble informationnel (applications métiers, fichiers de données informatisées, logiciels, postes de travail…) doit avoir un propriétaire et un gestionnaire.
  • Les équipes de production sont dépositaires des ensembles d’informations, elles doivent en assurer la préservation dans un état donné et être capables de le remettre à disposition des utilisateurs, dans ce même état, si nécessaire.
  • Tout accès au système d’information de l’entreprise est conditionné par une authentification plus ou moins forte, en fonction de la criticité des ensembles d’informations auxquels les utilisateurs peuvent accéder, par exemple :
    • authentification faible (accès public) : mot de passe statique relié à un identifiant, sans contrainte,
    • authentification moyenne (accès restreint en interne) : mot de passe statique relié à un identifiant, l’ensemble respectant les normes de maîtrise des risques édictées dans l’entreprise,
    • authentification forte (confidentiel) : mot de passe dynamique (type SecurId) à usage interne à l’entreprise, PKI Interne en mode local, clés chiffrées sur poste de travail,
    • authentification très forte (secret) : mot de passe dynamique (type SecurID) à usage externe sur carte à puce, PKI interne en mode roaming (utilisé pour les postes nomades) avec clés chiffrées sur un serveur.
  • Les postes de travail et serveurs d’administration doivent disposer d’une configuration ne permettant pas l’implémen­tation de mécanismes de saisie automatique des mots de passe
  • Une trace journalisée des accès doit être mise en place, elle doit être protégée contre tout effacement ou modification, et archivée. Elle doit contenir, au minimum, les éléments suivants : date et heure de l’accès, identité de la personne ayant accédé, type d’opération effectuée.
  • Tout serveur connecté au réseau d’entreprise doit respecter les normes et principes édictés dans la politique de maîtrise des risques et de sécurité, en particulier :
    • la configuration des masters par les équipes techniques,
    • l’activation permanente des protections de type antivirus, spamming, pare feu…
    • l’installation de nouveaux produits sous contrôle des équipes techniques,
    • le filtrage d’URL et de contenu par les équipes techniques et le paramétrage des firewalls par les équipes réseaux,
    • les outils de détection d’intrusion par les équipes réseaux…
  • L’accès au BIOS du poste de travail est interdit aux utilisateurs, il doit être protégé par une authentification adaptée (au minimum un mot de passe de 8 caractères).
  • Les procédures de mise en œuvre de tout nouveau projet, logiciel ou projet d’évolution, doivent garantir la possibilité de retour à la version précédente en cas de dysfonctionnement.
  • Dans le cadre de la maîtrise des risques, des inventaires matériels et immatériels doivent être réalisés, on doit tenir à jour la cartographie des risques. Des logiciels adaptés existent pour faciliter la mise à jour et la cohérence.
  • Les sauvegardes doivent être dupliquées et stockées dans des sites éloignés, parfaitement sécurisés sur les plans physique (contrôle d’accès, protection incendie, dégâts des eaux, poussières, produits chimiques…) et logique.
  • Les actions, dites de maintenance ou dépannage à chaud, doivent être journalisées et effectuées seulement après accord des utilisateurs (maîtrise d’ouvrage).
  • Les échanges (flux entrant) doivent faire l’objet d’une authentification forte.
  • Les points d’entrée Internet doivent être distincts physi­quement et faire l’objet de filtrages entrée et sortie d’Internet, selon différents niveaux d’accès, qui doivent avoir été prévus dans l’architecture de l’entreprise (niveau accueil Internet, niveau application, niveau donnée…).
  • Le contenu des flux de messagerie doit être filtré.
  • L’exécution des codes mobiles doit être soumise à un contrôle préalable des équipes techniques, en raison des dangers qu’ils peuvent occasionner s’ils sont malveillants (contrôle du code et filtrage en fonction des commandes possibles et antivirus sur les flux HTTP, …).
  • L’utilisation des réseaux sans fil est dépendante d’un accord et de la mise en place d’une sécurité préalable (firewall dans le poste de travail nomade et filtrage derrière chaque point d’accès sans fil.
  • La mise à jour des antivirus doit être automatisée, ainsi que le signalement de tout antivirus désactivé.
  • Tous les projets informatiques nouveaux, ou d’évolution, doivent appliquer la méthode de conduite de projet de l’entreprise, qui inclut la maîtrise des risques dans le processus projet et dans le développement de l’application.

 

Un exemple de fiche d’analyse de la sécurité applicative
Questions Réponses Gravité (*)
1 – 2 – 3
Informations générales
Quelles sont les grandes fonctionnalités de l’application future (se limiter aux cinq activités principales) ?
Une fraude financière est-elle possible par l’utilisation directe ou indirecte de l’application future (complicité) ? Si oui, indiquer son importance, si non, préciser pourquoi.
L’application future génèrera-elle des échanges (flux financiers ou autres) avec l’extérieur ? Si oui, indiquer le nombre moyen d’échanges et la fréquence.
Quelles sont les autres applications avec lesquelles des échanges d’informations seront effectuées (nommer les interfaces applicatives) ?
   Information sur les utilisateurs
 Qui sont les utilisateurs : collaborateurs internes, filiales, clients, partenaires financiers, sous-traitants… ?
 Quel est le nombre d’utilisateurs pressentis : moins de 100, moins de 1 000, moins de 10 000, plus de 10 000 ?
 Quel type de gestion des habilitations est à envisager : identifiant authentifiant simple, authentification forte, cartes à puces, biométrie ?
 L’application future sera-t-elle accessible à des utilisateurs distants ?
   Besoins MOA en disponibilité
En cas d’indisponibilité de l’application ou des données, quel est le délai maximum d’interruption acceptable (DMIA), sans que cela ne génère de nuisances financières, commerciales, d’image, légales, organisationnelles… ?
 Quelle est la perte de données maximum acceptable (PDMA) à la reprise ?
 Existe-t-il des périodes d’exigence de continuité de service plus élevées qu’en temps normal ? Si oui, lesquelles ?
   Besoins MOA en intégrité
 Quelles seraient les conséquences engendrées en cas de modifications des données par accident (rechargement d’un fichier ancien), par erreur (mauvaise saisie) ou par malveillance (afin de nuire ou d’en tirer profit) ?
 Quel niveau d’intégrité est nécessaire pour l’application future, les données, les traitements : standard, sensible, fort ?
   Besoins MOA en confidentialité
 Quelles seraient les conséquences engendrées si les données utilisées ou générées par l’application future faisaient l’objet d’un piratage (conséquences financières, commerciales, d’image, légales, organisationnelles, autres) ?
 L’application future utilisera-t-elle des données nominatives, à caractère personnel nécessitant une déclaration à la CNIL ?
 Quel est le niveau le plus élevé de confidentialité que vous donneriez à ces données : public, interne, restreint, secret ?
   Besoins MOA en preuve et contrôle
 Quelles conséquences (financières, commerciales, d’image, légales, organisationnelles ou autres) pourraient être engendrées par manque de preuve et de contrôle sur les opérations effectuées ?
 De quel niveau de traces ou de pistes d’audit a-t-on besoin pour l’application future ? (traces détaillées avec non-répudiation, traces simples, non répudiation, pas de besoin).
   Besoins réglementaires
 L’application future nécessitera-t-elle le respect de contraintes légales ou réglementaires ?
 L’application future nécessitera-t-elle un archivage légal ?
   Sous-traitance de l’application
 L’externalisation de l’application est-elle prévue ?
 (*) 1 = acceptable / 2 = sensible / 3 = critique