Table des matières

Fiche de présentation ..............................................................................................................5

PROGRAMME .............................................................................................................................6
CHAPITRE I : Introduction au Génie Logiciel .........................................................................7
I. La crise du logicielle ......................................................................................................8
I I . Le logiciel ........................................................................................................................9
CHAPITRE II : GESTION DE PROJETS LOGICIELS..................................................................... 10
Introduction.............................................................................................................................. 10
I. Les méthodes dites classiques ............................................................................................... 11
II. Les méthodes agiles.............................................................................................................. 12
1. Les valeurs communes des méthodes agiles ....................................................................... 12
2. Design Thinking............................................................................................................. 13
a) Définition ................................................................................................................ 13
b) Origine du Design Thinking .................................................................................. 14
c) Principes du Design Thinking.......................................................................................... 14
e) Av antages du Design Thinking ........................................................................... 16
1. Le Scrum .......................................................................................................................... 16
a) Le Product Owner................................................................................................. 17
b) Le ScrumMaster..................................................................................................... 18
2. La planification............................................................................................................. 19
a) Le Scrum quotidien............................................................................................... 19
b. Le sprint......................................................................................................................... 20
d. La release.................................................................................................................. 21
I II. Le manifeste agile ........................................................................................................... 22
IV. Cycle de vie ...................................................................................................................... 23
1. L’analyse des besoins.................................................................................................. 23
2. La conception générale............................................................................................. 24
3. La conception détaillée ............................................................................................. 24
4. L’implémentation et les tests unitaires ...................................................................... 24
5. L’intégration modulaire............................................................................................... 24
6. La v alidation et le déploiement ................................................................................ 24
7. La maintenance évolutive et corrective ................................................................. 25
8. Quelques cycles de vie .............................................................................................. 25
V. Analyse des besoins ........................................................................................................ 25
a. Collecte d’informations .............................................................................................. 26
 b. Définition des besoins .................................................................................................. 26
c. Spécification des besoins ........................................................................................... 27
d. Document d’analyse .................................................................................................. 27
CHAPITRE III : NOTION DE QUALITE LOGICIEL ....................................................................... 29
Définition .................................................................................................................................. 29
I. Indicateurs de qualité logicielle .................................................................................... 30
a. La capacité fonctionnelle .......................................................................................... 30
b. La facilité d’utilisation.................................................................................................. 30
c. La fiabilité...................................................................................................................... 30
d. La performance ........................................................................................................... 30
e. La maintenabilité ......................................................................................................... 30
I I . Les différentes perceptions de qualité ......................................................................... 31
III. Les trois axes de qualité d’un logiciel.................................................................................. 31
I V. Assurance qualité ........................................................................................................ 32
a. Assurer la qualité du logiciel....................................................................................... 32
b. Les sept principes de qualité d’un logiciel............................................................... 33
c. Processus d’assurance de la qualité ........................................................................ 33
d. Plan d’Assurance Qualité (PAQ) ............................................................................... 33
V. Contrôle qualité............................................................................................................... 34
VI . Types de menaces ...................................................................................................... 34
1. Les virus.......................................................................................................................... 34
a. Risques ....................................................................................................................... 34
b. Protection.................................................................................................................. 35
2. Chev aux de Troie/Backdoors .................................................................................... 35
a. Risques ....................................................................................................................... 35
b. Protection.................................................................................................................. 35
3. Spyw are......................................................................................................................... 36
a. Risques ....................................................................................................................... 36
b. Protection.................................................................................................................. 36
4. Les spams ...................................................................................................................... 36
a. Risques ....................................................................................................................... 36
b. Protection.................................................................................................................. 37
5. Hoaxes........................................................................................................................... 37
a. Risques ....................................................................................................................... 37
b. Protection.................................................................................................................. 37
6. Problèmes d’utilisateur ................................................................................................ 38
a. Risques ....................................................................................................................... 38
b. Protection.................................................................................................................. 38
7. Mots de passe .............................................................................................................. 38
a. Risques ....................................................................................................................... 38
b. Protection.................................................................................................................. 38
8. Partage ......................................................................................................................... 39
a. Risque......................................................................................................................... 39
b. Protection.................................................................................................................. 39
9. Sauv egarde.................................................................................................................. 39
a. Risques ....................................................................................................................... 39
b. Protection.................................................................................................................. 40
 Cours

INTRODUCTION AU GENIE LOGICIEL

Conçu par :

Christian BELINGA
Ingénieur Informaticien, Master en SSN Université de
Bourgogne Dijon
 Fiche de présentation
1. INTRODUCTION AU GENIE LOGICIEL

2. PUBLIC CIBLE : Etudiant niv eau III

3. EQUIPE PEDAGOGIQUE DE CETTE UV :

Responsable pédagogique : Madame NDJATHE Germaine
Concepteur : BELINGA AMOUGOU Christian
Tuteur : BELI NGA AMOUGOU Christian
4. PREREQUIS : Cours de Gestion de projets

5. MOTS CLES : Projets, Agile, Design Thinking, scrum, sprints, Backlog, cycle de v ie

6. MATERIELS ET LOGICIELS : Portable Computer

7. RESSOURCES COMPLEMENTAIRES :

8. OBJECTIF GENERAL : Maitriser les techniques de gestion de projets informatiques

9. OBJECTIFS SPECIFIQUES : Maitriser les méthodes agiles, les techniques de gestions

de projets informatiques et les techniques de travail collaboratif

10. DUREE : Semestre I

10.1 Volume horaire : 30 heures de cours

10.2 Plage de temps : 2 heures de cours par séance

10.3 Tutorat synchrone :

10.4 Tutorat asynchrone :

10. 5 Travail personnel de l’étudiant : 60%

11. CREDITS :

12. DEMARCHE PEDAGOGIQUE : Apprentissage par l’apprenant

13. EVALUATION : Contrôle continu, Projets et examen

14. ORGANISATION

14.1 Structuration du cours : 4 Chapitres

14.2 Description du contenu :

 PROGRAMME

Chapitre I : Introduction au génie logiciel

Chapitre II : Gestion des projets logiciels

Chapitre III : Notion de qualité logicielle

Chapitre IV : Conception, programmation et test (Projets)

CHAPITRE I : Introduction au Génie Logiciel

Un Logiciel est un ensemble bien documenté (à tous les niveaux) de

programmes informatiques conçu pour satisfaire les besoins de ses utilisateurs
ou Ensemble des programmes et des procédures nécessaires au
fonctionnement d'un système informatique.

Le Génie Logiciel définit alors l’ensemble des méthodes et des techniques

pouvant faciliter la conception, la réalisation des logiciels complexes et de
bonne qualité, il rassemble les règles de l’art de l’ingénierie des systèmes
logiciels. Cette discipline vise la formalisation et la proposition des approches
méthodologiques pour la construction des logiciels. Cette discipline est très
importante pour la mise en œuvre des systèmes complexes, où des objectifs
antagonistes doivent souvent être pris en compte.

Le Génie Logiciel est né en Europe dans les années 70. Il a été défini par un
groupe de scientifiques pour répondre à un problème qui devenait de plus en
plus évident : le logiciel n’est pas fiable et il est difficile de réaliser dans des
délais de temps prévus.

Petit e historique :

• 1968 : naissance du Genie Logiciel à la conférence de l'OTAN à

