Vous êtes sur la page 1sur 91

UNIVERSITE DE YAOUNDE I

UNIVERSITY OF YAOUNDE I

ECOLE NORMALE SUPERIEURE


HIGHER TEACHER TRAINING COLLEGE

DEPARTEMENT D’INFORMATIQUE ET DES TECHNOLOGIES EDUCATIVES


DEPARTMENT OF COMPUTER SCIENCE AND INSTRUCTIONAL TECHNOLOGY
**********

ANNEE ACADEMIQUE 2017 - 2018


2017 – 2018 ACADEMIC YEAR
**********

CONCEPTION ET REALISATION D’UN OUTIL D’AIDE A l’APPRENTISSAGE


SUR LES RISQUES DES ACCIDENTS LIES AUX MOUVEMENTS DE TERRAIN
EN CLASSE DE 4e DE L’ENSEIGNEMENT SECONDAIRE GENERAL

Mémoire présenté par :


GWETH LIONEL FITZGERALD - 13Y203
Licencié en Informatique

En vue d’obtention du :
DIPLÔME DE PROFESSEUR DES LYCÉES D’ENSEIGNEMENT
SECONDAIRE
GÉNÉRAL SECOND GRADE (DIPES II)

Filière Informatique Fondamentale

Sous l’encadrement de :
Dr MICHAEL N. NKWENTI
CHARGE DE COURS
DEDICACES

A mon père

A qui je dois toute ma réussite aujourd’hui. Car c’est grâce à toi que j’ai pu faire mes pas
dans ma vie et réaliser mes ambitions. Ta rigueur, ta sévérité et ton sens du travail
continueront à me servir de modèle. J’en serai éternellement reconnaissant.

A ma mère

Toi qui continues à te sacrifier pour nous malgré toutes les épreuves. Ton amour et ta
tendresse n’ont d’égal que mon estime pour toi. Puisse ce travail montrer l’admiration et la
reconnaissance que j’ai envers toi.

A ma famille, mes amis

Vous avez toujours été près de moi pour m’écouter, me tendre la main, me donner des
conseils. J’en suis éternellement reconnaissant. Je vous souhaite toute la réussite dans la vie.

Lionel Fitzgérald GWETH

i
REMERCIEMENTS

Au terme de ce travail, j’adresse mes vifs remerciements à l’ensemble des personnes qui de
près ou de loin m’ont permis de produire ce travail.

Je remercie :

• Le Pr. Marcel FOUDA NDJODO, Chef du département d’Informatique et des


Technologies Educatives de l’Ecole Normale Supérieure de Yaoundé pour ses
conseils, ses enseignements, sa rigueur dans le travail qu’il nous a apporté tout au
long de notre formation.
• Le Dr. Michael N. NKWENTI, Chargé de cours au Département d’Informatique et
des Technologies Educatives de l’Ecole Normale Supérieure de Yaoundé et notre
encadreur, pour sa disponibilité, ses orientations et ses conseils.
• Tout le corps enseignant des départements d’informatique et des Sciences de
l’Education pour leurs enseignements qui nous permettent d’être qui nous sommes
en ce jour.
• Mme Carine FOTSO, notre encadreur de stage professionnel, pour son
accompagnement moral tout au long de ce travail.
• Notre collaboratrice Anita Françoise NKOMIDIO, sans qui le travail n’aurait pris
cette forme.
• Mes amis et tous mes camarades de promotion pour leur soutien et leurs critiques
surtout car, cela a contribué en la qualité de ce travail.
• Tous ceux qui de près ou de loin ont contribué en faveur de la production de cette
œuvre.

ii
TABLE DES MATIERES

DEDICACES .......................................................................................................................................... i
REMERCIEMENTS ............................................................................................................................. ii
TABLE DES MATIERES ................................................................................................................... iii
RESUME ................................................................................................................................................ v
ABSTRACT .......................................................................................................................................... vi
LISTE DES SIGLES ET ABREVIATIONS ..................................................................................... vii
LISTE DES FIGURES ....................................................................................................................... viii
LISTE DES TABLEAUX .................................................................................................................... ix
CHAPITRE 1 : INTRODUCTION GENERALE .............................................................................. 1
1.1 Contexte général de l’étude ..................................................................................................... 1
1.2 Problème et problématique ...................................................................................................... 2
1.3 Questions de recherche ............................................................................................................ 3
1.4 Objectifs de l’étude ................................................................................................................. 3
1.5 Importance de l’étude .............................................................................................................. 4
1.6 Délimitations du champ de l’étude .......................................................................................... 4
CHAPITRE 2 : REVUE DE LITTERATURE ................................................................................... 6
2.1. Etude des travaux existants .......................................................................................................... 6
2.1.1 Dans le monde et en Afrique .................................................................................................. 6
2.1.2 Au Cameroun .................................................................................................................. 7
2.2 Les préférences des élèves dans un didacticiel ........................................................................ 7
2.3 Méthodes ou modèles de développement logiciel ................................................................... 8
2.3.1 Les méthodes « classiques » ............................................................................................ 8
2.3.2 Les méthodes « agiles »................................................................................................. 11
2.4 Conception ergonomique....................................................................................................... 23
2.4.1 Les critères ergonomiques d’un logiciel ........................................................................ 23
2.4.2 Les échelles d’utilisabilité ............................................................................................. 25
2.5 Choix des méthodes de travail ............................................................................................... 28
2.5.1 Choix de la méthode logicielle ...................................................................................... 28
2.5.2 Choix de l’échelle d’utilisabilité.................................................................................... 28
CHAPITRE 3 : METHODES ET MATERIELS ............................................................................. 29
3.1 Les méthodes ......................................................................................................................... 29
3.1.1 Les méthodes de recherche ........................................................................................... 29
3.1.2 La population cible et la population d’enquête ............................................................. 30

iii
3.1.3 Les techniques d’échantillonnage .................................................................................. 31
3.1.5 Plan d’application de la méthode scrum ........................................................................ 34
3.2 Matériels ................................................................................................................................ 35
3.2.1 Matériels d’enquête ....................................................................................................... 35
3.2.2 Matériels de développement .......................................................................................... 35
CHAPITRE 4 : RESULTATS ......................................................................................................... 37
4.1 Résultats d’enquête................................................................................................................ 37
4.1.1 Population d’enquête ..................................................................................................... 37
4.1.2 Le questionnaire des élèves ........................................................................................... 38
4.1.3 L’entretien des enseignants ........................................................................................... 43
4.2 Résultats de la méthodologie logicielle ................................................................................. 43
4.2.1 La phase d’analyse ........................................................................................................ 43
4.2.2 La phase de conception, de planification et d’estimation .............................................. 54
4.2.3 La phase d’implémentation ou de réalisation ................................................................ 64
4.2.4 La phase de tests ............................................................................................................ 69
4.2.5 La phase de production.................................................................................................. 71
CHAPITRE 5 : DISCUSSIONS ET IMPLICATIONS.................................................................... 72
5.1 Discussions ............................................................................................................................ 72
5.1.1 Difficultés liées à l’apprentissage des mouvements de terrain ...................................... 72
5.1.2 Styles d’apprentissage préférés des apprenants dans un didacticiel .............................. 72
5.1.3 Les impressions des élèves après l’utilisation du didacticiel......................................... 73
5.1.4 Limites de l’étude .......................................................................................................... 73
5.1.5 Difficultés rencontrées................................................................................................... 73
5.2 Implications pédagogiques .................................................................................................... 74
5.2.1 Pour l’apprenant ............................................................................................................ 74
5.2.2 Pour l’apprenant ............................................................................................................ 74
CONCLUSION ET PERSPECTIVES .............................................................................................. 75
BIBLIOGRAPHIE .............................................................................................................................. 76
ANNEXES ............................................................................................................................................ 78
Annexe 1 : Questionnaire 1 adressé aux élèves................................................................................. 78
Annexe 2 : Fiche d’entretien avec les enseignants ............................................................................ 79
Annexe 1 : Questionnaire 2 adressé aux élèves................................................................................. 80

iv
RESUME
La mondialisation des enseignements et des savoirs pousse aujourd’hui toute la communauté
éducative à s’arrimer à l’utilisation des technologies de l’information et de la communication
pour l’enseignement (TICE). La discipline que représentent les SVTEEHB (Sciences de la Vie
et de la Terre, Education à l’Environnement, Hygiène et Biotechnologie) au secondaire, est une
discipline dont l’enseignement se base sur les modèles, les représentations et les animations.
Elle nécessite donc des simulations et des expérimentations. Malheureusement la plupart des
établissements secondaires camerounais sont confrontés à une insuffisance d’infrastructures
liées à cette discipline. De plus le système éducatif camerounais possède très peu de ressources
numériques pour l’enseignement. C’est dans le but de palier à ce problème d’insuffisance de
ressources numériques tout en promouvant l’utilisation des TICE que notre étude vise à mettre
sur pied un didacticiel portant sur les risques des accidents liés aux mouvements de terrain en
classe de quatrième de l’enseignement secondaire général. Diaccmout (Didacticiel sur les
accidents liés aux mouvements de terrain) est un didacticiel qui vise à développer chez
l’apprenant un ensemble de compétences lui permettant de réduire les dégâts causés par les
mouvements de terrain. Notre étude s’est faite en deux grandes phases. La première phase est
représentée par une enquête faite auprès des enseignants et des élèves tandis que la seconde
représente le développement de l’application. En ce qui concerne l’enquête, nous avons utilisé
comme méthode de collecte le questionnaire pour les élèves et l’entretien pour les enseignants.
Dans la phase de développement de l’application, la méthode logicielle choisie et utilisée a été
scrum, qui est classée parmi les méthodes de développement dites agiles. Son approche basée
sur les incréments successifs et la participation du client à chaque phase nous a permis de
produire différentes versions de l’application chaque fois validées par l’analyste. L’enquête a
été effectuée sur 180 élèves de la ville de Yaoundé et nous a permis de ressortir que les élèves
de quatrième ont des réelles difficultés à se représenter les mouvements de terrain et préfèrent
des couleurs claires et des plus d’illustrations. Ce qui nous a poussé d’axer nos contenus sur
des images, des animations et des vidéos. A la fin du développement de notre application, un
test d’expérience utilisateur a été effectué sur 36 élèves et il en est ressorti un score
d’utilisabilité de notre application de 73 pourcents. En conclusion Diaccmout a prouvé son
intérêt dans l’apprentissage des accidents liés aux mouvements de terrain.

Mots clés : mouvement de terrain – didacticiel – Diaccmout – scrum - apprentissage.

v
ABSTRACT

The globalisation of teachings and knowledge in today’s world has prompted the educational
community to align itself to the use of information and communication technologies for
teaching. The subjects which are biology, environmental studies, hygiene and biotechnology
taught in secondary schools are subjects based on models, representations and animations. They
therefore need simulations and experimentations. Unfortunately, most secondary schools in
Cameroon are faced with the lack of infrastructures meant for these subjects. Moreover, the
Cameroonian educational system has very few digital resources meant for teaching. It is in a
bid to palliate these problems while at the same time promoting the use of ICT that our study
aimed to put in place a teachware meant for accidents linked to landslide taught in form three.
Didacticiel sur les accidents liés aux mouvements des terrains (DIACCMOUT) is a software
meant to develop in the usager a series of competencies to permit him reduce the damage cause
by landslides. Our study was done in two phases: the first was a survey done with teachers and
students with the help of questionnaires and interviews. The second which represented the
development of the software was done based on the software engineering method SCRUM
which is classified amongst the methods said to be ‘agile’. Its approach based on successive
increments and the customers’ participation at every stage helped us to produce several versions
of the application(app). The survey was carried out on 180 students in the city of Yaounde and
this allowed us to realise that form three students have difficulties in imagining themselves in
situations of landslides. They also preferred a more colourful and graphic app. This pushed us
to focus the app’s contents on images, animations and videos. At the end of the app’s creation
a usager experimentation was carried out on 36 students. The usability score of the app was
73%. Therefore, the DIACCMOUT software proved its interest in the learning of damages
caused landslides.

Key words: landslide-teachware-DIACCMOUT-SCRUM-learning

vi
LISTE DES SIGLES ET ABREVIATIONS

CSS : Cascading Style Sheets

DEEP : Design Oriented Evaluation and Perceived Usability

DIACCMOUT : Didacticiel sur les Accidents liés aux Mouvements de Terrain

EAO : Enseignement assisté par Ordinateur

ENS : Ecole Normale Supérieure

ESG : Enseignement Secondaire Général.

HTML : Hyper Text Markup Language

ISO: International Organization for Standardization

RUP: Rational Unified process

SUS : System Usability System

SVT : Science de la Vie et de la Terre

SVTEEHB : Sciences de la Vie et de la Terre, Education à l’Environnement, Hygiène et


Biotechnologie.

TIC : Technologie de L’Information et de de la Communication.

TICE : Technologie de L’Information et de de la Communication pour l’Enseignement.

UML: Unified Modeling Language

XP: Extreme programming

vii
LISTE DES FIGURES

FIGURE 1 : LE MODELE EN CASCADE (LONCHAMP, 2015) ....................................................................................... 9


FIGURE 2 : LE MODELE EN V (LONCHAMP, 2015) ................................................................................................. 10
FIGURE 3 : LE MODELE EN SPIRALE (LONCHAMP, 2015) ...................................................................................... 11
FIGURE 4 : RUP, PHASES, ITERATIONS ET DISCIPLINES (LONCHAMP, 2015) .......................................................... 12
FIGURE 5 : LES PRATIQUES XP (KHALIL, 2011) .................................................................................................... 14
FIGURE 6 : PROCESSUS DE DEVELOPPEMENT XP (KHALIL, 2011).......................................................................... 14
FIGURE 7 : LA STRUCTURE D'UN SPRINT (LONCHAMP, 2015) ................................................................................ 16
FIGURE 8 : LE SPRINT BACKLOG (LONCHAMP, 2015) ............................................................................................ 16
FIGURE 9 : LES REUNIONS (LONCHAMP, 2015) ..................................................................................................... 17
FIGURE 10 : APERÇU DE LA PHASE D'INITIATION (SCRUM BODY OF KNOWLEDGE (SBOK GUIDE), 2013) ............ 19
FIGURE 11: APERÇU DE LA PHASE D'ESTIMATION (SCRUM BODY OF KNOWLEDGE (SBOK GUIDE), 2013) ........... 20
FIGURE 12: APERÇU DE LA PHASE D'IMPLEMENTATION (SCRUM BODY OF KNOWLEDGE (SBOK GUIDE), 2013) .. 21
FIGURE 13: APERÇU DE LA PHASE DE REVUE (SCRUM BODY OF KNOWLEDGE (SBOK GUIDE), 2013).................. 22
FIGURE 14: APERÇU DE LA PHASE DE LANCEMENT (SCRUM BODY OF KNOWLEDGE (SBOK GUIDE), 2013)......... 22
FIGURE 15 : LISTE DES CRITERES ERGONOMIQUES (BASTIEN, 2006) ..................................................................... 24
FIGURE 16 : TRADUCTION LIBRE DEEP (GRONIER ET LALLEMAND, 2015) .......................................................... 27
FIGURE 17 : TRADUCTION LIBRE SUS (GRONIER ET LALLEMAND, 2015) ............................................................. 27
FIGURE 18: TAUX DE REPRESENTATIVITE DES AGES .............................................................................................. 38
FIGURE 19: TAUX DE REPRESENTATIVITE DES SEXES ............................................................................................. 38
FIGURE 20: DIAGRAMME DE REPRESENTATIVITE ITEM 10 ..................................................................................... 40
FIGURE 21: DIAGRAMME DE REPRESENTATIVITE ITEM 12 ..................................................................................... 41
FIGURE 22 : DIAGRAMME DE REPRESENTATIVITE ITEM 15 .................................................................................... 42
FIGURE 23: DIAGRAMME DE REPRESENTATIVITE ITEM 16 ..................................................................................... 42
FIGURE 24 : DIAGRAMME DE CAS D'UTILISATION GLOBAL .................................................................................... 47
FIGURE 25 : DIAGRAMME DE CAS D'UTILISATION DU SPRINT 1 .............................................................................. 48
FIGURE 26 : DIAGRAMME DE CAS D'UTILISATION SPRINT 2 ................................................................................... 50
FIGURE 27 : DIAGRAMME DE CAS D'UTILISATION DU SPRINT 3 ............................................................................. 52
FIGURE 28: PLANNING DES SPRINTS ...................................................................................................................... 54
FIGURE 29 : DIAGRAMME DE NAVIGATION DU SYSTEME ...................................................................................... 55
FIGURE 30 : DIAGRAMME DE DEPLOIEMENT DU SYSTEME ..................................................................................... 55
FIGURE 31: MAQUETTE DE LA PAGE D'ACCUEIL .................................................................................................... 56
FIGURE 32: MAQUETTE MENU D'APPRENTISSAGE .................................................................................................. 56
FIGURE 33 : MAQUETTE DE L‘INTERFACE SUR LES EBOULEMENTS ........................................................................ 57
FIGURE 34: MAQUETTE INTERFACE JEUX.............................................................................................................. 57
FIGURE 35 : DIAGRAMME DE SEQUENCE DU CAS "TESTER LES PREREQUIS" ........................................................... 59
FIGURE 36 : DIAGRAMME DE SEQUENCE DU CAS "LIRE UNE VIDEO " ..................................................................... 61
FIGURE 37 : DIAGRAMME DU CAS D'UTILISATION « S’EXERCER SUR LES GLISSEMENTS" ....................................... 61
FIGURE 38 : DIAGRAMME DE SEQUENCE DU CAS "JOUER AU PENDU" .................................................................... 63
FIGURE 39 : DIAGRAMME DE SEQUENCE DU CAS D'UTILISATION DU CAS "JOUER AU MILLIONNAIRE" ................... 63
FIGURE 40 : BURNDOWN CHART SPRINT 1 ............................................................................................................ 64
FIGURE 41 : INTERFACE DES OBJECTIFS................................................................................................................. 64
FIGURE 42 : INTERFACE DU TEST DE PREREQUIS .................................................................................................... 65
FIGURE 43 : BURNDOWN CHART SPRINT 2 ............................................................................................................ 65
FIGURE 44 : INTERFACE D'APPRENTISSAGE ........................................................................................................... 66
FIGURE 45 : INTERFACE DE LECTURE SUR LES EBOULEMENTS ............................................................................... 66
FIGURE 46 : INTERFACE DE TEST SUR LES EBOULEMENTS...................................................................................... 67
FIGURE 47 : BURNDOWN CHART SPRINT 3 ............................................................................................................ 67
FIGURE 48 : INTERFACE DES EXERCICES ............................................................................................................... 68
FIGURE 49 : INTERFACE DU JEU "LE MOT CACHE" ................................................................................................. 68
FIGURE 50 : INTERFACE DU JEU "LE MILLIONNAIRE" ............................................................................................. 69

