EXPOSE : L’AUDIT DE SITE WEB

SOMMAIRE :

1- Introduction ....................................................................................3

2- Etat de l’art......................................................................................5

3- L’Audit du SI .................................................................................6
3-1 les domaines d’audit..................................................................7
3-2 les critères d’audit.....................................................................8

4- Audit d’une application ................................................................9

4-1 Adéquation aux besoins............................................................11

4-2 Sécurité logique.........................................................................11
4-3 Fiabilité.....................................................................................12
4-4 Qualité de la documentation....................................................12
4-5 Cohérence..................................................................................12
4-6 Performance...............................................................................12
4-7 Maintenabilité............................................................................12
4-8 Rentabilité..................................................................................12

5- Audit d’un site web........................................................................13

5-1 Les résultats...............................................................................13

5-2 Discussion..................................................................................15

6- Conclusion......................................................................................19

RESUME :
Pour justifier et planifier leurs dépenses informatiques, les directions des
systèmes d’information sont depuis longtemps conduites à évaluer et
auditer leurs systèmes d’information et plus particulièrement leurs
applications informatiques. Les sites web développés par les entreprises
sont devenus des applications cruciales, voire stratégiques, à l’instar des
sites de e-commerce. Dans cette communication, nous proposons une
méthodologie d’audit spécifique pour l’évaluation d’un site web, quelle que
soit sa nature. Cette méthodologie est fondée sur un modèle hiérarchique
multicritère. L’audit du site web est réalisé en procédant à l’évaluation de la
qualité de ce site en fonction d’un nombre limité de critères. Nous
analysons les difficultés particulières liées à ce type d’audit, notamment
dues au nombre de ses utilisateurs et à leur localisation. Nous dégageons
une démarche spécifique inspirée de l’audit d’une application classique.
Nous illustrons notre approche sur un cas réel. Enfin, les voies de recherche
future sont décrites.

Bibliographie :
 Akoka J. et Comyn-W. (2001), “ Auditing Computer and
Management Information Systems ”, Encyclopedia of Library and
Information Science, A. Kent, Volume 68, Marcel Dekker, Inc., New
York.

 Atzeni P., Merialdo P., Sindoni G. (2001), “ Web Site Evaluation –

Methodology and Case Study ”

 Breese P. (2000), “ Guide juridique de l’Internet et du commerce

électronique ”, Collection Entreprendre Informatique, Vuibert

 Danna E., A. Laroche, “ Auditing Web Sites Using Their Access

Patterns ”

 Lewin J. , “ Web Site Audit and Evaluation ”

 Verbiest T., D. Cassiers, “ L’audit juridique d’un site web ”

1. Introduction
2
C’est sans réelle planification que les entreprises ont été amenées à
concevoir et mettre en œuvre des sites web, permettant a minima de
diffuser l’information relative à leurs produits et services et, le cas échéant,
de servir de canal de vente et même de distribution. Ces sites sont des
applications informatiques, souvent conçues sans méthode structurée.
La maintenance de ces applications est rendue plus difficile, notamment en
raison de deux facteurs :
- la nécessité de faire évoluer constamment le contenu des sites,
- la difficulté à remanier des applications conçues de façon non
systématique.

Le site web devient l’épine dorsale du système d’information, vital au bon

fonctionnement de l’entreprise. Cette dernière doit à tout moment s’assurer
de l’adéquation de son système d’information à sa stratégie et de sa
contribution à lui octroyer un avantage compétitif. Dans ce but, l’audit d’un
site web permet une évaluation des forces et faiblesses de ce dernier.

Le processus d’audit d’un site web ne se limite pas à quelques données