Garmisch-Partenkirchen (Allemagne)
• 1973 : première conférence sur le Genie Logiciel
• 1975 : première revue sur le GL (IEEE Transaction of Software
Engineering)
• 1980 : début des AGL

Le Génie Logiciel est à rapprocher du Génie civil, Génie mécanique ou Génie

chimique. La réalisation d'un pont ne peut être menée sans méthodologie, de
même la réalisation d'un logiciel nécessite un minimum de précautions qui
garantissent un certain nombre de propriétés. Le terme génie logiciel a été
choisi pour exprimer le fait que le développement d’un logiciel doit se fonder
sur des bases théoriques et sur un ensemble de méthodes et outils validés par
la pratique ; Le génie logiciel considère ainsi le logiciel comme un objet
complexe. La production du logiciel implique de ce fait des environnements
de développement avec toute la variété d'outils et d'approches dont on peut
disposer, les méthodes et les techniques de gestion de processus, mais aussi les
aspects humains au sein de l'équipe de développement et les relations que
celle-ci entretient avec les commanditaires et les utilisateurs du produit.

Historiquement, l’intérêt du génie logiciel s’est accru suite à la crise du

logiciel.

I. La crise du logicielle

Elle nait dans les années 1970 aux Etats Unis, et est perçue à travers les
symptômes suivants :

a. Les coûts de développement logiciel sont pratiquement imprévisibles et

extrêmement élevés.

b. Les logiciels produits ne remplissent souvent pas les besoins des

utilisateurs et comportent de nombreuses erreurs ; d’autre part, les clients
manquent de mét riques permettant de mesurer la qualité du logiciel.

c. La maintenance logicielle est difficile et coûteuse du fait de la faiblesse

de la documentation.

Ces problèmes suscitent des risques humains et économiques comme

l’illustrent les exemples célèbres suiv ants :
• TAURUS, un projet d'informatisation de la bourse londonienne :
définitivement abandonné après 4 années de travail et 100 millions de
£ (livres sterling) de pertes.
• L’avion C17 (1993) de McDonnell Douglas livré avec un dépassement
de 500 millions de $ ... (19 calculateurs hétérogènes et 6 langages de
programmation différents).
• Au Cameroun, les employés de l’état ont eu un retard sur le payement
de leur salaire à cause d’une panne du logiciel traitant les salaires au
CENADI.
• En 1999, les étudiants de la faculté des arts, lettres en sciences
humaines de l’université de Yaoundé I entrent en grève à cause d’une
erreur de calcul des moyennes sur les modules.

Remarque : Une erreur, petite soit -elle peut être dangereuse par exemple pour
la commande en temps réel de l’avion, … D'après le cabinet de conseil en
technologies de l'information Standish Group International, les pannes causées
par des problèmes de logiciel ont coûté en 2000 aux entreprises du monde
entier environ 175 milliards de dollars, soit deux fois plus qu’en 1998 (Le Monde
23/10/01).

II. Le logiciel

Le logiciel est aujourd'hui présent partout, sa taille et sa complexité

augmentent de façon exponentielle, les exigences en besoins et en qualité
sont de plus en plus sévères. L'objectif du génie logiciel est de développer dans
les délais des logiciels de qualité ; il se préoccupe des procédés de fabrication
de logiciels de façon à s’assurer que le produit qui est fabriqué :

• Réponde aux besoins des utilisateurs : Fonctionnalités

• Reste dans les limit es financières prévues au départ : Coût
• Corresponde au contrat de service initial : Qualité (la notion de
qualité de logiciel est multiforme)
• Reste dans les limites de temps prévues au départ : Délai

Règle du CQFD1 : Coût Qualité Fonctionnalités Délai. L'utilisation d’une

méthodologique pour produire un logiciel s'est montrée incontournable par la
crise de l'industrie du logiciel (crise du logiciel).

L’une des difficultés majeures dans l’élaboration des processus de

développement des logiciels tient à la nature du logiciel. L’organisation
internationale de normalisation (ISO) définit le logiciel comme une création
intellectuelle rassemblant des programmes, des procédures, des règles et la
documentation utilisée pour faire fonctionner un système informatique.
CHAPITRE II : GESTION DE PROJETS LOGICIELS

La gestion de projet, ou management de projet, est l’ensemble des

activités visant à organiser le bon déroulement d’un projet et en atteindre les
objectifs.

Un projet est un ensemble d’activités rassemblant des ressources

humaines et matérielles permettant de créer un bien, un produit ou un service
dans des limites de temps bien déterminées.

Introduction

Le métier de chef de projet est très enrichissant, mais aussi très

complexe, car il est amené à évoluer dans différents environnements qui sont
en constante évolution. Il doit donc être multi-compétent, c'est -à-dire
maitriser les techniques de gestion de projet, de management d’équipe, avoir
un bon relationnel lors des échanges avec le client, et enfin comprendre les
spécificités du projet.

L’objectif du chef de projet est de pouvoir mener son projet à terme en

respectant les délais et le budget alloué. Pour atteindre cet objectif, il doit
prendre en compte les contraintes qui constituent le projet (les 3 C) :

Contenu

Coût Calendrier
Le chef de projet doit avoir recours à plusieurs méthodes :

I. Les méthodes dites classiques

Depuis toujours, les projets sont gérés avec la méthode dite classique,
représentée par le schéma ci-après.

SCHEMA

On parle alors d’une approche prédictive ou de cycle en cascade. Comme

son nom l’indique, il s’agit de prévoir les phases séquentielles où il faut valider
l’étape précédente pour passer à la suivante. Le chef de projet doit alors
s’engager sur un planning précis de réalisation du projet en prévoyant des
retards sur la réalisation des tâches.

Avec la méthode dite classique, il faut tout bien faire du premier coup,
car elle ne permet pas de retour en arrière. Une décision où un problème
rencontré dans une phase peut remettre en cause partiellement ou
totalement les phases précédentes validées.

Dans un cycle en cascade, les risques sont détectés tardivement,

puisqu’il faut attendre la fin du développement pour effectuer la phase de test
; plus le projet avance, plus l’impact des risques augmente. Il sera toujours plus
difficile et coûteux de revenir en arrière lorsqu’on découvre une anomalie
tardivement.

Afin d’anticiper au mieux ces risques, il est nécessaire de produire des

documents très détaillés en amont (recueil des besoins, cahier de charges) qui
seront validés par le client, qui validera le contenu papier (conception,
maquette, développement des fonctionnalités…) ; mais le client sera toujours
plus sensible à ce qu’il verra sur l’écran.

Au final, du point de vue du client, c’est le chef de projet qui aurait dû

anticiper ces problèmes, alors qu’il est impossible de tout prévoir à l’avance,
surtout dans un environnement instable qui évolue constamment.
 Comment peut -on augmenter la satisfaction du client ? En facilitant la
gestion de projet et en améliorant la qualité de développement ? Comment
mieux s’adapter aux imprévus du projet ?

II. Les méthodes agiles

Les méthodes dites agiles vont nous permettre de répondre à toutes ces
questions.

Le mouvement des méthodes agiles a commencé aux Etats Unis, où

nous avons eu 17 experts en développement logiciel qui ce sont réunis afin de
mettre au point cette méthode suite à un taux d’échec important de projets
observé dans les années 1990.

