1

C.T. Josué MISSWAY KINDIA

SEMINAIRE INFORMATIQUE
A l’usage des étudiants de Deuxième année de Licence en
Conception de systèmes d’informations

Janvier 2024
 2

THEME 1 : EPISTEMOLOGIE DE L’INFORMATIQUE

L’épistémologie, « la Science de la Connaissance » (ou proprement dit, La

Théorie de la Connaissance »), se retrouve aujourd’hui au carrefour de
nombreuses batailles des esprits. Elle a une mission noble d’éclairer comment
on appréhende le monde, comment notre connaissance se forme-t-elle.

De nos jours, l’informatique occupe une place de choix car elle a un double
aspect : scientifique et technique. Une manière, parmi d’autres, de s’interroger
sur la nature d’une science ou d’une technique est de s’interroger sur les objets
que cette science étudie ou que cette technique fabrique.

1.1. Etymologie de l’épistémologie

Du grec épistémê (connaissance, science) et de logos (« discours sur »mais aussi

« logique de »), l’épistémologie est, étymologiquement, la théorie de la
science. Bien que la forme anglaise du vocable ait existé avant que le français
ne l’assimile, c’est pourtant avec le sens différent et plus large de « théorie de
la connaissance » qu’il est généralement utilisé par les Anglo-Saxons.

Le mot français lui-même renvoie à deux styles de théorie de la science : l’un,

plus proche de la philosophie d’obédience américaine ou britannique, met
l’accent sur les processus les plus généraux de la connaissance, sur leur
logique, sur leur fondement ; l’autre, assez caractéristique des épistémologues
français, et même continentaux, depuis la fin du XIXe siècle, privilégie
volontiers l’étude spécifique des sciences, voire du développement historique
concret de leurs problèmes. »

L’épistémologie « étudie de manière critique la méthode scientifique, les

formes logiques et modes d’inférence utilisés en science, de même que les
principes, concepts fondamentaux, théories et résultats des diverses sciences,
et ce, afin de déterminer leur origine logique, leur valeur et leur portée
objective». L’épistémologie fonde les démarches de construction de la
connaissance par différence avec la praxéologie (qui concerne les conduites et
les pratiques), l’ontologie (l’essence, l’identité avec les quatre aspects que sont
le pathos, les psychos, l’ethos et le thymos) et l’anthropologie (les valeurs).
 3

1.2. Epistémologie de l’informatique

L'épistémologie de l'informatique est la branche de l'épistémologie, parmi

les épistémologies disciplinaires, qui prend pour objet d'étude l'informatique
en tant que science pour en déterminer son épistémologie, c'est-à-dire, d'une
part son ou ses objet(s), ses principes, ses concepts fondamentaux, ses théories
et résultats, i.e. ce qui la constitue ; d'autre part ses modes de construction de
nouvelles connaissances, ses processus d'inférence et d'émergence de
nouveaux concepts, les éléments à l'origine de ses évolutions, i.e. ce qui la fait
progresser ; et enfin, ses fondements, son origine, sa portée objective, i.e. ce
qui la justifie dans le concert des sciences.

L'épistémologie de l'informatique cherche donc à répondre à plusieurs

questions, en reprenant la démarche de Jean-Louis Le Moigne :

 à quoi l'informatique s'intéresse-t-elle ? (question gnoséologique) ;

 comment l'informatique procède-t-elle pour connaitre ou engendrer son

objet ? (question méthodologique) ;

 de quelle manière l'informatique valide-t-elle ses résultats ?

3.2.1. Objets de l’informatique

Comme toute science, à l’origine l'informatique a un objet d'étude : le

traitement automatique de l'information.

Notons cependant que le degré d'automatisation des processus de traitement

de l'information est très variable.

Avec l'apparition de logiciels interactifs (à partir du milieu des années

soixante-dix) on a vu se développer des systèmes homme-machine pour des
applications de plus en plus variées et diversifiées avec un partage des tâches
entre l'ordinateur et l'être humain.

3.2.2. Concepts
3.2.2.1. Concepts fondamentaux
a) Information

Pour pouvoir être traitée automatiquement l'information, par un processus de

représentation, doit être formalisée, modélisée sous forme d'un ensemble
structuré de relations logico-mathématiques.
 4

Le terme « informatique » fait la part belle à la notion d'information et par

suite à la notion de langage formel pour représenter et manipuler ces
informations.

b) Machine

L’informatique n’est pas exclusivement la science des algorithmes, sinon nous

serions contraints de penser que les scribes de Mésopotamie et d’Égypte
étaient des informaticiens. Un deuxième concept qui définit l’informatique est
celui de « machine ».

Il a trait à l'artefact qui va effectuer automatiquement le traitement de

l'information.

Le terme anglais « computer science » place la machine au centre de

l'informatique, comme objet principal d'étude de cette jeune science. Ce choix
soulève de nombreuses critiques :

 c'est une place trop importante pour certains, comme Edsger Dijkstra ;

 c'est une source de dévalorisation, pour d'autres car cela tend à réduire
l'informatique à une technologie.

Pourtant, l'informatique n'a commencé vraiment qu'avec l'avènement des

premières machines, et son essor a suivi l'essor des machines. Oublier la
machine semble donc une grave erreur pour comprendre l'épistémologie de
l'informatique.

L'une des raisons de l'importance de la machine en informatique vient, pour

certains, de ce que sans machine, l'informatique reste une science formelle et
qu'en conséquence, une science que l'on pourrait ranger comme l'une des
disciplines des mathématiques.

Avec l'arrivée de la machine, c'est l'introduction, l'irruption, du réel dans une

science formelle que l'on observe, et la confrontation formel/réel. C'est la
confrontation entre l'informatique théorique et la réalisation pratique, une
dualité qui rappelle celle entre algorithme et programmation, entre machine
de Turing et architecture de von Neumann, entre complexité théorique et
benchmarking, ...
 5

Sur le terme machine, d'autres préfèrent le terme ordinateur, mais si l'un

semble trop large, l'autre est peut-être trop étroit.

3.2.2.2. Concepts opérationnels

A partir de ces deux concepts fondamentaux ont été élaborés d'autres concepts
que nous dirons opérationnels tels que :
 structure de données ;
 algorithme ;
 programme ;
 objet.

Certains de ces concepts sont propres à la science informatique, d'autres sont

empruntés à des disciplines ou des domaines connexes avec, en général, une
modification de leur contenu.

À chacun de ces concepts se rattache tout un ensemble de notions. Par

exemple au concept de programme on associe les notions de variable,
d'affectation, de structure de contrôle...

Toutefois de tous les concepts de l'informatique, le plus évident est

l'algorithme.

3.2.2.2.1. De l’algorithme
Bien souvent, effectivement, l'informatique est ainsi réduite à l'algorithmique,
science des processus systématiques de résolution, par le calcul, d'un
problème. Une science associée au verbe faire. Les termes traitement, calcul,
automatisme, processus, ... sont parfois aussi employés.

Pour Donald E. Knuth, la science informatique naissante aurait dû s'appeler

ainsi "algorithmics".

Cependant, l'algorithmique existait avant l'informatique, avant l'apparition