statistiques sur le nombre de visiteurs, les échecs de connexions, le
décompte des intrusions, etc. Il inclut non seulement les aspects
technologiques : temps de réponse, fiabilité, disponibilité, etc., mais aussi
les aspects managériaux, notamment organisationnels, humains et
financiers. Pour prendre en compte l’ensemble de ces aspects, nous
proposons une méthodologie fondée sur l’analyse hiérarchique multicritère
permettant l’évaluation du site web vis-à-vis d’un ensemble exhaustif de
critères, tels l’adéquation aux besoins, la sécurité, la convivialité, la
performance, l’évolutivité, la rentabilité, etc. Chacun de ces critères peut
être lui-même décomposé en sous-critères. Ainsi la sécurité peut être
décomposée en confidentialité et intégrité. Evaluer l’intégrité nécessite de
tester l’ensemble des vulnérabilités de l’application. A un niveau terminal,
chaque sous-critère correspond à un contrôle d’audit à mener. L’approche
hiérarchique multicritère permet, à l’aide de l’évaluation de chaque critère
final, d’obtenir une évaluation globale du site web.

3
La méthodologie Infauditor a été définie de façon générale pour auditer
l’ensemble du système d’information d’une entreprise. Elle comprend, en
particulier, une arborescence d’évaluation d’une application informatique.

L’objectif principal de cette communication est de montrer comment

adapter cette arborescence aux applications particulières que sont les sites
web. Il ne s’agit pas seulement de présenter une étude descriptive. Il s’agit
pour l’essentiel d’adapter une méthodologie générale d’audit des systèmes
d’information au cas particulier de l’évaluation d’un site web.
Notre démarche s’inscrit dans la problématique générale de l’audit. Ce
dernier ne consiste pas seulement à examiner un produit (dans notre cas un
site web) en vue d’exprimer une opinion sur ses caractéristiques attendues,
mais aussi à procéder à un examen approfondi des dispositifs de contrôle
interne mis en place pour s’assurer de la minimisation des
dysfonctionnements.

Notre méthodologie propose un ensemble de contrôles internes mis à la

disposition du management et des auditeurs. Elle s’inscrit donc dans la
problématique du contrôle interne permettant l’évaluation des risques afin
de les maîtriser.

Le reste de notre exposé est organisé comme suit : Dans la deuxième partie,
nous présentons un état de l’art. La troisième partie est consacrée au rappel
des concepts de base de l’audit d’un SI. Dans la quatrième partie, nous
décrivons la méthodologie Infauditor d’audit d’une application
informatique. Dans la cinquième partie et dernière partie, nous illustrons
cette démarche par une étude de cas. Sur la base de ce cas, nous proposons
un ensemble d’adaptations de notre démarche générale au problème
particulier de l’audit d’un site web, quelle que soit sa nature.

4
2. Etat de l’art

Il existe quelques travaux relatifs à l’audit des systèmes d’information, ces

travaux sont caractérisés par une approche générique de l’audit des SI.
Ainsi, la démarche la plus répandue dans les entreprises est COBIT
(Control Objectives for Information and related Technology). Elle est
orientée processus d’informatisation et diffusée par l’ISACA (Information
Systems Audit and Control Association).
Notre méthode Infauditor analyse le système d’information, domaine par
domaine, selon un ensemble de critères défini à l’avance.
Ces deux méthodes permettent ainsi d’auditer tous les processus
d’informatisation pour COBIT, et tous les domaines d’un système
d’information pour Infauditor, notamment les applications opérationnelles.

En revanche, il existe à ce jour peu de travaux sur l’audit des sites web, en
termes de systèmes d’information. Les travaux qualifiés d’audit de site web
se concentrent principalement sur l’analyse des flux et des statistiques
associés à l’utilisation du site web. Danna et Laroche proposent une
méthode d’identification des profils des utilisateurs au moyen d’un
algorithme de classification floue des accès recensés dans les journaux
d’enregistrement du site. James Lewin propose une démarche d’audit et
d’évaluation de site web. Les critères retenus sont la présentation,
l’architecture, la visibilité, l’accessibilité, l’utilisabilité, l’adéquation du
contenu, l’interactivité, l’intégrité et la conformité aux lois. Une démarche
particulière en ce qui concerne les aspects juridiques est présentée par
Verbiest. Deshpande décrit succinctement une démarche d’audit de site
web, fondée sur les étapes suivantes :
- recueil d’informations,
- entretiens avec les fonctionnels,
- entretiens avec les informaticiens,
- entretiens avec les utilisateurs,
- et tests techniques.