Si l’approche agile est nouvelle pour vous, il est important de partir sur de
bonnes bases, c'est -à-dire le terme méthode est trop réducteur pour parler de
cette façon de concevoir, développer et livrer un logiciel. Il s’agit de bien plus
qu’une méthode ; on parle de paradigme agile, de philosophie agile, de
mouvement agile ou d’approche agile.

On parle cependant de méthodes agiles pour définir les méthodes qui

relèvent de ce courant.

Définition : Les méthodes agiles sont des méthodologies essentiellement

dédiées à la gestion de projets informatiques. Elles reposent sur des cycles de
développement itératifs et adaptatifs en fonction des besoins évolutifs du
client. Elles permettent notamment d’impliquer l’ensemble des collaborateurs,
ainsi que le client, dans le développement du projet.

1. Les valeurs communes des méthodes agiles

Les méthodes agiles se reconnaissent toutes dans les valeurs suivantes :

 • L’équipe et la communication avant les outils et les processus : dans la
vision agile, l’équipe est très importante. Il est préférable d’avoir une
équipe soudée et dont les membres communiquent entre eux, plutôt
qu’une équipe d’experts qui travaillent de manière isolée.

• L’application avant la documentation : il est primordial que le projet

fonctionne, c’est la priorité avant toute chose. Une documentation
précise est utile comme moyen de communication, mais il est aussi
important de simplement commenter abondamment le code.

• La collaboration avant la négociation : le client doit être impliqué dans

le développement. Il doit collaborer avec l’équipe et fournir des
comptes rendus réguliers sur l’adaptation du logiciel à ses attentes.

• L’acceptation du changement et la flexibilité avant la planification : la

planification initiale et la structure du projet doivent être flexibles afin de
permettre les évolutions attendues par le client. En effet, les premières
livraisons de projet donnent très souvent suite à des demandes
d’évolution.

2. Design Thinking

Cette approche développée à Stanford dans les années 80 a pour but

d’appliquer la démarche d’un designer pour répondre à un problème ou à un
projet d’innovation. Cette manière de réfléchir et d’innover s’appuie de
manière très importante sur des retours d’utilisateurs.

Il s’agit d’un processus créatif où l’on commence par une problématique

(objectif) dont la solution n’est pas connue pour arriver à la maturation d’une
idée créative et originale qui répond parfaitement au besoin identifier. C’est
une méthode dont l’application systématique, conduit toujours à un résultat
certain.

Mais en quoi consiste réellement le design thinking ? Quels sont ses grands
principes et ses différentes étapes ? Quelles sont ses origines ? Quelles sont ses
plus grands avantages ?
a) Définition
Le Design Thinking est une méthodologie innovante qui permet de transformer
les idées et les projets en actions réelles et en prototypes tangibles. C’est un
modèle de management moderne parfaitement adapté au traitement des
problématiques complexes à l’issue incertaine et caractérisées par des prises
de décision qui impliquent les hommes et engagent l’entreprise.

b) Origine du Design Thinking

Le design thinking naît dans les années 50, aux Etats-Unis, lorsque le
publicitaire américain Alex Osborn met au point la technique du «
brainstorming ». L’idée est de réunir son équipe et stimuler sa créativité en lui
faisant brasser différentes idées afin de résoudre un problème en trouvant des
solutions.

Puis, dans les années 70, l’ouvrage Experiences in Visual Thinking est publié
par Robert H. McKim. Celui-ci-développe les différents préceptes du Design
Thinking. Des préceptes qui seront largement développés les années qui
suivent par Peter Rowe qui publie un ouvrage intitulé « Design Thinking » en
1987.

Dans les années 2000, de plus en plus de publication sont faites sur le design
thinking. Des colloques sont également tenus sur le sujet et des cours sont
donnés aux étudiants pour leur apprendre les bases de cette méthode
d’innovation. En 2012, trois écoles de design thinking voient le jour, à Paris, Pékin
et Tokyo.

c) Principes du Design Thinking

Le design thinking a pour but de répondre à un besoin, qu’il soit ou non

explicite. Il est donc important de se fier à certaines méthodes
anthropologiques telles que l’observation, l’immersion ou la co-construction
avec les utilisateurs :

• ALLIER LES MULTIPLES COMPÉTENCES DE L’ENTREPRISE DANS UN BUT

COMMUN : L’objectif est de faire travailler de concert des professionnels
domaines différents. En combinant toutes ces compétences, le but est
de pouvoir identifier une problématique et d’évaluer l’environnement
dans lequel elle évolue, de trouver l’innovation, la solution qui permettra
de résoudre cette problématique, et pour finir, de concevoir la forme qui
incarnera au mieux le concept. C’est un véritable projet collaboratif
dans l’organisation qui va favoriser le travail d’équipe et améliorer le
management de projet.
• DONNER VIE À UN PROJET QUI A DU SENS EN UN TEMPS RECORD : L’idée
est d’aboutir de manière efficace et rapide à l’achèvement d’un
produit ou d’un service. Comme dans la manière de travailler des
designers, le design thinking s’appuie sur le prototypage des idées.
Chaque idée doit prendre une forme pour être mieux visualisée, être
testée et améliorée. En outre, le design thinking permet de travailler dans
une logique de cocréation, en dialogue constant avec des personnes
n’ayant pas les mêmes expertises, les mêmes habitudes de travail ni les
mêmes manières de travailler. Cela favorise l’intelligence collective et
permet d’avancer ensemble, de façon très concrète.

d) Etapes du Design Thinking

• LA DÉFINITION : Cette première étape du Design Thinking réalisée en

amont, va rythmer l’ensemble du processus de création. En effet, à ce
stade un « challenge » précis à résoudre est défini. Les éléments à
prendre en compte et ceux à totalement écarter de la solution finale
sont énoncés. Enfin, les livrables de la solution sont identifiés. Ces livrables
pourront prendre la forme d’un site internet de type « landing page » ou
page d’acquisition client, si le challenge porte sur le lancement d’un
nouveau service en ligne. Ils pourront également prendre la forme
d’écrans d’application mobile afin d’imaginer le parcours utilisateur.
• LA RECHERCHE : Cette partie va permettre d’identifier les différents
problèmes rencontrés par l’utilisateur tout au long de son parcours client.
Le procédé se fait en entonnoir, il est donc nécessaire d’ouvrir au
maximum les champs des problématiques pour ensuite affiner ses choix
au moment de l’idéation. C’est une phase d’exploration.
• L’IDÉATION : Ensuite, chacun propose des idées, sans aucune barrière.
L’objectif est de trouver des solutions pour répondre aux besoins des
clients. Cette phase d’idéation, effectuée seul puis en groupe, est
alimentée par un moment d’inspiration où chaque participant va
s’informer des innovations du secteur.
• LE PROTOTYPAGE : Vient ensuite l’étape du « prototypage » durant
laquelle des ébauches de produit ou service commencent à être
élaborés. L’étape de « prototypage » dans le design thinking est une
phase clé car elle permet aux membres du groupe de “faire” et de se
lancer dans l’expérimentation.

• LA SÉLECTION : Puis, vient l’étape de la « sélection ». En général, une