des premières machines et considérée indépendamment de l'existence de ces
machines, c'est une discipline que nombreux considèrent comme pouvant
faire partie des mathématiques (c'est-à-dire, n'introduisant pas un nouveau
paradigme scientifique, ayant la même épistémologie que les mathématiques).

Si l'informatique n'est pas la science des algorithmes et seulement des

algorithmes, il faut tout de même constater l'omniprésence de cette notion
 6

dans toutes les branches de l'informatique (comme souvent aussi la notion de

langage).

Ce concept d'algorithme n'est pas propre à l'informatique, puisqu'il est

également utilisé en mathématiques, où existent de nombreux algorithmes
pour résoudre des équations de manière exacte ou approchée, dériver et
intégrer des expressions fonctionnelles, calculer la probabilité de certains
événements...

Pour bien saisir ce concept d’algorithme, il est important de comprendre que

tous les problèmes ne peuvent pas nécessairement être résolus par un
algorithme.
 7

3.2.3. Méthodes de l’informatique

L'informatique puise ses méthodes pour l'essentiel dans les mathématiques et

les sciences exactes : démarches logico-déductives et expérimentales.
Cependant, avec le développement de l'Intelligence Artificielle et des Sciences
Cognitives l'informatique est conduite à utiliser aussi les méthodes des
sciences humaines (psychologie cognitive par exemple) et des sciences
sociales (analyse d'une situation à informatiser).
Ces méthodes, l'informatique les a évidemment adaptées à ses propres
finalités.

3.2.4. Moyens de l’informatique

Par certains côtés, comme science formelle, l'informatique avance par pures
constructions intellectuelles cherchant la cohérence, l'efficacité, l'élégance de
ses productions.

L'existence des machines, introduit, par confrontation avec le réel, deux

aiguillons favorisant le développement de l'informatique :

 l'un des grands moteurs de l'informatique, c'est la course à l'efficacité, il

faut toujours essayer d'aller plus vite, moins coûteux, ... ce qui ouvre de
nouveaux horizons. C'est une course en avant, portée également par les
conséquences de la loi de Moore (doublement des capacités des machines
tous les 18 mois), qui élargit continuellement les domaines d'application
de l'informatique;

 l'autre moteur de l'informatique, c'est de chercher à faire au moins aussi

bien que l'intelligence humaine. C'est l'intelligence artificielle, ou certaines
de ces productions. Cela part du principe, ou de l'hypothèse, que ce que
l'expert sait faire « à la main », l'informaticien peut l'automatiser avec l'aide
éventuelle de l'expert pour expliciter l'algorithme implicite ou inconscient
employé par l'expert.

Les avancées technologiques hors de l'informatique, en électronique, par

exemple pour les aspects pratiques, en mathématiques, par exemple pour les
aspects formels, mais aussi parfois en mécanique quantique ou en biologie
cellulaire, sont aussi souvent à l'origine de progrès en informatique. Le double
aspect, science/technologie de l'informatique, lui permet de progresser sur les
deux plans. L'informatique étant par ailleurs très liée aux sciences et
 8

technologies de son siècle dans les deux sens, comme utilisatrice des résultats
de ces autres sciences et technologie mais aussi comme étant fournisseur de
moyens d'obtenir de nouveaux résultats dans ces autres disciplines, des
progrès lui aussi demandé par les autres sciences et technologies (ainsi la
cryptographie et la pré-informatique ont progressé ensemble pendant les
années de la seconde guerre mondiale avec la machine Enigma et le
calculateur Colossus).

L'informatique est investie par les autres sciences et technologie, c'est un lieu
commun, l'informatique est partout, elle bénéficie des avancées des autres et
fait bénéficier les autres de ses propres avancées.

3.2.5. Méthodes de validation de résultats

Les méthodes de validation de l'informatique sont de deux ordres :

les validations formelles : comme les sciences formelles, certains

résultats sont prouvés formellement et validés par la lecture attentive de
ces preuves par la communauté scientifique pour les approuver, les
amender ou les rejeter ;
les validations pratiques : plusieurs niveaux de validations pratiques
sont possibles en informatiques :
- les preuves de concept (simple réalisation effective),
- les benchmarks (tests sur des jeux d'essai spécifiques),
- les validations par les usagers (comprenant des preuves de montée
en charge, des questions d'adoption par le public, des analyses
d'usage).

Il semble qu'il y ait un avis assez général parmi les informaticiens pour dire
qu'un résultat n'est pas encore tout à fait validé tant qu'il n'y a pas eu de
validation pratique. Une grande confiance est placée dans la confrontation au
réel.

3.2.6. Résultats de l’informatique

L'informatique donne des résultats pour chacun de ses objets :

sur les algorithmes :

 9

- une foule d'algorithmes et de concepts (structures de

données, structures de contrôle, ...) pour résoudre de nombreux
problèmes,
- plusieurs notions de complexité algorithmique pour comparer les
algorithmes entre eux,
- des classes d'algorithmes (selon leur complexité),
- des résultats même sur les limites de l'algorithmique, sur
la calculabilité de certains problèmes ;
sur les machines :
- des machines effectives, dont la puissance suit une loi (la loi de
Moore, exponentielle), cas unique dans l'histoire de l'humanité,
- des modèles de machines (Turing vs Von Neumann),
- une théorie des machines et paradigmes de
programmation énonçant l'existence d'une classe quasi unique de
machines et paradigmes de programmation : la thèse de
Church (au moins jusqu'à l'informatique quantique) ;
sur l'information :
- des méthodes de codage de l'information, des formalismes
(théorie des langages formels).
 10

THEME 2 : PROCESSUS DE DEVELOPPEMENT AGILES

Les méthodes agiles sont des groupes de pratiques de pilotage et de réalisation
de projets. Elles ont pour origine le manifeste Agile, rédigé en 2001, qui
consacre le terme d'« agile » pour référencer de multiples méthodes existantes.

Ce manifeste était conçu par dix-sept experts du développement logiciels. Ils

estimaient que le taux important d'échecs des projets de développements
logiciels était dû à la lourdeur des méthodes traditionnelles inspirées du génie
civil et s'appuyant sur un cycle de développement en cascade.

Elles favorisent l’intégration du client dans l’équipe de développement d’un

projet. Elles permettent une flexibilité et une adaptation aux changements des
besoins d’un client.

1.1. Historique

En 2001, aux États-Unis, dix-sept figures éminentes du développement

logiciel se réunissent pour débattre d'un thème unificateur de leurs méthodes
respectives.
Les plus connus d'entre eux sont Ward Cunningham, l'inventeur du Wiki via
WikiWikiWeb, Kent Beck, père de l'extreme programming et cofondateur de
JUnit, Ken Schwaber créateur de Scrum et Jeff Sutherland (en) son
promoteur, Jim Highsmith (en), prônant l'ASD, Alistair Cockburn pour la
méthode Crystal clear, Martin Fowler et Dave Thomas, ainsi qu'Arie van
Bennekum pour DSDM (Dynamic System Development Method). Ces 17
experts extraient alors de leurs usages respectifs les critères communs et les
principes qui, selon eux, conduisent aux meilleurs concepts de direction de
projets et de développement de logiciels. De cette réunion émerge le Manifeste
agile, considéré comme la définition canonique des valeurs du développement
agile de logiciels et de ses principes sous-jacents par les praticiens et les
universitaires

Les méthodes pouvant être qualifiées d'agiles, depuis la publication du

manifeste Agile, sont le RAD (développement rapide d'applications). Les
deux méthodes agiles les plus utilisées sont la méthode Scrum qui fut publiée
en 2001 ainsi que la méthode XP Extreme programming publiée en 1999. Ces
deux méthodes sont d'ailleurs techniquement complémentaires dans le cas
d'un projet de développement de SI.
 11

1.2. Fondements

En s'appuyant sur leur expérience combinée du développement logiciel, les

dix-sept signataires du manifeste ont prôné les quatre valeurs
fondamentales :

1. Individus et interactions plutôt que processus et outils

2. Fonctionnalités opérationnelles plutôt que documentation exhaustive
3. Collaboration avec le client plutôt que contractualisation des relations

4. Acceptation du changement plutôt que conformité aux plans et douze

principes généraux :

1. Satisfaire le client en priorité

2. Accueillir favorablement les demandes de changement
3. Livrer le plus souvent possible des versions opérationnelles de
l’application
4. Assurer une coopération permanente entre le client et l’équipe projet
5. Construire des projets autour d’individus motivés
6. Privilégier la conversation en face à face
7. Mesurer l’avancement du projet en termes de fonctionnalités de
l’application
8. Faire avancer le projet à un rythme soutenable et constant
9. Porter une attention continue à l’excellence technique et à la
conception
10.Faire simple
11.Responsabiliser les équipes
12.Ajuster à intervalles réguliers son comportement et ses processus pour
être plus efficace

1.3. METHODE SCRUM

C’est un cadre de travail permettant de répondre aux problèmes

complexes et changeants. Elle favorise le développement productif et
créatif de produits de grande valeur.

C’est un canevas permettant l’amélioration des pratiques de gestion et de

développement.
 12

Scrum se base sur la théorie du contrôle pratique d’un processus : « Les

connaissances proviennent de l’expérience et d’une prise de décision de
faits connus. »

1.3.1. Caractéristiques
Scrum est un schéma d’organisation de développement de produits
complexes. Il est défini par ses créateurs comme un « cadre de travail
holistique itératif qui se concentre sur les buts communs en livrant de
manière productive et créative des produits de la plus grande valeur possible
». Le framework s'appuie sur le découpage d'un projet en boîtes de temps,
nommées « sprints ». Les sprints peuvent durer entre quelques heures et un
mois (avec une préférence pour deux semaines). Chaque sprint commence
par une estimation suivie d'une planification opérationnelle. Le sprint se
termine par une démonstration de ce qui a été achevé. Avant de démarrer un
nouveau sprint, l'équipe réalise une rétrospective. Cette technique analyse le
déroulement du sprint achevé, afin d'améliorer ses pratiques. Le flot de
travail de l'équipe de développement est facilité par son auto-organisation, il
n'y aura donc pas de gestionnaire de projet. La création de framework de
développement logiciel hybride couplant Scrum et d'autres frameworks est
commune puisque Scrum ne couvre pas le cycle de développement de
produit.

1.3.2.Les trois piliers de scrum

La méthode scrum est fondée sur la conviction que le développement logiciel

est une activité par nature non-déterministe et que l'ensemble des activités de
réalisation d'un projet complexe ne peut être anticipé et planifié. C'est en cela
que le scrum s'oppose aux démarches prédictives telles que le cycle en V. Pour
répondre à cette imprédictibilité, la méthodologie scrum propose un modèle
de contrôle de processus fondée sur l'empirisme, via l'adaptation continue aux
conditions réelles de l'activité et une réaction rapide aux changements.
L'analyse des conditions réelles d'activité lors des rétrospectives de fin de
Sprint et le plan d'amélioration continue qui en découle sont réalisés à
intervalle de temps régulier, donnant lieu à un cycle de développement
incrémental (Sprint).
 13

Scrum est un processus empirique : il se base sur l'expérience du terrain. Il

s'appuie sur trois piliers :

1. Transparence :

Scrum met l'accent sur le fait d'avoir un langage commun entre l'équipe et le
management. Ce langage commun doit permettre à tout observateur d'obtenir
rapidement une bonne compréhension du projet.

2. Inspection :

À intervalle régulier, Scrum propose de faire le point sur les différents

artéfacts produits, afin de détecter toute variation indésirable. Ces inspections
ne doivent pas être faites trop fréquemment, ou par un inspecteur mal formé
: cela nuirait à l'avancement du projet.

3. Adaptation :

Si une dérive est constatée pendant l'inspection, le processus doit alors être
adapté. Scrum fournit des rituels, durant lesquels cette adaptation est possible.
Il s'agit de la réunion de planification de sprint, de la mêlée quotidienne, de la
revue de sprint ainsi que de la rétrospective de sprint.

1.3.3. Rôles

Scrum définit trois rôles : le propriétaire du produit (product owner), le scrum

master et le développeur. Il est à noter que le rôle de développeur couvre
plusieurs métiers d'une organisation traditionnelle.
 14

1. Propriétaire du produit : Le propriétaire du produit (product owner) est

le représentant des clients et des utilisateurs. Il est « responsable de
maximiser la valeur du produit et du travail de l'équipe de
développement ». Il s'agit d'« une personne et non d'un comité ». Il est
seul à diriger l'activité de l'équipe de développement à qui il n'est « pas
permis de suivre les instructions d'une autre personne. »
De ce fait, cet acteur se charge de différents rôles et responsabilités :
• Il explicite les éléments (items) du carnet du produit.
• Il définit l'ordre dans lequel les fonctionnalités seront développées et
prend les décisions importantes concernant l'orientation du projet.
• Il s'assure que le carnet du produit est visible et compris de l'équipe de
développement.
• Il participe avec l'équipe à la définition de l'objectif du Sprint au début
de celui-ci (Sprint Planning). L'objectif peut être fonctionnel,
technique ou organisationnel. Si l'objectif devient obsolète pendant le
sprint, il a alors la possibilité d'interrompre le sprint en cours.
Dans l'idéal, le propriétaire du produit travaille dans la même pièce que
l'équipe. Il est important qu'il reste très disponible pour répondre aux
questions de l'équipe et pour lui donner son avis sur divers aspects du logiciel.
2. Maître de mêlée : Le maître de mêlée (scrum master) est responsable
de la compréhension, de l'adhésion et de la mise en œuvre du
framework. C'est un « leader au service de l'équipe», il assiste chaque
rôle de l'équipe scrum dans son activité et promeut le changement des
interactions entre les rôles dans le but de maximiser la valeur de ce que
produit l'équipe.
Son autorité s'exerce sur le processus de développement (définition de la
durée des Sprints, des modalités de tenues et de l'ordre du jour des réunions
scrum…), mais il ne dispose d'aucune autorité sur les autres membres de
l'équipe scrum. Ce n'est pas un chef de projet, ni un développeur, ni un
intermédiaire de communication avec les clients. Le rôle de scrum master ne
peut pas être cumulé avec celui de propriétaire du produit. Les attributions du
« chef de projet » présent dans d'autres approches sont distribuées dans les
différents rôles de l'équipe scrum. L'existence du rôle de chef de projet dans
un contexte scrum est le signe d'une « méconnaissance fondamentale de
scrum» et est perçue comme contre-productive et menant à de « piètres
résultats ».
 15

En tant que facilitateur, il aide l'équipe à déterminer quelles interactions avec

l’extérieur lui sont utiles, et lesquelles sont freinantes. Il aide alors à maximiser
la valeur produite par l'équipe.
Parmi ses attributions :
• communiquer la vision et les objectifs à l'équipe
• apprendre au propriétaire du produit à rédiger les composantes du
carnet du produit
• faciliter les rituels de scrum
• coacher l'équipe de développement
• faciliter son intégration à l'entreprise, surtout si celle-ci n'est pas
pleinement agile
• écarter les éléments pouvant perturber l'équipe
• aider l'adoption de la culture agile au niveau de l'entreprise
• travailler avec les autres Facilitateurs/animateurs pour coordonner
plusieurs équipes

3. Équipe de développement :
L'équipe de développement est constituée de 3 à 9 personnes et a pour
responsabilité de livrer à chaque fin d'itération une nouvelle version de
l'application enrichie de nouvelles fonctionnalités et respectant le niveau de
qualité nécessaire pour être livrée.
L'équipe ne comporte pas de rôles prédéfinis ; elle est « structurée et habilitée
par l'entreprise à organiser et gérer son propre travail ».
Elle est auto-organisée et choisit la façon d'accomplir son travail, sans que ce
soit imposé par une personne externe. Il n'y a pas non plus de notion de
hiérarchie interne : toutes les décisions sont prises ensemble. Ce mode
d'organisation a pour objectif d'augmenter l'efficacité de travail de l'équipe.

Elle est pluridisciplinaire et comporte toutes les compétences pour réaliser son
projet, sans faire appel à des personnes externes à celle-ci. L'objectif de
l'équipe est de livrer le produit par petits incréments. Ainsi, à tout instant, il
existe une version du produit « potentiellement utilisable » disponible.
L'équipe s'adresse directement au propriétaire du produit, et ne prend ses
instructions que de lui. Son activité est issue du carnet de produit uniquement.
Elle ne peut pas être multiproduits.
 16

1.3.4. Evènements

Toutes les activités (sprint, réunions de planning, revues, rétrospectives et

mêlées) décrites dans le framework scrum sont effectuées lors de boites de
temps.
• Sprint : Le sprint est une période d'un mois au maximum, au bout de
laquelle l'équipe délivre un incrément du produit, potentiellement
livrable. Une fois la durée choisie, elle reste constante pendant toute la
durée du développement. Un nouveau sprint démarre dès la fin du
précédent. Chaque sprint possède un but et on lui associe une liste
d'éléments du carnet du produit (fonctionnalités) à réaliser.
Durant un sprint :
- l'objet du sprint ne peut être modifié
- la composition de l'équipe reste constante
- la qualité n'est pas négociable
- la liste d'éléments est sujette à négociations entre le propriétaire du
produit et l'équipe de développement
La limitation est d'un mois afin de limiter la complexité et donc les risques
liés au sprint.
Si l'objet du sprint devient obsolète pendant celui-ci, le propriétaire du produit
peut décider de l'annuler. Dans ce cas, les développements terminés sont revus
par le propriétaire du produit, qui peut décider de les accepter. Les éléments
du sprint n'étant pas acceptés sont réestimés et remis dans le carnet du produit.
Un nouveau sprint démarre alors.
• Mêlée quotidienne : La mêlée quotidienne (daily scrum) est une
réunion de planification «juste à temps » et permet aux développeurs
de faire un point de coordination sur les tâches en cours et sur les
difficultés rencontrées. Cette réunion dure 15 minutes au maximum.
Seule l'équipe de développement intervient. Le Scrum Master peut
intervenir comme facilitateur en début de mise en place de Scrum.
Toute autre personne peut assister mais ne peut pas intervenir.
À tour de rôle, chaque membre aborde trois sujets :
- ce qu'il a réalisé la veille
- ce qu'il compte réaliser aujourd'hui pour atteindre l'objet du sprint
 17

- les obstacles qui empêchent l'équipe d'atteindre le but du sprint

Si le besoin s'en fait sentir, des discussions sont alors menées librement après
la clôture de la mêlée pour traiter des sujets levés en séance.
Cette réunion permet la synchronisation de l'équipe, l'évaluation de
l'avancement vers l'objectif de l'itération, la collecte d'information nécessaire
à l'autoorganisation. C'est le niveau quotidien des principes inspection et
adaptation de scrum.
• Réunion de planification d'un Sprint : Toute l'équipe scrum est
présente à cette réunion, qui ne doit pas durer plus de 8 heures pour
un sprint d'un mois. Pour un sprint plus court, la durée est en général
réduite mais peut durer 8h. À l'issue de cette réunion, l'équipe a décidé
des éléments du carnet du produit qu'elle traitera dans le cadre de la
prochaine itération, et comment elle s'organisera pour y parvenir.
La réunion de planification de sprint (sprint planning meeting) se passe en
deux temps. Dans la première partie, l'équipe de développement cherche à
prévoir ce qui sera développé durant le prochain sprint. À l'entrée de cette
phase, l'équipe doit avoir à sa disposition :
- le carnet du produit priorisé
- la capacité de production (vélocité) prévue pour ce sprint (estimation
théorique pour le premier sprint et basée sur la productivité réelle
obtenue pour les suivants)
L'équipe et le propriétaire du produit détermine le but du sprint. Dans un
second temps, l'équipe, aidée du propriétaire du produit, se focalise sur la
manière dont ses membres atteindront le but du sprint, en découpant en
activités d'une durée d'une journée au plus le travail à effectuer pendant le
sprint.
• Revue de sprint : À la fin du sprint, l'équipe scrum et les parties-
prenantes invitées se réunissent pour effectuer la revue de sprint, qui
dure au maximum quatre heures. L'objectif de la revue de sprint est de
valider l'incrément de produit qui a été réalisé pendant le sprint.
L'équipe énonce les éléments du carnet de produit sélectionnés en début de
sprint. L'équipe présente les éléments finis (complètement réalisés). Les
éléments non finis (partiellement réalisés) ne sont pas présentés.
Une fois le bilan du sprint réalisé, l'équipe de développement et le propriétaire
du produit mettent à jour le carnet du produit en fonction de ce qui a été réalisé
(fini). Ils discutent avec les parties-prenantes de l'état courant du projet
 18

(budget, financement, conditions du marché), pour ajuster les éléments de

carnet de produit et la planification selon les opportunités découvertes.
• Rétrospective du sprint : La rétrospective du sprint est faite en interne
à l'équipe scrum (équipe de réalisation, propriétaire du produit et
scrum master). Elle dure trois heures pour un sprint d'un mois. Elle a
pour but l'adaptation aux changements qui surviennent au cours du
projet et l'amélioration continue du processus de réalisation. L'objectif
est d’inspecter l'itération précédente, afin de déterminer quels sont les
éléments du processus de développement qui ont bien fonctionné et
ceux qui sont à améliorer. L'équipe de développement déduit un plan
d'actions d'amélioration qu'elle mettra en place lors de l'itération
suivante.
1.3.5. Artefacts

• Carnet du produit (product backlog) : Le carnet de produit est « une liste

ordonnée de tout ce qui pourrait être requis dans le produit et est l'unique
source des besoins pour tous les changements à effectuer sur le produit »10.
C'est un document qui évolue constamment au cours de la vie du produit et
n'est « jamais fini ».
Chaque élément du carnet représente une fonctionnalité, besoin, amélioration
et correctif, auquel sont associés une description, une estimation de l'effort
nécessaire à la réalisation de l'élément et une grandeur permettant d'ordonner
les éléments entre eux. Le carnet de produit, son évolution et sa publication
sont de la responsabilité du propriétaire du produit. Il peut changer à
discrétion l'ordre des éléments, en ajouter, modifier le découpage en éléments,
modifier leur description, ou supprimer des éléments qui n'ont pas encore été
réalisés par l'équipe de développement. Les éléments en tête du carnet de
produit sont destinés à être traités dans la prochaine itération et sont les plus
finement décrits et estimés. Ils sont dits «prêts » dans la terminologie scrum.
Les éléments moins prioritaires peuvent être découpés plus grossièrement en
attendant de devenir prioritaires et affinés à leur tour.
L'activité d'affinage du carnet de produit et de ses éléments est effectuée
conjointement par le propriétaire du produit et par l'équipe de réalisation.
C'est notamment elle seule qui a le mot final sur les estimations des éléments
du carnet du produit.
• Carnet de sprint (sprint backlog) : En début de sprint, un but est décidé.
Pour atteindre cet objectif, l'équipe de développement choisit lors de
 19

la réunion de planification de sprint quels éléments du carnet de

produit seront réalisés. Ces éléments sont alors groupés dans un carnet
de sprint.
Chaque équipe met à jour régulièrement le carnet de sprint au cours de son
activité, afin que celui-ci donne une vision la plus précise possible de ce que
l'équipe prévoit de réaliser pour atteindre l'objectif du sprint. Le carnet de
sprint est sous la responsabilité de l'équipe et elle est seule à pouvoir le
modifier en cours d'itération.
• Incrément de produit : L'incrément de produit est l'ensemble des
éléments du carnet de produit finis pendant ce sprint, et aussi ceux finis
pendant les sprints précédents. Les éléments sont finis lorsqu'ils
remplissent la définition de fini. Cet incrément doit être utilisable, qu'il
soit publié ou non.

1.4. EXTREME PROGRAMMING

1.4.1. Origine

L'extreme programming a été inventée par Kent Beck, Ward

Cunningham, Ron Jeffries et Palleja Xavier pendant leur travail sur un
projet de calcul des rémunérations chez Chrysler. Kent Beck, chef de
projet en mars 1996, commença à affiner la méthode de développement
utilisée sur le projet. Celle-ci est née officiellement en octobre 1999 avec
le livre Extreme Programming Explained de Kent Beck.

1.4.2. Pratiques extrêmes

En génie logiciel, extreme programming (XP) est une méthode agile

plus particulièrement orientée sur l'aspect réalisation d'une application,
sans pour autant négliger l'aspect gestion de projet. XP est adapté aux
équipes réduites avec des besoins changeants. XP pousse à l'extrême des
principes simples. Dans le livre Extreme Programming Explained, la
méthode est définie comme :

• une tentative de réconcilier l'humain avec la productivité ;

• un mécanisme pour faciliter le changement social ;
• une voie d'amélioration ;
• un style de développement ;
• une discipline de développement d'applications informatiques.
 20

Son but principal est de réduire les coûts du changement. Dans les méthodes
traditionnelles, les besoins sont définis et souvent fixés au départ du projet
informatique ce qui accroît les coûts ultérieurs de modifications. XP s'attache
à rendre le projet plus flexible et ouvert au changement en introduisant des
valeurs de base, des principes et des pratiques. Les principes de cette
méthode ne sont pas nouveaux : ils existent dans l'industrie du logiciel depuis
des dizaines d'années et dans les méthodes de management depuis encore
plus longtemps. L'originalité de la méthode est de les pousser à l'extrême
puisque :

- la revue de code est une bonne pratique, elle sera faite en permanence (par
un binôme)

- les tests sont utiles, ils seront faits systématiquement avant chaque mise en
œuvre

- la conception est importante, elle sera faite tout au long du projet

(refactoring)

• la simplicité permet d'avancer plus vite, nous choisirons toujours la

solution la plus simple
• la compréhension est importante, nous définirons et ferons évoluer
ensemble des métaphores
• l'intégration des modifications est cruciale, nous l'effectuerons
plusieurs fois par jour
• les besoins évoluent vite, nous ferons des cycles de développement très
rapides pour nous adapter au changement
1.4.3. Cycle de développement

L'extreme programming repose sur des cycles rapides de développement (des

itérations de quelques semaines) dont les étapes sont les suivantes:

• une phase d'exploration détermine les scénarios « client » qui seront

fournis pendant cette itération
• l'équipe transforme les scénarios en tâches à réaliser et en tests
fonctionnels
• chaque développeur s'attribue des tâches et les réalise avec un binôme
• lorsque tous les tests fonctionnels passent, le produit est livré

1.4.5.Programmation comme discipline collective

 21

Tout en mettant l'accent sur les bonnes pratiques de programmation, XP

préconise un déroulement par itérations courtes et gérées collectivement, avec
une implication constante du client. Il en découle une redéfinition de la
relation entre client et fournisseur avec des résultats surprenants sur le plan de
la qualité de code, de délais et de satisfaction de la demande du client.

1.4.6.Valeurs
L'extreme programming repose sur cinq valeurs fondamentales :

1. Communication : C'est le moyen fondamental pour éviter les problèmes.

Les pratiques que préconise l'XP imposent une communication intense.
Les tests, la programmation en binôme et le jeu du planning obligent les
développeurs, les décideurs et les clients à communiquer. Si un manque
apparaît malgré tout, un coach se charge de l'identifier et de remettre ces
personnes en contact.

2. Simplicité : La façon la plus simple d'arriver au résultat est la meilleure.

Anticiper les extensions futures est une perte de temps. Une application
simple sera plus facile à faire évoluer.