Notons aussi des tentatives de standardisation par le W3C (World Wide

Web Consortium) et IEEE2001 qui sont autant de référentiels utiles dans
l’audit des sites web.
5
A notre connaissance, il n’existe pas de méthodologie spécifique à l’audit
d’un site web. Notre interprétation des “ best practices ” nous amène à
assimiler un site web à une ou plusieurs applications. En conséquence, nous
pouvons adapter la méthodologie Infauditor pour l’audit d’une application,
à celle d’un site web. C’est précisément l’objet des paragraphes qui suivent.

3. L’audit du SI

Le but d’une mission d’audit est de permettre à l’auditeur de se forger une

opinion sur la contribution du système d’information à la réalisation des
objectifs de l’entreprise. Pour cela, il doit vérifier que le système
d’information renforce les objectifs de contrôle interne de l’organisation. A
cette fin, il doit rechercher et obtenir les informations fiables et pertinentes
lui permettant de tirer des conclusions raisonnables sur l’état du système
d’information. Son jugement doit de plus tenir compte des facteurs tels que
les caractéristiques de l’organisation, de son système d’information et du
risque d’audit inhérent à tout jugement. Ce risque peut être impacté par des
éléments tels que :

- la nature et les caractéristiques du système d’information audité,

- la complexité des technologies utilisées pour la conception, le
développement et la mise en œuvre de ce dernier,
- le biais possible des acteurs impliqués dans le processus (audité,
auditeur, prescripteur, etc.),
- l’expérience de l’auditeur.

L’audit du système d’information inclut l’étude des éléments critiques de ce

dernier, à savoir les méthodes de développement, la maintenance des
applications, la qualité des logiciels, la sécurité du système, sa
documentation, etc. Pour organiser et structurer le processus d’audit, nous
avons défini deux concepts principaux : les domaines d’audit et les critères.

3.1. Les domaines d’audit

6
Tout système d’information comporte deux dimensions principales, la
dimension technologique et la dimension organisationnelle et managériale.
La notion de domaine permet d’affiner ces deux dimensions. Ainsi, l’audit
de la dimension technologique comprend l’évaluation de :

- la sécurité informatique,
- l’exploitation,
- des projets informatiques,
- des applications,
- et des réseaux.

L’audit de la dimension organisationnelle et managériale contient les

domaines suivants :

- la stratégie des systèmes d’information,

- les systèmes d’information fonctionnels (marketing, ressources
humaines, logistique, etc.),
- les procédures organisationnelles,
- la fonction système d’information.

Chaque domaine peut être décomposé en sous-domaines, par exemple,

l’audit de la sécurité informatique comprend d’une part la sécurité physique
et d’autre part la sécurité logique. Un domaine élémentaire peut être évalué
au moyen d’un test d’audit à définir.

3.2. Les critères d’audit

Pour satisfaire les objectifs de l’entreprise, les domaines précédents doivent

obéir à un certain nombre d’exigences qualifiées de critères. Nous
proposons la hiérarchie de critères suivante :

- les exigences de qualité qui incluent l’efficacité et la performance,

- les exigences en termes de sécurité comprenant notamment la
cohérence, la sécurité, la conformité et la fiabilité,
- les exigences de lisibilité, parmi lesquelles nous classons la
faisabilité, l’auditabilité et l’évolutivité.