viii
LISTE DES TABLEAUX

TABLEAU 1 : LES PHASES ET PROCESSUS SCRUM (SCRUM BODY OF KNOWLEDGE (SBOK GUIDE), 2013) ............ 18
TABLEAU 2 : CARACTERISTIQUES DE L'ANALYSE QUALITATIVE ET QUANTITATIVE (LEE, 2014)............................ 30
TABLEAU 3: STATISTIQUES DES AGES DE LA POPULATION..................................................................................... 37
TABLEAU 4: STATISTIQUES DU QUESTIONNAIRE ................................................................................................... 38
TABLEAU 5: STATISTIQUES ITEM 10 ...................................................................................................................... 40
TABLEAU 6: STATISTIQUES ITEM 12 ...................................................................................................................... 40
TABLEAU 7: STATISTIQUES ITEM 15 ...................................................................................................................... 41
TABLEAU 8: STATISTIQUES ITEM 16 ...................................................................................................................... 42
TABLEAU 9 : LISTE DES MEMBRES DU PROJET ....................................................................................................... 44
TABLEAU 10: LES BESOINS FONCTIONNELS ........................................................................................................... 44
TABLEAU 11: BACKLOG DU PRODUIT .................................................................................................................... 46
TABLEAU 12: DESCRIPTION DU CAS D'UTILISATION "CONSULTER LES OBJECTIFS" ................................................ 48
TABLEAU 13 : DESCRIPTION TEXTUELLE DU CAS « LIRE LA VIDEO SUR LA POSE DES FILETS » .............................. 50
TABLEAU 14: DESCRIPTION TEXTUELLE SUR LE CAS "LIRE RESUME SUR LES AFFAISSEMENTS" ............................. 51
TABLEAU 15: DESCRIPTION TEXTUELLE SUR LE CAS "S'EXERCER SUR LES GLISSEMENTS" .................................... 51
TABLEAU 16 : DESCRIPTION DU CAS D’UTILISATION « S’EXERCER AU MATCHING » ............................................. 53
TABLEAU 17 : DESCRIPTION DU CAS D’UTILISATION « JOUER AU PENDU » ............................................................ 53
TABLEAU 18 : BACKLOG DU SPRINT 1 ................................................................................................................... 58
TABLEAU 19: BACKLOG SPRINT 2.......................................................................................................................... 59
TABLEAU 20 : BACKLOG DU SPRINT 3 ................................................................................................................... 62
TABLEAU 21: SCENARIO DE TEST DU SPRINT 1 ...................................................................................................... 69
TABLEAU 22 : SCENARIO DE TEST DU SPRINT 2 ..................................................................................................... 70
TABLEAU 23: SCENARIO DE TEST DU SPRINT 3 ...................................................................................................... 71
TABLEAU 24 : TABLE D’ENQUETE 1- ELEVE .......................................................................................................... 78
TABLEAU 25 : TABLE QUESTIONNAIRE SUS .......................................................................................................... 80

ix
Chapitre 1. Introduction générale

CHAPITRE 1 : INTRODUCTION GENERALE

1.1 Contexte général de l’étude

« Les TIC renforcent la mondialisation et la globalisation des savoirs et de l’enseignement. Les


enseignants doivent veiller à ce que cette mondialisation préserve et renforce les cultures
locales, développe les échanges culturels, le partage des savoirs, et renforce les chances
d’accès de tous aux savoirs ». (Béziat, 2008)

Un objectif important de l’enseignement reste l’acquisition des connaissances et celle-ci se


place aujourd’hui dans un monde où il faut combiner connaissances, capacités et attitudes. C’est
dans cette visée que se rangent les TICE qui représentent des outils éducatifs puissants. Un outil
d’apprentissage (J. Loisier, 2011), se réfère à la fois à des dispositifs techniques, à des processus
et à des usages utilisés pour l’éducation et la formation. Les TICE mettent à la disposition des
élèves, mais aussi des enseignants un ensemble d’artéfacts permettant de favoriser le processus
enseignement-apprentissage. Bertin en 2001, attribue de nombreux avantages aux TICE.
D’après Boterf (1994), la compétence n’est pas un état mais un processus. Selon lui le
compétent est celui qui est capable de mobiliser, de mettre en œuvre de façon efficace les
différentes fonctions d’un système où interviennent des ressources aussi diverses que des
opérations de raisonnement, des activations de la mémoire, des évaluations, des capacités
relationnelles ou des schémas comportementaux. Cette définition rejoint les avantages des
TICE cités par Bertin qui peuvent être regroupés en trois grands groupes à savoir l’acquisition
des connaissances spécifiques (le « savoir »), l’appropriation des compétences transversales (le
« savoir-faire ») et le développement des compétences et des valeurs pour la construction de la
personnalité de l’élève (le « savoir-être »). Erica de Vries (2001) à travers ses huit fonctions
pédagogiques nous permet de dégager des types de logiciels éducatifs tels que des exerciels,
des micromondes ou encore des didacticiels. L’intégration réussie des TICE nécessite
davantage d'efforts dans le volet pédagogique. En effet, selon Barrette (2007), les TIC ne se
révèlent efficaces que lorsqu'elles s'intègrent à une pédagogie qui articule finement des activités
pédagogiques dont les méthodes servent des objectifs explicites. Autrement dit, le pédagogue
doit savoir utiliser les TIC de façon judicieuse pour atteindre les objectifs proposés par les
programmes d'études. La discipline que représente la Science de la Vie et de la Terre (SVT)
n’est pas exclue des programmes cités dans la mesure où il s’agit d’une science dominée par
l’observation et l’expérimentation. Ainsi pour une meilleure transmission de cette science,

1
Chapitre 1. Introduction générale

l’enseignement devrait se baser sur des modèles, des représentations et des animations
(Lhoste,2008). D’où la forte place des TICE dans la discipline des SVT.

Le Maroc a entamé, en 1999, la réforme de son système éducatif par l'opérationnalisation de la


charte nationale de l'éducation et de la formation. Dans cette optique, le ministère de l'éducation
national a lancé en 2005 le programme GENIE 2006-2013 qui vise la généralisation des TICE.
Par ailleurs, nous relevons le portail national (Taalimtice ou portailtice en 2011) pour
l’intégration des TIC dans l’enseignement, permet à tous les acteurs du système éducatif
marocain de s’informer sur les TIC pour l’Enseignement, d’échanger des informations, de
participer activement au développement et à la diffusion de ressources numériques.

La loi d’orientation n° 98/004 du 14 avril 1998 du Cameroun dans son article 25 préconise une
évolution scientifique et technologique ainsi qu’une formation axée sur la culture et ouverte à
l’extérieure. Ceci peut se justifier par la création des 17 premiers centres de ressources
multimédia dans l’enseignement secondaire général en 2001 ainsi que le premier programme
officiel pour l’enseignement de l’informatique en 2003 pour les classes du secondaire et des
Ecoles Normales d’Instituteurs de l’Enseignement Général (ENIEG), et en 2007 pour les
classes de l’enseignement primaire (Djeumeni, 2010). Nous notons aussi la création en 2007 à
l’Ecole Normale Supérieure de Yaoundé la filière Informatique et technologie éducative dont
l’objectif est de former des personnes capables d’enseigner l’informatique, de piloter des
systèmes informations éducatifs et de promouvoir l’enseignement dans les lycées à l’aide des
TIC. C’est dans cette optique que dans le cadre de certains mémoires de fin de formation, de
nombreux didacticiels ont été développés au sein du département informatique et des
technologies éducatives.

1.2 Problème et problématique

Selon Djeumeni en 2010, l’enseignement reste théorique par des enseignants, car au Cameroun,
il n’existe pas une véritable stratégie de mise en œuvre de cette politique d’introduction des
TIC dans le secteur de l’éducation. Elle ajoute que c’est par les projets avec financement des
partenaires au développement et les consortiums et souvent grâce aux initiatives locales que se
manifeste cette volonté d’introduire les TIC en éducation. Selon les orientations pédagogiques
et programmes officiels, l'observation et l'expérimentation occupent une place primordiale dans
l'enseignement des SVT, Cependant l'enseignant se trouve dans plusieurs cas confrontés aux
problèmes de l'absence ou de la pénurie de matériels frais et d'équipements nécessaires dans les

2
Chapitre 1. Introduction générale

laboratoires des lycées. Dans ces situations, le recours aux technologies de l'information et de
la communication constitue-t-il, même partiellement une alternative efficace et prometteuse ?

Dans le cadre de notre étude qui porte sur l’enseignement des accidents liés aux mouvements
de terrain en SVT en classe de quatrième pour l’enseignement secondaire général au Cameroun,
nous constatons un véritable manque de logiciel éducatif permettant à l’élève d’accroître sa
compréhension ou à l’enseignant d’améliorer et simplifier son enseignement. C’est dans cette
optique que nous nous proposons ainsi de réaliser un didacticiel chargé de favoriser
l’apprentissage des apprenants dans ce cours.

1.3 Questions de recherche

Face à ce problème, dans le but d’organiser notre étude, nous sommes emmenés à nous
poser les questions suivantes :

• Quelles sont les difficultés rencontrées par les élèves dans l’apprentissage des accidents
liés aux mouvements de terrain en classe de quatrième ?
• Quelles sont les préférences des élèves dans un didacticiel à développer dans cette étude,
dont le but est de faciliter l’apprentissage des accidents liés aux mouvements de terrain
en classe de quatrième ?
• Quelle seront les impressions des élèves après l’utilisation du didacticiel développé pour
faciliter l’apprentissage des accidents liés aux mouvements de terrain en classe de
quatrième ?

1.4 Objectifs de l’étude

L’objectif général de note étude vise la mise sur pied d’un didacticiel devant permettre
d’améliorer les compétences des élèves de la classe de 4ème sur les risques des accidents en
zones montagneuses ou liés aux mouvements de terrain.
De par les différentes questions suscitées, cette étude vise spécifiquement à :

3
Chapitre 1. Introduction générale

• Analyser les difficultés rencontrées par les élèves dans l’apprentissage des accidents liés
aux mouvements de terrain en classe de quatrième en utilisant les méthodes
pédagogiques conventionnels ;
• Identifier les préférences des élèves dans un didacticiel à développer dans cette étude
pour faciliter l’apprentissage des accidents liés aux mouvements de terrain en classe de
quatrième ;
• Evaluer les impressions des élèves après l’utilisation du didacticiel développé pour
faciliter l’apprentissage des accidents liés aux mouvements de terrain en classe de
quatrième.

1.5 Importance de l’étude

Au vu des travaux antérieurs effectués au département sur la biologie, il été remarqué


un réel manque de travaux sur les notions en rapport avec les accidents en zones montagneuses.
Ce travail, de par son approche qui est celle de concevoir une application intégrant des
animations et des jeux pour expliquer ce mécanisme, vient ajouter un plus pour combler ce
manque. Il offrira donc ainsi aux élèves de la classe de quatrième ESG une variété d’images
animées, des exercices de compréhension et des jeux avec pour but de rendre l’apprentissage
de l’enfant ludique et plaisant.
Cette application est un outil accompagnant l’élève et l’enseignant dans leurs processus
respectifs d’apprentissage et d’enseignement. Les animations présentent dans cette application
décrivent de manière détaillée les mouvements de terrain produisant ainsi une sensation de réel
chez l’apprenant comme chez l’enseignant. Dans les établissements disposant de ressources
énergétiques et numériques suffisantes, cet outil est un appui pour l’enseignant dans la
présentation de son cours. L’apprenant peut ainsi mieux comprendre et mieux orienter ses
questions.

1.6 Délimitations du champ de l’étude

Géographiquement, notre étude est effectuée au Cameroun, dans la région du Centre, dans le
département du Mfoundi. Vu les difficultés financières, il a été choisi de mener l’étude dans
des établissements de la ville de Yaoundé, ville dans laquelle nous menons nos études
académiques. L’étude s’effectue dans quatre établissements de la Capitale dont le Collège

4
Chapitre 1. Introduction générale

François Xavier Vogt, le Collège Victor Hugo, le lycée de Nsam-Efoulan et le Collège


Adventiste d’Odza. Ces établissements ont été choisis grâce à leur proximité par rapport à notre
lieu de stage pratique. Notre étude porte sur le cours relatif aux risques en zones montagneuses
ou liés aux mouvements de terrain. Il s’agit ici d’une notion du programme de SVTEEHB en
classe de quatrième de l’enseignement général au Cameroun.

5
Chapitre 2. Revue de littérature

CHAPITRE 2 : REVUE DE LITTERATURE

2.1. Etude des travaux existants

2.1.1 Dans le monde et en Afrique

Yann Lhoste (2008), a travaillé sur la problématisation et l’apprentissage en sciences de la vie


et de la Terre. Son étude part du fait que la représentation la plus fréquente, aussi bien chez les
étudiants en sciences expérimentales que chez les enseignants, des SVT est qu’elles
correspondent à une somme de connaissances qui pourraient s’acquérir par l’expérience et
l’observation. Cette conception empiriste de l’activité scientifique se retrouve actuellement
dans les Instructions Officielles de l’enseignement des Sciences à l’école. Cette forte prégnance
de l’empirisme conduit à une forte survalorisation de l’expérimentation et de l’observation.

Pour Yann une approche rationaliste est la meilleure pour l’apprentissage des SVT. Il se base
sur les travaux de nombreux chercheurs tels que ceux de Bachelard (1972) et Popper (1934).
Par ailleurs à travers ses études sur les travaux de Martinand (1992) et Christian Orange (2000),
il montre qu’il existe une proximité forte entre explication et modélisation pour les SVT. Pour
Lhoste, l’enseignant doit se baser sur des modèles, des représentations, des animations pour
dispenser ses enseignements en Science de la Vie et de la Terre.

De nombreux logiciels utiles à l’apprentissage des SVT ont été développés à l’échelle
internationale. C’est le cas de “expehisto.exe” qui permet de comprendre les mécanismes de la
digestion à partir de l'étude des expériences historiques de Borelli, Réaumur, Spallanzani et
Beaumont. Aussi nous avons le logiciel TECTOGLOB, de Jean-François Madre, logiciel
destiné à choisir et à représenter (sur une carte ou en coupe) différents types de données
géologiques, à l'échelle du globe ou à l'échelle régionale, relatives à la tectonique des plaques.
Pour une meilleure maîtrise de l’anatomie humaine, “ users.skynet.be” est un Didacticiel
d'apprentissage de l'anatomie humaine à travers 6 planches interactives : le squelette, le crâne,
la peau, l'œil, l'appareil digestif et l'appareil respiratoire.