première pré-sélection va se faire en prenant compte des contraintes
de temps, de budget ou encore de faisabilité technique. S’ensuit alors
une session de pitch par petit groupe ou de manière individuelle. Les
différents participants vont alors discuter, laisser de côté leurs
divergences et délibérer sur le choix de l’idée la plus novatrice, réalisable
et rentable pour le projet.
 • IMPLÉMENTATION : La « mise en place » ou « implémentation » consiste
ensuite à rédiger un plan d’action, donner des responsabilités et définir
les ressources étant nécessaires à la mise en place du projet. Cette
phase est primordiale pour le suivi du projet. Chaque service travaille
conjointement afin de définir ensemble une roadmap produit réalisable.
• TEST ET APPRENTISSAGE : Dernière étape, et non des moindres, «
l’apprentissage » permet de recevoir un feed-back utilisateur. Ce
moment de test en direct va faire émerger sont ressenti vis à vis du
nouveau produit ou service et de son expérience. L’objectif : savoir si la
solution répond aux objectifs fixés au départ, si elle est viable et si des
améliorations doivent être apportées.

e) Avantages du Design Thinking

Le design thinking est une nouvelle méthode qui comporte de nombreux

avantages, les entreprises qui pratiquent cette méthode de travail seront
toujours beaucoup plus créatives. Elles auront toujours de l’avance sur les
sociétés concurrentes et peuvent innover plus facilement :
• CRÉER UNE COHÉSION INTER-SERVICE FORTE AU SEIN DE L’ENTREPRISE
• INSTALLER UNE CULTURE DU TRAVAIL BASÉE SUR LA CRÉATIVITÉ, LE TEST ET
L’ITÉRATION
• METTRE L’UTILISATEUR AU CENTRE DE LA DÉMARCHE D’INNOVATION
• Le Design Thinking permet l’optimisation des processus de l’entreprise
au juste coût.
• Le Design Thinking facilite le processus décisionnel et la qualité des
décisions prises.

1. Le Scrum

C’est une méthode de gestion de projets qui a pour but d’améliorer la

productivité des équipes. Ce terme est inspiré du terme "scrum" en Rugby, qui
désigne une mêlée. C’est une technique de reprise de jeu après faute qui
remet une équipe sure de bons rails par un effort collectif. Cette méthode a
été principalement conçue pour le développement de logiciels informatiques.

Le scrum fonctionne en cycles appelés sprints. Chaque sprint dure de 2 à 4

semaine afin de garder un rythme constant. A la fin de chaque sprint, une
version testable est fournie afin de faire le point.
Les acteurs du SCRUM

Dans une gestion de projet de type « Agile », il n’y a plus de chef de projet mais
deux acteurs qui le remplace : Le Product Owner et le ScrumMaster.

a) Le Product Owner

Le Product Owner est le stratège du projet. C’est lui qui a pour mission de définir
les fonctionnalités du produit final. C’est aussi lui qui choisit les dates et
contenus des différentes versions. Il définit les priorités dans les fonctionnalités
et valide ou non les travaux à chaque fin de Sprint. C’est à lui que revient aussi
la responsabilité du retour sur investissement ainsi que l’acceptation ou le rejet
des résultats.

C’est la personne qui représente le client et qui est la plus impliquée dans la
gestion du « backlog de produit ».
 b) Le ScrumMaster

Le ScrumMaster est, comme son nom l’indique, la personne en charge du

management du projet. Il doit faire appliquer les pratiques et les valeurs du
Scrum. Il s’assure que l’équipe est totalement opérationnelle et productive. En
cas de problème, c’est lui qui doit éliminer les obstacles pour que l’équipe
puisse continuer le projet. Il agit comme facilitateur au sein de l’équipe.

Il a pour rôle d’aider l’équipe à travailler et à s’améliorer constamment. Il est

responsable de l’application du Scrum.
 2. La planification

Le Scrum est actif à trois niveaux : le Scrum quotidien, le sprint et la release.

a) Le Scrum quotidien

Au quotidien, le ScrumMaster organise une réunion de 15 minutes : le Scrum

Meeting.

Toute l’équipe participe à cette réunion. Il permet au ScrumMaster de faire le

point sur l’avancée du projet. L’objectif est d’améliorer la probabilité que
l’équipe finisse les objectifs définis pour le sprint en cours.
La réunion se déroule en plusieurs étapes :

• Présenter ce qui a été fait : Chaque participant présente ce qu’il a fait

depuis le dernier Scrum Meeting et où il en est par rapport à l’objectif
qu’il s’était fixé.
• Prévoir ce qui va être fait : Chacun prévoit le travail qu’il va faire jusqu’à
la prochaine réunion.
• Identifier les obstacles : Tous les participants présentent ce qui les gènes
pour être efficace à 100%. L’objectif est de cerner les problèmes et d’y
apporter rapidement, efficacement et surtout collectivement une
solution.

Le résultat de cette réunion est l’actualisation du backlog de sprint ainsi que la

prévision et la résolution des obstacles.

b. Le sprint

Le Scrum est une méthode de gestion itérative. Ces itérations sont appelées «
sprint ». Chaque sprint dure entre 2 et 4 semaines selon la charge de travail,
l’équipe disponible ainsi que le nombre de fonctionnalités voulues à la fin de
cette durée.

Chaque sprint est planifié à partir de ce que l’on appelle un « backlog de

produit ». C’est le recueil de toutes les fonctionnalités du produit final établi en
début de projet. Il contient les priorités ainsi que les durées théoriques de
production de ces fonctionnalités.

Au début de chaque sprint, l’équipe et le ScrumMaster choisissent, à partir de

la liste de fonctionnalités, les éléments qu’elle pense pouvoir finir pour le sprint
(le « sprint backlog »). Les tâches sont alors listées, identifiées et estimées par
l’équipe et le ScrumMaster.

Des changements peuvent être appliqués pendant le sprint mais cela va avoir
une incidence sur les itérations suivantes. Chaque itération aboutit à une
version partielle et testable du produit. Cela a pour but, en fin de sprint, de faire
un point sur ce qui a été fait et d’avoir un visuel de l’effet ou de l’interaction
que cela a dans le produit.
En fin d’itération, l’équipe fait une rétrospective avec le ScrumMaster de ce
qui s’est passé pendant le sprint et de ce qu’il y a à faire pour le suivant. De
son côté, le Product Owner se voit présenté une version testable du produit
pour lui montrer l’avancée du projet.

d. La release
Pour optimiser et améliorer la gestion du projet, les sprints sont regroupés en
releases. Chacune est composée de plusieurs sprints. La release représente la
livraison d’une version partielle mais plus avancée qu’à la fin des sprints.

III. Le manifeste agile

Le manifeste agile est un texte publié en 2001 et rédigé par 17 experts du

développement logiciel. Il regroupe un ensemble de bonnes pratiques
préconisées par la philosophie agile. Ce texte reprend les quatre valeurs
communes des méthodes agiles et les dérive en douze principes :

• La plus haute priorité est de satisfaire le client en livrant rapidement et

