Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Forum de l’article

Contre les méthodes de conduite de projet

modération a priori

Ce forum est modéré a priori : votre contribution n’apparaîtra qu’après avoir été validée par un administrateur du site.

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)

Rappel de la discussion
Contre les méthodes de conduite de projet
Ghusse - le 4 février 2008

Bonjour,

Je me permet de réagir à un paragraphe du billet intitulé ’Contre les méthodes de conduite de projet’. Celui-ci traite de la sécurité informatique, et plus précisément de ce qu’on appelle une analyse de risques.
Je reprends ci-dessous le contenu de ce paragraphe.


Les deux erreurs ci-dessus, conjuguées entre elles, peuvent être utilement complétées par une attitude intellectuelle qui semble de prime abord assez saine, mais qui va se révéler comme une nouvelle erreur : le souci d’exhaustivité. Prenons comme exemple un projet de sécurité informatique destiné à évaluer et à améliorer la disponibilité d’un système d’information. Le responsable du projet pourra par exemple s’inspirer de la méthode EBIOS élaborée en France par la Direction centrale de la sécurité des systèmes d’information (DCSSI). Une telle méthode le conduira à dresser une liste des risques, à associer chacun de ces risques à des vulnérabilités, et à envisager les contre-mesures qu’il peut élaborer pour s’en prémunir, selon une formule pleine de bon sens et d’utilité :

risque = \fracmenace × vulnérabilité × sensibilitécontre-mesure

Cette conceptualisation est intéressante, mais elle peut engendrer la tentation de dresser une liste de risques ou une liste de vulnérabilités que l’on placera dans la colonne de gauche d’un tableau, afin d’en remplir la colonne de droite avec les contre-mesures appropriées.

Pourquoi cette démarche est-elle maladroite ? Parce que les risques et les menaces sont nombreux et souvent inconnus, alors que le répertoire des contre-mesures possibles est beaucoup plus réduit ; souvent, cela peut se résumer à cinq ou six grands thèmes : plan de sauvegarde des données, amélioration du stockage, aménagement d’un site de secours avec duplication des données à distance, administration correcte des serveurs (fermeture des services inutiles, séparation des privilèges, application des correctifs de sécurité, surveillance des journaux), sécurisation du réseau (pare-feu, authentification forte, fermeture des services inutiles), sécurisation physique des locaux. Il est donc plus simple et plus efficace de partir de la table inverse de la précédente : mettre les contre-mesures dans la colonne de gauche, et énumérer dans la colonne de droite les risques éliminés par elles, ce qui évitera de payer un consultant pendant des mois pour élaborer la liste des centaines de risques plus ou moins réels que l’on peut envisager.

Cette démarche prétendue exhaustive qui consiste à examiner de longues listes d’items pour cocher des cases dans la colonne d’en face, c’est la façon de travailler des ordinateurs, rapides, systématiques et mécaniques ; l’intérêt du travail d’un professionnel compétent par rapport à l’ordinateur, c’est que l’homme réfléchit, a des idées et des connaissances, il est capable d’en tirer parti pour éliminer les cas non pertinents et regrouper les cas similaires de façon à leur appliquer le même traitement, bref il est capable d’avoir une vue synthétique des choses. Réduire le travail humain à des procédures de type informatique est tout à fait contre-productif.


L’approche que vous décrivez a effectivement plusieurs inconvénients. Effectuer une analyse des risques informatique peut sembler à première vue sans intérêt. On dresse un tableau, on met des nombres "un peu au pif". Du point de vue d’un informaticien, cette démarche parait totalement inutile (on perd du temps), inefficace (ça ne résout pas les problèmes) et surtout inexacte (pourquoi 3 dans cette case, et pas 4, ni 10 ?).

Une analyse des risques informatique a l’immense avantage, lorsqu’elle est réalisée avec sérieux et rigueur, de recentrer les débats. Bien souvent, le responsable informatique parle de problèmes ou de solutions techniques : de patchs, de chiffrement, faille, injection etc. Or, le véritable enjeu de la sécurité informatique est ailleurs.

Ce qui doit être au centre des débats, ce sont les données ou les ressources. Les données sont importantes non pas du point de vue des RSSI mais pour les utilisateurs : les décideurs qui traitent de données confidentielles, les ressources humaines qui manipulent des données personnelles etc. L’analyse de risque permet de poser la question du coût de la perte, de la divulgation ou de l’altération de ces données. Et seules les personnes du métier peuvent répondre à cette question.

Pourquoi cette étape est indispensable pour un RSSI ? La réponse est simple : il peut avoir une notion de ce qui est important ou pas, mais il ne peut pas connaitre toutes les contraintes associées à toutes les activités de son entreprise. De plus, il aura à mettre en relation le coût d’une contre mesure avec le risque duquel il est sensé protéger l’entreprise.

C’est pourquoi je ne vous suis pas lorsque vous parlez d’exhaustivité. En effet, toutes les mesures que vous citez sont des "best practicies", un consultant n’a pas besoin d’intervenir dans n’importe quelle entreprise en tirer la conclusion "il faut mettre un pare-feu". Non, le problème n’est pas là.

Les questions sont les suivantes :
* Les données modifiées pendant une journée sur tel applicatif représentent combien de travail ?
* Une interruption de tel service coûte combien à notre entreprise par heure ?

En fonction des réponses, il faudra imaginer des solutions techniques et chiffrer celles-ci. La décision finale peut être - pour des gros budgets - laissée à l’appréciation du niveau supérieur du RSSI. La présentation est simple : à tel coût nous pouvons reprendre l’activité en tant de temps, avec un coût moindre c’est en x fois plus de temps etc. Que choisissez vous ?

J’ai encore beaucoup de choses à dire à propos de ce simple paragraphe, mais je vous laisse le soin de me répondre si vous voulez en débattre plus longuement.

À propos de l’analyse de risques
Laurent Bloch - le 5 février 2008

Ce que vous dites est raisonnable, bien sûr : l’intérêt d’une analyse de risques raisonnable, justement, est de faire réfléchir les responsables des données à leur responsabilité pour qu’ils en tirent des conclusions elles-mêmes raisonnables. Et je ne puis qu’être d’accord avec vous.

Les dysfonctionnements que j’ai observés sont des situations différentes : le client ne veut pas réfléchir, il veut la solution sans s’être posé le problème, il croit qu’elle réside dans une norme ou dans un référentiel, et un consultant qui doit gagner sa vie (c’est humain) lui défile les quatre volumes de la norme XXX et lui facture ensuite deux années de travail. Vous me direz, c’est moral, le client a payé le prix de son incompétence et de sa bêtise, le consultant a bien eu raison d’en profiter pour mettre un peu de beurre dans les épinards de sa petite famille. Bon, disons que j’ai écrit mon livre pour permettre au lecteur de ne pas trop beurrer les épinards de ses prestataires. Que les consultants se rassurent, les décideurs ne lisent pas.

Derniers commentaires

Controverses autour du Système d’information (SI)
Les traités d’informatisation des années 1960 (CEGOS- G. Bauvin, etc.) expliquaient déjà que (...)

Informatique confidentielle
Je cite "moins d’une machine virtuelle que d’un système exploitation virtuel". On a vraiment (...)

Pourquoi Scheme ?
Je suis étonné de la citation suivante dans le contexte d’un article "Pourquoi Scheme ?" : (...)

Le Projet Unicorn
Un grand merci tout d’abord pour cette fiche de lecture qui m’a donné envie de lire l’ouvrage. (...)

Informatique confidentielle
Lorsque j’étais responsable du SI de Dauphine, il s’est rapidement avéré que la solution la (...)