JP Gallerand, professeur au Collège T Vénard à Nantes, met sur pied 44.svt.free.fr qui est une
application web gratuite très complète avec de superbes animations et photographies à
télécharger. Ce logiciel comporte environ cinquante-uns logiciels téléchargeables ou en ligne.
On y retrouve des logiciels de simulation de germination, des expériences sur la nutrition des
plantes, de glissement de terrain et de simulation de séismes pour ne citer que ceux-là.

6
Chapitre 2. Revue de littérature

2.1.2 Au Cameroun

Au Cameroun, plusieurs étudiants en vue de l’obtention de leurs diplômes de fin de formation


ont travaillé sur des outils d’apprentissage, dans le but d’améliorer l’apprentissage des SVT.
Cependant, nous n’enregistrons pas encore de didacticiel portant sur les accidents liés aux
mouvements de terrain. Néanmoins, au Département d’informatique et de Technologies
Educatives (DITE) de l’Ecole Normale Supérieure de Yaoundé, quelques didacticiels utiles à
l’apprentissage des SVT au secondaire ont été mis sur pied à l’instar de DiARec qui est un
didacticiel d’apprentissage du relief du Cameroun en classe de 3e ESG développé conjointement
par CHEWO Stéphanie Josiane et WATI KOUMETIO Fabrice. Dans leurs travaux, ils partent
d’un problème qu’ont les élèves à identifier et représenter les différentes formes de relief au
Cameroun et proposent dont un outil qui est pour l’enseignant un outil didactique en plus et
pour l’élève un outil lui permettant d’améliorer ses connaissances. DiARec est un outil qui met
l’accent sur l’apprenant à travers ses nombreux jeux.

2.2 Les préférences des élèves dans un didacticiel

Les préférences peuvent être considérées comme les considérations que l’on accorde à
l’utilisation d’un outil. Chaptal en 1999 montre que les logiciels éducatifs apportent beaucoup
de bénéfice en termes d’efficacité éducative. Nous notons aussi que les élèves apprennent mieux
dans les cours où il y’a de l’enseignement assisté par ordinateur (EAO) et y mettent moins de
temps (Schacter, 1999). L’interactivité entre le didacticiel et l’élève provoque chez l’apprenant
de l’enthousiasme, la motivation et un esprit de créativité (Jule Laurent, 2002). La motivation
occupe une place prépondérante dans le processus d’apprentissage et l’ordinateur en plus
d’offrir des possibilités d’apprentissage, présente une réelle source d’envie et de motivation.
Les jeunes, en particulier, sont facilement absorbés par les outils informatiques. Des
chercheurs issus du mouvement cognitiviste explorent d’autres types de motivation qui
ne s’expliquent pas par des motivations extérieures même complexes comme le décrit
Bandura mais par des besoins intrinsèques aux individus. Harlow montre que les
individus ont un besoin intrinsèque de curiosité (ou d’exploration) et ce besoin est
diminué par le renforcement. Les élèves aiment des didacticiels où on retrouve des activités
qui ressemblent à des défis (Lepper, 2004), des activités qui stimulent ou des activités qui
procurent un sens de contrôle de son environnement. Il est donc ainsi important de prendre en
compte lors du développement d’un didacticiel les besoins des utilisateurs. Cet outil doit

7
Chapitre 2. Revue de littérature

répondre aux compétences et besoins spécifiques des élèves. Les apprenants aiment les couleurs
claires et qui ressortent. Apprendre en suivant un parcours personnalisé est un atout
car cela permet à l’apprenant de progresser à son rythme et selon ses besoins. Le but visé est
non seulement que l'élève apprenne de lui-même mais aussi de soutenir son intérêt (Steceff,
2012).

2.3 Méthodes ou modèles de développement logiciel

Comme pour toutes les fabrications, il est important d’avoir un processus bien défini et
documenté. Dans le cas du logiciel, il s’agit d’un type de fabrication un peu particulier, en un
seul exemplaire, car la production en série est triviale par simple recopie.

Les modèles de développement ou modèles de cycle de vie décrivent à un niveau très abstrait
les différentes manières d’organiser la production du logiciel. Les étapes, leur ordonnancement,
et parfois les critères pour passer d’une étape à une autre sont explicités : critères de terminaison
d’une étape, critères de choix de l’étape suivante, critères de démarrage d’une étape (Lonchamp,
2015). Dans le management de projet logiciel, nous distinguons deux grands types de
méthodes : les méthodes dites « classiques » et les méthodes « agiles ».

2.3.1 Les méthodes « classiques »

Les approches « classiques » de management de projet s’accordent sur l’hypothèse selon


laquelle les dépenses augmentent dramatiquement lorsque des rectifications sont effectuées
durant la phase d’implémentation. Dans cette perspective, les changements survenant après le
passage de la phase préliminaire du projet sont limités en vue de tenir les délais et respecter les
coûts préalablement fixés (Highsmith & Cockburn, 2001). Des contrats « rigides » sont élaborés
avec le client, précisant, de manière très fixe, le périmètre et le coût de la solution (Paetsch,
Eberlein & Maurer, 2003). L’accent est donc mis sur la phase de planification durant laquelle
se fait la définit ion de l’ensemble des besoins à implémenter. Le plan détaillé constitue le fil
conducteur, indispensable au projet. Beaucoup de temps et d’efforts sont ainsi consacrés pour
prévoir la totalité des demandes et réduire les changements éventuels (Sillitti, Ceschi, Russo &
Succi, 2005 ; Hilkka, Tuure & Matti, 2005). Nous pouvons classer les méthodes classiques en
deux groupes : les méthodes linéaires et les méthodes itératives et incrémentales.

2.3.1.1 Les méthodes linéaires

8
Chapitre 2. Revue de littérature

2.3.1.1.1 Le modèle en Cascade

Cette approche a été proposée en 1970 par Winston Royce. Chaque étape doit être terminée
avant que ne commence la suivante. À chaque étape, il y a production d’un « livrable »
(deliverable) qui sert de base pour l’étape suivante. La découverte d’une erreur entraîne le retour
à la phase à l’origine de l’erreur et une nouvelle cascade avec de nouveaux livrables. Les coûts
de correction des erreurs sont donc importants. Il faut si possible « tout bien faire » dès le début.
La résolution de beaucoup de facteurs de risque, comme le démarrage du codage ou
l’intégration des éléments de l’application (en un unique big bang), sont repoussés à la fin du
processus. Cette approche peut donc donner une fausse impression de progression. Les choix
en amont sont cruciaux, ce qui est typique d’une production industrielle. Les utilisateurs
interviennent en début de processus, pour définir les besoins, et en toute fin du processus pour
valider le système au regard des besoins exprimés au début (Lonchamp, 2015).

Figure 1 : Le modèle en cascade (Lonchamp, 2015)

Par contre, l’approche est simple à comprendre et à utiliser. Elle facilite l’organisation du travail
et des équipes dans les grands projets, en proposant des moments clés où des revues peuvent
prendre place. Elle simplifie la gestion du projet et l’assurance qualité. Cette approche est peu
adaptée si les besoins du client sont changeants ou difficiles à déterminer au départ (Lonchamp,
2015).

2.3.1.1.2 Le modèle en V

9
Chapitre 2. Revue de littérature

Le modèle en V met en évidence la complémentarité des phases menant à la réalisation et des


phases de test permettant de la valider. Les tests sont préparés tout au long des phases menant
à la réalisation et exécutés en fin de processus. Le modèle en V met clairement en évidence les
différents niveaux de test (unitaire, intégration, validation, acceptation). Les inconvénients sont
similaires à ceux évoqués pour la cascade. Les avantages reconnus sont de placer la vérification
et la validation au centre des préoccupations dès les premiers stades du développement et
d’imposer l’idée de livrable évaluable (Lonchamp, 2015).

Figure 2 : Le modèle en V (Lonchamp, 2015)

2.3.1.1 Les méthodes itératives et incrémentales

Dans ces approches le logiciel est développé en plusieurs itérations. Cela revient à répéter des
mini-processus de développement, plus ou moins complets. Chaque itération correspond au
raffinement d’un développement précédent ou à l’ajout d’un incrément supplémentaire (d’où
l’expression « itératif et incrémental »). Les avantages sont de permettre de développer en
premier les fonctions primordiales ou les plus risquées. Les clients peuvent réagir après chaque
itération. On peut aussi obtenir une meilleure motivation de l’équipe de développement qui voit
se concrétiser plus rapidement ses efforts. Les autres difficultés, comme la nécessité de
recueillir dès le départ et de figer les besoins, demeurent (Lonchamp, 2015).

10
Chapitre 2. Revue de littérature

2.3.1.1.1 Le modèle en spirale

Le modèle en spirale est parfois qualité de « méta procédé » car il peut inclure une activité de
choix du procédé de développement. Il met l’accent sur l’identification et la résolution des
risques. Chaque itération (ou cycle de la spirale) correspond à une séquence de quatre phases :

(1) La détermination des objectifs et des alternatives possibles pour les atteindre (comme
développer, réutiliser, acheter, sous-traiter, etc.) et des contraintes (temps, coûts). Ces analyses
se fondent sur les résultats des itérations précédentes ou initialement sur l’analyse préliminaire
des besoins.

(2) L’identification des risques et l’évaluation des alternatives pour les résoudre, par exemple
par du prototypage.

(3) Le développement et la vérification de la solution retenue, par un modèle de procédé à définir


(cascade, en V, etc.).

(4) La revue des résultats et la planification du cycle suivant. Ce type d’approche convient pour
de grands projets complexes, plutôt innovants et risqués.

Figure 3 : Le modèle en spirale (Lonchamp, 2015)

2.3.2 Les méthodes « agiles »

Appliquée au monde des logiciels, la notion d’agilité renvoie à la capacité d’adaptation des
sociétés informatiques aux demandes évolutives des clients, arrivant le plus souvent en cours
de projet et à une meilleure maîtrise du triptyque « coût/qualité/périmètre fonctionnel » (Khalil,

11
Chapitre 2. Revue de littérature

2011). Les approches agiles cherchent à alléger le cadre et à rester le plus possible focalisées
sur le code. Un objectif central est de répondre rapidement et de manière souple à tous les
changements qui peuvent apparaître à tout instant. Les approches agiles visent la simplicité, la
légèreté, l’auto-adaptation et l’autoorganisation. Contrairement aux approches prescriptives qui
définissent des ensembles de règles, les approches agiles sont plutôt à base de principes
(Lonchamp, 2015). Il existe plusieurs méthodes agiles. Nous en présenterons trois.

2.3.2.1 La méthode RUP

RUP (Rational Unified Process) définit un processus de développement relativement «


générique », qui peut être adapté à des contextes particuliers. Dans l’approche RUP, le
développement d’un logiciel passe par quatre phases, chacune pouvant donner lieu à une série
d’itérations : lancement (inception), élaboration, construction et transition. Chaque phase se
termine par un jalon d’évaluation et de prise de décision quant au passage à la phase suivante.
(Lonchamp, 2015).

Figure 4 : RUP, phases, itérations et disciplines (Lonchamp, 2015)

Inception (lancement) : C’est une phase très courte, avec souvent une seule itération. Elle
explicite la « vision » associée au projet en termes de faisabilité, de risques et de périmètre du
projet. (Lonchamp, 2015)

Elaboration : Cette phase comporte quelques itérations courtes et de durée fixe, pilotée par les
risques et centrée sur l’architecture. Elle comprend l’identification et la stabilisation de la

12
Chapitre 2. Revue de littérature

plupart des besoins, la spécification de la plupart des cas d’utilisation, la conception de


l’architecture de référence, du squelette du système à réaliser, la programmation et le test des
éléments d’architecture les plus importants, la réalisation et le test des cas d’utilisation critiques
et une estimation fiable du calendrier et des coûts de construction de l’application. (Lonchamp,
2015)

Construction : C’est la phase la plus longue (plus de 50 % du cycle de développement). La


construction se fait par incréments, avec une architecture stable malgré des changements
mineurs. À chaque incrément, le produit doit contenir tout ce qui avait été planifié. Par contre,
il peut éventuellement rester quelques erreurs non encore traitées. (Lonchamp, 2015)

Transition : Le produit est livré et il y a correction du reliquat d’erreurs. Le produit est essayé
et amélioré, les utilisateurs sont formés, l’assistance en ligne est élaborée. (Lonchamp, 2015).

2.3.2.2 La méthode XP

La méthode XP parue en 1999, dans un ouvrage intitulé « Extreme Programming Explained:


Embrace Change » qualifie un ensemble d’outils de coordination et de pratiques d’ingénierie
favorisant l’apprentissage, l’amélioration continue et l’adaptabilité des projets informatiques.
Cette méthode, itérative et incrémentale, revendique son nom au fait que les pratiques de
développement sont poussées à l’extrême (Khalil, 2011).

La méthode « extreme programming » revoie à un ensemble de principes et de pratiques allant


de la programmation à la collaboration en passant par l’organisation des équipes. Nous
présentons, dans la partie qui suit, les pratiques et principes tels qu’ils sont décrits dans
l’ouvrage de Kent Beck & Andres en 2004.

13
Chapitre 2. Revue de littérature

Figure 5 : Les pratiques XP (Khalil, 2011)

La méthode « XP », focalisée sur la partie programmation du projet, propose un modèle de


développement itératif avec une structure à deux niveaux : d’abord des itérations de livraison
puis des itérations de développement. Les premières consistent à livrer des fonctionnalités
complètes au client tandis que les secondes portent sur les scénarios qui contribuent à la
définition d’une fonctionnalité (Morley, 2006).

Figure 6 : Processus de développement XP (Khalil, 2011)..

14
Chapitre 2. Revue de littérature

2.3.2.3 La méthode scrum

Au sens initial du terme, « scrum » renvoie à une pratique généralement connue au rugby
signifiant la « mêlée ». Cette méthode qualifie un ensemble de rôles, d’instruments de gestion
et de pratiques managériales favorisant un environnement basé sur la transparence, l’inspection,
le suivi et l’adaptation (Khalil, 2011).

2.3.2.3.1 Les rôles dans scrum

Les responsabilités managériales sont réparties sur trois rôles : le « scrum-master », le «


product-owner » et l’équipe « scrum ».
Le scrum-master : Son rôle consiste à guider l’équipe dans la mise en œuvre de la méthode «
scrum » et à s’assurer qu’elle adhère aux valeurs, aux règles et pratiques soutenues par la
méthode.
Le product-owner : Il communique la vision du produit à l’équipe de développement et
détermine les fonctionnalités à développer en fixant la date de lancement du projet.
L’équipe scrum : elle a pour rôle de convertir les items du « product-backlog » en
fonctionnalités utilisables à la fin de chaque itération.

2.3.2.3.2 Les artéfacts « scrum »

La méthode scrum repose sur trois principaux artefacts : le carnet du produit « product backlog
», le carnet de l’itération « sprint-backlog » et le graphique de progression « burndown chart ».
Le product-backlog : cet outil représente un document listant les fonctionnalités du projet ou
du produit à développer.
Le sprint-backlog : il constitue le point de départ de chaque itération. Cet outil contient la liste
des tâches à réaliser dans la prochaine itération.

15
Chapitre 2. Revue de littérature

Figure 7 : La structure d'un sprint (Lonchamp, 2015)

Figure 8 : Le sprint backlog (Lonchamp, 2015)

Le burndown chart : c’est un graphe permettant de visualiser l’avancement des tâches au fil
du temps.

2.3.2.3.3 Les pratiques managériales « scrum »

Pre-sprint : c’est une réunion de planification de livrable permettant de discuter et répartir les
items du « product-backlog » sur les prochaines itérations. Durant cette réunion, à laquelle
participent les parties prenantes du projet, les coûts, le budget et la date de livraison du produit
sont estimés.
Sprint planning meeting : c’est une réunion, à double phase, organisée par le « Scrum Master
». Dans un premier temps, l’équipe « scrum » décide avec le « product-owner », de l’objectif
de l’itération et des « scénarios » à réaliser. Dans un deuxième temps, le « Scrum Master » et
l’équipe « scrum » se réunissent pour se focaliser sur la manière dont l’incrément sera

16
Chapitre 2. Revue de littérature

implémenté : les différentes tâches à réaliser sont ainsi identifiées, estimées et priorisées. La
granularité d'une tâche doit être d'environ un à deux jours de travail.
Daily scrum : la « mêlée » est une réunion quotidienne de quinze minutes où l’équipe « scrum
» se réunit, souvent, au même endroit et au même moment. Durant cette réunion, le « scrum-
master » pose trois questions à chaque membre de l’équipe : qu'est-ce que tu as fait hier ? Qu'est-
ce que tu vas faire aujourd'hui ? Et quelles difficultés as-tu rencontrées ?
Post-sprint meeting : à la fin de chaque itération, le travail de l’équipe est présenté devant le
« product-owner ». Cette réunion permet d’estimer le progrès du projet et sa conformité aux
critères d’acceptation définis par le « product-owner ».
Rétrospective-meeting : après la réunion « post-sprint », l’équipe « scrum » et le « Scrum
Master » se réunissent pour évaluer rétrospectivement le déroulement de l’itération : l’équipe
évoque ce qui s’est bien passé et ce qui s’est mal passé et avec le « scrum-master », ils identifient
les améliorations à faire dans les prochaines itérations.