régulièrement des fonctionnalités à grande valeur ajoutée.
• Il faut accueillir positivement les changements et les nouveaux besoins,
même lorsqu’ils arrivent tardivement. Les processus agiles exploitent la
flexibilité au changement afin de fournir un avantage compétitif pour le
client.
• Il faut livrer régulièrement un logiciel opérationnel (utilisable en produit)
avec des cycles courts, idéalement entre 2 et 4 semaines.
• Les utilisateurs ou leurs représentants et les développeurs doivent
travailler ensemble au quotidien tout au long du projet.
• Il faut réaliser des projets avec des personnes motivées pour atteindre les
objectifs fixés.
• Le dialogue face à face entre les différents acteurs d’un projet agile est
la méthode la plus simple et la plus efficace pour transmettre les
informations et les connaissances entre ces derniers.
• L’aspect opérationnel d’un produit est la principale mesure
d’avancement de ce dernier.
• Les processus agiles doivent amener à un rythme de développement
constant et soutenable pour l’équipe (il ne doit pas y avoir de période
de forte montée ou de baisse de charge de travail ayant des impacts
significatifs sur l’équipe).
• La recherche de l’excellence et de la performance conceptuelle et
technique renforce l’agilité d’un produit.
• Simplifier le travail en minimisant le nombre de tâches inutiles et
redondantes.
 • Les meilleures solutions logicielles émergent d’équipes auto-organisées
tant au niveau de la clarté, des spécifications, de la conception et de la
mise en place d’architectures performantes et efficaces.
• L’équipe doit, à intervalles réguliers, réfléchir à des moyens pour devenir
davantage efficace et mettre en pratique ces nouvelles méthodes une
fois décidées.

IV. Cycle de vie

Ici, nous nous intéresserons à des découpages en phases possibles en vue de

structurer le processus de développement d’un logiciel.

Nous considérerons que le développement d’un logiciel obéit à un cycle

appelé cycle de développement. Ce cycle comporte les différentes allant de
la conception d’un logiciel à son déploiement et à son entretien.

Les principales phases de ce cycle sont :

• L’analyse des besoins
• La conception générale
• La conception détaillée
• L’implémentation
• Les tests (tests unitaires, tests d’intégration)
• La validation et le déploiement
• La maintenance corrective et évolutive

Le découpage en phases correspond à une division du développement d’un

logiciel par la mise au point des modules que l’on développe séparément, puis
que l’on assemble.

1. L’analyse des besoins

Dans cette phase, le client logiciel et les ingénieurs logiciels se concertent pour
la définition des objectifs et des besoins du futur logiciel. Il s’agit principalement
d’exprimer formellement les besoins du futur logiciel de façon non ambigüe et
de réaliser sa faisabilité. D’un point de vue managérial, cette phase sert aussi
à l’évaluation du coût du logiciel, ainsi qu’à l’élaboration du plan de travail.
L’analyse des besoins définit le contrat entre le client et les ingénieurs logiciels.

2. La conception générale

Elle vise à élaborer les spécifications de la structure du logiciel. Elle se base sur
l’analyse des besoins. Les fonctionnalités retenues ici sont exprimées à travers
des modules ou des unités. Il est important par ailleurs de s’assurer ici que
l’ensemble des fonctionnalités retenues permet de satisfaire les besoins du
logiciel. Les fonctionnalités identifiées dans la conception générale seront plus
explicites dans la phase de conception détaillée.

3. La conception détaillée

En reprenant les fonctionnalités identifiées dans la conception générale, la

conception détaillée consiste à définir, pour chacune d’elle, les sous-
fonctionnalités nécessaires. Idéalement, elle doit parvenir à découper de sorte
à se situer à un niveau de détail où l’on peut facilement programmer.

4. L’implémentation et les tests unitaires

Cette phase concerne l’écriture du code logiciel et les premiers tests. Le code
est développé suivant la structuration en modules retenue aux précédentes
étapes et en accord avec les spécifications de la conception détaillée. Une
fois le code des modules terminé, ceux-ci sont testés indépendamment pour
s’assurer qu’ils satisfont les fonctionnalités attendues.

5. L’intégration modulaire

Dans cette phase, les modules développés et testés sont intégrés. Les tests sont
réalisés pour s’assurer que l’ensemble des modules fonctionne correctement.
Il est important dans cette phase de réaliser des tests dans un environnement
proche du futur environnement d’utilisation du logiciel pour éventuellement
identifier certains problèmes.

6. La v alidation et le déploiement
C’est dans cette phase que le logiciel est installé dans son futur environnement
d’utilisation après validation préalable du client. Cette phase introduit aussi la
formation des utilisateurs et est donc l’occasion pour ceux-ci de formuler les
écarts entre les fonctionnalités offertes par le logiciel et celles attendues.

7. La maintenance év olutive et correctiv e

Les bugs et les fautes sont corrigés dans la phase de maintenance corrective.
La maintenance évolutive quant à elle vise certaines fonct ionnalités du
logiciel. La maintenance est généralement très coûteuse pour le client, car elle
débute à la livraison du logiciel et se termine à la fin de son exploitation.

8. Quelques cycles de v ie

• Le modèle en cascade : il a été introduit par Royce en 1975. Il propose

un enchainement linéaire des différentes phases depuis l’analyse des
besoins jusqu’au déploiement du logiciel chez le client. Chaque produit
en sortie est utilisé pour la phase suivante.
• Le modèle en V : ce modèle peut être considéré comme une variante
du modèle en cascade, où des points de communication sont créés
entre différentes phases.
• Le modèle itératif : le cycle de vie itératif repose sur l’idée selon laquelle,
lorsqu’un projet est énorme, il est difficile de le réaliser de façon linéaire.
Il est préférable dans de telles situations de développer le logiciel par
petits bouts que l’on enrichit successivement en exploitant les différentes
phases du modèle en cascade.

V. Analyse des besoins

Dans cette partie, on se situe dans un contexte où il y a un problème posé par

le client à un groupe de développeurs.

L’analyse formule le problème du logiciel à réaliser en définissant chaque

exigence du client. Elle fait intervenir deux types d’acteurs : le client et les
analystes. Les analystes sont les personnes parmi les responsables du
développement chargées de dialoguer avec le client et de donner une
description claire et formelle des exigences ou besoins du client pour le futur
logiciel.
L’analyse aboutit à l’élaboration d’un cahier des charges. Ce cahier
représente le contrat entre le client et le responsable développement, et c’est
sur la base de ce cahier que le logiciel est validé et déployé chez le client.

Dans plusieurs situations, le logiciel produit ne répond pas aux attentes du

client. Plusieurs causes au niveau de l’analyse entrainent cet état de choses :

• Le client de sait pas ce qu’il veut : ceci est souvent dû au fait que la
nécessité du logiciel ne s’inscrit pas principalement dans les besoins
immédiats du client. C’est le cas d’une entreprise voulant s’approprier
une technologie par pur esprit de mode.
• Le client ne sait pas exprimer ce qu’il veut : ceci est dû à la difficulté pour
le client d’être précis, concret et complet. Sur tous les besoins imprécis,
l’analyste doit suggérer et exprimer au client des exigences beaucoup
plus précises. Ne jamais penser à la place du client.
• Incompréhension entre client et analyste : elle est liée à l’expression des
besoins. C’est le cas des besoins validés par le client et compris
difficilement par l’analyste, qui devrait multiplier les discussions avec le
client afin de capter le sens qu’il donne à chaque besoin.
L’analyse peut être structurée en trois phases :
• Collecte d’information
• Expression des besoins
• Spécification des besoins

a. Collecte d’informations