3. Feedback : Le retour d'information est primordial pour le programmeur et

le client. Les tests unitaires indiquent si le code fonctionne. Les tests
fonctionnels donnent l'avancement du projet. Les livraisons fréquentes
permettent de tester les fonctionnalités rapidement.

4. Courage : Certains changements demandent beaucoup de courage. Il faut

parfois changer l'architecture d'un projet, jeter du code pour en produire
un meilleur ou essayer une nouvelle technique. Le courage permet de
sortir d'une situation inadaptée. C'est difficile, mais la simplicité, le
feedback et la communication rendent ces tâches accessibles.

5. Respect :

Cette valeur fut ajoutée dans la deuxième édition d’Extreme Programming

Explained de K. Beck. Cette valeur inclut le respect pour les autres, ainsi que
le respect de soi. Les programmeurs ne devraient jamais valider les
modifications qui cassent la compilation, qui font échouer les tests unitaires
existants ou qui retardent le travail de leurs pairs. Les membres respectent leur
propre travail en cherchant toujours la qualité et la meilleure conception pour
la solution et cela grâce au refactoring.
 22

1.4.7. Pratiques

Ces cinq valeurs se déclinent en treize pratiques qui se renforcent

mutuellement :
1. Client sur site : Un représentant du client doit, si possible, être
présent pendant toute la durée du projet. Il doit avoir les connaissances
de l'utilisateur final et avoir une vision globale du résultat à obtenir. Il
réalise son travail habituel tout en étant disponible pour répondre aux
questions de l'équipe.
2. Jeu du planning ou planning poker : Le client crée des scénarios
pour les fonctionnalités qu'il souhaite obtenir. L'équipe évalue le temps
nécessaire pour les mettre en œuvre. Le client sélectionne ensuite les
scénarios en fonction des priorités et du temps disponible.