7
Avant de démarrer une mission d’évaluation d’un système d’information,
l’auditeur doit valider auprès de son commanditaire le ou les domaines à
auditer et le ou les critères retenus pour évaluer le système.
L’étape suivante consiste à générer l’arborescence d’audit, c’est-à-dire
l’ensemble des nœuds des domaines retenus. Pour permettre une évaluation
globale, chaque nœud de cette arborescence est affecté d’un poids. La note
d’évaluation d’un nœud, par exemple la sécurité physique d’un système
d’information, résulte de la somme pondérée des notes calculées lors de
l’évaluation de chacun des sous-domaines de la sécurité physique. Au
niveau élémentaire, c’est l’auditeur qui, au vu des résultats du test d’audit,
affecte une note et une appréciation au nœud terminal correspondant. Un
exemple partiel d’arborescence est donné figure 1. A chaque niveau, un
seul nœud est déployé. Les valeurs numériques figurant sur les arcs sont les
poids de chaque nœud dans l’évaluation de leur nœud parent.

Audit
d’une
application

0.2 0.2 0.2 0.05 0.05 0.1 0.1 0.1

Adéquation Documen- Maintena-
Sécurité Fiabilité Cohérence Performance Rentabilité
aux besoins tation bilité

0.2 0.2 0.2 0.1 0.1 0.1 0.1

Degré de Atteinte des Procédures Adéquation Performance Degré d’obso-
Convivialité
satisfaction objectifs parallèles documentation Du service lescence

Figure 1. Arborescence d’audit d’une application

8
L’avantage de la méthodologie Infauditor est qu’elle permet d’aborder
l’analyse de façon structurée. De plus, elle peut être adaptée aisément à des
domaines particuliers ou à des situations spécifiques, soit en aménageant
l’arborescence, soit en modifiant les poids. Dans la partie suivante, nous
décrivons de façon plus précise l’audit d’une application avant de
l’appliquer à l’audit d’un site web.

4. Audit d’une application

Il est fréquent qu’un auditeur soit amené à évaluer une application. Ainsi,
dès qu’un problème d’insatisfaction des utilisateurs, de temps de réponse
trop long, de maintenance coûteuse, de fiabilité, etc., se produit,
l’application informatique est rapidement mise en cause par ses utilisateurs
et peut conduire la direction des systèmes d’information ou le directeur du
service utilisateur à effectuer ou commander un audit de cette application.
Les audits d’application sont aussi utilisés par les cabinets de conseil pour
évaluer le patrimoine informatique d’une filiale à acheter par exemple. La
décision de recourir à un progiciel de gestion intégrée peut résulter de
l’audit d’une application jugée archaïque. Bref, ce type d’opération est très
fréquent. Disposer d’une méthode structurée permettant d’auditer et
d’évaluer une application, quelle qu’elle soit, est un atout précieux.
Dans Infauditor, nous proposons d’évaluer le domaine correspondant à une
application selon les huit critères suivants :

- adéquation aux besoins,

- sécurité logique,
- fiabilité,
- qualité de la documentation,
- cohérence,
- performance,
- maintenabilité,
- rentabilité.
4-1 Adéquation aux besoins
L’adéquation aux besoins consiste à vérifier que l’application répond aux
besoins réels de ses utilisateurs, qu’elle s’intègre harmonieusement dans les
procédures de l’entreprise et qu’elle satisfait ses utilisateurs. L’adéquation
aux besoins comprend sept sous-domaines ou critères :

- Le degré de satisfaction, qui peut être mesuré à l’aide d’un

questionnaire. Outre l’évaluation de ce degré, la synthèse des réponses
au questionnaire permet aussi de cibler les sous-domaines de
l’application qui semblent les plus critiques.
- L’atteinte des objectifs : ce sous-domaine peut être audité en
rapprochant l’application des différents documents préalables à sa mise
en place et à ses éventuelles évolutions, cahier des charges, additifs, etc.
- L’existence de procédures parallèles : il est fréquent que l’insatisfaction
des utilisateurs ou leur manque de confiance ou les limites de
l’application aient conduit les acteurs à mettre en place des procédures
parallèles, par exemple des re-calculs manuels ou sur tableur, des
transmissions de bordereaux de confirmation, etc. La détection de ce
type de procédure est un élément important de l’évaluation de cette
application.
- La documentation : il ne s’agit pas d’évaluer la documentation en
générale, mais l’adéquation de la documentation aux besoins des
utilisateurs. Est-elle suffisante, claire et d’actualité ?
- La performance du service : là encore, on n’évalue pas la performance
de façon absolue, mais le niveau de performance obtenu en regard des
attentes de l’utilisateur. Il convient pour cela de mesurer les délais de
restitution ou de réponse, mais aussi les délais de mise à jour de
l’application au travers, par exemple, du nombre de demandes de
modifications en attente de réalisation.
- La convivialité des postes de travail : on mesure l’ergonomie de
l’interface, l’agencement aisé et performant des menus et des étapes
d’interaction avec l’application.
- Le degré d’obsolescence : permet de vérifier que les fonctionnalités de
l’application sont toujours d’actualité.