Elle nécessite beaucoup d’échanges entre client et développeur. Ceux-ci

peuvent être réalisés à travers des interviews, lecture de documents fournis par
le client, et réunions de travail entre client et analystes. Il s’agit principalement
ici d’identifier et de cerner le problème à résoudre et le contexte dans lequel
il intervient.

b. Définition des besoins

Elle doit préciser le travail demandé, extrait de l’information collectée. Ce

travail est organisé ici en un ensemble d’exigences.
Nous précisons qu’il ne s’agit pas à ce niveau de proposer une solution à ces
besoins, mais simplement de les définir. Les besoins peuvent être rangés en
deux catégories. Il s’agit des besoins fonctionnels et des besoins non
fonctionnels.

• Besoins fonctionnels : ils précisent à quoi sert le système et ce qu’il fait.

Ce sont généralement les traitements que doit effectuer le logiciel en
réponse à une demande.

• Besoins non fonctionnels : ils accompagnent les besoins fonctionnels. Ce

sont généralement des spécificités avec lesquelles les besoins
fonctionnels doivent être réalisés. On distingue principalement des
besoins d’utilisation (aspects généraux d’interface utilisateur) et des
besoins de sécurité et de fiabilité.

c. Spécification des besoins

La définition des besoins peut manquer de clarté ou peut être ambigüe à

cause de l’usage d’un langage naturel. D’autre part, une fois les besoins
définis, il faut déjà envisager la mise en œuvre qui doit se faire dans un langage
de programmation. Il est alors intéressant de pouvoir définir les besoins dans un
langage qui s’en approche. La spécification a pour objectif de donner une
description formelle des besoins. Elle utilise à cet effet des langages formels ou
semi formels de modélisation. Un bon indicateur pour ne pas se tromper ici est
de noter que l’analyste doit répondre à la question "Qu’est -ce qu’il faut faire
?" et non "Comment le faire ?"

d. Document d’analyse

Ce document indique l’ensemble des besoins que devrait réaliser le futur

système. Il doit être validé par le client, les analystes, le chef de projet, le chef
d’équipe… Il guidera l’ensemble des phases qui suivront dans le
développement du logiciel, et c’est sur sa base que sera élaborée la
conception du logiciel. En fonction du problème, ce document peut avoir
plusieurs structurations, mais nous y retrouverons les éléments généraux suivants
:

• Les motivations pour le développement du logiciel

• Le contexte dans lequel le problème est posé
• L’estimation de la durée en temps du projet
• L’estimation des coûts financiers du projet
• Les détails du paiement
• Les marges de retard autorisées
• Les acteurs du futur système et leurs rôles
• La liste des besoins validés par le client, et pour chacun d’eux sa
provenance, sa date et les acteurs concernés
• Les détails du logiciel à produire (livrables)
• Détails de la formation des utilisateurs (guide utilisateur)
CHAPITRE III : NOTION DE QUALITE LOGICIEL

Définition

En informatique, et en particulier en génie logiciel, la qualité logicielle est une

appréciation globale d’un logiciel basée sur de nombreux indicateurs.

La complétude des fonctionnalités, la précision des résultats, la fiabilité, la

tolérance de pannes, la facilité et la flexibilité de son utilisation, la simplicité,
l’extensibilité, la compatibilité et la portabilité, la facilité de correction et de
transformation, la performance, la consistance et l’intégrité de l’information
sont toutes des facteurs de qualité. Un logiciel est un produit qui ne se détériore
pas et qui est continuellement modifié. La qualité d’un logiciel dépend
entièrement de sa construction ; la qualité logicielle est par conséquent un
sujet central en génie logiciel. Une appréciation globale de la qualité tient
autant compte des facteurs extérieurs, directement observables par
l’utilisateur, que des facteurs intérieurs observables par les ingénieurs lors des
revues de code ou des travaux de maintenance.

Les problèmes de qualité des logiciels, connus depuis les années 1960, sont par
ailleurs à l’origine du génie logiciel : la science de la création de logiciels, y
compris toutes les difficultés qui y sont liées (respect des coûts, des délais, du
cahier des charges et du niveau de qualité).

Il existe un référentiel de certification des systèmes de management de la

qualité en entreprise en matière de génie logiciel : c’est le Tickit. Notons aussi
qu’il existe des facteurs qui déterminent la non qualité du logiciel :

• Mauvaise spécification des besoins

• Mauvaise estimation
• Mauvaise répartition des tâches
• Mauvais suivi
• Mauvaise réalisation technique
• Problèmes humains
• Manque d’expérience du métier de chef de projet
 I. Indicateurs de qualité logicielle

La norme ISO-9126 définit six groupes d’indicateurs de qualité logicielle :

a. La capacité fonctionnelle

Il s’agit de la capacité qu’ont les fonctionnalités d’un logiciel à répondre au x

exigences et besoins explicites ou implicites des usagers. En font partie la
précision, l’interopérabilité, la conformité aux normes et à la sécurité.

b. La facilité d’utilisation

Elle porte sur l’effort nécessaire pour apprendre à manipuler le logiciel. E n font
partie la facilité de compréhension, d’apprentissage, d’exploitation et la
robustesse (une utilisation incorrecte n’entraine pas de dysfonctionnement).

c. La fiabilité

Il s’agit de la capacité d’un logiciel à rendre des résultats corrects quelles que
soient les conditions d’exploitation. En fait partie la tolérance de pannes (la
capacité d’un logiciel de fonctionner, même en étant handicapé par la
panne d’un composant).

d. La performance

C’est le rapport entre la quantité de ressources utilisée (moyens matériels,

temps, personnel) et la quantité de résultats délivrés. En font partie le temps de
réponse, le débit et l’extensibilité (capacité à maintenir la performance même
en cas d’utilisation intensive).

e. La maintenabilité
Elle porte sur l’effort nécessaire en vue de corriger ou de transformer le logiciel.
En font partie l’extensibilité (le peu d’effort nécessaire pour y ajouter de
nouvelles fonctions).

f. La portabilité

C’est l’aptitude d’un logiciel à fonctionner dans un environnement matériel ou

logiciel différent de son environnement initial. En font partie la facilité
d’installation et de configuration pour le nouvel environnement.

II. Les différentes perceptions de qualité

Pour apprécier la qualité d’un logiciel, il est nécessaire qu’il soit évalué sur la
base des éléments suivants :

• La validité : aptitude d’un produit logiciel à remplir exactement ses

fonctions, définies par le cahier des charges et les spécifications.
• La fiabilité (ou robustesse) : aptitude d’un produit logiciel à fonctionner
dans des conditions anormales.
• L’intégrité : aptitude d’un logiciel à protéger son code et ses données
contre des accès non autorisés.
• La réutilisabilité : aptitude d’un logiciel à être réutilisé, en tout ou en
partie, dans de nouvelles applications.
• La compatibilité : facilité avec laquelle un logiciel peut être combiné
avec d’autres logiciels.
• L’efficacité : utilisation optimale des ressources matérielles.
• La portabilité : facilité de transfert du logiciel sous différents
environnements matériels et logiciels.
• La vérifiabilité : facilité de préparation des procédures de test.
• L’extensibilité : facilité avec laquelle un logiciel se prête à une
modification ou à une extension des fonctions qui lui sont demandées.
• La facilité d’utilisation : facilité d’apprentissage, d’utilisation, de
préparation des données, d’interprétation d’erreurs et de rattrapage en
cas d’erreur d’utilisation.