3. Intégration continue : Lorsqu'une tâche est terminée, les

modifications sont immédiatement intégrées dans le produit complet.
On évite ainsi la surcharge de travail liée à l'intégration de tous les
éléments avant la livraison. Les tests facilitent grandement cette
intégration : quand tous les tests passent, l'intégration est terminée.

4. Petites livraisons : Les livraisons doivent être les plus fréquentes

possible. L'intégration continue et les tests réduisent considérablement
le coût de livraison.

5. Rythme soutenable : L'équipe ne fait pas d'heures

supplémentaires. Si le cas se présente, il faut revoir le planning. Un
développeur fatigué travaille mal.

6. Tests de recette (ou tests fonctionnels) : À partir des scénarios

définis par le client, l'équipe crée des procédures de test qui permettent
de vérifier l'avancement du développement. Lorsque tous les tests
fonctionnels passent, l'itération est terminée. Ces tests sont souvent
automatisés mais ce n'est pas toujours possible. En effet, seuls les tests
de non régression peuvent être potentiellement automatisés du fait de
leur récurrence. La recette fonctionnelle d'une application est de plus
en plus souvent confiée à des experts du test indépendants des
développeurs.
 23

7. Tests unitaires : Avant de mettre en œuvre une fonctionnalité, le

développeur écrit un test qui vérifiera que son programme se comporte
comme prévu. Ce test sera conservé jusqu'à la fin du projet, tant que la
fonctionnalité est requise. À chaque modification du code, on lance
tous les tests écrits par tous les développeurs, et on sait immédiatement
si quelque chose ne fonctionne plus. 8. Conception simple : L'objectif
d'une itération est de mettre en œuvre les scénarios sélectionnés par le
client et uniquement cela. Envisager les prochaines évolutions ferait
perdre du temps sans avoir la garantie d'un gain ultérieur. Les tests
permettront de changer l'architecture plus tard si nécessaire. Plus
l'application est simple, plus il sera facile de la faire évoluer lors des
prochaines itérations.