Figure 9 : Les réunions (Lonchamp, 2015)

2.3.2.3.4 Le processus de développement « scrum »

Selon le Framework guide proposé par le guide SBOK en 2013, le processus Scrum se divise
en 5 phases : L’initiation, le plan et estimation, l’implémentation, la revue et rétrospection, le
lancement. Ces différentes phases sont présentées et résumées dans le tableau suivant :

17
Chapitre 2. Revue de littérature

Tableau 1 : Les phases et processus Scrum (Scrum Body Of Knowledge (SBOK guide), 2013)

PHASES PROCESSUS
Initiation 1. Création de la vision du projet
2. Identifier le scrum master et les parties
prenantes
3. Former l’équipe scrum
4. Développer les fonctionnalités
5. Créer le Backlog Product prioritaire
6. Conduire une planification de versions
Plan et estimation 7. Créer les Users Stories
8. Approuver, estimer les Users Stories
9. Créer les tâches
10. Estimer les tâches
11. Créer le Sprint Backlog
Implémentation 12. Créer les livrables
13. Conduire le standup quotidien
14. Améliorer le Product Backlog prioritaire
Revue et rétrospection 15. Programmer les réunions
16. Démontrer et Valider le sprint
17. Rétrospection du sprint
Lancement 18. Livrer les livrables
19. Rétrospection du projet

2.3.2.3.4.1 La phase d’initiation

La phase d’initiation a pour objectif de définir le cadre général du développement du projet.


Elle comporte 06 processus :
1. Création de la vision du projet : Dans ce processus, l'analyse de rentabilisation du projet
est examinée afin de créer un énoncé de vision du projet qui servira d'inspiration et de
centre d'intérêt pour l'ensemble du projet. Le propriétaire du produit est identifié dans
ce processus.
2. Identifier le scrum master et les parties prenantes : Dans ce processus, le Scrum Master
et les parties prenantes sont identifiés en utilisant des critères de sélection spécifiques.

18
Chapitre 2. Revue de littérature

3. Former l’équipe scrum : Dans ce processus, les membres Scrum Team sont identifiés.
Normalement, le Product Owner a la responsabilité principale de sélectionner les
membres de l'équipe, mais il le fait souvent en collaboration avec le Scrum Master.
4. Développer les fonctionnalités : Dans ce processus, l'énoncé de vision du projet sert de
base au développement des fonctionnalités. Des réunions de groupes d'utilisateurs
peuvent être organisées pour discuter des fonctionnalités appropriées.
5. Créer le Backlog Product priorisé : Dans ce processus, fonctionnalités sont affinées,
élaborées, puis hiérarchisées pour créer un Backlog produit prioritaire pour le projet.
Les critères définis sont également établis à ce stade.
6. Conduire une planification des versions : Dans ce processus, l'équipe Scrum passe en
revue les histoires d'utilisateurs dans le carnet de commandes prioritaires pour
développer un calendrier de planification des versions, qui est essentiellement un
calendrier de déploiement par étapes pouvant être partagé avec les parties prenantes du
projet. La longueur des sprints est aussi déterminée dans ce processus.

Figure 10 : Aperçu de la phase d'initiation (Scrum Body Of Knowledge (SBOK guide), 2013)

2.3.2.3.4.2 La phase d’estimation

7. Créer les Users Stories : Dans ce processus, les User Stories et leurs critères
d'acceptation d'user story sont créés. Les Users Stories sont généralement rédigées par
le propriétaire du produit et sont conçues pour garantir que les exigences du client sont

19
Chapitre 2. Revue de littérature

clairement représentées et peuvent être parfaitement comprises par toutes les parties
prenantes. Des ateliers de rédaction de Users Stories peuvent être organisés, impliquant
des membres de l'équipe Scrum qui créent les Users Stories. Les Users Stories sont
intégrées dans le carnet de commandes des produits prioritaires.
8. Approuver, estimer les Users Stories : Dans ce processus, le Product Owner approuve
les User Stories pour un Sprint. Ensuite, les Scrum Master et Scrum Team évaluent
l'effort requis pour développer les fonctionnalités décrites dans chaque User Story.
Enfin, l'équipe Scrum s'engage à répondre aux besoins des clients sous la forme de Users
Stories approuvées, estimées et validées.
9. Créer les tâches : Dans ce processus, les Users Stories approuvées, estimées et validées
sont réparties en tâches spécifiques et compilées dans une liste de tâches. Souvent, une
réunion de planification des tâches est organisée à cette fin.
10. Estimer les tâches : Dans ce processus, l'équipe Scrum, dans les réunions d'estimation
des tâches, estime les efforts nécessaires pour accomplir chaque tâche dans la liste des
tâches. Le résultat de ce processus est une liste de tâches estimée par l'effort.
11. Créer le Sprint Backlog : dans ce processus, l'équipe Scrum Core tient des réunions de
planification de sprint où le groupe crée un backlog Sprint contenant toutes les tâches à
effectuer dans le sprint.

Figure 11: Aperçu de la phase d'estimation (Scrum Body Of Knowledge (SBOK guide), 2013)
2.3.2.3.4.3 La phase d’implémentation

12. Créer les livrables : Dans ce processus, l'équipe Scrum travaille sur les tâches du Sprint
Backlog pour créer des livrables Sprint. Un Scrumboard est souvent utilisé pour suivre

20
Chapitre 2. Revue de littérature

le travail et les activités en cours. Les problèmes ou problèmes rencontrés par l'équipe
Scrum pourraient être mis à jour dans un journal d'empêchement.
13. Conduire le standup quotidien : Dans le cadre de ce processus, une réunion très ciblée
et chronologique est organisée chaque jour sous le nom de réunion quotidienne. C'est le
forum où l'équipe Scrum se tient mutuellement au courant de leurs progrès et des
obstacles auxquels ils peuvent être confrontés.
14. Améliorer le Product Backlog priorisé : Dans ce processus, le carnet de commandes
prioritaire de produits est continuellement mis à jour et maintenu. Une réunion d'examen
des arriérés de produits hiérarchisés par ordre de priorité peut être tenue, au cours de
laquelle les modifications ou les mises à jour de l'arriéré sont discutées et intégrées au
carnet de commandes des produits prioritaires, le cas échéant.

Figure 12: Aperçu de la phase d'implémentation (Scrum Body Of Knowledge (SBOK guide),
2013)

2.3.2.3.4.4 La phase de revue et de rétrospection

15. Programmer les réunions : Dans ce processus, les représentants de l'équipe Scrum
convoquent des réunions Scrum of Scrums (SoS) à intervalles prédéterminés ou chaque
fois que nécessaire pour collaborer et suivre leurs progrès, obstacles et dépendances
respectifs entre les équipes. Ceci n'est pertinent que pour les grands projets où plusieurs
équipes Scrum sont impliquées.
16. Démontrer et Valider le sprint : dans ce processus, l'équipe Scrum présente les livrables
de sprint au propriétaire du produit et aux parties prenantes concernées lors d'une
réunion d'examen de sprint. Le but de cette réunion est d'obtenir l'approbation et
l'acceptation du produit ou du service par le propriétaire du produit.

21
Chapitre 2. Revue de littérature

17. Rétrospection du sprint : Dans ce processus, l'équipe Scrum Master et Scrum se


rencontrent pour discuter des leçons apprises tout au long du Sprint. Cette information
est documentée en tant que leçons apprises qui peuvent être appliquées aux futures
Sprints. Souvent, à la suite de cette discussion, il peut y avoir des améliorations
convenues

Figure 13: Aperçu de la phase de revue et de rétrospection (Scrum Body Of Knowledge


(SBOK guide), 2013)

2.3.2.3.3.5 La phase de lancement

18. Livrer les livrables : Dans ce processus, les livrables acceptés sont livrés ou transférés
aux parties prenantes concernées. Un accord formel de livrables de travail documente
la réussite du Sprint.
19. Rétrospection du projet : Dans ce processus, qui complète le projet, les parties
prenantes organisationnelles et les membres Scrum Team se réunissent pour
reprospecter le projet et identifier, documenter et internaliser les leçons apprises.
Souvent, ces leçons conduisent à la documentation d'améliorations convenues, qui
seront mises en œuvre dans de futurs projets.

Figure 14: Aperçu de la phase de lancement (Scrum Body Of Knowledge (SBOK guide),
2013)

22
Chapitre 2. Revue de littérature

2.4 Conception ergonomique


Le mot ergonomie vient du grec ergon (travail) et nomos (lois, règles). L’Executive Council of
the Human Factors Society (Christensen 1988) stipule que « l’ergonomie est une des branches
de la science et de la technologie qui incorpore ce qui est connu et conceptualisé des
caractéristiques biologiques et comportementales de l’homme et qui peut être appliqué de façon
valide à la spécification, à la conception, à l’évaluation, à l’utilisation et à la maintenance des
produits et systèmes afin d’en assurer la sécurité, l’efficacité et l’usage satisfaisant par des
opérateurs individuels, des groupes et des organisations ».

Un logiciel dit ergonomique doit donc faciliter l’interaction entre l’homme et la machine. Dans
ce cas, ce logiciel doit répondre à un minimum de critères ergonomiques prévus avant de mettre
sur pied le logiciel. Ce qui permettra à la fin du développement de pouvoir évaluer l’ergonomie
de ce dernier.
Afin d’assurer une conception ergonomique de notre logiciel, nous vous présenterons dans la
suite de ce travail un ensemble de critères ergonomiques et une méthode d’évaluation
ergonomique de logiciel éducatif.

2.4.1 Les critères ergonomiques d’un logiciel

Le travail des chercheurs a abouti à une liste de dix-huit critères répartis en huit dimensions
(Scapin, et al. 1997) ; ils ont procédé empiriquement puis ils ont suivi une démarche itérative
de classification et d'accords interjuges. Nous nous proposons de présenter brièvement chacun
d’eux.

23
Chapitre 2. Revue de littérature

Figure 15 : Liste des critères ergonomiques (Bastien, 2006)

a) Le guidage
« Le guidage est l’ensemble des moyens mis en œuvre pour conseiller, orienter, informer, et
conduire l’utilisateur lors de ses interactions avec l’ordinateur (messages, alarmes, labels, etc.).
Quatre sous critères participent au guidage : le prompting, les groupements et distinctions entre
items, le feed-back immédiat et la clarté » (Bastien, 2006).
b) La charge de travail
« La charge de travail concerne l’ensemble des éléments de l’interface qui ont un rôle, pour
l’utilisateur, dans la réduction de sa charge perspective ou mnésique et dans l’augmentation de
l’efficacité du dialogue. Deux sous-critères participent à la charge de travail : la « brièveté »
qui englobe « concision » et « actions minimales », et « charge mentale » » (Bastien, 2006).
c) Le contrôle explicite
« Il se réfère à la fois au contrôle qu’a l’utilisateur sur l’interface ou le logiciel, et au caractère
explicite de ses actions » . Deux sous critères participent au contrôle explicite : les « actions
explicites » et le « contrôle utilisateur » (Bastien, 2006).

d) L’adaptabilité
« L’adaptabilité d’un système réfère à sa capacité à réagir selon le contexte, et selon les besoins
et préférences de l’utilisateur ». Deux sous-critères participent à l’adaptabilité : la « flexibilité »
et la « prise en compte de l’expérience utilisateur ». (Bastien, 2006).

24
Chapitre 2. Revue de littérature

e) La gestion des erreurs


« Elle concerne tous les moyens d’une part permettant d’éviter ou de réduire les erreurs, et
d’autre part de les corriger lorsqu’elles surviennent ». Trois sous critères participent à la gestion
des erreurs : la « protection contre les erreurs », la « qualité des messages », et la « correction
de erreurs ». (Bastien, 2006).
f) Homogénéité/consistance
« L’homogénéité réfère à la façon avec laquelle des choix d’objets de l’interface (code,
procédures, dénominations, etc.) sont conservés pour des contextes identiques, et des objets
différents pour des contextes différents » (Bastien, 2006).
g) Signification des codes
« La signification des codes se réfère à l’adéquation entre les objets ou l’information affichée
ou demandée, et son référent ». (Bastien, 2006).
h) Compatibilité
« La compatibilité réfère à l’accord pouvant exister entre les caractéristiques de l’utilisateur
(mémoire, perception, habitude, etc.) et l’organisation des sorties, des entrées et du dialogue »
(Bastien, 2006).

2.4.2 Les échelles d’utilisabilité

Les échelles d’utilisabilité sont des outils standardisés qui recueillent l’avis des utilisateurs sur
la facilité d’utilisation perçue d’un système et la satisfaction liée à l’interaction. Ce sont des
questionnaires d’évaluation subjective auto-administrés : les utilisateurs y répondent eux-
mêmes (Gronier et Lallemand, 2015).
Le principal intérêt des échelles de mesure de l’utilisabilité est leur format standardisé. Une
échelle standardisée est un questionnaire qui reprend un ensemble de questions prédéfinies,
toujours posées dans le même ordre, et qui dispose d’une grille de réponses et de cotations
identiques pour tous les répondants. Ainsi, les échelles standardisées peuvent être répliquées
afin de :
• Comparer plusieurs versions d’un même système, dans le cas d’un cycle de conception
itératif ;
• Comparer différents systèmes entre eux, si l’on souhaite par exemple positionner son
propre système par rapport à la concurrence ;
• Tester un système auprès de plusieurs catégories d’utilisateurs afin de différencier leur
opinion (séniors, juniors, hommes, femmes, statuts socioprofessionnels…).

25
Chapitre 2. Revue de littérature

Il existe plusieurs échelles de mesures. Nous en présenterons 2 : DEEP et SUS.


2.4.2.1 Le format DEEP

Le DEEP a été développé afin de pallier un défaut des principales autres échelles qui, selon les
auteurs, ne permettent pas de proposer des recommandations de conception en se limitant
uniquement à l’évaluation du système. Aussi, l’ambition du DEEP est-elle de mesurer :
• La manifestation de l’expérience de l’utilisateur, que les auteurs nomment le «
phénotype de l’utilisabilité » ;
• Ce qui est à l’origine du problème dans l’interface, appelé le « génotype de l’utilisabilité
».
L’échelle est ainsi constituée de dix-neuf items sous forme de phrases affirmatives, réparties en
six catégories.

2.4.2.2 Le format SUS

Le SUS (System Usability Scale) a été l’une des premières échelles de mesure de l’utilisabilité
perçue (en 1996). Elle est libre de droits et comporte un nombre restreint d’items faciles à
comprendre pour les utilisateurs. Le créateur du SUS, John Brooke, explique que cette échelle
a été créée avec soin en se basant sur les éléments de la norme ISO 9241-11 sur l’utilisabilité,
mais qu’elle se voulait quick and dirty pour les utilisateurs, c’est-à-dire rapide à remplir et facile
à comprendre (Brooke, 2013).
Le SUS comprend dix items présentés sous la forme affirmative, dont un sur deux est inversé.

26
Chapitre 2. Revue de littérature

Figure 16 : Traduction libre DEEP (Gronier et Lallemand, 2015)

Figure 17 : Traduction libre SUS (Gronier et Lallemand, 2015)

27
Chapitre 2. Revue de littérature

2.5 Choix des méthodes de travail

2.5.1 Choix de la méthode logicielle

La méthode d’ingénierie logicielle que nous avons choisie est Scrum car :
➢ Scrum permet de produire des versions constantes du produit
La méthode scrum offre la possibilité à l’équipe de développer un produit en plusieurs versions.
Ce qui permet de livrer le produit au fur et à mesure que le développement avance. Cette
méthode évite au développeur de terminer complétement le produit avant de le présenter au
Client. Celui-ci peut déjà utiliser le produit pendant que les autres fonctionnalités sont
développées. Nous notons ainsi un grand gain de temps. Cette méthode ne précise pas de
technique de réalisation précise. Elle laisse cet aspect à la discrétion de l’équipe. Cette ouverture
permet l’inclusion de pratiques provenant d’autres méthodes. Ainsi, lors de la réalisation d’un
sprint, nous nous proposons d’utiliser quelques pratiques de la méthode RUP car elle est
beaucoup plus centrée sur l’architecture à travers son architecture couche/vue utilisant les
diagrammes UML.
➢ Scrum permet de développer un produit satisfaisant les attentes du client.
Le modèle itératif et incrémental permet d’avoir une appréciation du client après chaque étape
du processus de développement, afin de diminuer les risques de changement des besoins.
- Chaque itération prend en compte un certain nombre de cas d’utilisation
- Les risques majeurs sont traités en priorité
- Chaque itération donne lieu à un incrément et produit une nouvelle version exécutable.
- Différentes réunions sont faites au début, pendant et après un sprint pour vérifier si les
besoins du client sont respectés.