III. Les trois axes de qualité d’un logiciel

Dans le domaine du logiciel, satisfaire les besoins de l’utilisateur suppose une
démarche qualité qui prend en compte :

• La qualité de son processus de développement (coût, délais,

méthode, organisation, personnel, technique et outils).
• La qualité intrinsèque du produit (modularité, simplicité).
• La qualité du service fourni par le logiciel en exploitat ion.

La qualité du processus de développement est basée sur l’utilisation de

méthodes de développement et de gestion de projets, généralement définies
dans le manuel qualité de l’entreprise rédigé au cours de la mise en place
d’une politique d’assurance qualité.

L’évaluation de la qualité intrinsèque du logiciel est effectuée sur le produit en

développement en fonction des facteurs de qualité attendus, définis lors de la
commande (spécifications).

Celle du service porte sur le logiciel en exploitation chez l’utilisateur, et consiste

notamment à vérifier son adéquation aux exigences spécifiées.

IV. Assurance qualité

L’assurance qualité est définie comme l’ensemble des actions préétablies et

systématiques nécessaires pour donner la confiance appropriée en ce qu’ un
produit ou service satisfera aux exigences relatives à la qualité.

En fait, les moyens que l’entreprise juge nécessaires pour parvenir à la qualité
souhaitée en matière de SI (systèmes d’information), ses dispositions
s’attachent à définir un cadre de production, de mise en œuvre et
d’exploitation des applications.

a. Assurer la qualité du logiciel

Pour assurer la qualité d’un logiciel, nous devons :
• Assurer que le niveau de qualité requis est atteint.
• Définir des standards de qualité et des procédures permettant
d’assurer le niveau requis.
 b. Les sept principes de qualité d’un logiciel

En matière de génie logiciel, les ingénieurs et experts ont défini les principes
de qualité d’un logiciel. Nous en comptons sept :

• Formalisation des procédures : écrire ce que l’on doit faire

• Contrôle du respect des procédures : vérifier que ce qui est fait est
conforme à ce qui a été écrit
• Traçabilité : écrire ce que l’on fait
• Mesure de la qualité : apprécier la satisfaction du client
• Calibrage par le retour d’expérience : améliorer les procédures de
façon continue
• Unicité de responsabilité : éviter la confusion des rôles
• Séparation du contrôle et de la production : éviter d’être juge et partie

c. Processus d’assurance de la qualité

Le processus d’assurance de la qualité doit fournir l’assurance que les

produits du travail et les activités du projet sont conformes à leurs exigences
et satisfont au plan établi.

d. Plan d’Assurance Qualité (PAQ)

Le plan d’assurance qualité peut :

• Etre établi à partir du manuel qualité logicielle et des caractéristiques

d’un projet déterminé doté de ses propres exigences de qualité.
• Décrire les procédures, les règles et les méthodes applicables au projet.
• Fixer aux différents acteurs du projet leurs droits, mais aussi leurs devoirs,
en matière de qualité.
• L’établissement et le suivi du PAQ sont du ressort du responsable qualité
du projet.

Exemple :

Le plan d’assurance qualité comporte 4 caractéristiques :

• Les objectifs qualité du projet : il faut hiérarchiser les critères.
• Les moyens de la qualité : quelle étape de développement (cycle de
vie), choix de méthodes et techniques, structuration de l’équipe ?
• Le suivi de la qualité : quelles mesures ?
 • L’identification et la prévention des risques : le document de PAQ
possède un aspect contractuel.

V. Contrôle qualité

Le contrôle qualité d’un logiciel renvoie le plus souvent aux revues de projet :

• Le groupe qualité examine avec précision les aspects méthodes et le

logiciel produit, ainsi que la documentation associée.
• Le code, la conception, les spécifications, les plans de test, les
standards utilisés… sont examinés.
• Le groupe qualité établit des recommandations qui doivent être mises
en œuvre et vérifiées lors de l’audit suivant.

Revue de projet :

• Equipe qualité : constituée de l’ingénieur qualité, du chef de projet et

du responsable interface client.
• Objectif : détecter, en amont, les défauts et inconsistances dans les
documents et logiciels produits, ainsi que dans les procédures.
• Résultats : corrections à réaliser ; les concepteurs ou programmeurs
doivent corriger les fautes identifiées ; les modifications dans les
méthodes de travail ; RAS (pas de correction demandée)

VI. Types de menaces

1. Les v irus
a. Risques

Un virus informatique est un programme conçu pour se dupliquer ; il se propage

par tous les moyens d’échange de données numériques (internet, réseau,
disquettes, CD-ROM, clés USB…). Les effets d’un virus sont très variés, de
l’affichage d’un message anodin à la destruction complète des données d’un
ordinateur.
 b. Protection
Les antivirus sont des logiciels conçus pour repérer les traces d’activité des virus,
les bloquer et isoler ou supprimer les fichiers qui en sont responsables. Leurmode
de fonctionnement est basé sur une veille permanente à deux niveaux :

• Sur tout ordinateur, un programme antivirus doit être installé et actif.

• Cet antivirus doit être tenu à jour : la surveillance par l’antivirus se réfère
à une base de données contenant les signes d’activité de tous les virus
connus.
Chaque jour, de nouveaux virus apparaissent, inventés par des experts en
programmation désireux de prouver leurs compétences ; en permanence,
d’autres experts surveillent l’apparition de ces nouveaux programmes et
conçoivent des antidotes. On comprend qu’un antivirus ne sera efficace
que s’il est régulièrement actualisé pour détecter les manifestations de
tous les nouveaux virus.

2. Chev aux de Troie/Backdoors

a. Risques

Voisin des virus, un cheval de Troie, aussi appelé Troyen ou Trojan, est un
programme qui, sous les apparences d’un logiciel utile, autorise l’exécution de
commandes sur votre ordinateur depuis un ordinateur distant via internet.
Certains chevaux de Troie, les backdoors, permettent de contrôler à distance
votre ordinateur : après avoir infecté votre machine (lors du téléchargement
d’un fichier ou de l’ouverture d’une pièce jointe), le programme permet,
lorsque vous êtes connecté à Internet, d’avoir un accès libre en lecture, en
écriture ou en suppression à la totalité des fichiers présents sur votre disque dur,
mais également de faire exécuter à votre ordinateur des actions illégales
(attaques de serveurs, intrusion dans des sites sensibles…).

b. Protection

Un antivirus (à jour) permet de limiter les risques d’infection. Un firewall (matériel

ou logiciel) permet en plus de surveiller le trafic sur votre accès internet pour
détecter les tentatives de connexion non volontaires, mais aussi de bloquer
l’accès à des sites internet non fiables.
 3. Spyware
a. Risques

Un spyware, ou logiciel espion, est un programme conçu pour collecter des

données personnelles sur son utilisateur et les envoyer, à l’insu de ce dernier, à
un tiers via internet. Les spywares ne sont pas des virus parce qu’ils ne mettent
pas en danger l’intégrité du système, des applications et des données.
Cependant leur action pose des problèmes éthiques et juridiques quant à la
violation de la vie privée.