4-2 Sécurité logique

Il existe un grand nombre de techniques de sécurisation des logiciels, en
termes de confidentialité par le contrôle des accès en lecture et en termes
d’intégrité par le contrôle des accès aux données en écriture. La sécurité
logique d’une application peut être divisée en cinq aspects :

- le contrôle des accès : l’auditeur vérifiera que l’accès à l’application

n’est possible qu’aux personnes autorisées et qu’en particulier les
procédures d’identification et d’authentification ne sont pas
contournées, que les mots de passe sont régulièrement modifiés, etc.
- Le contrôle à la saisie : il permet l’intégrité des données. Il peut être
testé par l’auditeur qui tentera d’introduire des données aberrantes et
vérifiera qu’elles sont effectivement rejetées, mais aussi que les
procédures de contrôle sont efficaces en termes de temps de réponse.
- Le contrôle des traitements : là encore, il s’agit d’intégrité des données.
On vérifiera par une série de tests que les calculs sont conformes aux
attentes, qu’il n’y a ni problème d’exactitude, ni erreur d’arrondi, ni
aucune autre imprécision.
- Le contrôle des résultats : différentes techniques (totalisation,
vraisemblance, échantillonnage) sont à combiner pour s’assurer de
l’exactitude des résultats produits par l’application.
- La pérennité des données et des traitements : elle est liée à la mise en
place de sauvegardes régulières.

4-3 Fiabilité
L’audit de la fiabilité d’une application consiste à vérifier qu’il existe des
procédures de gestion et de suivi des incidents et d’en mesurer l’efficacité.
Cet audit comprend deux éléments principaux :

- Le suivi des incidents : il s’agit de s’assurer de l’existence d’une

procédure de suivi des incidents au travers des documents générés lors
de son exécution.
- L’évaluation de la fiabilité au travers de grandeurs de référence : les
trois grandeurs habituelles sont le délai moyen entre incidents, le délai
moyen de service et la durée moyenne des incidents. Ces valeurs sont à
rapprocher d’un référentiel interne ou externe.

4-4 Qualité de la documentation

Par documentation, on entend les trois manuels nécessaires respectivement
à l’utilisation, à l’exploitation et à la maintenance de l’application. Ces trois
documentations doivent être disponibles, adaptées et à jour.

4-5 Cohérence
La cohérence de l’application peut être mesurée par rapport à un référentiel
interne ou externe. Elle consiste à s’assurer que l’application répond aux
standards en termes de méthode de conception, de développement et de
maintenance.

4-6 Performance
L’auditeur est amené à conduire des tests sur l’application pour vérifier que
les temps de réponse sont satisfaisants et que l’application n’a pas d’impact
négatif sur l’ensemble du système d’information, ce qui peut être le cas par
exemple si elle consomme toutes les ressources matérielles disponibles.

4-7 Maintenabilité
La facilité de maintenance d’une application est évaluée par interview des
informaticiens responsables d’effectuer les évolutions logicielles, tant en
termes de maintenance corrective que de maintenance évolutive.