2.5.2 Choix de l’échelle d’utilisabilité

Au regard des différents critères cités plus haut, nous nous proposons d’utiliser l’échelle de
SUS dans le cadre des tests d’expérience utilisateur à la fin du développement de notre
application. Nous choisissons cette échelle car elle est libre de droit et donne un nombre d’items
restreints faciles à comprendre pour l’utilisateur. (Brooke, 2013).

28
Chapitre 3. Méthodes et matériels

CHAPITRE 3 : METHODES ET MATERIELS

Dans ce chapitre, une présentation sera faite tout d’abord sur les différentes méthodes
d’enquêtes, d’analyse et de développement logiciel que nous allons utiliser durant notre travail.
Enfin nous présenterons les matériels utilisés pour mettre en application ces méthodes.

3.1 Les méthodes

3.1.1 Les méthodes de recherche

Tout travail de mémoire est constitué de recherches. Et celles-ci peuvent se présenter sous des
études de différentes formes, ceci en fonction des questions de recherches posées et des
objectifs cherchés.

Dans le cadre de notre recherche, nous avons opté pour deux formes de méthodes de recherche
à savoir la méthode de recherche quantitative et la méthode de recherche qualitative. Nous
expliquerons brièvement ces deux méthodes dans les parties suivantes.

3.1.1.1 La méthode de recherche quantitative

La méthode de recherche quantitative décrit un processus de collecte et d’analyse de données


basé sur des larges effectifs (Samuel, 2017). Elle permet de prouver ou démontrer des faits. Les
résultats d’études quantitatives sont souvent exprimés en chiffres (statistiques canada). Les
données recueillies peuvent être utilisées pour créer des graphiques ou des tableaux. Les
caractéristiques suivantes décrivent généralement les études quantitatives.
• Les données sont collectées en utilisant des techniques standardisées ;
• On recherche des corrélations et des relations causales entre les variables ;
• Les données et les analyses sont utilisées pour tester si les hypothèses sont correctes.

Dans notre étude cette méthode a été utilisée lors de la recherche d’informations auprès des
élèves.

3.1.1.2 La méthode de recherche qualitative


La recherche qualitative est plus descriptive et se concentre sur des interprétations, des
expériences et leur signification. Les résultats d’études qualitatives sont généralement exprimés

29
Chapitre 3. Méthodes et matériels

avec des mots. La recherche qualitative ne cherche pas à quantifier ou à mesurer, elle concise
le plus souvent à recueillir les données verbales permettant une démarche interprétative. Cette
méthode permet aussi d’explorer les émotions, les sentiments des patients, ainsi que leurs
comportements et leurs expériences personnelles. Elle peut contribuer à une meilleure
compréhension du fonctionnement des sujets et des interactions entre eux (Aubin-Auger, et al.,
2008).

Dans notre étude, cette méthode a été utilisée lors de la recherche d’informations auprès des
enseignants.

Le tableau 1 effectue une comparaison des caractéristiques des deux méthodes.


Tableau 2 : Caractéristiques de l'analyse qualitative et quantitative (Lee, 2014)

Analyse quantitative Analyse qualitative


Type de connaissance Subjectif Objectif
Objectif Exploratoire et observationnel Généralisable et testé
Caractéristiques Flexible Fixé et contrôlé
Portrait contextuel Vari ables indépendantes et
dépendantes
Vue dynamique et continue du Pré et post mesure du
changement changement
Echantillonnage Déterminé Au hasard
Collecte de données Semi structuré ou non structuré Structuré
Nature des données Narratives, citations, descriptions Numéros, statistiques
Valeur unicité, particularité Réplication
Analyse Thématique Statistique

3.1.2 La population cible et la population d’enquête

Les éléments suivants sont essentiels à la définition de la population cible et aux définitions
opérationnelles en général :
➢ Le genre d’unités que comprend la population et caractéristiques particulières de ces
unités (qui ou quoi ?),
➢ La localisation des unités (où ?),

30
Chapitre 3. Méthodes et matériels

➢ La période de référence considérée (quand ?).


La population d’enquête est en fait la population que couvre l’enquête. Elle peut être différente
de la population cible, mais idéalement, les deux devraient être très semblables. Il est important
de souligner que les conclusions tirées des résultats de l’enquête s’appliquent seulement à la
population de l’enquête (Statistique Canada, 2003).

Notre population cible représente tous les élèves de la classe de 4e de l’enseignement secondaire
général au Cameroun au 1er Janvier 2018.

Notre population d’enquête est constituée de 180 élèves de la classe de 4e dans les
établissements de Yaoundé suivants : Lycée de Nsam Efoulan, le Collège François Xavier
Vogt, le collège Victor Hugo et le Collège Adventiste d’Odza.

3.1.3 Les techniques d’échantillonnage

L’échantillonnage est « un moyen de sélectionner un sous-ensemble d’unités dans une


population aux fins de la collecte de l’information sur ces unités pour formuler des inférences
sur l’ensemble de la population » (Statistique Canada, 2003). L’échantillonnage décrit ainsi la
manière avec laquelle la population d’enquête sera sélectionnée. Il existe deux grandes formes
d’échantillonnages : l’échantillonnage probabiliste et l’échantillonnage non probabiliste.
L’échantillonnage probabiliste, qui est la plus complexe, permet la sélection d’unités dans une
population selon le principe du hasard. L’échantillonnage non probabiliste quant à elle se base
sur des méthodes subjectives c’est-à-dire non aléatoires.

Dans notre travail nous allons utiliser l’échantillonnage aléatoire simple et l’échantillonnage à
choix raisonné, présentés dans la suite du document.

3.1.3.1 L’échantillonnage aléatoire simple

L’échantillonnage aléatoire simple est « une forme d’échantillonnage probabiliste. Ici chaque
individu est perçu avec la même probabilité de faire partie de l’échantillon » (Statistique
Canada, 2003).
Comparée à d’autres méthodes probabilistes, elle présente les avantages suivants :
- C’est la technique d’échantillonnage la plus simple (Statistique Canada, 2003) .
- Il n’est pas nécessaire d’avoir des informations supplémentaires dans la base de sondage
pour tirer l’échantillon (Statistique Canada, 2003).

31
Chapitre 3. Méthodes et matériels

- L’élaboration technique n’est pas nécessaire (Statistique Canada, 2003).

Cette méthode a été utilisée dans le cadre du recueil des difficultés et des préférences auprès
des élèves.
3.1.3.2 L’échantillonnage par choix raisonné

« L’échantillonnage à choix raisonné, encore appelé échantillonnage par quotas.


L’échantillonnage est fait jusqu’à ce qu’un nombre déterminé d’unités (quotas) soient
sélectionnées dans diverses sous-populations. L’échantillonnage par quotas est un moyen
d’atteindre les objectifs de taille d’échantillon pour les sous populations » (Statistique Canada,
2003).

Cet échantillonnage a été effectué dans le cadre d’administration des interviews aux enseignants
de SVT.

3.1.4 Les techniques de collecte de données

La collecte des données est « le processus qui permet d’obtenir l’information nécessaire pour
chaque unité sélectionnée de l’enquête. Pendant la collecte des données, les intervenants de
l’enquête déterminent où sont les membres de la population, c’est-à-dire des particuliers ou des
organismes, ils communiquent avec eux et leur demandent de participer à l’enquête. »
(Statistique Canada, 2003). Nous pouvons classer les techniques de collecte de données en trois
catégories : l’auto dénombrement (questionnaire), les interviews sur place et les interviews
téléphoniques.

Dans notre travail nous avons uniquement utilisé les questionnaires et l’interview sur place.

3.1.4.1 L’auto dénombrement (questionnaire)

Les méthodes d’enquête par auto dénombrement exigent un questionnaire très bien structuré,
facile à suivre et donnant des instructions claires au répondant. Il peut y avoir un numéro de
téléphone pour obtenir de l’aide, afin de remplir le questionnaire. Celui-ci a habituellement une
présentation visuelle plus élaborée qu’un questionnaire assisté par intervieweur et ce, pour
susciter la participation du répondant » (Statistique Canada, 2003). Le questionnaire a été
administré aux élèves de l’enquête. Il est constitué au départ de 19 items relatifs aux questions
de recherche pour pouvoir déterminer :
➢ Les difficultés des apprenants dans les risques liés aux mouvements de terrain

32
Chapitre 3. Méthodes et matériels

➢ Les préférences des élèves dans un didacticiel pour l’apprentissage des accidents liés
aux mouvements de terrain.
Pour valider ce questionnaire, il a été soumis aux élèves du Collège Vogt. Et un enseignant de
SVT a aussi passé ce test pour l’occasion.
Il est important de marquer que ledit questionnaire a été élaboré non seulement suivant les
questions de recherches mais aussi selon l’échelle de Likert pour exprimer les niveaux de
réponse. Nous avons donc ainsi les alternatives : pas du tout d’accord, pas d’accord, neutre,
d’accord, très d’accord.
A la suite de l’analyse de ce premier test, nous avons décidé de le maintenir et de l’administrer
au reste de la population choisie.

3.1.4.2 L’interview sur place (entretien)

L’interview sur place se déroule en présence du répondant. Celle-ci est habituellement faite à
la résidence de la personne ou en milieu de travail. (Statistique Canada, 2003). Statistique
canada ajoute toujours en 2003 que c’est la seule méthode réaliste de collecte des données pour
certaines populations cibles, par exemple, lorsque l’interview téléphonique est impossible ou
que l’enquête exige une visite pour échantillonner ou repérer des membres de la population.
L’interview a été effectué sur 04 enseignants de SVT ou qui ont été en charge de la classe de
4e.
3.1.4.3 Administration de l’instrument ou procédure expérimentale

L’administration des différents instruments est passée tout d’abord par l’acquisition auprès du
département de l’autorisation d’enquête pour effectuer notre recherche. L’étape suivante a été
l’acquisition des emplois de temps dans différents établissements de la capitale afin d’établir
un planning de passage pour administrer les instruments. Après avoir établi un planning de
passage, il a été question de se rendre dans les différents établissements les jours choisis pour
rencontrer les élèves et les professeurs.
En ce qui concerne les questionnaires pour les enfants, ils se remplissaient en présence de
l’administrateur qui s’assurait que chaque élève puisse répondre de façon efficace à chaque
question.

Pour les entretiens, ils se sont effectués avec les enseignants dans leurs bureaux pour certains
ou dans la salle des professeurs de l’établissement pour d’autres.

33
Chapitre 3. Méthodes et matériels

3.1.5 Plan d’application de la méthode scrum

Notre plan d’application de la méthode Scrum est divisé en 5 étapes étroitement liées aux 5
phases de Scrum vues dans le chapitre 2 à savoir : l’analyse, la conception, l’implémentation,
les tests et la production.

3.1.5.1 La phase d’analyse

Dans cette étape il s’agissait pour nous de présenter le travail préalablement fait avant la
conception de l’application. Pour ce faire, notre analyse comprend les étapes suivantes :

➢ La présentation de la vision du projet.


➢ L’identification du scrum master, du Product Owner, et des parties prenantes
➢ La formation de l’équipe scrum
➢ La présentation des besoins
➢ L’élaboration du Backlog du produit
➢ L’élaboration de diagramme de cas d’utilisation global
➢ Pour chaque sprint, la présentation du diagramme de cas d’utilisation spécifique ainsi
que la description textuelle de quelques cas d’utilisation
L’étape d’analyse ainsi terminée nous passons à l’étape de conception.

3.1.5.2 La phase de conception

L’étape de conception consiste à préparer tous les outils d’architecture de l’application. Notre
phase de conception comprend les étapes suivantes :

➢ La planification des sprints


➢ La présentation de la navigation du système
➢ La présentation du déploiement de l’application
➢ Le prototypage des interfaces ou maquettage
➢ Pour chaque sprint, le backlog du sprint et les diagrammes de séquences de quelques
cas d’utilisation liés au sprint.

L’étape de conception terminée, nous passons à l’implémentation.

34
Chapitre 3. Méthodes et matériels

3.1.5.3 La phase d’implémentation

La phase d’implémentation se traduit par la phase de réalisation proprement dite des différents
modules de l’application. Ainsi elle est liée à chaque sprint.
Pour cela, pour chaque sprint, nous allons présenter le burndown Chart à la fin du temps idéal
ainsi que quelques captures d’écran obtenues à la fin de la réalisation.

L’implémentation ainsi terminée, il faut passer à la revue et la rétrospection des sprints c’est-
à-dire en réalité les tests.

3.1.5.4 La phase de tests

Cette phase consiste à vérifier si les critères d’acceptabilités ont été respectés à la fin du
développement. Pour ce faire nous présenterons le scénario de test de chaque sprint avec le
résultat obtenu.

Cette étape faite, il est donc question de déployer l’application en environnement réelle.

3.1.5.5 La phase de production

Dans cette phase, il est question pour nous de recueillir auprès des utilisateurs finaux leurs
impressions sur l’utilisation du logiciel. Pour ce faire, nous présenterons les résultats obtenus
après le test d’utilisabilité de l’application

3.2 Matériels

3.2.1 Matériels d’enquête

Dans le cadre de notre enquête nous avons utilisé le logiciel Microsoft Excel pour l’analyse des
données recueillies et la production des tableaux et graphes.

3.2.2 Matériels de développement

3.2.2.1 Langages de développement


L’application à développer est une application web. De ce fait, quelques langages du Web
seront utilisés tels que :

35
Chapitre 3. Méthodes et matériels

➢ Le langage HTML (Hyper Text Markup Language) : utilisé pour décrire les différentes
vues
➢ Le langage CSS (Cascading Style sheets) : utilisé pour l’embellissement et la mise en
forme de nos pages
➢ Le langage Javascript : utilisé pour l’interactivité et le dynamisme des pages.
➢ Le langage Actionscript 3 : utilisé pour la réalisation des animations.

3.2.2.2 Frameworks utilisés


Nous allons utiliser comme Framework les Framework suivants :
- Framework JQuery : qui est une librairie javascript.
- Framework Bootstrap : qui est utilisé pour faciliter l’utilisation du CSS

3.2.2.3 Environnement de travail


Nous avons en plus utilisé en plus :
➢ Sublimetext, pour le développement de l’application nous allons utiliser
➢ Google chrome, pour voir les aperçus.
➢ Adobe Photoshop, pour les maquettes, logo, images, nous allons utiliser le logiciel.
➢ Adobe Flash/animate cc 2017, pour la réalisation de nos animations.
➢ Microsoft Word, pour la saisie du document.
➢ SonyVégas pro 64 pour l’édition des vidéos
➢ StarUML, pour la réalisation des diagrammes UML
➢ Rquiz qui est une librarie Javascript pour la réalisation des mots croisés et d’autres
exercices.
➢ Balsamiq pour réaliser nos maquettes d’interface.

36
Chapitre 4. Résultats

CHAPITRE 4 : RESULTATS

Dans cette section, il sera question de présenter tout d’abord les résultats obtenus à la suite de
notre enquête, ensuite les résultats obtenus aux différentes phases de la méthode scrum.

4.1 Résultats d’enquête

4.1.1 Population d’enquête

Notre population d’enquête est constituée de 180 élèves répartis sur 4 établissements de la
ville de Yaoundé à savoir :
- Le collège Victor Hugo (20 élèves)
- Le collège François Xavier Vogt (40 élèves)
- Le lycée de Nsam-Efoulan (70 élèves)
- Le Collège Adventiste d’Odza (50 élèves)
Les statistiques liés à l’Age et au sexe sont inclus dans le tableau qui suit.
Le tableau 3 montre les statistiques des âges de la population d’enquête
Tableau 3: Statistiques des âges de la population

Age Filles Garçons Total


[11 – 12] 29 13 42
[13 – 15] 63 68 131
[16 – ] 4 3 7
Total 96 84 180

37
Chapitre 4. Résultats

Taux de représentation des âges


[16 – ]
4% [11 – 12]
23%

[13 – 15]
73%

[11 – 12] [13 – 15] [16 – ]

Figure 18: Taux de représentativité des âges

Taux de représentaton des sexes


1,2 80
70
1
60

Pourcentage
0,8
50
0,6 40
30
0,4
20
0,2
10
0 0
[11 – 12] [13 – 15] [16 – ]
Ages

Garçons Filles Colonne1

Figure 19: taux de représentativité des sexes

4.1.2 Le questionnaire des élèves