9. Utilisation de métaphores : On utilise des métaphores et des

analogies pour décrire le système et son fonctionnement. Le
fonctionnel et le technique se comprennent beaucoup mieux lorsqu'ils
sont d'accord sur les termes qu'ils emploient.

10. Refactoring (ou remaniement du code) : Amélioration régulière

de la qualité du code sans en modifier le comportement. On retravaille
le code pour repartir sur de meilleures bases tout en gardant les mêmes
fonctionnalités.

11. Appropriation collective du code : L'équipe est collectivement

responsable de l'application. Chaque développeur peut faire des
modifications dans toutes les portions du code, même celles qu'il n'a
pas écrites. Les tests diront si quelque chose ne fonctionne plus.

12. Convention de nommage : Puisque tous les développeurs

interviennent sur tout le code, il est indispensable d'établir et de
respecter des normes de nommage pour les variables, méthodes,
objets, classes, fichiers, etc.

13. Programmation en binôme : La programmation se fait par deux.

Le premier appelé driver (ou pilote) tient le clavier. C'est lui qui va
travailler sur la portion de code à écrire. Le second appelé partner (ou
copilote) est là pour l'aider en suggérant de nouvelles possibilités ou en
décelant d'éventuels problèmes.
 24

THEME 3 : MACHINE LEARNING

L'apprentissage automatique (en anglais : machine

learning, litt. « apprentissage machine »), apprentissage
artificiel ou apprentissage statistique est un champ d'étude de l'intelligence
artificielle qui se fonde sur des approches mathématiques et statistiques pour
donner aux ordinateurs la capacité d'« apprendre » à partir de données, c'est-
à-dire d'améliorer leurs performances à résoudre des tâches sans être
explicitement programmés pour chacune.

Le machine learning (ML) est une forme d’intelligence artificielle (IA) qui est
axée sur la création de systèmes qui apprennent, ou améliorent leurs
performances, en fonction des données qu’ils traitent.

Plus largement, il concerne la conception, l'analyse, l'optimisation, le

développement et l'implémentation de telles méthodes. On parle
d'apprentissage statistique car l'apprentissage consiste à créer un modèle dont
l'erreur statistique moyenne est la plus faible possible.

L'apprentissage automatique (AA) permet à un système piloté ou assisté par

ordinateur comme un programme, une IA ou un robot, d'adapter ses réponses
ou comportements aux situations rencontrées, en se fondant sur l'analyse de
données empiriques passées issues de bases de données, de capteurs, ou du
web.

Aujourd’hui, nous utilisons le machine learning dans tous les domaines.

Lorsque nous interagissons avec les banques, achetons en ligne ou utilisons
les médias sociaux, des algorithmes de machine learning entrent en jeu pour
optimiser, fluidifier et sécuriser notre expérience. Le machine learning et la
technologie qui l’entoure se développent rapidement, et nous commençons
seulement à entrevoir ses capacités.

TYPE D’APPRENTISSAGE

Les algorithmes sont les moteurs du machine learning. En général, Les

algorithmes d'apprentissage peuvent se catégoriser selon le mode
d'apprentissage qu'ils emploient.
 25

Apprentissage non supervisé

L'apprentissage non supervisé est la forme la moins courante d'apprentissage.

En effet, dans cette forme d'apprentissage, il n'y a pas de résultat attendu.
On utilise cette forme d'apprentissage pour faire du clustering: on a un
ensemble de données, et on cherche à déterminer des classes de faits.
Par exemple, à partir d'une base de données de clients, on cherche à obtenir
les différentes catégories, en fonction de leurs achats ou budgets. On ne sait
pas a priori combien il y a de catégories ou ce qu'elles sont.
On va donc chercher à maximiser la cohérence des données à l'intérieur d'une
même classe et à minimiser celle-ci entre les classes.

Apprentissage par renforcement

Dans l'apprentissage par renforcement, on indique à l'algorithme si la décision
prise était bonne ou non. On a donc un retour global qui est fourni. Par contre,
l'algorithme ne sait pas exactement ce qu'il aurait dû décider.

Dans le cas des réseaux de neurones, on utilise souvent cette forme

d'apprentissage quand on cherche à obtenir des comportements complexes
faisant intervenir des suites de décisions. C'est par exemple le cas en robotique
ou pour créer des adversaires intelligents dans les jeux vidéo. En effet, on
cherche alors un programme qui prendra différentes décisions l'emmenant à
une position où il est gagnant.

L'apprentissage non supervisé peut se faire grâce aux métas heuristiques. En