Les adwares sont des spywares qui utilisent les données récoltées (pages web
visitées, essentiellement) pour afficher des publicités ou envoyer des mails
ciblés ; certains sont capables de modifier la page par défaut de votre
navigateur. Les spywares sont généralement inclus dans les logiciels utilitaires :
logiciels P2P, lecteurs médias (DivX) en sont des vecteurs connus.

Les cookies sont également des fichiers qui recueillent des informations sur la
navigation des internautes, mais ils ne servent qu’à faciliter la navigation dans
un site donné ; ils restent en principe stockés sur le disque dur de l’utilisateur et
ne sont pas transmis à des tiers.

b. Protection

La relative innocuité des spywares a conduit les fabricants d’antivirus à les

négliger, et des logiciels spécifiques souvent gratuits se sont développés. Les
anti-spywares, comme les antivirus, utilisent des bases de données
fréquemment mises à jour.

• Sur tout ordinateur, un anti-spyware doit être installé et actif.

• Cet anti-spyware doit être tenu à jour ; la plupart sont actualisables en
ligne.
4. Les spams
a. Risques

Le spam, ou pourriel, désigne l’envoi massif de courrier électronique sans

sollicitation des destinataires, à des fins publicitaires ou malhonnêtes. C’est un
phénomène d’ampleur, puisqu’on estime que 30 à 40% des mails circulant sur
internet seraient des spams. Il existe un important trafic souterrain de listes
d’adresses électroniques qui permet à des ordinateurs d’adresser un nombre
énorme de mails en peu de temps.

Les produits les plus vantés sont les sites pornographiques, les médicaments, le
crédit financier, ou des escroqueries prétendant enrichir rapidement. Une
autre forme de spam, appelée phishing, consiste à tromper le destinataire en
faisant passer le message pour un message de sa banque ou d’un quelconque
service protégé par un mot de passe. Le but est de récupérer les données
personnelles du destinataire en les attirant sur un site factice enregistrant leurs
actions.

b. Protection
Il est difficile, au niveau de l’utilisateur, de lutter contre les spams ; quelques
mesures de prévention sont toutefois possibles :

• Ne pas donner son adresse mail sur un site inconnu.

• Ne pas répondre aux messages de spam, ni cliquer sur les liens qui
prétendent vous désabonner de ces courriers.
Les serveurs de messagerie des FAI sont équipés de logiciels anti-spam qui
analysent les messages et limitent l’arrivée dans votre ordinateur de ce type
de mail.

5. Hoaxes

a. Risques
Il existe de faux virus appelés hoaxes : un hoax se présente en général sous la
forme d’un mail d’alerte contre un nouveau virus ; le message se réclame
souvent d’un fabricant connu d’antivirus ou de matériel informatique, il signale
un fichier dangereux et vous conseille de le détruire, et demande qu’on diffuse
largement l’information. Le but des hoaxes est le simple plaisir, pour leur
concepteur de constater l’affolement et les encombrements provoqués par
leur plaisanterie.

b. Protection
Lors de la réception d’un message douteux de ce type, avant de supprimer un
fichier essentiel de Windows et d’alerter tout votre carnet d’adresse,
renseignez-vous… On peut trouver sur internet des sites d’information sur ces
fausses alertes.

6. Problèmes d’utilisateur
a. Risques

Les utilisateurs eux-mêmes peuvent être à l’origine des pertes de données : par
malveillance ou par maladresse. Documents non enregistrés, effacés ou
perdus lors des manipulations hasardeuses sont sources d’importantes pertes
de temps et d’animosité à l’égard de l’outil informatique.

b. Protection
La protection contre ce risque passe par une connaissance de base du
fonctionnement d’un ordinateur, et en particulier du système de fichiers (notion
d’arborescence, dossier, fichier…). Des habitues efficaces et bien maitrisées
de création et d’enregistrement de documents sont indispensables : création
de documents directement dans un dossier adapté, enregistrement à
intervalles réguliers pendant le travail, la maitrise des opérations
copier/couper/coller limite les risques de fausse manœuvre.

7. Mots de passe

a. Risques
Un certain nombre de ressources sont protégées par mot de passe pour
garantir que leur utilisation reste le fait de personnes autorisées : accès à un
ordinateur, voire à certains dossiers et fichiers, connexion internet, accès à une
boite de messagerie, accès à certaines pages web… Le vol de mot de passe
(par simple lecture s’il est placé à un endroit trop facilement accessible, ou par
devinette s’il est trop simple) permet à un des usagers non autorisés d’accéder
à des outils ou à des données qui ne le concernent pas ; l’usage qu’il peut en
faire serait alors imputé à l’utilisateur dont il a usurpé le mot de passe.

b. Protection
Le caractère relativement peu sensible des données d’une école ne nécessite
pas une politique très contraignante en matière de mots de passe. Cependant
un minimum de sécurité et de confidentialité est recommandé :
 • L’accès à un ordinateur de gestion devra être protégé par mot de
passe, puisqu’il contient des données confidentielles sur les élèves.
• Ce mot de passe ne sera pas affiché sur un post -it collé sur l’ordinateur
8. Partage
a. Risque

L’intérêt principal d’un réseau est le partage des ressources : dossiers et fichier,
accès internet, imprimantes… Par défaut, lors de l’installation d’un réseau, rien
n’est partagé, ce qui permet de n’ouvrir à l’accès depuis une autre machine
que les ressources souhaitées en les protégeant éventuellement par mot de
passe. Les risques liés au partage sont de deux types :

• Accès à des données confidentielles par des utilisateurs locaux non

autorisés.
• Accès à ces mêmes données et/ou prise de contrôle à distance depuis
un ordinateur extérieur via la connexion internet.
b. Protection
Le partage complet des imprimantes est sans danger ; le partage de
connexion internet se met en place lors de la configuration du réseau et n’a
pas à être restreint, sauf si on souhaite interdire la sortie à une machine
particulière ; quant au partage de dossiers, il est à définir en fonction des
contenus et des utilisateurs susceptibles d’y accéder. Il est possible d’activer le
partage complet des disques durs des différents postes utilisateurs, ce qui
facilite le transfert de fichiers ; il est cependant plus prudent de limiter ce
partage à un dossier, appelé par exemple "Documents Partages", dans lequel
on pourra créer autant de sous-dossiers que nécessaire pour éviter l’accès aux
dossiers système de la machine.

9. Sauv egarde

a. Risques
Malgré toutes les protections prises contre les risques évoqués plus haut, il peut
arriver que des données soient perdues ; le temps mis à les créer, la complexité
de leur élaboration, leur caractère vital sont autant de facteurs aggravant de
cette pert e ; c’est pourquoi le recours à des procédures de sauvegarde est
indispensable au moins pour les données essentielles : il s’agit de conserver en
lieu sûr une copie de ces données.

b. Protection
Une sauvegarde n’a de sens que si elle est :
• Rigoureuse : il faut définir précisément les fichiers à sauvegarder. Ceci
suppose une connaissance du système de fichiers de l’ordinateur et une
gestion assez rigoureuse lors de l’enregistrement de vos documents.
• A jour : donc assez fréquente pour sauvegarder la dernière version de
chaque document.
• Récupérable : il s’agit donc d’utiliser un support et un logiciel
appropriés et de les avoir testés avant d’avoir besoin d’une vraie
restauration de données.