Le questionnaire élaboré sera retrouvé en annexe 1 à la fin du document. Toutefois, le tableau


suivant présente les statistiques recueillis.

Tableau 4: Statistiques du questionnaire

Items Pas du Pas Très


tout D’accord Neutre D’accord d’accord
d’accord

38
Chapitre 4. Résultats

1. Le cours est très long 128 16 2 10 8


2. Les leçons sont difficiles à 41 10 4 23 132
comprendre
3. Les schémas sont complexes 38 18 16 25 83
à interpréter
4. Les photos ne sont pas 9 13 18 43 82
souvent claires et
compréhensibles
5. Le vocabulaire utilisé dans 80 26 49 15 10
les leçons est difficile
6. Je n’arrive pas à faire de lien 22 19 13 37 92
entre les différentes parties
du cours
7. Je n’étudie pas assez 37 58 63 6 28
8. Je ne rencontre pas beaucoup 5 11 19 32 113
les notions que j’apprends
dans la vie courante
9. J’ai des difficultés à identifier 39 27 36 11 91
les déformations des couches
de terrain et leurs causes
10. J’ai des difficultés à me 8 12 15 26 109
représenter les phénomènes
de mouvement de terrain tels
que les glissements, les
effondrements, les coulées
boueuses, le retrait-
gonflement.
11. Je suis incapable d’identifier 38 80 3 38 20
des techniques de prévention
et de protection des accidents
liés aux mouvements de
terrain
12. J’ai des difficultés à choisir 6 19 34 56 65
des sites favorables aux
constructions de maison
13. Apprendre avec un logiciel 4 3 15 41 132
m’aidera davantage à
comprendre des phénomènes
liés aux mouvements de
terrain
14. Je préfère beaucoup plus 36 17 83 30 44
d’activités pratiques dans les
cours
15. Je préfère apprendre en 7 4 18 12 139
jouant
16. Je préfère des couleurs claires 17 22 23 42 76
17. Je préfère utiliser des cours 13 25 23 33 86
audio/vidéos

39
Chapitre 4. Résultats

18. Je préfère utiliser plus 30 41 35 17 57


d’images
19. Je préfère des résumés de 108 72 10 27 13
cours

Nous allons à présent ressortir des graphes représentatifs de quelques items de notre tableau
de statistique.
➢ J’ai des difficultés à me représenter les phénomènes de mouvement de terrain tels que
les glissements, les effondrements, les coulées boueuses, le retrait-gonflement

Le tableau 5 présente les statistiques obtenus à l’item 10.


Tableau 5: Statistiques item 10

Item 10 Pas du tout Pas Très


D’accord Neutre D’accord
d’accord d’accord
Stats 8 12 15 26 109
Taux 5% 7% 9% 15% 64%

Diffficultés à se representer les phénomènes liés aux


mouvements de terrain
Pas du tout
Pas d'accord
d'accord
7%
5% Neutre
9%
D'accord
Très d'accord
15%
64%

Pas du tout d'accord Pas d'accord Neutre D'accord Très d'accord

Figure 20: Diagramme de représentativité item 10


➢ J’ai des difficultés à choisir des sites favorables aux constructions de maison
Le tableau 6 présente les statistiques obtenus à l’item 12.

Tableau 6: Statistiques item 12

Item 12 Pas du tout Pas Très


d’accord D’accord Neutre D’accord d’accord
Stats 6 19 34 27 94

40
Chapitre 4. Résultats

Taux 3% 11% 19% 15% 52%

Diffficultés à choisir des sites favorables aux constructions


Pas du tout
Pas d'accord
d'accord
11%
3%
Neutre
Très d'accord
19%
52%
D'accord
15%

Pas du tout d'accord Pas d'accord Neutre D'accord Très d'accord

Figure 21: Diagramme de représentativité item 12

➢ Je préfère apprendre en jouant

Le tableau 7 présente les statistiques obtenus à l’item 15.

Tableau 7: Statistiques item 15

Item 15 Pas du tout Pas Très


D’accord Neutre D’accord
d’accord d’accord
Stats 7 4 18 12 139
Taux 5% 10% 12% 8% 65%

41
Chapitre 4. Résultats

Je préfère apprendre en jouant


Pas du tout
d'accord Pas d'accord
5% 10%
Neutre
12%
Très d'accord D'accord
65% 8%

Pas du tout d'accord Pas d'accord Neutre D'accord Très d'accord

Figure 22 : Diagramme de représentativité item 15

➢ Je préfère des couleurs claires


Le tableau 8 présente les statistiques obtenus à l’item 16.

Tableau 8: Statistiques item 16

Item 16 Pas du tout Pas Très


D’accord Neutre D’accord
d’accord d’accord
Stats 17 22 23 42 76
Taux 7% 5% 10% 18% 60%

Je préfère des couleurs claires


Pas du tout Pas d'accord
d'accord 5%
7% Neutre
10%
Très d'accord
D'accord
60%
18%

Pas du tout d'accord Pas d'accord Neutre D'accord Très d'accord

Figure 23: Diagramme de représentativité item 16

42
Chapitre 4. Résultats

4.1.3 L’entretien des enseignants

La fiche d’entretien est trouvée en annexe 2 du document. Les résultats tirés des entretiens avec
les enseignants ont permis de tirer les énoncés suivants :

➢ Le programme de SVT est très long et par conséquent la leçon qui se trouve à la fin du
programme n’est pas souvent bien faite.
➢ Le livre au programme n’est pas assez imagé pour pouvoir faciliter la compréhension
de la leçon.
➢ Les effectifs sont grands, ce qui entraine parfois un négligemment de certaines
explications supplémentaires.
➢ Il est préférable de montrer à l’enfant un réel mouvement de terrain que de l’expliquer
avec de simples mots
➢ Les enfants préfèrent jouer et manipuler l’ordinateur. Implémenter un jeu et un logiciel
les aiderait davantage
➢ Il faut mettre beaucoup plus d’accent sur les simulations des mouvements de terrain et
leurs techniques de prévention.
➢ Il faut diversifier les jeux et les exercices pour que l’enfant ne reste pas dans une routine.

4.2 Résultats de la méthodologie logicielle

4.2.1 La phase d’analyse

4.2.1.1 Création de la vision du projet

Le projet consiste à concevoir et à mettre sur pied un didacticiel portant sur l’apprentissage des
techniques de prévention des accidents en zone montagneuse ou liés aux mouvements de
terrain, notion apprise en classe de 4e de l’enseignement général au Cameroun.
Tout au long du processus le Product Owner est ici notre binôme en charge de l’analyse
pédagogique du projet.

4.2.1.2 Identification du scrum master et des parties prenantes

Le scrum Master ici est moi-même et, les enseignants des SVT, les élèves de la classe de 4e
ainsi que notre encadreur constituent ici les parties prenantes.

43
Chapitre 4. Résultats

4.2.1.3 Former l’équipe scrum

L’équipe scrum dans notre cas est représenté uniquement par celui qui est chargé de développer
l’application.

Tableau 9 : Liste des membres du projet

Noms et prénoms Rôles


GWETH LIONEL FITZGERALD Scrum Master et membre de la scrum team
NKOMIDIO ANITA FRANÇOISE Product Owner
Dr NWENTI N. MICHAEL Stakeholder
Anonyme Membre de la ScrumTeam

4.2.1.4 Développer les besoins

Les acteurs
Un acteur représente une entité externe qui interagit avec le système. Dans notre cas, nous
n’avons qu’un seul acteur et il s’agit de l’élève.

Les besoins fonctionnels


Les besoins fonctionnels explicitent les besoins du client. Dans notre cas, les besoins fournis
par le Product Owner sont représentés dans le tableau suivant :

Tableau 10: Les besoins fonctionnels

Objectifs Besoins fonctionnels


Module Rappels - Lire les objectifs visés par les notions présentées
- Tester ses prérequis
- Consulter les rappels
Module - Lire les vidéos sur les accidents liés aux mouvements de terrain ;
J’apprends - Lire les vidéos sur les techniques de prévention contre les
accidents liés aux mouvements de terrain :
- S’exercer sur les différents mouvements de terrain ;
- Lire les notes à retenir sur les différents mouvements de terrain ;
- Consulter le résumé
- Consulter le glossaire

44
Chapitre 4. Résultats

- Consulter l’aide
Module - Effectuer les Quizz
Exercices - Effectuer les Matching
- Effectuer des questions à trou
Module Jeux - Jouer au pendu
- Jouer au mot caché
- Jouer au Millionnaire

Les personas
Les personas sont des personnages fictifs très détaillés, représentatifs de la majorité des
utilisateurs et des autres parties prenantes qui n'utilisent pas directement le produit final. Les
personas sont créées pour identifier les besoins de la base d'utilisateurs cible. La création de
personas spécifiques peut aider l'équipe à mieux comprendre les utilisateurs, leurs exigences et
leurs objectifs. Basé sur un Persona, le Product Owner peut prioriser plus efficacement les
fonctionnalités pour créer le Backlog du produit priorisé.

La description de notre persona est :

Bob est âgé de 14 ans et réside à Bova à Buea près du Mont Cameroun. Situé dans une zone à
risque, il aimerait plus apprendre sur les risques auxquels il fait face chaque jour ainsi que les
techniques qu’il pourrait utiliser pour y faire face. Bob est lassé des cours théoriques statiques
et sans images.

Les besoins non fonctionnels


Il s’agit des contraintes techniques exigées et les fonctionnalités nécessaires pour rendre le
logiciel plus performant. Nous relevons les besoins suivants auprès du Product Owner :
➢ Ergonomie : Les interfaces conviviales et faciles à utiliser.
➢ Fiabilité : Fonctionnement de l’application correct et sans bugs.
➢ Extensibilité : l’application doit faciliter l’ajout de nouvelles fonctionnalités.
➢ Portabilité : l’application doit être exécutable sur tous les systèmes pour PC
➢ Déploiement : l’application doit être déployée par simple copie.
➢ Technologie : l’application doit être une application web.

45
Chapitre 4. Résultats

4.2.1.5 Créer le Back log du produit

Le backlog représente l’ensemble des caractéristiques fonctionnelles ou techniques qui