4-8 Rentabilité
Le développement de l’application a nécessité un investissement dont il
faut évaluer la rentabilité, c’est-à-dire le retour sur investissement. Les
informations relatives à cet aspect financier sont parfois disponibles dans
l’étude préalable et/ou l’étude de faisabilité. Dans la plupart des cas, ils
n’ont pas été mis à jour. L’audit complet de l’application doit aussi tenir
compte de cet aspect en évaluant les bénéfices réalisés au moyen de cette
application. Ces bénéfices doivent être dégrevés des coûts d’exploitation et
de maintenance de l’application.
L’ensemble des critères précédents sont regroupés sous forme
d’arborescence multicritère pondérée. C’est cette arborescence que nous
nous proposons d’adapter au cas particulier d’un site web. A priori, un site
web peut être assimilé à une application informatique. En conséquence, la
démarche précédente peut sembler adéquate dans la réalisation d’un audit
de site web. Néanmoins, il existe un ensemble de différences entre une
application classique et un site web. Dans la suite, nous proposons
d’analyser ces différences et d’adapter la démarche Infauditor à l’audit d’un
site web.

5. Audit d’un site web

La méthodologie d’audit décrite ci-dessus a été appliquée à l’évaluation

d’un site web ayant pour objet la mise en ligne de loteries. L’audit a été
réalisé au moyen d’entretiens détaillés. Les résultats ont été comparés avec
le cahier des charges de l’application. La stratégie de cette entreprise est
fondée sur l’utilisation des technologies de l’information et de la
communication, ainsi que sur le renouvellement de ses jeux. Le site
Internet complète les autres outils d’information utilisés (télévision, radio,
etc.). Dans le futur, le site Internet sera utilisé également dans les relations
commerciales avec les détaillants. Chaque mois, environ 48000 connexions
sont enregistrées sur ce site. Certaines fonctionnalités prévues dans le
cahier des charges, telles que les historiques des rapports et des tirages, la
recherche des points de vente et les jeux gratuits sont encore à réaliser.
L’audit avait pour but de vérifier si ces fonctionnalités représentent un vrai
besoin sur ce marché, si le site correspond aux attentes exprimées dans le
cahier des charges et s’il existe d’autres besoins non explorés.

5-1 Les résultats

La méthodologie Infauditor a été appliquée à ce cas réel. Pour évaluer
chacun des nœuds de l’arborescence, chaque point a été rapproché des
objectifs du cahier des charges. Nous nous contentons donc de synthétiser
les résultats de l’audit dans un tableau. Pour rendre nos propos plus précis,
nous ne faisons pas figurer les notes mais plutôt les appréciations liées à
chaque nœud.
 CRITERES POINTS FORTS POINTS FAIBLES

Adéquation aux
besoins

Degré de 80 à 85% des utilisateurs se Le moteur de recherche n'est pas

satisfaction déclarent satisfaits complet

La recherche par mot-clé est Les utilisateurs regrettent

efficace l'absence de contact par email,
de jeux gratuits et le manque
La navigation est jugée d'information didactique sur les
conviviale jeux eux-mêmes.

Objectifs atteints On peut déclarer que les Il manque de ressources

objectifs globaux sont humaines et de temps pour
atteints perfectionner le site

Procédures Aucune procédure n'est

parallèles utilisée

Documentation L'utilisation du site est rendue aisée par la navigation

Performance du Elle est jugée très bonne. Il n'y a pas de file d'attente. Un site
service miroir permet un "back up" continu. Le serveur est
actuellement suffisamment puissant, la bande passante aussi.

Convivialité Elle est évaluée positivement par tous les intervenants

Degré Une commission ad hoc se Les réunions de la commission

d'obsolescence réunit régulièrement pour ne sont pas assez formalisées
vérifier la mise en œuvre des
procédures de mise à jour

Sécurité

Contrôles à la saisie Plusieurs contrôles Divers moyens de

automatisés existent communication obligent à une
double saisie (fax, email)

Il semble exister un manque de

coordination entre les entités
internes de l'entreprise

On déplore une absence de suivi

de la relation client en cas
d'erreur

Contrôle des Il existe plusieurs niveaux de Le contrôle n'est effectué que sur
traitements contrôle et des procédures
 sous forme de check-list les nouvelles pages

Contrôle des Il n'existe pas de contrôle global.