effet, elles permettent d'optimiser des fonctions sans connaissances a priori.
Cependant, la technique la plus employée est l'utilisation des algorithmes
génétiques. Ils permettent, grâce à l'évolution, d'optimiser les poids et de
trouver des stratégies gagnantes, sans informations particulières sur ce qui
était attendu.

Apprentissage supervisé

L'apprentissage supervisé est sûrement le plus courant. Il est utilisé pour des
tâches d'estimation, de prévision, de régression ou de classification.
Dans l'apprentissage supervisé, un ensemble d'exemples est fourni à
l'algorithme d'apprentissage. Celui-ci va comparer la sortie obtenue par le
réseau avec la sortie attendue.
Les poids sont ensuite modifiés pour minimiser cette erreur, jusqu'à ce que les
résultats soient satisfaisants pour tous les exemples fournis.
Cette approche est utilisée à chaque fois que les exemples sont présentés au
réseau de neurones les uns à la suite des autres, sans liens entre eux.
 26

C'est le cas en estimation où une valeur doit être calculée en fonction d'autres
fournies : la consommation d'une maison en fonction de ses caractéristiques,
la lettre dessinée en fonction des pixels noirs et blancs, la modification d'une
valeur en bourse en fonction de son historique des dernières heures ou
derniers jours, etc.
 27

THEME 4 : LA SECURITE INFORMATIQUE

4.1. Notions
Le système informatique, présente des failles susceptibles d'être
exploitées par les tierces personnes de façon illicite, c'est pourquoi il est
important de maitriser rigoureusement et méthodiquement la sécurité de
systèmes d'informations et de réseau des télécommunications.

La sécurité des systèmes d’information (SSI) ou plus

simplement sécurité informatique, est l’ensemble des moyens techniques,
organisationnels, juridiques et humains nécessaires à la mise en place de
moyens visant à empêcher l'utilisation non autorisée, le mauvais usage, la
modification ou le détournement du système d'information. Assurer la
sécurité du système d'information est une activité du management du système
d'information.

Aujourd’hui, la sécurité est un enjeu majeur pour les entreprises

ainsi que pour l’ensemble des acteurs qui l’entourent. Elle n'est plus confinée
uniquement au rôle de l’informaticien. Sa finalité sur le long terme est de
maintenir la confiance des utilisateurs et des clients. La finalité sur le moyen
terme est la cohérence de l’ensemble du système d’information. Sur le court
terme, l’objectif est que chacun ait accès aux informations dont il a besoin.

4.2. Objectifs de la sécurité

« Le système d'information représente un patrimoine essentiel de
l'organisation, qu'il convient de protéger. La sécurité informatique consiste à
garantir que les ressources matérielles ou logicielles d'une organisation sont
uniquement utilisées dans le cadre prévu »
La sécurité des systèmes d'information vise les objectifs suivants (C.A.I.D.) :

1. Confidentialité : seules les personnes autorisées peuvent avoir accès aux

informations qui leur sont destinées (notions de droits ou permissions).
Tout accès indésirable doit être empêché.
2. Authenticité : les utilisateurs doivent prouver leur identité par l'usage
de code d'accès. Il ne faut pas mélanger identification et authentification :
dans le premier cas, l'utilisateur n'est reconnu que par son identifiant public,
tandis que dans le deuxième cas, il doit fournir un mot de passe ou un élément
que lui-seul connaît (secret). Mettre en correspondance un identifiant
public avec un secret est le mécanisme permettant de garantir
l'authenticité de l'identifiant. Cela permet de gérer les droits d'accès
aux ressources concernées et maintenir la confiance dans les relations
d'échange.
 28

3. Intégrité : les données doivent être celles que l'on attend, et ne doivent
pas être altérées de façon fortuite, illicite ou malveillante. En clair, les
éléments considérés doivent être exacts et complets. Cet objectif utilise
généralement des méthodes de calcul de checksum ou de hachage.
4. Disponibilité : l'accès aux ressources du système d'information doit être
permanent et sans faille durant les plages d'utilisation prévues. Les
services et ressources sont accessibles rapidement et régulièrement.
D'autres aspects peuvent aussi être considérés comme des objectifs de la
sécurité des systèmes d'information, tels que :

1. La traçabilité (ou « preuve ») : garantie que les accès et tentatives

d'accès aux éléments considérés sont tracés et que ces traces sont
conservées et exploitables.
2. La non-répudiation et l'imputation : aucun utilisateur ne doit pouvoir
contester les opérations qu'il a réalisées dans le cadre de ses actions
autorisées et aucun tiers ne doit pouvoir s'attribuer les actions d'un
autre utilisateur.

4.3. Risques liés à l’utilisation de l’informatique

Les coûts d'un problème informatique peuvent être élevés et ceux de
la sécurité le sont aussi. Il est nécessaire de réaliser une analyse de risque en
prenant soin d'identifier les problèmes potentiels avec les solutions avec les
coûts associés.

L’utilisation de l’outil informatique est susceptible de nous exposer

à plusieurs types de risques. Il est nécessaire de mesurer ces risques en fonction
de la probabilité ou de la fréquence de leurs survenances et aussi en mesurant
leurs effets possibles.

4.3.1. Risques humains

Ce sont les plus importants, même si beaucoup semble l’ignorer ou minimises.

Certes, il concerne les utilisateurs mais également les informaticiens eux-
mêmes. Sur ce on peut catégoriser ces vices :

- La maladresse ;
- L’inconscience ou l’ignorance ;
- La malveillance ;
- L’espionnage ;
- Etc.
 29

4.3.2. Risques matériels

Ils sont liés aux défauts ou aux pannes inévitables que connaissent tous les
systèmes matériels et logiciels. Ces incidents sont plus moins fréquents selon
le soin apporté lors de fabrication et l’application de procédures de test
effectuées avant que les ordinateurs et les programmes ne soit mise en service.
A cet effet, il y a :

- Incident lié au matériel ;

- Incident lié au logiciel ;
- Incident lié à l’environnement.

4.4. Principales attaques

Un logiciel malveillant est un logiciel développé dans le but de nuire

à un système informatique. Notez qu’il en existe de plusieurs.
4.4.1. Virus
Les virus est un exécutable qui va exécuter des opérations plus ou
moins destructrices sur votre machine. Les virus existent depuis que
l’informatique est née et se propageaient initialement par disquettes de jeux
ou logiciels divers... Sur Internet, les virus peuvent contaminer une machine
de plusieurs manières :
- Téléchargement de logiciel puis exécution de celui-ci sans
précautions,
- Ouverture sans précautions de documents contenant des
macros,
- Pièce jointe de courrier électronique (exécutable, script type
vbs…),
- Ouverture d’un courrier au format HTML contenant du
javascript exploitant une faille de sécurité du logiciel de courrier
(normalement javascript est sans danger).

- Exploitation d’un bug du logiciel de courrier (effectuer

régulièrement les mises à jour).
Les virus peuvent être très virulents mais ils coûtent aussi beaucoup
de temps en mise en place d’antivirus et dans la réparation des dégâts causés.
On peut malheureusement trouver facilement des logiciels capables de
générer des virus et donc permettant à des « amateurs » (aussi appelés crackers)
d’étaler leur incompétence.
La meilleure parade est l’utilisation d’un antivirus à jour et
d’effectuer les mises à jour des logiciels (pour éviter l’exploitation des bugs).
 30