constituent le produit souhaité (QUENEC'HDU, Jan 2013).
Le tableau suivant présente le tableau de notre produit :
➢ ID : qui représente l’identifiant de la user story
➢ Module : qui représente le module concerné
➢ User Story : comporte la description du besoin sous la forme « en tant que …… je
souhaite …… »
➢ Priorité : représente l’ordre de priorité
➢ Effort : représente la complexité d’implémentation du besoin

Tableau 11: Backlog du produit

ID Module User Story Priorité Effort


1 Rappels En tant que Bob je veux lire les objectifs 1 2
2 Rappels En tant que Bob je veux tester mes prérequis 2 4
3 Rappels En tant que Bob je veux lire les rappels 2 2
4 J’apprends En tant que Bob je veux lire les vidéos sur les 3 60
accidents
5 J’apprends En tant que Bob je veux lire les vidéos sur les 4 12
techniques de prévention
6 J’apprends En tant que Bob je veux lire chaque note à 5 10
retenir sur les risques liés aux accidents
7 J’apprends En tant que Bob je veux lire le résumé global 6 2
8 J’apprends En tant que Bob je veux lire le glossaire 7 3
9 J’apprends En tant que Bob je veux consulter l’aide 7 2
10 J’apprends En tant que Bob je veux m’exercer sur chaque 5 20
accident
11 Exercices En tant que Bob je veux traiter les Quizz 8 5
12 Exercices En tant que Bob je veux traiter les Matching 8 5
13 Exercices En tant que Bob je veux traiter les questions à 8 5
trou
14 Jeux En tant que Bob je veux jouer au pendu 9 8

46
Chapitre 4. Résultats

15 Jeux En tant que Bob je veux jouer au mot caché 9 8


16 Jeux Jouer au millionnaire 9 8

4.2.1.6 Diagrammes des cas d’utilisation global

Nous présenterons dans la figure suivante une vue globale concernant le comportement
fonctionnel du système en faisant ressortir les différents acteurs.

La figure 24 présente le diagramme de cas d’utilisation global du système

Figure 24 : Diagramme de cas d'utilisation global

4.2.1.7 Analyse du sprint 1

Diagramme de cas d’utilisation du sprint

La figure 25 montre le diagramme d’utilisation du sprint 1 pour nous permettre de représenter


les fonctionnalités concernées tout au long de notre premier sprint.

47
Chapitre 4. Résultats

Figure 25 : Diagramme de cas d'utilisation du sprint 1

Description textuelle des cas d’utilisation

• Description textuelle du cas d’utilisation « consulter les objectifs »


Le tableau ci-dessous montre le cas d’utilisation du cas « consulter les objectifs »
Tableau 12: Description du cas d'utilisation "consulter les objectifs"

Titre Consulter les objectifs


Acteur principal Elève
Résumé Lire les objectifs et les compétences visées
par les notions enseignées
Précondition Lancer l’application
Scénario Nominal - Ouvrir l’application
- Cliquer sur le bouton objectif
- Lire les objectifs
Postcondition Objectifs lus

• Description textuelle du cas d’utilisation « tester les prérequis »


Le tableau 15 montre le cas d’utilisation du cas « tester les prérequis »

48
Chapitre 4. Résultats

Tableau 15 : Description du cas d'utilisation "tester les prérequis"

Titre Tester les prérequis


Acteur principal Elève
Résumé Evaluer les prérequis de l’élève
Précondition Application lancée
Scénario Nominal 1. Ouvrir l’application
2. L’élève clique sur le bouton tester les prérequis
3. Le système lance les questions
4. L’élève clique répond aux questions
5. Le système valide ses prérequis
6. Le système déverrouille le bouton « j’apprends »
Postcondition Bouton « j’apprends » est déverrouillé
Scénario nominal 4.1 Le client rate une question
5.1 Le système invalide les prérequis
6.1 le système maintient le bouton « j’apprends » verrouillé

4.2.1.8 Analyse du sprint 2

Diagramme de cas d’utilisation du sprint

La figure 26 présente le diagramme de cas d’utilisation du sprint 2 pour nous permettre de


représenter les fonctionnalités concernées tout au long de notre second sprint.

49
Chapitre 4. Résultats

Figure 26 : Diagramme de cas d'utilisation Sprint 2

Description textuelle des cas d’utilisation

• Description textuelle du cas d’utilisation « lire la vidéo sur la pose des filets »

Tableau 13 : Description textuelle du cas « lire la vidéo sur la pose des filets »

Titre Lire la vidéo sur la pose des filets


Acteur principal Elève
Résumé Vidéo explicative permettant de se protéger contre les
éboulements
Précondition Application lancée, vidéo non lue
Scénario Nominal 1. Ouvrir l’application
2. L’élève clique sur j’apprends
3. Le système ouvre la page d’apprentissage
4. L’élève clique sur le bouton « les éboulements »
5. Le système ouvre la page sur les éboulements
6. L’élève clique sur le boutons « la pose des filets »
7. Le système charge la vidéo sur la pose des filets
8. L’élève clique sur « jouer »
9. Le système démarre la vidéo

50
Chapitre 4. Résultats

Postcondition Vidéo lue


Scénario alternatif 8.1 L’élève clique sur pause
8.2 L’élève clique sur arrête
9.1 le système arrête la vidéo
9.2 le système met la vidéo en pause

• Description textuelle du cas d’utilisation « lire résumé sur les affaissements »

Tableau 14: Description textuelle sur le cas "lire résumé sur les affaissements"

Titre Lire résumé sur les affaissements


Acteur principal Elève
Résumé Résumé sur les affaissements et ses techniques de protection
Précondition Application lancée, résumé non lu
Scénario Nominal 1. Ouvrir l’application
2. L’élève clique sur j’apprends
3. Le système ouvre la page d’apprentissage
4. L’élève clique sur le bouton « les affaissements »
5. Le système ouvre la page sur les affaissements
6. L’élève clique sur le boutons « je retiens »
7. Le système ouvre le résumé
Postcondition Résumé lu

• Description textuelle du cas d’utilisation « s’exercer sur les glissements »

Tableau 15: Description textuelle sur le cas "s'exercer sur les glissements"

Titre S’exercer sur les glissements


Acteur principal Elève
Résumé Evaluation formative sur les glissements
Précondition Application lancée,
Scénario Nominal 1. Ouvrir l’application
2. Cliquer sur j’apprends
3. Le système ouvre la page d’apprentissage
4. Cliquer sur le bouton « les glissements »

51
Chapitre 4. Résultats

5. Le système ouvre la page sur les glissements


6. Cliquer sur le boutons « QUIZZ »
7. Le système lance le Quizz
8. L’élève répond aux questions
9. Le système affiche « succès »
Postcondition Exercice effectué
Scénario nominal 8.1 l’élève rate une question
9.1 le système affiche « échoué »

4.2.1.9 Analyse du sprint 3

Diagramme de cas d’utilisation du sprint

La figure 27 présente le digramme des cas d’utilisation du sprint 3 pour nous permettre de
représenter les fonctionnalités concernées dans notre troisième sprint.

Figure 27 : Diagramme de cas d'utilisation du sprint 3

52
Chapitre 4. Résultats

Description textuelle des cas d’utilisation

• Description du cas d’utilisation « s’exercer au Matching »

Tableau 16 : Description du cas d’utilisation « s’exercer au Matching »

Titre S’exercer au Matching


Acteur principal Elève
Résumé Associer les éléments correspondants
Précondition Application lancée, internet connecté
Scénario Nominal 1. Ouvrir l’application
2. Cliquer sur j’apprends
3. Le système ouvre la page d’apprentissage
4. Cliquer sur le bouton « Exercices »
5. Le système ouvre la page des exercices
6. Cliquer sur le boutons « Matching »
7. Le système lance l’exercice
8. Le client s’exerce
9. Le système affiche le résultat succès
Postcondition Exercice effectué
Scénario alternatif 8.1 l’élève rate une question
9.1 le système affiche échec
9.2 le système invite l’élève à recommencer

• Description du cas d’utilisation « jouer au pendu »

Tableau 17 : Description du cas d’utilisation « jouer au pendu »

Titre Jouer au pendu


Acteur principal Elève
Résumé S’amuser en trouvant le mot correspondant
Précondition Application lancée, internet connecté
Scénario Nominal 1. Ouvrir l’application
2. Cliquer sur j’apprends
3. Le système ouvre la page d’apprentissage

53
Chapitre 4. Résultats

4. Cliquer sur le bouton « Jeux »


5. Le système ouvre la page des jeux
6. Cliquer sur le boutons « Le pendu »
7. Le système lance le jeu
8. L’élève joue
9. Le système affiche félicitation
Postcondition Jeu lancé
Scénario alternatif 8.1 l’élève rate une question
9.1 le système affiche que l’élève a échoué

4.2.2 La phase de conception, de planification et d’estimation

4.2.2.1 Conduire la planification des versions

Après avoir établit le backlog du produit, il est donc question par la suite de tenir une réunion
pour la planification du produit. Le but de cette réunion est de construire le backlog de sprint
en se basant sur le backlog de produit réalisé par le Product Owner. Enfin, nous avons identité,
les durées prévisionnelles du travail à exécuter durant chaque sprint. Pour notre projet nous
avons devisé le travail sur deux releases (versions). La première contient deux sprints d’une
durée de 03 jours et deux semaines, la deuxième contient un sprint d’une durée d’une semaine.

La figure 28 montre la planification des sprints de notre système.

Figure 28: Planning des sprints

54
Chapitre 4. Résultats

4.2.2.2 La navigation de l’application

Pour pouvoir exprimer la navigation et le lien entre les différentes pages, la figure 29 représente
le diagramme de navigation de l’application.

Figure 29 : Diagramme de Navigation du système

4.2.2.3 Le déploiement de l’application

La vue déploiement décrit les ressources matérielles et la répartition des parties du logiciel. La
figure 30 présente le diagramme de déploiement du logiciel. Elle correspond à la description de
l’environnement d’exécution et la façon dont les composant y sont installés.

Figure 30 : Diagramme de déploiement du système


55
Chapitre 4. Résultats

4.2.2.4 Prototypage des interfaces

Le prototypage ou maquettage est une étape importante. Elle permet de préparer les futurs
interfaces du produit. Elle est réalisée en présence du Product Owner et destinée à l’équipe
développement.

La figure 31 présente la maquette de la page d’accueil

Figure 31: Maquette de la page d'accueil


La figure 32 présente la maquette du menu principal

Figure 32: Maquette menu d'apprentissage

56
Chapitre 4. Résultats

La figure 33 présente la maquette de l’interface sur les éboulements

Figure 33 : Maquette de l‘interface sur les éboulements

La figure 34 présente la maquette de jeux

Figure 34: Maquette interface Jeux

57
Chapitre 4. Résultats

4.2.2.5 Conception du sprint 1

4.2.2.5.1 Backlog du sprint 1

Après les étapes d’estimation, de raffinage des user stories et de découpage en taches, nous
obtenons dans le tableau ci-dessous le backlog du sprint 1

Tableau 18 : Backlog du sprint 1

ID User Story Taches Priorité Effort


1 En tant que Bob je veux Ajouter la page des objectifs 1 2
lire les objectifs Charger le contenu dans la page 1 1
2 En tant que Bob je veux Réaliser le test 2 4
tester mes prérequis Charger les questions du test 2 2
3 En que Bob je veux lire Ajouter la page de rappels 2 2
les rappels Charger le contenu de la page 2 1
4 En tant que Bob je veux Consulter l’aide 2 1
lire les rappels

4.2.2.5.2 Diagrammes de séquences du sprint 1

Le digramme de séquence détaillé permet de décrire les interactions avec les objets de façon
chronologique. Nous présenterons uniquement dans le sprint 1 le diagramme de séquence du
cas d’utilisation « tester les prérequis ».

L’option « tester les prérequis » apparait au lancement du programme. Il a pour but d’évaluer
les connaissances requises chez l’apprenant. Ainsi cette option est obligatoire pour pouvoir
accès au menu d’apprentissage de l’application qui, reste verrouillé jusqu’au succès du test par
l’enfant.

La figure ci-dessous présente le diagramme de séquence du cas d’utilisation « tester les


prérequis »

58
Chapitre 4. Résultats

Figure 35 : Diagramme de séquence du cas "tester les prérequis"

4.2.2.6 Conception du sprint 2

4.2.2.6.1 Backlog du sprint 2

Le tableau 14 présente le backlog du sprint 2


Tableau 19: Backlog sprint 2

ID User story Taches Priorité Effort


5 En tant que Bob je Réaliser la vidéo sur les affaissements 1 4
veux lire les vidéos
sur les techniques Réaliser la vidéo sur les éboulements 2 4
de prévention Réaliser la vidéo sur les coulées boueuses 3 4
Réaliser la vidéo sur les retraits-gonflements 4 4
Réaliser la vidéo sur les glissements 5 4
6 En tant que Bob je Réaliser les notes sur les affaissements 1 2
veux lire chaque Réaliser les notes sur les éboulements 2 2
note à retenir sur Réaliser les notes sur les coulées boueuses 3 2
les risques liés aux Réaliser les notes sur les retraits-gonflements 4 2
accidents Réaliser les notes sur les glissements 5 2

59
Chapitre 4. Résultats

7 En tant que Bob je Réaliser la page 1 1


veux lire le résumé Charger le résumé 2 1
global
8 En tant que Bob je Réaliser la page 1 2
veux lire le Charger le glossaire 2 1
glossaire
9 En tant que Bob je Réaliser la page 1 2
veux consulter Chargé l’aide 2 1
l’aide
10 En tant que Bob je Réaliser l’exercice sur les affaissements 1 4
veux m’exercer sur Réaliser l’exercice sur les éboulements 2 4
chaque accident Réaliser l’exercice sur les coulées boueuses 3 4
Réaliser l’exercice sur les retraits- 4 4
gonflements
Réaliser l’exercice sur les glissements 5 4

4.2.2.6.2 Diagrammes de séquences du sprint 2


Après avoir terminé le diagramme de cas d’utilisation du deuxième sprint, nous passons à la
présentation des diagrammes de séquence.

• Diagramme de séquence du cas d’utilisation « lire une vidéo »

La figure 36 illustre le diagramme de séquence du cas d’utilisation.

60
Chapitre 4. Résultats

Figure 36 : Diagramme de séquence du cas "lire une vidéo "

• Diagramme de séquence du cas d’utilisation « s’exercer sur les glissements »

Figure 37 : Diagramme du cas d'utilisation « s’exercer sur les glissements"

61
Chapitre 4. Résultats

4.2.2.7 Conception du sprint 3

4.2.2.7.1 Backlog du sprint 3

Le tableau 18 présente le backlog du sprint 3


Tableau 20 : Backlog du sprint 3

ID User story Tâche Priorité Effort


11 En tant que Bob je veux Réaliser le quizz 8 4
traiter les Quizz Charger les questions 1
12 En tant que Bob je veux Réaliser le Matching 8 4
traiter les Matching Charger les correspondances 1
13 En tant que Bob je veux Réaliser l’exercice 8 6
traiter les questions à Charger le contenu 2
trou
14 En tant que Bob je veux Réaliser le pendu 9 6
jouer au pendu Charger les questions 2
15 En tant que Bob je veux Réaliser la grille 9 6
jouer au mot caché Charger les questions 2
16 Jouer au millionnaire Réaliser le jeu 9 6
Charger les questions 2

4.2.2.7.2 Diagrammes de séquences du sprint 3

• Diagramme de séquence du cas d’utilisation « jouer au pendu »

62
Chapitre 4. Résultats

Figure 38 : Diagramme de séquence du cas "jouer au pendu"

• Diagramme de séquence du cas d’utilisation « jouer au millionnaire »

Figure 39 : Diagramme de séquence du cas d'utilisation du cas "jouer au millionnaire"

63
Chapitre 4. Résultats

4.2.3 La phase d’implémentation ou de réalisation

4.2.3.1 Réalisation du sprint 1

Cette partie est consacrée à la présentation du travail achevé à la fin du sprint 1, à travers
des captures d’écran de quelques interfaces développées pendant ce sprint.

La figure suivante présente le burndown chart du sprint 1

Burndown Chart Sprint 1


14
12
10
8
6
4
2
0
0 1 2 3

Idéal Réalisé

Figure 40 : Burndown Chart Sprint 1

Interface des objectifs


La figure suivante présente l’interface des objectifs du didacticiel.

Figure 41 : Interface des objectifs

64
Chapitre 4. Résultats

Interface du test de prérequis


La figure suivante présente l’interface du test de prérequis du didacticiel.

Figure 42 : interface du test de prérequis

4.2.3.2 Réalisation du sprint 2

Dans cette section, nous présentons les différentes captures interfaces de l’application. Il s’agit
ainsi de représenter les interfaces obtenues à la fin du sprint 2.

La figure suivante présente le burndown Chart du sprint 2

Burndow Chart Sprint 2


60

50

40

30

20

10

0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Idéal Réalisé

Figure 43 : Burndown Chart sprint 2

65
Chapitre 4. Résultats

Interface de la page d’apprentissage


La figure suivante illustre la page d’apprentissage du système

Figure 44 : Interface d'apprentissage

Interface de lecture sur les éboulements


La figure suivante présente la page de lecture sur les éboulements.

Figure 45 : Interface de lecture sur les éboulements


Interface de test sur les éboulements
La figure suivante présente l’interface du test sur les éboulements

66
Chapitre 4. Résultats

Figure 46 : interface de test sur les éboulements

4.2.3.3 Réalisation du sprint 3


Nous présentons quelques captures d’interfaces obtenues à la fin du sprint 3.

Burndown Chart du sprint 3


La figure suivante présente le burndown Chart du Sprint 3

Burndown Chart sprint 3


45
40
35
30
25
20
15
10
5
0
0 1 2 3 4 5 6 7

Idéal Réalisé

Figure 47 : Burndown Chart Sprint 3

67
Chapitre 4. Résultats

Interface de la page exercices


La figure suivante présente l’interface des exercices

Figure 48 : interface des exercices

Interface du pendu
La figure suivante présente l’interface du jeu « Le mot caché »

Figure 49 : Interface du jeu "le mot caché"


Interface du millionnaire

68
Chapitre 4. Résultats

La figure suivante présente l’interface du jeu « le millionnaire »

Figure 50 : Interface du jeu "le millionnaire"

4.2.4 La phase de tests

4.2.4.1 Test et rétrospection du sprint 1

Le test de logiciel vise à garantir le bon fonctionnement du système. Par conséquent avant la
fin du sprint il est important de tester le module et vérifier que les actions sont conformes aux
besoins fixés au départ du sprint dans le Backlog. Le tableau suivant décrit le scénario des tests
effectué sur le sprint 1.

Tableau 21: Scénario de test du sprint 1

Cas de test Démarche Comportement attendu Résultats


Test de lecture Afficher les objectifs Liste des objectifs Conforme
des objectifs
Test de lecture Afficher les rappels Contenu des rappels Conforme
des rappels affiché
Test sur le test Effectuer une - Test validé ou échoué Conforme
des prérequis simulation de test - Présentation des
questions ratées

69
Chapitre 4. Résultats

- Déverrouillage du
menu apprentissage en
cas de réussite
Test de l’aide Afficher l’aide Contenu de l’aide Conforme
affiché

Cette étape marque la fin du sprint 1. Tous les tests effectués étant positifs, nous entamons le
deuxième sprint.

4.2.4.2 Test et rétrospection du sprint 2

Le tableau suivant décrit le scénario de test appliqué sur le sprint 2

Tableau 22 : Scénario de test du sprint 2

Cas de test Démarche Comportement attendu Résultats


Test de lecture Lire les vidéos Lire les vidéos Non Conforme
des vidéos
Test de lecture Afficher les Contenu des résumés Conforme
des résumés résumés affiché
Test sur le test Effectuer une - Affichage de toutes les Conforme
des Quizz simulation de test questions
- Affichage du résultat
- Présentation des questions
erronées
Test sur le Afficher le - Contenu affiché Conforme
« retenons » « retenons »
Test sur le Afficher le - Glossaire affiché Conforme
glossaire glossaire

Cette étape marque la fin du sprint 2. Tous les tests effectués étant positifs, nous entamons le
troisième sprint.

4.2.4.3 Test et rétrospection

Le tableau suivant décrit le scénario de test appliqué sur le sprint 3

70
Chapitre 4. Résultats

Tableau 23: Scénario de test du sprint 3

Cas de test Démarche Comportement attendu Résultats


Test des exercices Effectuer l’exercice Afficher le résultat correct Conforme
Test du Matching Effectuer l’exercice Afficher le résultat correct Conforme
Test des questions Effectuer l’exercice Afficher le résultat correct Conforme
à trou
Test du pendu Jouer Afficher le résultat correct Conforme
Test du mot caché Jouer Afficher le résultat correct Conforme
Test du Jouer Afficher le résultat correct Conforme
millionnaire

Nous sommes ainsi à la fin du sprint 3 et il est donc question de soumettre l’application
développée à un ensemble d’utilisateurs pour en tester les impressions.

4.2.5 La phase de production

Le Test d’expérience utilisateur


Dans cette section il est question de recueillir les résultats de l’expérience utilisateur. Il
est important d’obtenir les avis de quelques clients sur l’application avant son déploiement.
Pour cela nous allons utiliser un questionnaire pour ressortir le niveau d’utilisabilité du client.
Nous rappelons que le questionnaire choisi dans la section 2.6.2 était le questionnaire SUS pour
son implémentation facile. Le questionnaire utilisé est retrouvé en annexe 3 du document.
Le test a été effectué sur 36 élèves en classe de 4e au Collège Vogt.
Le score SUS d’un individu est calculé de la manière suivante :
Pour les questions/affirmations impaires (1, 3, 5, 7 et 9), vous devez soustraire 1 au résultat
donné par le répondant. Si le répondant répond 4, le score correspondant est 3 (4-1).
Pour les questions/affirmations paires (2, 4, 6, 8 et 10), le score est égal à 5 moins le score
donné par le répondant. Si le répondant répond 3, le score est de 2 (5-3).
Une fois que vous avez calculé le score de toutes les questions/affirmations, vous devez faire
le total et multiplier ce total par 2,5. Vous obtenez ainsi le score SUS compris entre 0 et 100.

Après analyse nous, nous avons obtenu un score moyen de 73,8%. Ce qui permet d’évaluer le
niveau d’utilisabilité de l’application comme Bien.

71
Chapitre 5. Discussions et implications

CHAPITRE 5 : DISCUSSIONS ET IMPLICATIONS

Dans ce chapitre, il est question de discuter de nos résultats obtenus par rapport à nos recherches
faites sur nos différentes questions de recherches. Puis il s’agit de montrer l’implication
pédagogique de notre travail dans le processus enseignement- apprentissage Camerounais.

5.1 Discussions

5.1.1 Difficultés liées à l’apprentissage des mouvements de terrain

Les résultats de l’enquête effectuée sur le terrain nous ont permis de ressortir bon nombre de
problèmes chez les apprenants. En effet 64% de la population par exemple présentent des
difficultés à se représenter les phénomènes liés aux mouvements de terrain. Cette information
nous a permis de concentrer beaucoup nos contenus sur les animations et les vidéos, pour que
les enfants s’imaginent mieux les différents phénomènes liés aux mouvements de terrain. Par
ailleurs nous avons ressorti que 52% ont des difficultés à choisir des sites favorables aux
constructions. Ceci est dû à une faible connaissance des mesures de prévention contre les
mouvements de terrain. C’est pour cette raison que nos contenus font uniquement référence aux
techniques de prévention et de protection contre les mouvements de terrain.

5.1.2 Styles d’apprentissage préférés des apprenants dans un didacticiel

Pour ce qui a trait aux styles d’apprentissages, il a été relevé durant notre recherche
documentaire que les apprenants manifestent beaucoup plus d’enthousiasme et de motivation
quand il s’agit d’apprendre avec un outil informatique. Cet élément a été vérifié lors de l’analyse
de notre questionnaire. En effet, sur les 180 élèves que constituait notre population d’enquête
132 élèves pensent qu’apprendre avec un logiciel leur permettrait d’apprendre mieux, soit 73,33
% de la population étudiée.

Par ailleurs nous avons aussi relevé que les élèves préfèrent des couleurs qui frappent et qui
ressortent. Cela se justifie par le fait que 76 élèves soient 60% de la population souhaitent avoir
des couleurs claires dans l’application. Raison pour laquelle nous avons optés pour des couleurs
orange et verte.

72
Chapitre 5. Discussions et implications

5.1.3 Les impressions des élèves après l’utilisation du didacticiel

Le test utilisateur final effectué à la phase de production avait pour but de rechercher les
impressions des élèves après l’utilisation du didacticiel. Nous avons pu remarquer que suite à
l’évaluation de l’application, le score d’utilisabilité de notre application est de 73% ; ce qui
nous permet de dire que notre application est utilisable.

5.1.4 Limites de l’étude

A notre niveau nous avons pu ressortir les limites suivantes :


• La taille de la population étudiée n’est pas représentative. Pour avoir choisi une méthode
quantitative, il est important de s’assurer que la taille de la population d’enquête soit
représentative par rapport à la population cible.
• Les tests d’expérience utilisateur effectués sur le terrain se sont faits sur un échantillon
très réduit.
• L’application développée ne permet pas un suivi particulier de l’élève comme préconisé
parmi les styles d’apprentissages préférés par les élèves.
• L’application ne permet pas une modification des contenus par un enseignant. Ce qui
limite la personnalisation des enseignements.
• L’échelle d’utilisabilité choisie pour tester l’expérience des utilisateurs ne nous permet
pas de ressortir les problèmes ergonomiques précis de notre application afin de faciliter
la maintenance.

5.1.5 Difficultés rencontrées

Les principales difficultés ont été rencontrées pendant la phase de collecte des données. Déjà il
faut noter que le cours qui constitue notre thème d’étude se trouve à la fin des programmes
scolaire de SVTEEHB. Par conséquent beaucoup d’établissements parfois ne le font pas faute
de temps. Ce qui a réduit considérablement les choix d’établissements pour effectuer l’enquête.
Par ailleurs l’accès à certains enseignants s’est trouvé très difficile. Ceci à cause du caractère
réfractaire qu’ont certains et le manque d’importance qu’ils accordent à cette étude. Sans
toutefois oublier la disponibilité de ces derniers.
De plus nous notons des difficultés dans l’application de la méthodologie logicielle choisie qui
est Scrum. Nous avons eu beaucoup de difficultés dans la compréhension et l’application des
différentes phases de scrum. C’est-à-dire utiliser les outils préconisés pour ressortir les résultats

73
Chapitre 5. Discussions et implications

attendus. De par son fonctionnement qui diffère complètement des méthodes classiques, il
fallait s’habituer à travailler avec une nouvelle méthode qui d’après l’expérience acquise
produit beaucoup plus d’efficacité.

5.2 Implications pédagogiques

Les chapitres qui précèdent nous ont permis de mettre sur pied un outil d’aide à
l’apprentissage des accidents liés aux mouvements de terrain. Diaccmout (Didacticiel sur les
Accidents liés aux Mouvements de Terrain) se range ainsi dans le cadre de l’enseignement
assisté par ordinateur. IL a pour but de présenter un ensemble de techniques de protection contre
les accidents liés à certains mouvements de terrain. Nous présenterons les implications sur le
volet enseignement et sur le volet apprentissage.

5.2.1 Pour l’apprenant

Le logiciel développé favorise une multiplicité des styles d’apprentissage. A travers les
images, les sons et les vidéos, chaque catégorie d’apprentissage est représentée c’est-à-dire, les
enfants qui aiment lire, les enfants qui aiment écrire et les enfants qui aiment écouter. Il est
important de mettre un accent sur la diversité des exercices proposés et l’aspect ludique de
l’application. Ceci dans le but d’entretenir la motivation chez les apprenants. L’approche
utilisée par Diaccmout est une approche basée sur les compétences. Il vise à développer les
compétences chez les enseignants en leur apportant un ensemble de savoirs, de savoirs-être et
de savoir-faire, leur permettant de lutter efficacement contre les accidents liés aux mouvements
de terrain.

5.2.2 Pour l’apprenant

Diaccmout est une application servant aussi d’outil d’aide à l’enseignement. En effet, le logiciel
peut être utilisé par un enseignant comme outil d’appui dans son processus. Pour les
établissements possédant un centre de ressource multimédia, l’application peut être installé en
réseau dans un serveur et partagé aux différents élèves. Le test de prérequis implémenté
permettrait de vérifier les rappels avant de débuter la leçon. Les vidéos contenues dans
l’application permettraient de renforcer l'action pédagogique. Diaccmout représente donc ainsi
un matériel qui accompagne l’enseignant dans sa tâche.

74
Conclusion et perspectives

CONCLUSION ET PERSPECTIVES

Il était initialement question pour nous de concevoir et de développer un outil d’aide à


l’apprentissage sur les risques des accidents en zone montagneuse ou liés aux mouvements de
terrain en classe de 4e de l’enseignement secondaire général. Après une investigation profonde
dans le but de récolter les problèmes qu’ont les élèves dans ce cours ainsi que les préférences
qu’ils ont dans un didacticiel, nous avons pu développer Diaccmout (Didacticiel des accidents
liés aux mouvements de terrain) qui est un didacticiel proposant à l’enfant un ensemble de cours
vidéo, d’exercices variés, de jeux, d’animations et de notes. Pour en arriver là, nous avons
procédé tout d’abord par une décente sur le terrain afin de recueillir les informations nécessaires
à la mise sur pied de l’application. Puis nous avons mené la conception sur une méthodologie
agile qui est Scrum. Après la réalisation de l’application nous avons eu à effectuer un test auprès
de quelques élèves afin de recueillir des feedbacks. Face au problème que représente le manque
de ressources numériques dans l’enseignement secondaire, le présent travail offre ainsi une
solution de plus à travers l’application développée.

Comme perspectives, le Cameroun étant bilingue, nous envisageons une version anglaise
de l’application. Par ailleurs nous souhaitons mettre sur pied un espace de configuration pour
permettre à l’enseignant de pouvoir modifier les contenus des exercices ou des vidéos afin de
pouvoir personnaliser l’application. D’autre part, nous envisageons développer une partie
réseau pour permettre aux enfants de jouer à certains jeux en réseau comme le jeu du
millionnaire. Nous prévoyons aussi rendre l’application responsive pour qu’elle soit prise en
compte par n’importe quel écran.

En définitive de par les résultats obtenus, Diaccmout est donc une ressource qui
contribuera au renforcement du processus enseignement- apprentissage sur les risques des
accidents liés aux mouvements de terrain.

75
BIBLIOGRAPHIE

1. Andres, B. &. (2004). Extreme Programming Explained: Embrace Change (éd. 2th
edition). Addison-Wesley Professional.
2. Aubin-Auger, s., Alain Mercier, Laurence Baumann, Anne-Marie Lehr-Drylewicz,
Patrick Imbert, Laurent Letrilliart, & GROUM-F. (2008). Introduction à la recherche
qualitative. Exercer(84), pp. 142-5.
3. Bachelard. (1938). La formation de l'esprit scientifique.
4. Barrette, C. (2007). Réussir l'intégration pédagogique des TIC. Récupéré sur
http://clic.ntic.org/cgibin/aff.pl ?page=article&id=2020
5. Bastien, c. (2006). validation de critères ergonomiques pour l'évaluation d'interfaces
utilisateurs.
6. Bertin. (2001). Des outils et des langues : Multimédia et apprentissage. Paris: Ellipses
Edition Marketing.
7. Béziat, J. (2008). Les TICE et l'Europe. Des anéées 1970 aux années 1990.
8. Boterf, L. (1994). De la compétence, essai sur un attracteur étrange. Les éditions
d'organisation: Paris.
9. Brooke, J. (2013). SUS: A Retrospective. Journal of Usability Studies, 29-40.
10. C Orange. (1997). problème et modelisation en biologie. Paris: PUF.
11. Cockburn A. & Highsmith. (2001). Agile software development : The People Factor
»,.
12. Daniel, S. l. (1999). the seven sins of memory. Harvard University.
13. Gronier et Lallemand. (2015). Méthodes de design UX. (Eyrolles, Éd.)
14. Khalil, C. (2011). Les méthodes "agies" de management de projets informatiques :
une analyse "par la pratique". Paris.
15. Laurent, J. (2002). Une étude de cas sur l’utilisation de logiciels éducatifs au sein.
INRP-Tecne.
16. Lee. (2014).
17. lhoste, y. (2008). problematisation et apprentissage en science de la vie et de la terre.
18. Lonchamp, J. (2015). Analyse des besoins pour le développement logiciel. Recueil et
spécification, démarches ittératives et agiles. Parisa: Dunod.
19. M. Djeumeuni. (2010). Les pratiques pédagogiques des enseignants avec les TIC au
Cameroun entre politiques publiques et dispositifs techno-pédagogiques; compétences
des enseignants et compétences des apprenants; pratiques publiques et
pratiquesprivées. Université René Descartes - Paris V.

76
20. Morley. (2006). Management d'un système d'information (éd. 6). Dunod.
21. Paetsch F., E. A. (2003). Requirements engineering and agile software development »,
Proceedings of the IEEE International Workshops on Enabling Technologies:
Infrastructure for collaborative enterprises. Austria.
22. QUENEC'HDU, Y. (Jan 2013). Unofficial Scrum Guide. Slideshare.
23. Royce, W. (1970). Managing the development of large software systems Proc. IEEE
WESCON.
24. Samuel, N. (2017). Conception et réalisation d'un didacticiel sur les mouvements de la
terre et leurs conséquences pour la classe de troisième. Yaoundé.
25. Scrum Body Of Knowledge (SBOK guide) (éd. 2013 edition). (2013).
26. Sillitti A., C. M. (2005). « Managing uncertainty in requirements : a survey
documentation driven and agile companies », 11th IEEE International. (C. Society,
Éd.) 11th IEEE International .
27. Statistique Canada. (2003). Méthodes et pratiques d’enquête. ISBN 978-1-100-95206-
2( 12-587-X).
28. Van Royen. (décembre 2007). Cours d'introduction à la recherche qualitative. Institut
médécine tropicale de Bruxelles.
29. Vries, E. D. (2001). Les logiciels d'apprentissage: panoplie ou éventail? (I. N.
Pédagogique, Éd.) Revue française de pédagogie, 105-116.