résultats

Fiabilité

Suivi des incidents Peu d'incidents sont à déplorer

Il existe une procédure de suivi de ces incidents, ainsi qu'une

documentation écrite listant les incidents possibles

Mesure des Le délai de 2 à 3 heures pour remonter le serveur en présence

incidents du web master est jugé court.

Documentation Une seule personne est

responsable du système dans
son ensemble

De ce fait, la documentation est

limitée.

Cohérence Le site de développement est Le site a été lancé à partir d'un

séparé du site en exploitation prototype, sans la définition
d'une méthode de suivi
Il existe des documents
internes résumant les
normes en vigueur

Performance Acceptable

Maintenabilité Satisfaisante

Rentabilité Le coût est inférieur au Les coûts ne sont pas analysés

support papier séparément des frais généraux

Le coût des ressources

humaines est limité

5-2 Discussion
La méthodologie Infauditor s’avère applicable à un site web. Elle permet
une approche structurée et une évaluation systématique des différents
aspects importants relatifs au site web. Toutefois, cette expérimentation et
la revue de la littérature nous conduisent à proposer certains aménagements
de la méthodologie Infauditor pour ce type très spécifique d’application.
Par exemple, la notion de procédure parallèle est très difficile à mettre en
application. Dans un site de commerce électronique, peut-on considérer que
l’acheteur qui utilisera un autre canal de vente que le site web utilise une
procédure parallèle ? Oui, dans la mesure où cela peut refléter un manque
de confiance dans la transaction électronique. Non, s’il ne dispose pas de ce
moyen de commercer avec l’entreprise.
Cet aspect n’est pas majeur dans l’audit d’une application. Pourtant, c’est
un moyen de mesurer la satisfaction des utilisateurs.
Plus généralement, plusieurs éléments différencient un site web d’une
application informatique classique :
- le nombre d’utilisateurs est généralement très élevé, leur profil peut être
extrêmement varié, leur comportement et leurs besoins sont très
différents. Ces particularités vont rendre plus complexe l’évaluation de
l’adéquation aux besoins. La satisfaction des utilisateurs devra être
mesurée à l’aide de moyens spécifiques, non plus sur la base d’un
échantillon d’utilisateurs connus, mais par le biais d’un questionnaire
on-line, enrichi d’une analyse statistique sur le journal de suivi des
accès au site.
- Les utilisateurs sont pour la plupart externes à l’organisation. Le site
web est une application ouverte, plus vulnérable. La sécurité de cette
application sera donc à considérer avec d’autant plus de vigilance.
- On ne peut généralement pas limiter le site web à une application.
L’accès par un utilisateur à un site va impacter plusieurs applications,
l’application de gestion des accès, l’application de gestion du contenu,
les modules de sécurité du SI, etc. L’audit du site web doit concerner
toutes les applications reliées à travers ce site.
- La plupart des sites proposent deux modes d’accès : un mode public
sans contrôle d’identité, fournissant une information limitée et un mode
“ privé ” nécessitant une authentification et, le cas échéant, un paiement
électronique. Cette particularité augmente la vulnérabilité du site face
aux intrusions et impacte l’audit de la sécurité de cette application.
- La mesure de la fiabilité du site requiert l’exploitation des journaux
(fichiers “ log ”). C’est une tâche bien plus conséquente que le suivi
d’incidents d’applications classiques.
- La performance du site web est, elle aussi, complexe à évaluer. D’une
part, il faut la mesurer à différents moments, par exemple à l’aide de
routines spécifiques. D’autre part, il faut prendre en compte la
 performance des différentes applications appelées et la performance des