4.4.2. Déni de service (DoS)

Le but d'une telle attaque n'est pas de dérober des informations sur
une machine distante, mais de paralyser un service ou un réseau complet. Les
utilisateurs ne peuvent plus alors accéder aux ressources. Les deux exemples
principaux, sont le « ping flood » ou l’envoi massif de courrier électroniques
pour saturer une boîte aux lettre (mailbombing). La meilleure parade est le
firewall ou la répartition des serveurs sur un réseau sécurisé.

4.4.3 Écoute du réseau (sniffer)

Il existe des logiciels qui, à l’image des analyseurs de réseau,
permettent d’intercepter certaines informations qui transitent sur un réseau
local, en retranscrivant les trames dans un format plus lisible (Network packet
sniffing). C’est l’une des raisons qui font que la topologie en étoile autour d'un
hub n’est pas la plus sécurisée, puisque les trames qui sont émises en «
broadcast » sur le réseau local peuvent être interceptées. De plus, l’utilisateur
n’a aucun moyen de savoir qu’un pirate a mis son réseau en écoute.

L’utilisation de switches (commutateurs) réduit les possibilités

d’écoute mais en inondant le commutateur, celui-ci peut se mettre en mode «
HUB » par « sécurité » !
La meilleure parade est l’utilisation de mot de passe non rejouable,
de carte à puce ou de calculette à mot de passe.

4.4.4. Intrusion
L'intrusion dans un système informatique a généralement pour but
la réalisation d’une menace et est donc une attaque. Les conséquences
peuvent être catastrophiques : vol, fraude, incident diplomatique, chantage…
Le principal moyen pour prévenir les intrusions est le coupe-feu
("firewall"). Il est efficace contre les fréquentes attaques de pirates amateurs,
mais d’une efficacité toute relative contre des pirates expérimentés et bien
informés. Une politique de gestion efficace des accès, des mots de passe et
l’étude des fichiers « log » (traces) est complémentaire.

4.4.5. Cheval de Troie

L’image retenue de la mythologie est parlante; le pirate, après avoir
accédé à votre système ou en utilisant votre crédulité, installe un logiciel qui
va, à votre insu, lui transmettre par Internet les informations de vos disques
durs. Un tel logiciel, aussi appelé troyen ou trojan, peut aussi être utilisé pour
générer de nouvelles attaques sur d’autres serveurs en passant par le vôtre.
Certains d’entre eux sont des « key logger » c'est-à-dire qu’ils enregistrent les
frappes faites au clavier.
 31

La première mesure de protection face aux attaques, et de sécuriser au

maximum l’accès à votre machine et de mettre en service un antivirus
régulièrement mis à jour.
4.4.6 « social engeneering »

En utilisant les moyens usuels (téléphone, email…) et en usurpant

une identité, un pirate cherche à obtenir des renseignements confidentiels
auprès du personnel de l’entreprise en vue d’une intrusion future. Seule une
formation du personnel permet de se protéger de cette attaque.

4.5. Eléments de sécurité

De nombreux moyens techniques peuvent être mis en œuvre pour
assurer une sécurité du système d'information.
Voici une liste non exhaustive de moyens techniques pouvant
répondre à certains besoins en matière de sécurité du système d'information :

1. Contrôle des accès au système d'information ;

2. Surveillance du réseau : sniffer, système de détection d'intrusion ;
3. Sécurité applicative : séparation des privilèges, audit de code, rétro-
ingénierie ;
4. Emploi de technologies ad hoc : pare-feu, UTM, anti-logiciels
malveillants (antivirus, anti-spam, anti-logiciel espion) ;
5. Cryptographie : authentification forte, infrastructure à clés
publiques, chiffrement.
6. Plan de continuité d'activité : sauvegarde et restauration de
données, Plan de Reprise d'activité.
4.6. Principaux défauts de sécurité

Les défauts de sécurité d’un système d’information les plus souvent

constatés sont :
- Installation des logiciels et matériels par défaut.
- Mises à jour non effectuées.
- Mots de passe inexistants ou par défaut.
- Services inutiles conservés (Netbios…).
- Traces inexploitées.
- Pas de séparation des flux opérationnels des flux d’administration des
systèmes.
- Procédures de sécurité obsolètes.
- Eléments et outils de test laissés en place dans les configurations en
production.
- Authentification faible.
 32

THEME 5 : WEB SERVICE

Les services web permettent à différentes applications écrites dans des

langages de programmation différents de communiquer entre elles.

Les applications web modernes sont développées dans différents langages de

programmation : Java, Net, Angular JS, Node.js… de fait, il peut être difficile
d’assurer la communication entre ces applications. C’est la raison pour
laquelle on utilise des « services web ».

Les services web fournissent une plateforme commune permettant à de

multiples applications développées avec différents langages de
programmation de communiquer entre elles.

FONCTIONNEMENT DE SERVICE WEB

Une fois invoqué, un service web est en mesure de fournir ses fonctionnalités
au client qui l’invoque. Le client invoque une série d’appels de service web
par le biais de requêtes envoyées au serveur qui héberge le service. Ces
requêtes sont effectuées par le biais d’appels de procédure distante (Remote
Procedure Calls).

Par exemple, Amazon propose un service web fournissant les prix pour des
produits vendus en ligne via Amazon.com. Le front end ou la couche de
présentation peuvent être en .Net ou en Java, mais ces deux langages de
programmation auront la capacité de communiquer avec le service web.

Le principal composant d’un service web sont les données transférées entre le
client et le serveur. Ces données sont en XML (Extensible Markup Language).
Le XML est la contrepartie du HTML. Pour faire simple, on peut le décrire
comme un langage intermédiaire compris par la plupart des langages de
programmation. Ainsi, les applications communiquent entre elles en XML.
 33

Pour envoyer les données XML entre les applications, les services web
utilisent le SOAP (Simple Object Access Protocol). Les données envoyées du
service web vers l’application sont appelées des messages SOAP. Il s’agit tout
simplement d’un document au format XML.

Avantages

En plus de permettre aux applications écrites dans différents langages de

programmation de communiquer entre elles, les services web offrent d’autres
avantages. Tout d’abord, ils permettent d’accéder à des fonctionnalités via
internet. En effet, les fonctionnalités fournies par le service web à une
application client sont invoquées via le protocole HTTP. Elles peuvent donc
être invoquées via internet. A l’heure où toutes les applications sont
connectées à internet, les services web sont donc devenus bien plus utiles
qu’autrefois.

Par ailleurs, les services web permettent une interopérabilité entre les
applications. Ils permettent en effet à diverses applications de communiquer
entre elles, et de partager des données et des services. Ainsi, plutôt que d’avoir
à écrire un code spécifique pouvant être compris uniquement par des
applications spécifiques, il est possible d’écrire un code générique pouvant être
compris par toutes les applications.

Un autre avantage des services web est qu’ils utilisent un protocole industriel
standardisé pour la communication. Les quatre couches (Service Transport,
XML Messaging, Service Description et Service Discovery) utilisent des
protocoles bien définis.