77
ANN EXES

Annexe 1 : Questionnaire 1 adressé aux élèves

FICHE D’ENQUETE PEDAGOGIQUE CONCERNANT LE PROCESSUS ENSEIGNEMENT-


APPRENTISSAGE SUR LES ACCIDENTS LIES AUX MOUVEMENTS DE TERRAIN EN CLASSE DE
QUATRIEME

Ce questionnaire vise à déterminer vos attentes, vos opinions et habitudes en ce qui concerne
le processus enseignement-apprentissage des accidents liés aux mouvements de terrain en
classe de quatrième.
Les informations recueillies dans cette étude entrent dans un cadre d’étude académique et par
conséquent nous vous assurons de la confidentialité de l’identité de toute personne remplissant
ce questionnaire. Nous vous tiendrons informés des résultats de ladite enquête.
Identité de l’élève
1. Etablissement fréquenté ……………………………………………………………
2. Âge ………………………………………
3. Quel est votre sexe F M
4. Etes-vous redoublant ? Oui Non
Consigne : Cochez la case qui vous convient.
Tableau 24 : Table d’enquête 1- élève

Items Pas du Pas Très


tout D’accord Neutre D’accord d’accord
d’accord
1. Le cours est très long
2. Les leçons sont difficiles à
comprendre
3. Les schémas sont complexes
à interpréter
4. Les photos ne sont pas
souvent claires et
compréhensibles
5. Le vocabulaire utilisé dans
les leçons est difficile
6. Je n’arrive pas à faire de lien
entre les différentes parties
du cours
7. Je n’étudie pas assez
8. Je ne rencontre pas beaucoup
les notions que j’apprends
dans la vie courante

78
9. J’ai des difficultés à identifier
les déformations des couches
de terrain et leurs causes
10. J’ai des difficultés à me
représenter les phénomènes
de mouvement de terrain tels
que les glissements, les
effondrements, les coulées
boueuses, le retrait-
gonflement.
11. Je suis incapable d’identifier
des techniques de prévention
et de protection des accidents
liés aux mouvements de
terrain
12. J’ai des difficultés à choisir
des sites favorables aux
constructions de maison
13. Apprendre avec un logiciel
m’aidera davantage à
comprendre des phénomènes
liés aux mouvements de
terrain
14. Je préfère beaucoup plus
d’activités pratiques dans les
cours
15. Je préfère apprendre en
jouant
16. Je préfère des couleurs claires
17. Je préfère utiliser des cours
audio/vidéos
18. Je préfère utiliser plus
d’images
19. Je préfère des résumés de
cours

Annexe 2 : Fiche d’entretien avec les enseignants

FICHE D’ENTRETIEN PEDAGOGIQUE CONCERNANT LE PROCESSUS ENSEIGNEMENT-


APPRENTISSAGE SUR LES ACCIDENTS LIES AUX MOUVEMENTS DE TERRAIN EN CLASSE DE
QUATRIEME

1. Quelles sont vos activités dans le cadre de votre fonction ? Indiquez pour chacune le
niveau de maîtrise : très facile, facile, difficile, très difficile
2. Depuis combien d’années exercez-vous en tant qu’enseignant de SVT ?

79
3. Tenez-vous ou avez-vous tenue une classe de 4e ? Si oui depuis ou pendant combien de
temps ?
4. Avez-vous déjà enseigné le cours sur les risques des accidents en zone montagneuse ?
5. Combien de temps dure ce cours ?
6. Avez-vous des difficultés dans la transmission de ce cours ? si oui lesquelles ?
7. Selon vous, les élèves rencontrent-ils des difficultés dans ce cours ? si oui lesquelles ?
8. Que proposerez-vous pour palier à ces problèmes ?
9. Pensez-vous qu’un didacticiel pourrait aider dans l’apprentissage de ce cours ?
10. Quelles orientations proposerez-vous quant à la mise sur pied d’un didacticiel dans
cette leçon ?

Annexe 1 : Questionnaire 2 adressé aux élèves


FICHE D’ENQUETE PEDAGOGIQUE CONCERNANT LE PROCESSUS ENSEIGNEMENT-
APPRENTISSAGE SUR LES ACCIDENTS LIES AUX MOUVEMENTS DE TERRAIN EN CLASSE DE
QUATRIEME

Ce questionnaire vise à déterminer vos impressions après l’utilisation d’un didacticiel d’aide à
l’apprentissage des accidents liés aux mouvements de terrain en classe de 4e
Les informations recueillies dans cette étude entrent dans un cadre d’étude académique et par
conséquent nous vous assurons de la confidentialité de l’identité de toute personne remplissant
ce questionnaire. Nous vous tiendrons informés des résultats de ladite enquête.
Identité de l’élève
1. Etablissement fréquenté ……………………………………………………………
2. Âge ………………………………………
3. Quel est votre sexe F M
4. Etes-vous redoublant ? Oui Non
Consigne : Choisir le niveau correspondant
Tableau 25 : Table questionnaire SUS

Avis 1 2 3 4 5

1. Je pense que j’aimerais utiliser ce logiciel fréquemment

2. J’ai trouvé ce système complexe

3. J’ai trouvé ce système facile à utiliser

80
4. Je pense que j’ai besoin d’un support technique pour
l’utiliser
5. J’ai trouvé que les différentes fonctions étaient bien
intégrées
6. J’ai trouvé qu’il y’avait trop d’incohérence

7. Je suppose que la plupart des gens apprendraient très


rapidement à utiliser ce système
8. J’ai trouvé ce système très contraignant à utiliser

9. Je me suis senti très confiant en utilisant ce système

10. J’ai dû apprendre beaucoup de choses avant de me sentir


familiarisé avec ce logiciel

81

Vous aimerez peut-être aussi