réseaux (Intranet et Internet) sur lesquels transitent les interactions.
- La qualité de la documentation diffère en ce qui concerne la
documentation utilisateur. En effet, celle-ci est complètement en ligne,
intégrée à l’interface utilisateur. La convivialité de la documentation est
étroitement liée à celle de l’application et inversement.
- La maintenabilité du site web est un aspect important. Notons que
l’application correspondante est plus sujette à maintenance qu’une
application classique : son contenu évolue parfois d’heure en heure.
Toutefois, des outils de gestion de contenu peuvent être utilisés pour
faciliter cette mise à jour. On considèrera donc qu’un site qui utilise
astucieusement de tels outils a une maintenabilité largement supérieure.
- La rentabilité d’un site web mesure le rapport entre l’investissement
consenti pour son développement et sa maintenance avec les bénéfices
liés à son exploitation. Dans ces bénéfices, il convient d’évaluer pour les
sites marchands la part de marché atteinte via ce créneau de
commercialisation. On mesure de plus l’efficacité du service au client
rendu par le moyen des conseils en ligne, des moteurs de recherche
intégrés au site, etc.
- Enfin, le référencement du site est un critère important d’évaluation de
son adéquation aux besoins, mais aussi de sa rentabilité. Il convient de
mesurer ce référencement et de pallier les lacunes éventuelles, par
exemple par le moyen d’accords commerciaux.
- Le risque d’audit est élevé dans la mesure où il n’est pas possible
d’interroger un grand nombre d’utilisateurs, ni même – dans de
nombreux cas – de connaître ces utilisateurs.
- Les aspects juridiques deviennent cruciaux dans ces systèmes
d’information ouverts. C’est un critère supplémentaire à considérer dans
l’audit. En particulier, le nom du site ne doit pas être sujet à réclamation
par des tiers. Les textes, images, sons intégrés dans le site doivent être
conformes au droit de la propriété intellectuelle. Le site ne doit pas
contenir de lien vers des sites dont le contenu est illégal. Pour se
protéger de réclamations liées au contenu informationnel, le site doit
contenir une clause exonératoire de responsabilité.
A la lumière de ces différences, la démarche d’audit d’une application
adaptée à un site web nécessite plusieurs types de transformations :

 la modification de certains tests d’audit :

A titre d’exemple, citons la vérification de l’existence de procédures

parallèles, la mesure du degré de satisfaction des utilisateurs, l’évaluation
de la fiabilité, de la performance ou encore de la rentabilité du site web qui
donnent lieu à des méthodes spécifiques de conduite de tests.

 la modification des poids de l’arborescence :

La sécurité et la maintenabilité doivent être pondérées de façon plus

importante que dans les applications classiques.

 l’aménagement de l’arborescence :

A titre d’illustration, nous proposons l’ajout d’un nœud Référencement du

site pour évaluer l’adéquation aux besoins de ce dernier. De la même façon,
nous proposons l’ajout d’un nœud Conformité aux lois situé au premier
niveau de l’arborescence d’audit d’application.

Les limites de notre approche de l’audit d’un site web sont celles de la
méthodologie d’analyse hiérarchique multicritère, et donc d’Infauditor. Elle
impose une connaissance préalable de l’ensemble des critères pouvant
intervenir dans l’évaluation d’un site web. De plus elle nécessite le
regroupement de ces critères à des niveaux d’agrégation appropriés. Enfin,
elle requiert une pondération de ces critères adaptés au site web considéré
et aux objectifs poursuivis par les responsables de ce site.

6. Conclusion :
Dans cet exposé, nous avons présenté une démarche structurée d’audit d’un
site web. Dans un premier temps, nous avons défini les concepts relatifs à
l’audit d’un système d’information. Puis nous avons proposé une
méthodologie d’audit d’une application. Cette dernière, appelée Infauditor,
est fondée sur un modèle hiérarchique multicritère formant une
arborescence pondérée d’audit. Nous avons appliqué cette démarche à
l’audit d’un site web réel, puis nous avons montré les différences
importantes existant entre une application classique et un site web. Fondées
sur cette expérience, nous avons proposé des adaptations de notre démarche
d’audit d’application afin de tenir compte des spécificités d’un site web. Le
résultat constitue une démarche autonome et structurée d’audit d’un site
web, qu’il s’agisse d’une vitrine, d’un portail ou d’un site de e-commerce.